I spend most of my time on Blackwell, so the honest reason I read about Rubin is to work out which of my current habits are about to expire. The answer is encouraging and slightly annoying: the arithmetic transfers, and the topology assumptions do not.
Rubin is a platform rather than a part. A custom Arm CPU called Vera sits next to the Rubin GPU over NVLink-C2C, with several other chips codesigned around them. That framing matters more than any single spec, because the thing being redesigned is the boundary between host and accelerator, and that boundary is where a lot of my current serving problems live.
The Vera CPU, and why I care about a CPU at all
Vera is 88 custom Armv9.2 cores, and the interesting part is not the core count but the link: NVLink-C2C connects it to Rubin at 1.8 TB/s rather than over PCIe. On the fleet I think about, the CPU is not decorative. It runs the scheduler, the KV-cache bookkeeping, the tokenizer and the request orchestration, and when a node behaves badly under load it is often one of those, not the GPU. Removing PCIe from between the two is the change I would feel first.
The Rubin GPU
Fifth-generation tensor cores, 50 PFLOPS of NVFP4 against B200's roughly 9 PFLOPS of dense FP4, a third-generation Transformer Engine with hardware-accelerated compression, and NVLink 6 at 3.6 TB/s per GPU, double NVLink 5. Taken together that is a step change in the compute side and a doubling on the fabric side, which are not the same kind of improvement and do not help the same workloads.
What I actually expect it to change for me
Decode is memory-bound. It is bound by how fast weights stream out of HBM, not by how many FLOPs the die can do. So a jump from 9 to 50 PFLOPS is not, on its own, a decode story, and I would be careful about reading it as one. The two numbers I would watch instead are bandwidth per GPU and what NVLink 6 does to the cost of crossing between GPUs, because those are what set the token rate and what set where a tensor-parallel group is allowed to end.
The compression in the third-generation Transformer Engine is the line I find most interesting and the least well specified publicly. If it applies to the KV cache rather than only to weights, it changes the memory arithmetic on every page of this site. If it does not, it is a weight-loading optimisation and decode barely notices. I do not think the public material settles this yet, and I would not plan around either reading.
The NVL72 rack, which is the actual product
The headline form factor is a rack, not a card: 36 Vera CPUs and 72 Rubin GPUs in one coherent NVLink domain, with 18 BlueField DPUs alongside, and a SuperPOD stacking fourteen of those into 1,008 GPUs. Quoted figures for the rack run to roughly 260 TB/s of aggregate NVLink and around a petabyte of fast memory, with the SuperPOD in the tens of exaflops at FP4.
The number that matters in that list is not any of the throughput figures. It is 72. Seventy-two GPUs in a single NVLink domain means the whole rack behaves like one machine, and model partitioning stops being a placement problem in the way it is on smaller domains. A tensor-parallel group of sixteen is an ordinary thing to run. Prefill workers and decode workers can be separate pools that still hand caches to each other at memory speed rather than network speed.
That single property is why almost every published serving figure for a frontier model comes off rack-scale hardware, and why the aggregated-or-disaggregated question has a different answer depending on which of these you own.
What that means if you do not buy racks
I work with eight-GPU nodes and a NIC between them, so the NVL72 claim does not apply to me and I have to be careful reading numbers produced on it. Rack figures do not divide cleanly. A throughput result measured on a 72-GPU domain is partly measuring the domain, so taking it and dividing by nine to get a per-node number produces something optimistic and wrong.
Rubin raises both sides of the ratio rather than removing it. NVLink 6 doubles the in-domain bandwidth, and the scale-out side improves too, but the gap between talking inside the domain and talking outside it remains the thing that decides where a parallel group is allowed to end. Whether that gap widens or narrows with Rubin is the number I would most like published and have not found.
What transfers
All the arithmetic. The roofline still tells me whether a kernel is starved for compute or for data. The KV cache still grows linearly with tokens and batch and still overtakes the weights at a context length you can calculate. Active parameters still decide cost per token and total parameters still decide whether it fits. Those are properties of transformers and memory hierarchies, not of a GPU generation, which is the main reason I am relaxed about the hardware moving underneath me.
The generation changes the constants. It has not yet changed which number you should be looking at.
Sources
- NVIDIA: DGX SuperPOD sets the stage for Rubin: the CES 2026 announcement.
- NVIDIA: Vera Rubin driving performance per watt: production ramp, 10x per-megawatt.
- NVIDIA: gigawatt AI factories: Kyber, Rubin Ultra, 800V DC.
- NVIDIA: Blue Lion on Vera Rubin: the superchip concept.