NVIDIA Cuts Vera Rubin’s Shipping Bandwidth Targets | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
NVIDIA Cuts Vera Rubin’s Shipping Bandwidth Targets
Published shipping figures show less HBM4 and NVLink bandwidth, faster scale-out networking, and largely unchanged compute targets, with different consequences across Vera Rubin systems.
NVIDIA has revised its Vera Rubin GPU specifications, reducing per-GPU HBM4 memory bandwidth from 22 TB/s to 19.2 TB/s and NVLink bandwidth from 3.6 TB/s to 3.0 TB/s. While theoretical compute figures remain unchanged, these bandwidth cuts impact data-heavy workloads. Conversely, scale-out networking speeds increased from 400 GB/s to 450 GB/s.
These adjustments vary by system, with the HGX Rubin NVL8 seeing additional reductions in memory capacity and training throughput. Buyers should re-evaluate capacity planning, as these changes affect memory-bound inference and communication-heavy tasks differently depending on the specific configuration.
NVIDIA has lowered Rubin’s published per-GPU memory bandwidth from 22 TB/s to 19.2 TB/s and NVLink bandwidth from 3.6 TB/s to 3.0 TB/s, according to ServeTheHome’s October 31, 2026 report. Scale-out networking moved in the opposite direction, rising from 400 GB/s to 450 GB/s per GPU.
The revisions matter for buyers sizing expensive Vera Rubin deployments around memory-bound inference or communication-heavy multi-GPU workloads. The headline theoretical compute figures remain intact, but the bandwidth available to feed those compute units and exchange data between GPUs is lower than initially advertised.
October 31 is the report date, not an announced specification-change date. ServeTheHome says NVIDIA updated its pages and architecture datasheet in September, and that the earlier figures were explicitly preliminary.
What Changed in Rubin’s Shipping Specifications
ServeTheHome’s comparison shows three bandwidth revisions alongside unchanged GPU memory capacity and theoretical compute ratings.
Per-GPU specification
Preliminary target
Shipping specification
Change
HBM4 capacity
288 GB
288 GB
Unchanged
HBM4 bandwidth
22 TB/s
19.2 TB/s
−12.7%
NVLink scale-up bandwidth
3.6 TB/s
3.0 TB/s
−16.7%
Scale-out networking
400 GB/s
450 GB/s
+12.5%
Theoretical NVFP4 inference
50 PFLOPS
50 PFLOPS
Unchanged
Theoretical NVFP4 training
35 PFLOPS
35 PFLOPS
Unchanged
Percentage changes above are calculated from the listed preliminary and shipping figures. The memory-bandwidth reduction is approximately 13%, using 22 TB/s as the baseline.
These units describe different resources. TB/s means terabytes transferred per second; PFLOPS means quadrillions of floating-point operations per second. A GPU can retain its arithmetic throughput rating while having less bandwidth available to move data into and out of that arithmetic hardware.
I’d use the shipping bandwidth figures as the procurement baseline. Preliminary targets explain the change in expectations, but they are a poor foundation for a new capacity plan once more concrete specifications are available.
NVL72, NVL8 and Superchip Have Different Revisions
The per-GPU changes carry through to larger systems, but the reductions are not uniform across NVIDIA’s lineup.
The NVL72 rack retains 20.7 TB of aggregate HBM4 capacity. Its published aggregate NVLink bandwidth falls from 260 TB/s to 216 TB/s, while scale-out networking rises from 28.8 TB/s to 32.4 TB/s.
Capacity and bandwidth answer different buying questions. Unchanged capacity means the published space available for model weights, caches and other GPU-resident data has not shrunk. Lower bandwidth reduces the peak rate at which those resources can be accessed.
Rack-level totals also need care: adding the bandwidth of 72 GPUs does not make that total available to a single GPU accessing its local memory.
HGX Rubin NVL8 Has Additional Cuts
The eight-GPU HGX Rubin NVL8 shows a larger revision. SiliconReport reports that system memory capacity falls from 2.3 TB to 2.0 TB, alongside the bandwidth reduction from 176 TB/s to 130 TB/s. NVLink Switch bandwidth drops from 28.8 TB/s to 24 TB/s.
Its dense training ratings also decline: NVFP4 moves from 280 to 270 PFLOPS, and FP8 from 140 to 130 PFLOPS. Consequently, “compute unchanged” accurately summarizes the main per-GPU comparison, but not every product configuration.
TechRadar also flags inconsistent HGX documentation, with older per-GPU figures appearing beside revised system totals. Buyers should request a configuration-specific specification from their supplier before assuming an NVL8 offers eight times the memory resources listed for another Rubin configuration. The system totals alone cannot establish the physical memory-stack arrangement.
The HBM4 Change Is a Lower Data Rate
Rubin’s main per-GPU comparison retains eight 36 GB HBM4 stacks, totaling 288 GB. The published memory interface remains eight stacks wide, with 2,048 bits per stack. The revision lowers the data rate from approximately 10.75 gigabits per second per pin to 9.375 Gbps per pin, according to ServeTheHome’s technical breakdown.
The bandwidth calculation is straightforward:
8 stacks × 2,048 bits × 9.375 billion transfers per second ÷ 8 bits per byte = 19.2 TB/s.
That explains how capacity can stay unchanged while bandwidth falls. The GPU still has the same published amount of memory and interface width; data moves across that interface at a lower rate.
ServeTheHome puts the original HBM4 specification’s target at 8 Gbps per pin. NVIDIA’s revised 9.375-Gbps figure remains above that baseline, although it falls short of the preliminary target.
NVIDIA has not publicly explained the revision in the supplied reporting. Memory-stack yields, controller limits and thermal constraints are possible explanations raised in coverage, not confirmed causes. The documented result is a changed balance of bandwidth resources; it does not establish why NVIDIA made the changes or prove a particular engineering failure.
Why Faster Scale-Out Networking Cannot Cancel the Cuts
HBM, NVLink and scale-out networking serve different data paths:
HBM bandwidth moves data between a GPU and its attached high-bandwidth memory.
NVLink scale-up bandwidth supports communication among tightly connected GPUs.
Scale-out networking connects systems through the broader cluster network.
The 12.5% scale-out increase can help workloads constrained by that network path. It cannot directly replace local memory bandwidth or restore the removed NVLink capacity.
My view is that treating the networking increase as compensation for the other cuts would be misleading. A workload waiting on HBM accesses cannot automatically use spare external network bandwidth to finish those accesses faster. The bottleneck’s location matters more than whether another specification improved.
Unchanged compute throughput makes that distinction especially important. Compute-bound work may be relatively insensitive to these revisions; work that already struggles to feed the GPU has less published bandwidth headroom.
What Buyers Can Infer About Inference Performance
Memory-bound inference is an obvious area to examine. During token generation, workloads may repeatedly move model weights and attention-cache data through memory. Batch size, model size, precision, cache behavior and parallelization determine how much that movement limits throughput.
A simple calculation shows the possible consequence without pretending to be a benchmark. For a fixed amount of data transferred at the published peak rate:
Moving from 22 to 19.2 TB/s increases the theoretical minimum memory-transfer time by approximately 14.6%.
Moving from 3.6 to 3.0 TB/s increases the theoretical minimum NVLink-transfer time by 20%.
These follow from dividing the old bandwidth by the new bandwidth. They apply to an isolated transfer under idealized conditions, not total inference latency. Real workloads overlap communication and computation, achieve varying fractions of peak bandwidth, and spend time on other operations. The supplied reports provide no independent measurements establishing a corresponding tokens-per-second loss.
For procurement, the useful questions are therefore specific:
Does the intended model fit? NVL72’s capacity is unchanged, while NVL8’s published capacity is lower.
Which data path limits performance? Local memory, NVLink and external networking require separate analysis.
What changes at the intended batch size? A deployment’s balance between compute and data movement can shift with concurrency.
Which configuration supports the performance commitment? Require the quoted system, precision, sparsity assumptions and software setup to match the proposed deployment.
The practical consequence is narrower than a blanket performance downgrade, but still material: bandwidth-based forecasts need updating, and NVL8 buyers also need to revisit memory-capacity assumptions. A published PFLOPS figure alone cannot settle either question.
Frequently Asked Questions
3 questions
1
How Much Did Rubin’s Memory Bandwidth Fall?
The main per-GPU specification fell from 22 TB/s to 19.2 TB/s, a reduction of approximately 12.7%. HGX Rubin NVL8’s published system bandwidth fell more sharply, by about 26%.
2
Did NVIDIA Reduce Rubin’s Compute Targets?
The main per-GPU theoretical NVFP4 inference and training targets remain 50 and 35 PFLOPS. The HGX Rubin NVL8’s published dense training ratings declined, so the answer depends on the configuration.
3
Will Inference Be 13% Slower?
That cannot be concluded from peak specifications. The effect depends on the workload’s bottleneck, achieved bandwidth, batching and communication patterns. The reports document specification changes, not measured application slowdowns.
