Nvidia Took 13 Percent Off Vera Rubin's Memory Bandwidth. The Eight-GPU Board Lost 26.

Vera Rubin is in full production and shipping today, according to Nvidia. The specification page for the rack it ships in still contradicts itself.

The HGX page is the clearest case. The system line for the eight-GPU Rubin board reads 2 TB of HBM4 at 130 TB/s. Four rows below, under Individual GPU Specifications, the same page lists 288 GB at 22 TB/s and 3.6 TB/s of NVLink. Divide 130 TB/s by eight GPUs and you get 16.25 TB/s each. Multiply 288 GB by eight and you get 2.3 TB, which is the capacity the page no longer quotes. Two documents from one vendor, two different answers about one part, with a purchase order somewhere in between.

This is not a recall. It is a specification revision, and the revision happened in September without an announcement. What makes it a story is not that Nvidia lowered a number. It is that the numbers customers were sizing clusters against are still on the same website, in the same font, one scroll apart, and that the smallest system took the deepest cut.

The edit, and the month nobody noticed

On 1 September, the Vera Rubin NVL72 page said each Rubin GPU carried 288 GB of HBM4 at 22 TB/s, with 3.6 TB/s of NVLink 6, for a rack total of 1,580 TB/s of memory bandwidth and 260 TB/s of NVLink. By 11 September, the same page said 19.2 TB/s, 3 TB/s, 1,400 TB/s and 216 TB/s. Wccftech pinned the window by comparing Wayback Machine snapshots from those two dates. IT Home had already compared Nvidia's October documentation against a copy saved in June, and Guru3D picked it up from there.

There was no press release and no footnote explaining the change. The revised figures sat on the site through the rest of September and most of October before trade press reported them.

The deltas are not uniform, which is the first clue that this is not a rounding exercise. Per GPU, memory bandwidth fell 12.7 percent and NVLink 16.7 percent. The two-GPU superchip went from 44 to 38.5 TB/s and from 7.2 to 6 TB/s of NVLink. At rack level, memory bandwidth fell 11.4 percent and NVLink 16.9 percent. Memory capacity did not move at 288 GB per GPU or 20.7 TB per rack, and the headline 50 petaflops of sparse NVFP4 inference did not move either. One line went up: scale-out networking, the fabric between racks rather than inside one, rose 12.5 percent, from 28.8 to 32.4 TB/s.

So Nvidia took bandwidth out of the package and added bandwidth between packages, in a single edit, and said nothing about why.

A bandwidth number is a pin speed wearing a suit

HBM4 has not changed shape. Each stack is 2,048 bits wide, and a Rubin GPU carries eight of them, which is where 288 GB comes from at 36 GB per stack. Bandwidth is stack count times lanes times lane speed, and the first two are fixed by the package. The only variable is how fast each pin runs.

Twenty-two terabytes a second across eight stacks works out to roughly 11.7 Gbps per pin. Nineteen point two works out to roughly 9.4 to 9.6. ETNews, which reported the change on 28 October, put the same arithmetic in exactly those terms and drew the obvious conclusion: Nvidia eased the pin speed requirement, and pin speed is where HBM4's manufacturing risk lives. The standard doubles the interface width from HBM3E and, for the first time, moves a logic base die into the stack. Hitting a high bin across eight stacks per GPU, at volume, is a yield problem before it is anything else.

JEDEC's HBM4 baseline is 8 Gbps per pin, or about 2 TB/s per stack. Even after the revision, Nvidia is asking for roughly a fifth more than the standard specifies, per stack, on every stack, in every GPU. That is still an aggressive part. It is just less aggressive than the number the company published at CES.

