Rubin and the Roadmap

The idea in one minute#

Rubin is the first NVIDIA GPU built around HBM4, and its headline change is the one LLM serving cares about most: about 22 TB/s of memory bandwidth per GPU, 2.75x Blackwell. It also doubles NVLink to 3.6 TB/s, moves I/O onto separate dies, and pairs with a new CPU, Vera. NVIDIA sells it as six chips designed together and ships it only as the liquid-cooled Vera Rubin NVL72 rack, since August 2026.

Behind it the roadmap is already public: Rubin Ultra (2027, four dies per package, racks of about 600 kW) and Feynman (2028). This lesson covers what Rubin is, and how to read an announcement before the hardware exists. Facts checked on 16 October 2026.

A picture#

How it really works#

The Rubin GPU#

What is new in the package:

• HBM4 doubles the interface per stack from 1,024 to 2,048 bits. Same eight stacks, far more bandwidth. For decode-heavy serving this is the biggest generational gain since HBM arrived.
• Separate I/O dies carry NVLink 6 and the host links, so the two reticle-sized compute dies spend their area on SMs. Analysts read the block diagram as 224 SMs in 8 GPCs, up from 148 on B200, each with twice the FP4 tensor width.
• Two FP4 numbers. NVIDIA quotes 50 PF for inference and 35 PF for training. Treat both as peak claims under NVIDIA’s own conditions until independent measurements exist.

Vera and the six chips#

NVIDIA presents Rubin as a platform of six chips designed together:

The rack keeps the NVL72 shape: 72 Rubin GPUs, 36 Vera CPUs, 20.7 TB of HBM4, about 3.6 EF of NVFP4 (NVIDIA). It is liquid-cooled only; there is no air-cooled Rubin.

Beside the GPUs: an inference-only rack#

At GTC 2026 NVIDIA added a rack that contains no GPUs: the Groq 3 LPX, built on technology licensed from Groq. Each LP30 chip has 500 MB of SRAM and no HBM; 256 of them make a rack. It is sold to sit next to Rubin racks and take over latency-critical decode (see SRAM machines). Meanwhile the GDDR7-based “Rubin CPX” prefill chip announced in 2025 has dropped off the public roadmap.

Announced, not shipping#

Kyber is a different building: 600 kW in one rack needs facility power and cooling that Blackwell-era halls do not have.

How to read a launch slide#

Every generation’s numbers come wrapped in conventions. Before comparing, ask:

1. Dense or sparse? Sparse figures are 2x and rarely apply to LLMs.
2. Which precision? An FP4 figure against last year’s FP8 figure is a format change, not a faster chip.
3. Per die, per package, or per rack? Rubin Ultra’s “576” counts dies; NVL72 counts packages.
4. Inference mode or training? Rubin quotes both, 50 vs 35 PF.
5. At what power? The same chip is quoted at different TDPs in different systems.
6. Shipping or announced? Plan on what you can rent this quarter.
7. Which lever does my workload need? (8.a) Bandwidth for decode, FLOPs for prefill and training, capacity for model size and KV cache.

Code#

Machine balance per generation: how much arithmetic each GPU does per byte it reads, and the batch size at which FP4 decoding stops being memory-bound.

// balance.go — does each generation get more compute per byte, or more bytes?
package main

import "fmt"

type Gen struct {
	Name       string
	PFLOPs     float64 // dense, smallest supported format
	Format     string
	BytesPerW  float64 // bytes per weight in that format
	BandwidthT float64 // TB/s
}

func main() {
	gens := []Gen{
		{"H100", 1.98, "FP8", 1, 3.35},
		{"H200", 1.98, "FP8", 1, 4.8},
		{"B200", 9, "FP4", 0.5, 8},
		{"B300", 15, "FP4", 0.5, 8},
		{"Rubin (claim)", 50, "FP4", 0.5, 22},
		{"Rubin Ultra (ann.)", 100, "FP4", 0.5, 32},
	}
	fmt.Println("GPU                  format  FLOP per byte   batch to be compute-bound")
	for _, g := range gens {
		balance := g.PFLOPs * 1e15 / (g.BandwidthT * 1e12)
		// decode: 2 FLOPs per weight per token in the batch, BytesPerW bytes per weight
		perToken := 2 / g.BytesPerW
		fmt.Printf("%-20s %-6s %13.0f %27.0f\n", g.Name, g.Format, balance, balance/perToken)
	}
}

B300 added FP4 math but no bandwidth, so its balance jumped from 1,125 to 1,875 FLOP per byte: decode needs a batch of almost 470 before that extra math is used, and latency-sensitive serving rarely runs that large. Rubin triples the math again, yet its balance rises only a little (2,273), because HBM4 nearly triples the bytes too. For serving, that is the bigger upgrade.

Remember this#

• Rubin = HBM4 (~22 TB/s), 3.6 TB/s NVLink 6, separate I/O dies, 336 B transistors; shipping since August 2026 in Vera Rubin NVL72 racks only.
• Vera CPU: 88 Arm cores, up to 1.5 TB LPDDR5X, 1.8 TB/s to the GPUs.
• The platform is six chips: GPU, CPU, NVLink switch, SuperNIC, DPU, Ethernet switch.
• Rubin Ultra (2027, 4 dies, ~1 TB HBM4e, 600 kW Kyber racks) and Feynman (2028) are announced.
• Read every launch number for format, sparsity, unit of count, mode and power.

Try it#

1. Run balance.go. Add the MI455X (40 PF FP4, ~20 TB/s; lesson AMD Instinct). Where does it land?
2. Using the bars in the second figure, which lever grew most from H100 to Rubin? Which grew least?
3. Find NVIDIA’s current Rubin data sheet. Has any number in the table above moved?

Check yourself#

1. Why is HBM4 the most important change in Rubin for LLM serving?
2. What do Rubin’s separate I/O dies free up?
3. What are the six chips of the Vera Rubin platform?
4. Name four questions to ask of a launch-day performance figure.

Sources#

• NVIDIA Rubin platform: six new chips (CES 2026, via Tech Briefs)
• Vera Rubin NVL72 specifications (Cisco datasheet)
• SemiAnalysis: Vera Rubin, extreme co-design
• Rubin Ultra NVL576 and the 600 kW Kyber rack (DCD)
• NVIDIA Groq 3 LPX