Systems & Infrastructure
NVIDIA Infrastructure
FundamentalThe GPUs, racks, and networks that AI actually runs on - and how to match them to a workload.
Many jobs, one fabric
Almost everything in AI infrastructure exists to keep expensive GPUs busy. But “keeping them busy” means different things for different workloads - and the right hardware choice follows the workload, not the other way around. These are the major classes you will be sizing for:
Training
GB200/GB300 NVL72, H100/H200 clustersPretraining and large fine-tunes: thousands of GPUs in lockstep, bound by interconnect and memory.
Inference (serving)
H100/H200, B200/B300, L40S, RTX PRO 6000Serving tokens to users: memory-bandwidth bound in decode, latency-sensitive, scaled horizontally.
Reasoning / test-time compute
GB300/GB200 NVL72, B300, B200Long chain-of-thought models emit far more tokens per query. The workload Blackwell Ultra (FP4) is tuned for.
Fine-tuning
H100/H200 node, L40S, RTX PRO 6000LoRA/QLoRA and domain adaptation: far smaller footprint, often a single node.
Data processing & ETL
L40S, RTX PRO 6000, H100Curation, dedup, tokenization, and embedding generation at petabyte scale - increasingly GPU-accelerated (RAPIDS, NeMo Curator).
Simulation
L40S, RTX PRO 6000, B200Omniverse, digital twins, world models: mixed graphics + compute, RTX-class features matter.
HPC & scientific computing
H100/H200, GB200Weather, molecular dynamics, CFD: FP64-heavy simulation where double-precision throughput still decides the job.
The hardware shown is a representative sweet spot, not a limit - any modern data-center GPU can serve inference; the right one depends on model size, context length, and your latency and cost budget.
The GPU lineup
Three generations are in play today: Hopper (H100, H200), Blackwell (B200, GB200) and Blackwell Ultra (B300, GB300), with Ada Lovelace (L40S) and the RTX PRO 6000 covering inference, graphics, and simulation. Each generation moves the same three levers: more memory, more bandwidth, and faster links between GPUs.
H100
2022Hopper
- Memory
- 80 GB HBM3
- Bandwidth
- 3.35 TB/s
- NVLink/GPU
- 900 GB/s
- Per system
- 8 / HGX node
The training workhorse of the LLM boom.
H200
2024Hopper
- Memory
- 141 GB HBM3e
- Bandwidth
- 4.8 TB/s
- NVLink/GPU
- 900 GB/s
- Per system
- 8 / HGX node
H100 compute, far more memory - built for long context.
B200
2024–25Blackwell
- Memory
- 192 GB HBM3e
- Bandwidth
- ~8 TB/s
- NVLink/GPU
- 1.8 TB/s
- Per system
- 8 / HGX node
Dual-die design; adds FP4 for inference throughput.
GB200
2024–25Grace + Blackwell
- Memory
- 384 GB (2× B200)
- Bandwidth
- ~16 TB/s
- NVLink/GPU
- 1.8 TB/s
- Per system
- 72 / NVL72 rack
A Grace CPU fused to two B200s; the NVL72 building block.
B300
2025–26Blackwell Ultra
- Memory
- 288 GB HBM3e
- Bandwidth
- ~8 TB/s
- NVLink/GPU
- 1.8 TB/s
- Per system
- 8 / HGX node
Blackwell Ultra: more HBM and ~1.5× the FP4 for reasoning inference.
GB300
2025–26Grace + Blackwell Ultra
- Memory
- 576 GB (2× B300)
- Bandwidth
- ~16 TB/s
- NVLink/GPU
- 1.8 TB/s
- Per system
- 72 / NVL72 rack
Grace + two B300s; the GB300 NVL72 building block for AI factories.
VR200 (Rubin)
2H 2026Vera + Rubin
- Memory
- 288 GB HBM4
- Bandwidth
- ~22 TB/s
- NVLink/GPU
- 3.6 TB/s
- Per system
- 144 / NVL144 rack
NVIDIA-reported. Vera CPU + Rubin GPU; HBM4 and NVLink 6 - the NVL144 building block.
RTX PRO 6000
2025Blackwell (RTX)
- Memory
- 96 GB GDDR7
- Bandwidth
- 1.6 TB/s
- NVLink/GPU
- -
- Per system
- up to 8 / server
Blackwell on a PCIe card: FP4, graphics, and 96 GB for inference, fine-tuning, and sim.
L40S
2023Ada Lovelace
- Memory
- 48 GB GDDR6
- Bandwidth
- 864 GB/s
- NVLink/GPU
- -
- Per system
- up to 8 / server
Inference, graphics, and simulation in one card.
Three things to know about Vera Rubin
- “144” counts dies, not packages. The VR200 NVL144 rack holds 72 Rubin packages (two dies each), so it is the same physical footprint as today's NVL72 - the count just changed how it is measured.
- Named after an astronomer. Vera Rubin's work on galaxy rotation gave the first strong evidence for dark matter - the platform pairs a Vera CPU with a Rubin GPU.
- HBM4 keeps memory the headline. 288 GB at ~22 TB/s per GPU - inference stays memory-bound, so bandwidth and capacity (not just FLOPS) decide how much KV cache and context a GPU can hold.
Specs are NVIDIA-reported from GTC 2025; ships 2H 2026.
The roadmap ahead
NVIDIA now ships a new data-center architecture roughly every year, so sizing a multi-year build means knowing what's next. Three things define the next two years: memory moves to HBM4, the rack becomes the unit of compute, and inference begins to disaggregate its prefill and decode phases across the fleet. Click an era to see what changes.
NVIDIA datacenter GPU roadmap - where AI infrastructure is heading
The unit of compute keeps growing - from one GPU, to a node, to a rack, to a multi-rack NVLink domain - while memory (HBM4) and disaggregated inference (separate context vs decode silicon) define the next two years.
Rubin GPU + Vera CPU, NVL144
HBM4 (288 GB/GPU at ~22 TB/s); NVLink 6 (~3.6 TB/s per GPU). NVL144 rack ≈ 3.6 EF FP4 inference, ~1.2 EF FP8 training. 'NVL144' counts dies, not packages - same rack footprint as NVL72.
Roadmap dates and figures are NVIDIA-announced and subject to change; future-gen numbers are vendor estimates.
Reading a spec sheet
Four numbers tell you most of what you need to know about a data-center GPU:
Memory capacity (HBM)
How big a model - and its KV cache - can live on one GPU. The first wall you hit. 80 GB on H100, 192 GB on B200, 288 GB on B300.
Memory bandwidth
How fast weights stream from HBM to the compute cores. Token generation is bandwidth-bound, so this often matters more than raw FLOPS.
Compute (tensor cores)
Throughput at a given precision. Quoted in TFLOPS/PFLOPS - but read the fine print: numbers usually assume sparsity and the lowest precision.
Precision support
Which number formats the silicon accelerates. Hopper added FP8; Blackwell adds FP4 - each halving of precision roughly doubles throughput.
Compute throughput
Peak tensor-core throughput per GPU, by precision. Lower precision trades numerical range for speed: each step down (FP16 → FP8 → FP4) roughly doubles the rate, which is why inference has marched toward FP4 on Blackwell.
| GPU | FP4 | FP8 / INT8 | BF16 / FP16 | FP64 |
|---|---|---|---|---|
| H100 | - | 1.0 PF | 0.5 PF | 67 TF |
| H200 | - | 1.0 PF | 0.5 PF | 67 TF |
| B200 | 9 PF | 4.5 PF | 2.25 PF | 40 TF |
| GB200 | 20 PF | 10 PF | 5 PF | 90 TF |
| B300 | 15 PF | 7.5 PF | 3.75 PF | - |
| GB300 | 30 PF | 15 PF | 7.5 PF | - |
| VR200 (Rubin) | 50 PF | 35 PF | - | - |
| RTX PRO 6000 | 4 PF | 2 PF | 1 PF | - |
| L40S | - | 1.5 PF | 0.36 PF | - |
Representative dense peak figures (PF = PFLOPS, TF = TFLOPS); structured sparsity roughly doubles them. These are per-chip numbers - GB200 / GB300 rows are per Grace-Blackwell superchip (two GPUs), and their dies clock higher than the air-cooled HGX boards. A full NVL72 rack multiplies these across 72 GPUs (e.g. ~1.44 EF FP4 sparse for GB200 NVL72), so the per-rack totals in the rack diagram below are far larger and do not contradict these figures. Confirm against current NVIDIA datasheets before sizing.
Nodes and racks
GPUs ship in standardized building blocks. What matters for sizing is how many GPUs share one fast memory domain - and how much HBM that adds up to, because that pooled memory is what a single large model or KV cache can spread across.
HGX / DGX H100
total HBM
8 × 80 GB, one NVLink domain over NVSwitch.
HGX H200
total HBM
8 × 141 GB - same node, far more aggregate HBM.
DGX / HGX B200
total HBM
8 × 192 GB Blackwell in a single server.
HGX B300
total HBM
8 × 288 GB Blackwell Ultra.
GB200 NVL72
total HBM
72 × 192 GB as one NVLink domain - a rack that acts as one GPU.
GB300 NVL72
total HBM
72 × 288 GB HBM3e in a single NVLink domain - the flagship AI-factory rack.
VR200 NVL144
total HBM
NVIDIA-reported. 72 packages / 144 Rubin dies as one NVLink-6 domain - same rack footprint as NVL72.
How you actually buy it
The same GPUs reach customers through very different consumption models - from a bare baseboard an OEM builds a server around, to a turnkey validated cluster, to rented capacity in a neocloud. The choice is usually about who owns the integration risk and the CapEx, not the silicon - and a reference architecture is the thread that de-risks every path.
Deployment model explorer - how enterprises actually buy NVIDIA AI
Same silicon, very different go-to-market. Pick a deployment model to see who it's for, how you buy it, and the trade-off you're signing up for. Knowing which one a customer fits is the first move in any AI-infrastructure conversation.
HGX
The 8-GPU baseboardWho it's for
OEMs/ODMs, neoclouds, and most enterprises.
How you buy
NVIDIA sells the 8-GPU baseboard; partners (Supermicro, Dell, etc.) build the server around it.
Trade-off
Maximum choice and best price - but you (or your vendor) own the integration.
What's a reference architecture?
A pre-validated blueprint spanning compute, network, storage and software - tested for thermals, power, mechanicals and signal integrity. It removes integration risk so an AI factory goes live in weeks, not months. It's the single most deployment-relevant concept for a buyer.
Pricing figures are illustrative market estimates (neocloud vs hyperscaler H100-equivalent hourly).
The NVL72 rack, up close
The flagship building block deserves a closer look. An NVL72 rack groups its 9 NVLink switch trays in the center, flanked by two banks of compute trays, with power shelves at top and bottom - a copper spine fuses all 72 GPUs into one all-to-all NVLink-5 domain. The GB200 and GB300 builds share this rack; GB300 raises HBM, FP4, and power.
Inside an NVL72 rack - a rack that acts as one GPU
18 compute trays split into two banks, with the 9 NVLink switch trays grouped in the center and power shelves at top and bottom. A copper spine wires the trays into a single all-to-all NVLink-5 domain - any GPU reaches any other at full NVLink speed.
Centering the switch trays keeps every compute tray within a short, equal cable run of the NVLink fabric. Any GPU reaches any GPU at NVLink speed - the packet doesn't care which tray it lands in. No in-rack optics; the spine is all copper.
Pooled HBM
~13.5–20 TB
FP4 compute
~1.1–1.44 EF FP4
Aggregate HBM BW
~570 TB/s
Power (liquid-cooled)
~120–142 kW
GB200/300 NVL72 (Blackwell (B200) → Blackwell Ultra (B300)). Both share the same rack - GB300 raises HBM and FP4. Figures span both as per-rack totals, not the per-chip numbers in the compute table above.
The power wall - and why racks went liquid
A single NVL72 rack draws 120–142 kW - five to six times what an air-cooled rack can dissipate. That's why Blackwell racks ship direct-to-chip liquid-cooled by default, and why per-GPU power keeps climbing every generation. Toggle the views to see both walls - and where the roadmap (600 kW, then ~1 MW racks) is heading.
The power wall - why cooling now sets the design
Rack power has blown past the air-cooling ceiling, and per-GPU TDP keeps climbing. Direct-to-chip liquid cooling stopped being optional somewhere around 25 kW per rack.
Hover or tap a bar for what its power density means for cooling.
Past ~25 kW/rack, air can't keep up. NVL72 uses direct-to-chip cold plates; an in-row CDU (coolant distribution unit) isolates the clean technology loop on the chips from the facility water loop.
Rack/TDP figures are approximate, from NVIDIA and vendor reference designs; roadmap (Rubin/Kyber, 800 VDC, ~1 MW racks by 2027) is NVIDIA-stated direction.
Power is the new constraint
Once power - not chips - caps how much you can deploy, the metric that matters shifts from FLOPS to tokens per watt and cost per token. On those, each generation is a step change: NVIDIA reports Blackwell delivering far more tokens per megawatt and a fraction of Hopper's cost per token. Drag the slider to see how that reshapes the bill at scale.
Inference economics - power is the new constraint
At scale the KPIs aren't FLOPS - they're cost-per-token and tokens-per-watt. Slide your monthly token volume and watch the bill, and the megawatts behind it, diverge between Hopper and Blackwell.
Monthly inference cost
$4.20M
Tokens per megawatt
Monthly inference cost
$120.0K
Tokens per megawatt
Why this matters: at scale, inference revenue is gated by your megawatt budget, not GPU sticker price - so the metric that matters is tokens per watt and per dollar, not FLOPS.
Figures are NVIDIA-reported, illustrative round numbers (Blackwell vs Hopper, reasoning-model inference): ~$0.12 vs ~$4.20 per 1M tokens, >50× tokens/MW. Real results vary by model, precision (FP4), and workload.
From one GPU to a SuperPOD
A frontier model never fits on one GPU. NVIDIA's answer is a hierarchy of ever-larger “single” computers, each tier glued together by a faster network than the last.
1 GPU
The unit of computeA single accelerator with its own HBM. Once a model or its KV cache exceeds this memory, you must scale out.
Node (HGX / DGX)
8 GPUs, one NVLink domainEight GPUs inside a server talk over NVLink/NVSwitch at terabytes per second - fast enough to split one model across them. 640 GB on H100, up to ~2.3 TB on B300.
NVL72 rack
72 Blackwell GPUs as oneGB200/GB300 NVL72 links 72 GPUs into a single NVLink domain (~13.5–20.7 TB of pooled HBM), so the rack behaves like one very large accelerator.
SuperPOD
Many racks over InfiniBand / Spectrum-XRacks are stitched together with InfiniBand or Spectrum-X Ethernet into clusters of thousands of GPUs.
Scale up vs scale out
That hierarchy splits into two moves. Scaling up grows the NVLink domain into one bigger GPU; scaling out stitches racks together over InfiniBand or Ethernet. Zoom from a single node to a SuperPOD and watch where the fat NVLink links give way to the thin network - and where storage bypasses the CPU entirely.
Scale up, then scale out - three zoom levels
Line thickness encodes bandwidth: thick green NVLink inside the domain, thin blue InfiniBand/Ethernet between racks. The fourth lane is the storage path that bypasses the CPU entirely.
Node
8 GPUs ↔ NVSwitch
thick NVLink · 1.8 TB/s/GPU
Rack · NVL72
72-GPU NVLink domain
72 GPUs as one · copper spine
SuperPOD
Many racks over IB / Spectrum-X
thin scale-out · ~50–100 GB/s/GPU
GPUDirect Storage streams NVMe straight into GPU HBM - checkpoints · data loading · KV-cache tiering - never touching host DRAM. See the VAST platform →
Scale up
Grow the NVLink domain - make one bigger GPU. Bandwidth-rich (1.8 TB/s/GPU), but capped at 72 GPUs per domain today.
Scale out
Add racks over InfiniBand / Ethernet. Near-unlimited size, but each hop is ~100–260× less bandwidth than NVLink - so you keep tight traffic in-domain and spread the loosely-coupled work out.
Why liquid cooling
A copper-spine NVL72 packs 72 GPUs and 1.8 TB/s links into ~132 kW per rack. Air can't shed that heat - direct-liquid cooling is the only way to run the density that makes one NVLink domain possible.
Grace NVLink-C2C
A coherent ~900 GB/s link fuses each Grace CPU to its Blackwell GPUs, with LPDDR5X acting as a capacity tier behind HBM - CPU and GPU share one memory space without crossing PCIe.
SHARP in-network reduction
Quantum InfiniBand switches compute part of an all-reduce inside the network (SHARP v4 on Quantum-X800), so collective ops don't pay the full round-trip - recovering scale-out bandwidth.
Six paradigms driving the build-out
Above the technical workloads sits a market-level view: the kinds of AI demand pulling infrastructure into data centers. The first two are two faces of the same plant - an AI factory manufactures intelligence (raw materials: data + electricity; product: a model), and the token factory turns that model into tokens, where the currency is tokens per watt. (NVIDIA often uses “AI factory” for the whole operation, training and inference alike - the split below is about emphasis.)
AI Factory
Training
Building the model. NVIDIA reframes the data center as a plant that manufactures intelligence - raw materials are data and electricity, the product is a trained model. Thousands of GPUs in lockstep, interconnect-bound.
Hardware: GB200/GB300 NVL72, H100/H200 clusters
Training & fine-tuning →Token Factory
Inference at scale
Once the model exists, the factory's output is tokens. Economics are measured in tokens per watt and per dollar - and reasoning models multiply the tokens spent per query.
Hardware: GB300 NVL72, B300, H200
Inference & serving →Agentic AI
Autonomous workflows
Multi-step agents that plan, call tools, and carry memory across turns. Long context and bursty, latency-sensitive inference loops rather than one-shot prompts.
Hardware: H200, B200 / B300
Agentic AI →Sovereign AI
Owned & controlled
Nations and enterprises building AI on infrastructure they own - for data residency, language and culture, and regulatory control. Drives full-stack, in-country deployments.
Hardware: DGX SuperPOD, full-stack NVIDIA AI
RAG / Enterprise AI
Grounded on private data
Grounding general models on proprietary data through retrieval and vector search - the dominant enterprise pattern for accuracy and freshness without retraining.
Hardware: L40S, H100/H200 + fast storage
RAG & vector search →Physical AI / Digital Twin
AI that acts in the world
AI that perceives and acts physically - robotics, autonomous vehicles, and Omniverse digital twins / world models. Mixed graphics and compute simulation.
Hardware: L40S, RTX PRO 6000, B200, Omniverse
Simulation →The flagship hardware story across these: GB200 and GB300 NVL72 racks, where 72 GPUs act as one accelerator and FP4 maximizes tokens per watt for large-scale reasoning inference.
The real moat: CUDA and the full stack
A competitor can match a chip far sooner than it can match twenty years of CUDA. The durable lock-in is the software stack - the CUDA platform, the sprawling CUDA-X libraries (cuDNN, cuBLAS, cuDF, cuML, cuVS, cuGraph, NCCL and hundreds more), and the frameworks and microservices built on top. Explore the layers to see why the ecosystem, not the silicon, is the hard thing to leave.
The NVIDIA stack - the real moat isn't the chip
Competitors can match a chip; matching ~20 years of CUDA-X libraries and every framework optimizing for them is far harder. Click a layer - or a CUDA-X library chip - to see what it does.
Stack layer
CUDA-X libraries
The domain-specific accelerated libraries every framework and platform calls into. Pick a chip to see what it does.
CUDA-X spans 400+ libraries; shown here is a representative slice. Names are NVIDIA products/libraries.
The serving and training layers (NIM, NeMo, Dynamo, TensorRT-LLM) get their own treatment on the inference & serving and training & fine-tuning pages.
The interconnect
At scale, the network is the computer. How fast GPUs exchange gradients and activations decides whether a 10,000-GPU cluster behaves like 10,000 GPUs or a fraction of that.
NVLink
GPU ↔ GPU, inside a node
Direct high-bandwidth links between GPUs. 900 GB/s on Hopper, 1.8 TB/s per GPU on Blackwell - orders of magnitude faster than PCIe.
NVSwitch
The NVLink fabric
A switch chip that lets every GPU in a node (or NVL72 rack) reach every other at full NVLink speed, not just its neighbors.
InfiniBand
Node ↔ node, across the cluster
Low-latency RDMA networking that connects nodes into a SuperPOD with minimal CPU overhead. Quantum-2 runs 400 Gb/s NDR; Quantum-X800 pushes 800 Gb/s XDR (ConnectX-8) with SHARP v4 in-network reduction.
Spectrum-X Ethernet
Node ↔ node, Ethernet path
An Ethernet fabric tuned for AI - adaptive routing and congestion control recover bandwidth that vanilla RoCE leaves on the table.
DPUs and SuperNICs - keeping GPUs fed
Two specialized NICs sit in every Blackwell tray. The ConnectX-8 SuperNIC moves GPU-to-GPU traffic at up to 800 Gb/s; the BlueField-3 DPU offloads networking, storage, and security off the host CPU so its cores aren't stolen from the work that feeds the GPUs. Toggle the node to see the difference. The next generation, BlueField-4, doubles networking to 800 Gb/s via ConnectX-9 and adds a new headline role - offloading KV-cache “context memory” to a petabyte NVMe tier.
DPU vs SuperNIC - who keeps the GPUs fed
Two NVIDIA networking chips do very different jobs. The DPU takes infrastructure work off the host CPU; the SuperNIC moves GPU-to-GPU traffic between nodes. Toggle the DPU below to see what changes on the compute node.
No DPU - infrastructure work stays on the CPU.
The host CPU burns cycles moving packets, handling storage and security - cores that should be feeding the GPUs.
The GPU-to-GPU scale-out NIC - RDMA/RoCE + GPUDirect that carries the east-west AI traffic between nodes.
Offloads networking, storage, security & management off the host CPU; isolates tenants. In GB200/GB300 trays it pairs with ConnectX-8.
Rule of thumb: the SuperNIC moves GPU data fast; the DPU takes infrastructure work off the CPU. Both exist so GPUs stay fed instead of idle.
Specs are NVIDIA datasheet figures (ConnectX-8 up to 800 Gb/s; BlueField-3 up to 400 Gb/s, 16 Armv8.2 cores).
BlueField-3 to BlueField-4 - the AI-factory jump
6x compute · 4x larger AI factoriesBlueField-4 is one of the six Vera Rubin platform chips. It roughly doubles networking, quadruples the Arm core count, and shifts the DPU from general datacenter offload to a purpose-built AI-factory infrastructure processor.
Networking
400 Gb/s
Networking
800 Gb/s
Integrated NIC
ConnectX-7
Integrated NIC
ConnectX-9
Arm cores
16 (Cortex-A78)
Arm cores
64 (Grace)
PCIe
Gen5
PCIe
Gen6
Ships
2022
Ships
2026 (Vera Rubin)
The headline new role: KV-cache context memory
GPU HBM is small and expensive, so the KV cache overflows on long context. BlueField-4 turns a petabyte NVMe pool into a fast “context memory” tier - storing and reusing KV cache across the whole fleet, at line rate, with encryption handled on the DPU.
GPU HBM
small KV cache, overflows
BlueField-4 DPU
800 Gb/s · NVMe-oF · encrypt
NVMe context memory
petabytes · stored & reused
Paired with NVIDIA Dynamo (NIXL / STX storage), this persists KV cache off the GPU so a reused prefix never has to be recomputed - directly attacking the memory wall that makes inference memory-bound.
NVIDIA-reported: 800 Gb/s (ConnectX-9), 6x compute / 3x memory bandwidth vs BlueField-3, PCIe Gen6, Grace CPU, ships 2026 with Vera Rubin, KV-cache / inference-context-memory role. Press-reported (pending NVIDIA datasheet): 64 Arm cores (Neoverse V2), 128 GB LPDDR5.
The bandwidth cliff
Those interconnects aren't interchangeable - they span more than two orders of magnitude in bandwidth. Plotting them on a log scale shows why the topology is built the way it is: stay on NVLink and you move terabytes per second; cross InfiniBand and you fall off a cliff.
The bandwidth cliff - every hop away from HBM costs you
Per-GPU bandwidth, log-scaled. Inside the NVLink domain GPUs talk at terabytes per second; the moment data crosses InfiniBand it falls off a cliff. This is why a job that fits one NVLink domain runs so much faster than one that has to cross the network.
on-package GPU memory - the baseline
GPU ↔ GPU inside the NVLink domain
any-to-any in NVL72 · 130 TB/s aggregate
GPU ↔ host / non-NVLink path
Quantum-X800 · scale-out per port
Quantum-2 · scale-out per port
NVMe → GPU HBM, per BlueField-3
The ~260× drop from NVLink to InfiniBand is the headline.
NVLink 5 moves 1.8 TB/s per GPU; 400G InfiniBand moves ~50 GB/s. That ~36× (800G) to ~260× (400G) gap is exactly why 72 GPUs share one NVLink domain - you keep all-to-all traffic inside the fabric and only cross the network when you absolutely must.
NVIDIA networking: Spectrum-X
Spectrum-X is NVIDIA's Ethernet platform for AI - Spectrum-4 switch silicon paired with BlueField/ConnectX SuperNICs, adding adaptive routing and congestion control that standard Ethernet lacks. Two switches anchor the 400G and 800G tiers:
| Switch | Family | Throughput | Ports |
|---|---|---|---|
| Spectrum SN5600 | 800G | 51.2 Tb/s | 64× 800GbE (OSFP), 2U |
| Spectrum SN5400 | 400G | 25.6 Tb/s | 64× 400GbE (QSFP-DD) |
Spectrum SN5600
800GSpectrum-4 flagship. Can also break out to 128× 400GbE. The switch behind 800G Spectrum-X AI clusters.
Spectrum SN5400
400GThe 400G Spectrum-X tier - same Spectrum-4 lineage, sized for 400GbE leaf/spine fabrics.
Try it yourself
Two calculators make the trade-offs concrete. The first asks whether a job fits one NVLink domain; the second shows how long a transfer takes across every tier - and why the storage and network path, not raw compute, usually decides utilization.
NVLink domain playground - does your job fit one domain?
All-to-all traffic that stays inside the NVLink domain moves at 1.8 TB/s per GPU; anything spilling across racks drops to InfiniBand speed. Set the domain size and the job size and watch the effective bandwidth.
Effective all-to-all BW
1.80 TB/s
100% in-domain
Per-step time
0.04 ms
64 MB / effective BW
all traffic stays on NVLink
Effective BW for this job: 8-GPU domain vs 72-GPU domain
~6× faster when the job fits one 72-GPU domain
Keeping all-to-all traffic inside the NVL72 domain (1.8 TB/s/GPU) instead of crossing 800G InfiniBand can deliver up to a ~36× (800G) to ~260× (400G) bandwidth advantage - the whole reason 72 GPUs are wired into one domain.
Formula is illustrative: effective BW = f·1800 + (1−f)·cross, where f = min(domain, GPUs)/GPUs. Real collectives also pay latency and topology overheads.
Data-movement calculator - how long does a transfer take?
Pick a transfer size and a tier; time = size / bandwidth. The strip shows the same transfer on every tier - the gap between HBM and the network is why storage throughput, not FLOPS, decides GPU utilization.
only applies to GPUDirect Storage
1.00 TB over InfiniBand 400G
20.00 s
Same transfer, every tier
A 1 TB checkpoint clears HBM in ~0.13 s but takes ~20 s over a single 400G InfiniBand link. When thousands of GPUs stall waiting on checkpoints, data loading, or KV reloads, the bottleneck is the storage and network path - which is exactly where a high-bandwidth data platform keeps the fleet busy.
GPUDirect Storage - skipping the CPU
The last mile of keeping GPUs busy is the path from storage into HBM. GPUDirect Storage lets the NIC DMA data straight into GPU memory, bypassing the CPU bounce buffer - higher bandwidth, lower latency, and CPU cores freed for real work. Flip between the two paths to see why it matters for utilization.
GPUDirect Storage - keep the GPUs fed, not idle
Storage throughput is part of GPU utilization. Watch where the data has to travel before it reaches GPU memory - and what NVIDIA GPUDirect Storage removes from the path.
CPU + system DRAM
bounce buffer
Storage / NVMe
data at rest
NIC
network adapter
GPU HBM
where compute happens
Data is copied into CPU system memory first (a "bounce buffer"), then copied again into GPU memory - extra hops, CPU overhead, higher latency.
This is why a high-bandwidth data platform (e.g. VAST) plugs straight into the GPU fabric - keeping GPUs fed, not idle.
GPUDirect Storage uses the cuFile API + O_DIRECT; the NIC/storage controller DMAs directly into pinned GPU memory. Conceptual diagram.
Where the data platform plugs in
All this compute is worthless if it sits idle waiting for data. Training reads enormous datasets and writes frequent checkpoints; inference streams context in and logs out. Storage throughput is a first-class part of GPU utilization - which is exactly where a high-bandwidth data platform earns its place in the rack.