NVIDIA Shipped Vera Rubin With 13 Percent Less Bandwidth Than It Advertised

NVIDIA quietly cut Vera Rubin bandwidth by 13 percent. Its specification page now lists 19.2 TB/s of HBM4 for each GPU, against 22 in September.

Capacity never moved. Each Rubin GPU still carries 288 GB, and the 72 GPU rack still totals 20.7 TB. What changed is how fast that memory can be read, and bandwidth is what sets how many tokens a second a serving node produces. Nobody issued a release. The edit is visible in the specifications table on the Vera Rubin NVL72 page.

Wayback Machine captures bracket the change between 1 September and 11 September 2026. NVIDIA has since said the new numbers are deliberate. A company representative told Wccftech that the earlier figures were “preliminary architectural targets” and that the published specifications “reflect what the system sustains at qualified, volume production.” Hassan Mujtaba reported that exchange for Wccftech on 29 October.

The eight GPU board lost the most, and it is the one most clusters will rack

Almost nobody buys a 72 GPU rack. They buy eight GPU boards in servers from Dell, HPE, Supermicro or Lenovo, and the HGX Rubin NVL8 took the deepest cut of the four. The page now lists 2 TB of HBM4 and 130 TB/s for the whole system, against 2.3 TB and 176 TB/s before. NVLink Switch bandwidth fell from 28.8 to 24 TB/s. Dense training slipped from 280 to 270 PFLOPS of NVFP4.

The math on that same page no longer closes. The system total and the per GPU row sit a few lines apart and disagree. Divide 130 TB/s by eight GPUs and you get 16.25 TB/s each. Divide 2 TB by eight and you get 250 GB. The per GPU row still prints 288 GB at 22 TB/s and 3.6 TB/s of NVLink, which is the old number sitting beside the new one. NVIDIA has not explained the gap.

Two readings fit. Eight smaller HBM4 stacks running just under 8 Gbps per pin, or one of the eight stacks disabled on each GPU, a trick NVIDIA used on the 80 GB H100. They imply different things about what a customer is buying, and the page does not say which one applies.

AMD now leads on both memory figures

The comparison that matters is not against Blackwell. AMD Instinct MI455X lists 432 GB of HBM4 at 23.3 TB/s per GPU on its own published figures, against Rubin’s 288 GB at 19.2 TB/s. At rack scale AMD’s Helios platform is listed at 1.67 PB/s of memory bandwidth against 1,400 TB/s for Vera Rubin NVL72, roughly 19 percent more.

None of this makes Rubin slow. At 19.2 TB/s it still delivers about 2.4 times the 8 TB/s of a Blackwell GPU. NVIDIA’s own Rubin architecture write-up continues to claim 2.8 times, because it still uses the 22 TB/s target. Anyone benchmarking a customer environment against that document is benchmarking an intention.

What a 13 percent cut does to a token budget

Decode is a memory problem, not a compute problem. Every generated token forces the node to read the model weights and the KV cache it has built for that conversation. Tensor cores sit idle waiting on those reads far more often than they sit idle waiting on arithmetic. Cut the read rate by 13 percent and the decode ceiling falls by roughly that much before batching is taken into account.

Continuous batching hides it while concurrency is high and stops hiding it once the KV cache fills. That is the moment a capacity plan built on the launch figure stops matching the bill, when the node reaches half the tokens a second it was sized for and the answer is another node rather than a tuning pass. The KV cache arithmetic we ran for a trillion parameter model is the same arithmetic at a lower read rate. The host CPU that feeds the GPU is the next constraint down the line.

Three questions for anyone sizing a Rubin order this quarter. Does the capacity model use the September figure or the launch figure, and who signed off on it? Has the eight GPU board been quoted at its revised memory capacity of 2 TB rather than 2.3? And when a vendor revises a table after the racks ship, what in your procurement process would have caught it?