BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Nvidia's power pitch: 40,000 Rubin GPUs in 100MW, or 2.5kW a GPU at the meter
The zettaFLOPS figure is an estimate. The measured one, sitting in a GB300 example, is a 25 percent density gain, and it is paid for out of the safety margin.
The Engineer · Build desk

What happened
- Nvidia told Hot Chips that 40,000 Rubin GPUs, roughly 40 DGX SuperPODs, can be provisioned inside an example 100MW facility budget using its DSX MaxLPS site power tooling.
- It expects that installation to reach up to 2 zettaFLOPS of NVFP4 inference and up to 1.4 zettaFLOPS of NVFP4 training.
- Nvidia's measured GB300 case: static provisioning against 135kW peaks fits four racks in 540kW, with as much as 170kW never drawn.
Why it matters
- decision How many racks a signed megawatt buys is now a provisioning choice rather than an electrical fact, and the two answers differ by a quarter of the hall.
- constraint The extra density comes out of the peak reserve, so coincident-peak behaviour becomes a software responsibility instead of something absorbed by an oversized allocation.
- exposure Substation capacity and utility contracts get sized on 2.5 kW per GPU; if that number is optimistic the operator carries the power bill against compute that never arrives.
- precedent A GPU vendor selling land, power and shell design tooling makes site-level power engineering part of the accelerator purchase, and hard to source separately.
Divide the two headline numbers and you get the figure an operator will actually plan against: 2.5 kW of site power for every Rubin GPU installed [11], or 2.5 MW per SuperPOD [12]. That is measured at the meter, so it has to cover cooling, networking, conversion losses and everything else in the shell, not just the accelerator. Run the same division on the performance claim and the site delivers roughly 20 TFLOPS per watt for NVFP4 inference and 14 for training [10]. Those are the numbers to hold Nvidia to, and Tom's Hardware has already said the FLOPS half is estimated rather than measured, with real workloads landing significantly lower [1].
The measured part of the pitch is smaller and more useful. In Nvidia's GB300 example, provisioning statically against a 135 kW peak fills a 540 kW budget with four racks and leaves as much as 170 kW unspent [4], which is 31 percent of the allocation sitting behind a breaker doing nothing [13]. Reclaim it and a fifth rack fits inside the same budget [5]. That is 25 percent more installed compute per contracted megawatt [14], at an average allocation of 108 kW per rack rather than 135 [15].
Where that 25 percent comes from decides whether it travels. The control loop harvests the gap between what a group of racks could draw and what it does draw, watching power at chip, rack and group-of-racks level and moving slack to whichever system needs it [6]. Nvidia's own description of the problem is a load differential between racks, one busy and one not [7]. That differential is a property of the workload mix, not of the silicon. A hall running one synchronous training job across every rack has less to redistribute than a mixed inference fleet with idle capacity, and the rack-level profiles Nvidia ships for inference, training and memory-bound work [8] are an admission that the answer changes by job type.
Then there is the reserve. The five-rack configuration works partly because much less power is held back for peaks [5]. Static provisioning was wasteful, and it also failed safe: that stranded 170 kW was, incidentally, insurance. Dynamic allocation converts the insurance into inventory and moves the guard band into software. That is a defensible trade for an operator who can measure it. Note also what DSX stands for, which is Land, Power, Shell [2], and what that implies about where Nvidia now expects to be consulted.
What to watch
- Whether any operator publishes measured compute per megawatt at the meter for Rubin racks, rather than Nvidia's estimated zettaFLOPS.
- Whether utilities and colocation providers will bill on dynamically managed draw or keep charging against nameplate peaks, which would cancel the density gain commercially.
- Whether Nvidia discloses control loop response time and behaviour when a group of racks peaks simultaneously with the reserve reduced.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence42
- Adoption15
- Hype gap+34
- Incentives78
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Tom's Hardware, doing its own back-of-the-napkin math from publicly available Rubin specs, said it felt safe assuming those performance figures are estimated rather than measured, and that the maximum achievable FLOPS from real-life workloads is likely to be significantly lower.
ReportedSupportedSource: Tom's Hardware2 sources— create a free account to open themView cited source - [2]
At its Hot Chips presentation on the Rubin GPU, Nvidia said that all of Vera Rubin's power management technologies combined with its DSX MaxLPS (Land, Power, Shell) suite of design and site-level dynamic power management resources will let operators provision 40,000 Rubin GPUs, about 40 Rubin DGX SuperPODs, within an example fixed facility power budget of 100MW.
- [3]
Nvidia expects that hardware to deliver up to 2 zettaFLOPS for NVFP4 inference and up to 1.4 zettaFLOPS for NVFP4 training.
- [4]
In Nvidia's measured example using current GB300 racks, an operator statically provisioning for peaks could install four 135kW systems within a 540kW power budget, but in practice as much as 170kW of that budget might sit unused because of differences in rack utilisation.
- [5]
Nvidia's example shows five rack-scale systems installed within the same 540kW budget, and across those five systems the amount of reserve power allocated for peaks can be much lower.
- [6]
DSX MaxLPS applies a dynamic scheme continuously aware of power usage at chip level, rack level and groups-of-racks level; Nvidia's Dynamic Power Software control loop finds unused power and redistributes it to systems where it is most needed at that moment.
- [7]
A companion Nvidia blog post said past provisioning assumptions focused on fixed worst-case power peaks per rack, inflating power budgets and stranding allocation in racks that rarely use it; in its example, an application load differential between racks could not be re-routed under static provisioning.
- [8]
At rack level, DSX MaxLPS offers workload-specific power profiles, similar to quiet, balanced and high-performance modes on client PCs, assignable to systems running workloads such as inference, training, and more general memory-bound or compute-bound tasks.
- [9]
Tom's Hardware frames the ultimate constraint on rack-scale AI system performance as the amount of power that can be delivered to the building and into each rack, rather than individual chip performance.
- [10]
Against the 100MW site budget, the claimed throughput implies about 20 TFLOPS per watt for NVFP4 inference and about 14 TFLOPS per watt for NVFP4 training.
- [11]
Nvidia's example works out to 2.5 kW of facility power per Rubin GPU, covering everything at the meter and not only the accelerator.
- [12]
The same example allocates about 2.5 MW of site power per Rubin DGX SuperPOD.
- [13]
The unused 170kW in the GB300 example is about 31 percent of the 540kW budget.
- [14]
Going from four statically provisioned racks to five within the same 540kW budget is a 25 percent increase in installed rack count per megawatt contracted.
- [15]
Five racks inside 540kW averages 108kW per rack, 20 percent below the 135kW static peak allocation.
Sources
1 independent publisher whose own reporting we read for this story.
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
Entities
- NvidiaFollow
- NVIDIA DSX MaxLPSFollow
- Dynamic Power SoftwareFollow
- Nvidia RubinFollow
- Vera Rubin NVL72Follow
- Rubin DGX SuperPODFollow
- Nvidia GB300Follow
- NVFP4Follow
- DeepSeek-R1Follow
- Hot Chips 2026Follow
- Tom's HardwareFollow