Systems & Infrastructure

NVIDIA Infrastructure

Fundamental

The 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 clusters

Pretraining and large fine-tunes: thousands of GPUs in lockstep, bound by interconnect and memory.

Inference (serving)

H100/H200, B200/B300, L40S, RTX PRO 6000

Serving tokens to users: memory-bandwidth bound in decode, latency-sensitive, scaled horizontally.

Reasoning / test-time compute

GB300/GB200 NVL72, B300, B200

Long 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 6000

LoRA/QLoRA and domain adaptation: far smaller footprint, often a single node.

Data processing & ETL

L40S, RTX PRO 6000, H100

Curation, dedup, tokenization, and embedding generation at petabyte scale - increasingly GPU-accelerated (RAPIDS, NeMo Curator).

Simulation

L40S, RTX PRO 6000, B200

Omniverse, digital twins, world models: mixed graphics + compute, RTX-class features matter.

HPC & scientific computing

H100/H200, GB200

Weather, 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

2022

Hopper

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

2024

Hopper

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–25

Blackwell

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–25

Grace + 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–26

Blackwell 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–26

Grace + 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 2026

Vera + 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

2025

Blackwell (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

2023

Ada 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.

Vera Rubin2H 2026
GPUs

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.

GPUFP4FP8 / INT8BF16 / FP16FP64
H100-1.0 PF0.5 PF67 TF
H200-1.0 PF0.5 PF67 TF
B2009 PF4.5 PF2.25 PF40 TF
GB20020 PF10 PF5 PF90 TF
B30015 PF7.5 PF3.75 PF-
GB30030 PF15 PF7.5 PF-
VR200 (Rubin)50 PF35 PF--
RTX PRO 60004 PF2 PF1 PF-
L40S-1.5 PF0.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

8× H100640 GB

total HBM

8 × 80 GB, one NVLink domain over NVSwitch.

HGX H200

8× H200~1.1 TB

total HBM

8 × 141 GB - same node, far more aggregate HBM.

DGX / HGX B200

8× B200~1.5 TB

total HBM

8 × 192 GB Blackwell in a single server.

HGX B300

8× B300~2.3 TB

total HBM

8 × 288 GB Blackwell Ultra.

GB200 NVL72

72× B200~13.5 TB

total HBM

72 × 192 GB as one NVLink domain - a rack that acts as one GPU.

GB300 NVL72

72× B300~20.7 TB

total HBM

72 × 288 GB HBM3e in a single NVLink domain - the flagship AI-factory rack.

VR200 NVL144

144× Rubin (dies)~20+ TB

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 baseboard

Who 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.

GB200/300
72 GPUs · 36 Grace · 18 NVSwitch chips · one NVLink-5 domain
Management switch2× Spectrum Ethernet
Power shelf33 kW · 6× 5.5 kW PSU
Power shelf33 kW · 6× 5.5 kW PSU
Power shelf33 kW · 6× 5.5 kW PSU
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
NVLink switch tray2× NVSwitch
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
Compute tray2× Grace + 4 Blackwell
copper spine
>5,000 copper cables · 130 TB/s
Power shelf33 kW · 6× 5.5 kW PSU
Power shelf33 kW · 6× 5.5 kW PSU
Power shelf33 kW · 6× 5.5 kW PSU

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.

air-cooled OKliquid-cooled requiredfar over the limitair ceiling ≈ 25 kW
air ceiling

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.

Blackwell vs Hopper
~35× lower cost per token · >50× tokens per megawatt · Blackwell vs Hopper
Tokens served per month1.0T
1B1T100T
Hopper (H100)$4.20 / 1M

Monthly inference cost

$4.20M

Tokens per megawatt

1×
Blackwell (GB300 NVL72)$0.12 / 1M

Monthly inference cost

$120.0K

Tokens per megawatt

50×

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.

01

1 GPU

The unit of compute

A single accelerator with its own HBM. Once a model or its KV cache exceeds this memory, you must scale out.

02

Node (HGX / DGX)

8 GPUs, one NVLink domain

Eight 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.

03

NVL72 rack

72 Blackwell GPUs as one

GB200/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.

04

SuperPOD

Many racks over InfiniBand / Spectrum-X

Racks 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.

01
Node

8 GPUs ↔ NVSwitch

NVSwitch

thick NVLink · 1.8 TB/s/GPU

02
Rack · NVL72

72-GPU NVLink domain

spine

72 GPUs as one · copper spine

03
SuperPOD

Many racks over IB / Spectrum-X

rail-optimized fat-tree

thin scale-out · ~50–100 GB/s/GPU

GPUsBlueField DPUGPUDirect Storagearrow bypasses the CPU

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.

NVIDIA's framing

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.

Host CPUsaturated
App / data-prepfeeds the GPUs
Networkingpacket processing, RoCE
Storage I/ONVMe-oF, GPUDirect Storage
Securityencryption, isolation
Managementtelemetry, control plane
BlueField-3 DPUnot installed

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.

ConnectX-8 SuperNICup to 800 Gb/s

The GPU-to-GPU scale-out NIC - RDMA/RoCE + GPUDirect that carries the east-west AI traffic between nodes.

BlueField-3 DPUup to 400 Gb/s · 16 Arm

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 factories

BlueField-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.

BlueField-3
BlueField-4

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.

log scale
HBM3e (B200)8 TB/sbaseline

on-package GPU memory - the baseline

NVLink 5 (per GPU)1.8 TB/s4× slower

GPU ↔ GPU inside the NVLink domain

NVSwitch domain (per GPU)1.8 TB/s4× slower

any-to-any in NVL72 · 130 TB/s aggregate

PCIe Gen5 x16128 GB/s63× slower

GPU ↔ host / non-NVLink path

InfiniBand 800G (XDR)100 GB/s80× slower

Quantum-X800 · scale-out per port

InfiniBand 400G (NDR)50 GB/s160× slower

Quantum-2 · scale-out per port

GPUDirect Storage (400G DPU)50 GB/s160× slower

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:

SwitchFamilyThroughputPorts
Spectrum SN5600800G51.2 Tb/s64× 800GbE (OSFP), 2U
Spectrum SN5400400G25.6 Tb/s64× 400GbE (QSFP-DD)

Spectrum SN5600

800G

Spectrum-4 flagship. Can also break out to 128× 400GbE. The switch behind 800G Spectrum-X AI clusters.

Spectrum SN5400

400G

The 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.

scale-out link
GPUs needed for the job64
Data per all-to-all step64 MB

Effective all-to-all BW

1.80 TB/s

100% in-domain

Per-step time

0.04 ms

64 MB / effective BW

fits in domain

all traffic stays on NVLink

Effective BW for this job: 8-GPU domain vs 72-GPU domain

8-GPU domain
0.31 TB/s
72-GPU domain
1.80 TB/s

~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.

Transfer size (log scale)1.00 TB
1 MB1 GB1 TB
# DPUs (GPUDirect Storage)8

only applies to GPUDirect Storage

1.00 TB over InfiniBand 400G

20.00 s

Same transfer, every tier

HBM (B200)
125.0 ms
NVSwitch domain (aggregate)
7.7 ms
NVLink 5 (per GPU)
555.6 ms
PCIe Gen5 x16
7.81 s
InfiniBand 800G
10.00 s
InfiniBand 400G
20.00 s
GPUDirect Storage (per 400G DPU)
2.50 s

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.