The history makes the revision look less like a surprise and more like an invoice arriving. TechPowerUp's reporting traces Rubin's per-GPU memory target climbing from 13 TB/s at GTC 2025 to 20.5 TB/s in September 2025 to 22 TB/s at CES 2026, with a SemiAnalysis note saying SK hynix and Samsung were struggling to reach the final figure and that early shipments would land nearer 20 TB/s. TrendForce warned in September 2025 that if volumes fell short or costs ballooned, Nvidia "may abandon the upgrade or segment its platform products." Nineteen point two is the fallback, and it lands just below the 20 TB/s those early reports expected.

By ETNews's reading, the looser bar helps all three memory makers, since more stacks clear qualification and the gap between the fastest supplier and the rest narrows. That is a reasonable trade for a company trying to ship racks. It is a worse trade for anyone who bought a cluster on the assumption that 22 was real.

The eight-GPU board is where it gets expensive

The NVL72 gets the headlines and the hyperscalers. The HGX Rubin NVL8 is what most of the market can actually order: a standard eight-GPU baseboard, paired with either a Vera CPU or an x86 host, sitting in a normal server rather than a purpose-built rack. It also took the worst cut on the sheet.

System memory bandwidth on that board fell from 176 to 130 TB/s, a 26.1 percent reduction, and total HBM4 capacity fell from 2.3 TB to 2.0 TB. NVLink Switch bandwidth dropped from 28.8 to 24 TB/s. Dense training throughput slipped from 280 to 270 petaflops of NVFP4 and from 140 to 130 of FP8. Scale-out networking rose, as it did everywhere else, from 1.6 to 1.8 TB/s.

Run the division and the board stops reconciling with the GPU it is built from. Eight GPUs at 19.2 TB/s would be 153.6 TB/s; the page says 130. Eight at 288 GB would be 2.3 TB; the page says 2.0, which is 250 GB per GPU. TechRadar, working the same numbers, laid out the two plausible explanations: eight smaller HBM4 stacks running at just under the JEDEC baseline of 8 Gbps per pin, or one of the usual eight stacks disabled per GPU, the trick Nvidia used to build the 80 GB H100. Nvidia has not said which, and the two readings are not equivalent for a customer. One costs capacity. The other costs capacity and changes the memory topology a kernel sees.

This matters commercially because the NVL8 is the enterprise and mid-tier cloud product. CoreWeave's own launch post for the board, published 21 October, quotes 2 TB of HBM4 and 130 TB/s as the specification, alongside 24 TB/s of NVLink Switch bandwidth, and presents them as the reason the system handles million-token KV caches. CoreWeave is not misquoting anything. It is quoting the post-edit page, five days before the trade press picked the edit up, and the number it is selling against is 26 percent below the one Nvidia put on a slide in January.

Nvidia's answer is a definition, not a measurement

Nvidia's first public comment came on 29 October, in response to Wccftech. A company representative said the figures published during development "were preliminary architectural targets" and that the final specifications "reflect what the system sustains at qualified, volume production." The fuller statement added that "individual component specifications do not determine application performance," that Vera Rubin is in full production and shipping, and that third-party agentic benchmarks have been available for months, measured on production specifications, showing 30x more performance per watt and 30x more tokens per dollar against GB300 NVL72.

Read plainly, that is a concession dressed as a clarification. Preliminary targets that the hardware did not reach are, by definition, numbers that were published and not met. What the statement does not do is say which component set the ceiling, whether the limitation is the memory controller, the stacks, or the package, or when Nvidia knew. It also does not address the two documents that still disagree: the HGX page's per-GPU table, and Nvidia's own architecture deep dive from 21 July, which still states that HBM4 provides "up to 22 TB/s of bandwidth" per GPU and that NVLink 6 delivers 3,600 GB/s. The technical blog has not been annotated. Neither has the GPU table.

The benchmark argument is the strongest thing Nvidia has, and it is checkable in principle. If AgentX and AgentPerf results really were measured on hardware running at 19.2 TB/s, then the shipping system has always behaved this way and the June page was aspirational for months while customers were sizing against it. That is a better defence than it first appears. It is also an argument that the published figure was wrong for longer than the revision admits.

