DGX Station GB300 specs top out at 748GB of coherent memory on a single GPU-and-CPU pair: 252GB of HBM3e on one B300 Blackwell Ultra GPU, plus 496GB of LPDDR5X on its Grace CPU, joined by a 900 GB/s NVLink-C2C link. Every spec sheet covering this box repeats that 748GB figure as a bullet point and moves on. None of them run it through an actual fine-tuning VRAM formula to say which real open models fit, and which don't, or ask what actually breaks first once a job gets big enough to need more than one GPU.
TL;DR: What Do DGX Station GB300 Specs Mean for Fine-Tuning?
- Memory: DGX Station GB300 packs 252GB HBM3e GPU memory plus 496GB LPDDR5X CPU memory for 748GB coherent memory, per NVIDIA's spec sheet.
- Full fine-tuning ceiling: this site's VRAM formula caps full fine-tuning at roughly 61B dense parameters (about 745.75GB) before Adam's optimizer states exceed the box.
- LoRA ceiling: standard BF16 LoRA reaches roughly 337B dense parameters, short of Llama 3.1 405B, whose BF16 weights alone need about 810GB.
- QLoRA headroom: a 4-bit pass over a 671B-total MoE model like DeepSeek-V3 needs only around 335GB for weights, well inside the 748GB pool.
- Spheron rents standalone B300 on-demand and reserves GB300 NVL72 for jobs past one Superchip's single GPU. Compare GB300 NVL72 reservations.
DGX Station GB300 Specs: Memory Architecture With HBM3e Plus LPDDR5X
A DGX Station GB300 is one GB300 Superchip, not a rack: one B300 Blackwell Ultra GPU paired with one 72-core Grace CPU over a coherent memory fabric. NVIDIA's own spec sheet lists 252GB of HBM3e running at 7.1 TB/s on the GPU side, plus 496GB of LPDDR5X on the CPU side, for 748GB that both processors can address without a copy step.
| Component | Capacity | Bandwidth |
|---|---|---|
| GPU memory (B300 Blackwell Ultra) | 252GB HBM3e | 7.1 TB/s |
| CPU memory (Grace, 72-core) | 496GB LPDDR5X | shares the pool over NVLink-C2C |
| Total coherent memory | 748GB | 900 GB/s NVLink-C2C link between the two |
On compute, NVIDIA rates the DGX Station GB300 at up to 20 petaFLOPS of FP4 with sparsity, with ConnectX-8 SuperNIC networking up to 800 Gb/s and power draw as high as 1,600W on a dedicated 20A circuit, a provision most office desks don't have without an electrician first. A hands-on review of the MSI XpertStation WS300, a certified DGX Station GB300 build, independently landed on the same two headline numbers: its title alone reads "748GB of Coherent Memory and 20 PetaFLOPS on a Desk". The only confirmed purchase price anywhere is $85,000, at MSI.
That 7.1 TB/s HBM3e figure against 396 GB/s typical for LPDDR5X also matters once a job's working set grows past the 252GB sitting in fast GPU memory; the section below on where this box falls short picks that gap back up. For the same formula run at a tenth the scale, DGX Spark's 128GB unified memory hits a much lower ceiling on a much smaller GB10 chip.
What Fits at Full Precision: LoRA Fine-Tuning Up to Roughly 340B Parameters
Run this site's own fine-tuning VRAM formula, weights plus gradients plus optimizer state plus activations, against the Station's 748GB pool instead of a discrete GPU's VRAM, and standard LoRA at a BF16 base is the method that gets furthest. It holds up to roughly 337B dense parameters before the pool runs out, nearly six times the ceiling full fine-tuning hits on the same hardware.
| Method | What it stores | Dense parameter ceiling on 748GB |
|---|---|---|
| Full fine-tuning | weights + gradients + Adam's two FP32 moment buffers + activations | ~61B |
| Standard LoRA (BF16 base) | frozen base weights + a small adapter, its gradients, and its optimizer state | ~337B |
| QLoRA (4-bit NF4 base) | quantized base weights + adapter overhead on active parameters only | scales with active, not total, parameters on sparse MoE models |
The source formula's own numbers show why LoRA gets so much further. Stretch each rate out to 748GB and full fine-tuning lands around 60.9B parameters; LoRA's much lighter per-parameter cost carries it to roughly 337B before the pool runs dry.
That 337B ceiling puts a real decision in front of whoever is picking a model. Llama 3.1 405B sits past the line entirely: Meta's own announcement puts the model at 405B parameters, and its BF16 weights alone need roughly 810GB, more than the Station's entire 748GB pool before a single gradient or optimizer byte gets added. There's no LoRA trick that closes that gap, because the base weights themselves don't fit in the first place.
Quantization is what gets a model that size back into range, provided it's also sparse. DeepSeek-V3 is a 671B-total-parameter MoE model with only 37B parameters activated per token (1 shared expert plus 8 of 256 routed experts), per its own technical report. Quantized to 4-bit NF4, its weights need only around 335GB, comfortably inside the 748GB pool with the adapter, gradient, and optimizer overhead for its 37B active parameters still to add on top. That's the practical ceiling-breaker on this hardware: a 671B-total model is unworkable in BF16 on anything short of a multi-GPU cluster, but a sparse architecture plus 4-bit quantization brings it inside what fits on one desk-side GPU. For the expert-parallel mechanics that determine how those active parameters actually train, see our MoE fine-tuning and expert parallelism guide.
Where DGX Station GB300 Specs Still Fall Short: Full Fine-Tuning's Lower Ceiling, Long Context, and No Second GPU
Full fine-tuning's ceiling is the one number here that looks unimpressive next to LoRA's. The same formula clears 748GB at around 61B dense parameters, specifically about 745.75GB at the 60.9B solve point, leaving less than 3GB of the entire coherent pool free for activations, data loading, and anything else the OS needs while the job runs. The gap between the two methods isn't a quirk of this particular box: Adam's optimizer state costs 8 bytes per trainable parameter in full fine-tuning against almost nothing extra in LoRA, since LoRA only ever trains and stores state for a small adapter, never the base model. Our GPU-hours comparison of LoRA against full fine-tuning on a 70B model found the identical gap on rented H100s: LoRA fits on 2 GPUs where full fine-tuning needs 11, for the same reason the optimizer state scales with every parameter instead of just the adapter.
Dense open models at 70B already cross that 61B line. Llama 3.3 70B needs roughly 860GB for a full fine-tune by the same formula, more than the entire Station holds, let alone leaves available for anything else running on the box.
None of that is really a memory story, though. The more structural ceiling is that a DGX Station GB300 has exactly one GPU in it. Every cloud workaround this site uses to fit a 70B full fine-tune, FSDP sharded across 11x H100 SXM5, or a 70B LoRA run split across 2x H100 SXM5 because no single H100 or H200 card holds the full base weights, depends on spreading state across multiple GPUs. The Station can't do that: there's no NVLink peer to shard onto, no second card to split the optimizer state across, and no way to add one without buying a second Superchip and finding a way to wire it in. A cloud cluster with the same total memory, split across several GPUs, handles a far larger model than this box can, because it can shard and this box cannot. The single-GPU ceiling here is the design's trade-off, not its memory's limit: 748GB on one chip buys offline, no-network iteration at the cost of ever adding a second GPU to the same job.
Long context compounds that same ceiling from a different angle. KV cache and activation memory grow with sequence length, and on a model already sitting near the Station's parameter ceiling, little of the 748GB pool is left to absorb a longer context window or a larger batch; the margin that's thin at 61B for full fine-tuning gets thinner the longer the sequences running through it. Every figure above is taken at the same batch-size-1, sequence-length-512 snapshot the source formula uses, a floor at the start of training rather than a guarantee across its full length.
DGX Station GB300 vs Renting GB300 NVL72 for the Same Fine-Tune
Buying one DGX Station GB300 and renting GB300-class capacity by the hour aren't really competing for the same job. The Station is one GPU; everything downstream of it, standalone B300 rental and GB300 NVL72 reservations, is sized in multiples of eight or seventy-two GPUs instead. Our GB300 vs B300 comparison covers that node-vs-rack distinction in more depth; this section applies it specifically to the desk-side Superchip.
| Option | GPUs | Memory | Access |
|---|---|---|---|
| DGX Station GB300 | 1 B300 Superchip | 748GB coherent (252GB HBM3e + 496GB LPDDR5X) | One-time purchase, $85,000 confirmed at MSI |
| Standalone B300 (Spheron) | 1 of 8 per node | 288GB HBM3e per GPU | On-demand $11.52/hr, spot $7.20/hr, billed per minute, no contract |
| GB300 NVL72 (Spheron) | up to 72 | 288GB HBM3e per GPU, 20TB per rack | Reservation, typical 24-48 hour turnaround, sized from one node up |
Worth flagging for honesty: the desk-side Superchip actually ships a smaller HBM3e bin than either cloud product. NVIDIA bins the GB300 NVL72 rack's GPUs at 288GB of HBM3e each. Same B300 silicon family, different memory binning, and a very different scale.
A job that fits inside the Station's own 748GB pool for LoRA or QLoRA, which by the math above covers almost every open dense model up to 337B and plenty of quantized MoE models well past that, has no reason to rent anything once the $85,000 is already spent; it just runs locally. Renting only enters the picture once a job exceeds what one Superchip holds, or needs the multi-GPU sharding the Station's single-GPU design can't do at any price. Standalone B300 is the fit for that first gap: a 70B full fine-tune, or anything that needs FSDP across a handful of GPUs but doesn't need a 72-GPU NVLink domain, books self-serve with no reservation cycle. A GB300 NVL72 reservation is the fit once the job's own expert-parallel group or NVLink domain genuinely needs to span more GPUs than a single node offers; Spheron prices that from a single node up rather than forcing a full 72-GPU commitment, though it's a quoted reservation rather than an instant checkout rate.
For the dollar math on when owning the Station actually pays back against renting GB300-class compute by the hour, our DGX Station GB300 price and break-even guide runs that same $85,000 figure against the only published GB300-class hourly rate anywhere.
Pricing fluctuates based on GPU availability. Spheron rates above are live as of 08 Nov 2026; other figures in this piece reflect their sources' most recently published data and may have changed since. Check current GPU pricing → for live rates.
A fine-tune that formula-fits inside the Station's own 748GB pool has no reason to leave the desk. Once it needs a second GPU, Spheron books standalone B300 by the minute and reserves GB300 NVL72 from a single node up.
Frequently Asked Questions
748GB of total coherent memory: 252GB of HBM3e on the B300 Blackwell Ultra GPU at 7.1 TB/s, plus 496GB of LPDDR5X on the Grace CPU, joined over a 900 GB/s NVLink-C2C link so both processors address the same pool without a copy step.
It depends on the method. Run this site's own VRAM formula against the Station's 748GB pool and standard BF16 LoRA reaches roughly 337B dense parameters, full fine-tuning tops out around 61B, and a quantized QLoRA pass over a sparse MoE model like DeepSeek-V3 (671B total, 37B active) needs only about 335GB for weights, leaving real room to spare.
Same B300 Blackwell Ultra silicon, different memory binning and a completely different scale. A GB300 NVL72 rack's GPUs carry 288GB of HBM3e each across 72 GPUs, while the single B300 GPU inside a DGX Station GB300 carries 252GB. One is a desk-side workstation with one GPU; the other is a 72-GPU rack. Confusing the two is the most common mistake in this search.
Not with standard LoRA or a full fine-tune. Llama 3.1 405B's BF16 weights alone need roughly 810GB, more than the Station's entire 748GB pool before a single gradient or optimizer byte is added. A model that size only becomes workable on this hardware if it is sparse and quantized, the way a 4-bit QLoRA pass over DeepSeek-V3's 671B total parameters fits because only 37B of them are active per token.