What nobody has done is rerun the marketing. The NVL72 page still promises up to 10x more tokens per megawatt and one-tenth the cost per million tokens versus GB200 NVL72, footnoted "LLM inference performance subject to change." Nvidia has not said whether those projections were recomputed on the lower bandwidth. A 10x efficiency claim resting on a memory subsystem that has since been revised down by 13 percent is not automatically wrong, because the comparison baseline has not moved. It is, at minimum, a claim that should come with a date.

On paper, the lead changed hands

AMD spent the same period selling the opposite strategy. The Instinct MI455X carries 432 GB of HBM4 across 12 stacks at 23.3 TB/s, and AMD gets there with width rather than speed: 12 stacks at roughly 7.6 Gbps per pin, which is below the JEDEC baseline. AMD never needed above-standard memory because it bought more lanes instead.

At launch in July, AMD claimed 6 percent more memory bandwidth than Vera Rubin's published figure. Against 1,400 TB/s, the 72-GPU Helios rack's 31 TB of HBM4 and 1.7 PB/s of memory bandwidth is roughly a fifth ahead, and its 260 TB/s of scale-up bandwidth now exceeds Nvidia's 216 TB/s where the two were level in the summer. Nvidia's scale-out increase trims AMD's claimed advantage there, but it does not reverse it.

Two caveats belong next to that comparison. These are vendor numbers on both sides, with no independent rack-scale production benchmarks published for either platform, and Nvidia's software position is not a spec sheet line item. The second caveat is funnier: AMD's own product page still lists Vera Rubin at 288 GB and 22.0 TB/s in its comparison table. The competitor's slide is now out of date in Nvidia's favour.

What a buyer should take from this

The useful lesson is not that Nvidia sandbagged a launch. Platform vendors revise targets constantly, and the revision here was disclosed, eventually, when a reporter asked. The useful lesson is that a specification page is a purchasing document with no version control, and that the gap between a page and a contract is where capital gets stranded.

Three questions follow from that, and none of them is exotic. Which line on the page applies to the SKU being quoted, per-GPU or system-level, because on the NVL8 they disagree by 26 percent. What is the measured bandwidth on the workload that matters, because decode-bound serving is limited by memory movement, as Nvidia's own engineers wrote in July, and a planner who modelled 22 TB/s has to redo the arithmetic at 19.2. And what happens contractually if the datasheet changes after the order, because the June version of this page is still in a public archive and the delta is now a documented fact that customers, analysts and competitors can all cite.

Scale makes those questions expensive to get wrong. The Japanese national AI infrastructure programme announced with Nvidia in July is planned around 27,500 Rubin GPUs and 13,750 Vera CPUs across 140 MW, according to the Japanese outlet Joho no Todai, which verified the spec change against Nvidia's current pages and flagged that performance estimates built on the July documentation now need recalculating. That is one project. Every capacity plan, power envelope and cost-per-token model built on the CES numbers has the same problem in miniature.

The memory industry, meanwhile, gets a quieter benefit. A lower pin speed requirement means more stacks pass qualification, which means more shippable HBM4 from SK hynix, Samsung and Micron in a year when HBM supply is the constraint on everything. Nvidia traded a headline for volume, and it is hard to argue that was the wrong call when the racks are shipping and the alternative was waiting for a bin that three factories were struggling to hit.

What is harder to defend is leaving the old number on the page. Archived documentation has made quiet revisions permanent, and the delta between 22 and 19.2 is now a data point rather than a rumour. The next time a vendor publishes a bandwidth figure, the first question a serious buyer should ask is which version of the page it came from.

Hardware sourcing decisions get made years before the datasheet settles, and the difference between a platform that meets its published numbers and one that revises them after the order is usually visible in the qualification process rather than the press release. At DMC we work with hardware teams on supplier qualification, cost modelling and production ramp planning, including the awkward part where the specification moves after the design is frozen. If your AI infrastructure roadmap is priced against a page that has since changed, let's talk.