TL;DR: Build it in five terms and expect the total to be roughly 1.9 times the GPU board power. GPUs first: 512 Blackwell-class parts at about 1,400 W is 717 kW. Then the rest of each node, meaning CPUs, memory, NICs, storage and fans, which is commonly 25 to 40 percent on top of the GPU power for a dense node. Then the network: switches plus roughly 2,048 transceivers at about 15 W each, which is about 31 kW that nobody budgets. Then storage and management. That sum is the IT load, around 1.1 MW. Then multiply by the facility's power usage effectiveness, typically 1.15 to 1.3 for a liquid-cooled hall, giving roughly 1.3 MW drawn. Finally, the number in the contract is larger again, because redundant A and B feeds each have to carry the full load, so reserved capacity is close to twice the draw. Quoting the 717 kW figure to a facilities team understates the requirement by about 3.6 times.
How to approach it
Name the terms before computing any of them, because the failure in this question is omission rather than arithmetic. Go GPUs, rest of node, network, storage and management, then apply PUE, then state the contracted figure separately. Give the transceiver term explicitly, since it is the one nobody includes. Close with what the number is used for, which is different for the electrician, the finance team and the capacity planner.
A strong answer
A typical situation: an engineer is asked for the power requirement of a new cluster and returns the GPU count times the board power. The facilities team designs to it, and the hall runs out of capacity during commissioning when the switches, transceivers and cooling plant turn on.
The derivation, term by term:
term 1: GPU board power
512 GPUs x 1,400 W = 716,800 W = 717 kW
term 2: the rest of the node
CPUs, DRAM, NICs, local NVMe, fans and power-supply losses
for a dense 8-GPU node this is commonly 25 to 40% of the GPU power; take 30%
717 x 0.30 = 215 kW
node subtotal = 717 + 215 = 932 kW
cross-check: 64 nodes x 14.6 kW per node = 932 kW, which is in the right range for a
Blackwell-class node
term 3: network
leaf and spine switches: 8 leaves plus spines, on the order of a few kW each
take 12 switches x 3 kW = 36 kW
transceivers: 512 node-to-leaf plus 512 leaf-to-spine links = 1,024 links
two modules per link = 2,048 modules
at about 15 W for a twin-port 800G OSFP: 2,048 x 15 = 30.7 kW
network subtotal = 36 + 31 = 67 kW
term 4: storage and management
a storage tier sized for an 18.7 GB/s checkpoint burst, plus head nodes, provisioning and
monitoring: take 60 kW for a cluster this size
IT load = 932 + 67 + 60 = 1,059 kW
term 5: facility overhead
PUE for a liquid-cooled hall with warm water: 1.15 to 1.3
at 1.2: 1,059 x 1.2 = 1,271 kW drawn from the utility
term 6: contracted capacity
A and B feeds each sized for the full load: about 2,542 kW reserved
sanity: 717 kW of GPUs becomes 1,271 kW drawn and about 2,542 kW contracted, a factor of 3.6
from the number most people quote, and every step of that factor is a real line item
Rack Power Delivery and Busways covers the per-rack side, where the useful figure is the current: a 132 kW rack at 415 V three-phase is about 185 A, and the reserved figure is roughly double. Cables, Transceivers and the Optics Power Budget covers term three, which is the one that surprises people because it lands on the switch rows rather than the compute rows.
Which number to give to whom:
| Audience | The number they need | Why |
|---|---|---|
| Electrical engineer | Amps per rack position, and the peak | They design breakers and busway taps, and they work in current |
| Facilities and cooling | IT load in kilowatts per rack and per row | Heat rejection is sized from the IT load, not the utility draw |
| Colocation contract | Reserved capacity, both feeds | This is what is billed monthly whether drawn or not |
| Finance | Drawn kilowatt-hours plus the reserved charge | The bill has two components and they behave differently |
| Capacity planner | Headroom to the next rack | Whether the site can take the next expansion without construction |
The transient belongs in the answer too, because it changes the design rather than the total:
a training cluster is a synchronized load
every GPU stalls together during a collective and resumes together
integrator guidance sizes for peaks around 1.4x nominal rather than for the average
at 1,059 kW of IT load that is a swing toward 1,483 kW in milliseconds
the remedies are power capping through nvidia-smi or a DCGM policy, deliberate
desynchronization, or on-rack energy storage
sanity: capping to 90% of board power costs a few percent of throughput and cuts the peak by
the same 10%, which is far cheaper than upstream electrical capacity
The reversal condition: for an inference cluster rather than a training one, several of these terms move. The load is not synchronized, because requests arrive independently, so the 1.4 times peak factor does not apply and the hall can be provisioned closer to the average. The network is smaller, since inference replicas rarely need a non-blocking fabric between nodes, which removes much of term three including a large share of the transceivers. And utilization is lower and more variable, so the gap between contracted and drawn power is wider and the reserved-capacity charge dominates the bill. Applying a training cluster's power model to an inference deployment overstates the requirement and overpays for reserved capacity.
What interviewers probe next
- "Where does the 30 percent for the rest of the node come from?" Node-level measurement, which is what
ipmitoolor a Redfish power reading gives, against the summed per-GPU figure from DCGM. Measure it rather than assuming it. - "What PUE would you assume?" State it as an assumption and say what it depends on: climate, water temperature, and whether the hall uses chillers or dry coolers.
- "Why is contracted capacity twice the draw?" Because both redundant feeds must carry the whole load, and the provider reserves against that.
- "How would you verify the model after deployment?" Sum
DCGM_FI_DEV_POWER_USAGEper rack and compare against the metered PDU reading; the gap is everything that is not a GPU.
Common mistakes
- Quoting GPU count times board power as the cluster's power requirement.
- Omitting transceivers, which are about 31 kW at this scale and land on the network rows.
- Ignoring PUE, so the utility draw is understated by 15 to 30 percent.
- Conflating drawn power with contracted capacity, which differ by about a factor of two.
- Applying the training cluster's 1.4 times peak factor to an inference fleet, where the load is not synchronized.
Key takeaways
- Five terms: GPUs, rest of node at 25 to 40 percent on top, network including transceivers, storage and management, then PUE.
- 512 GPUs at 1,400 W is 717 kW of boards, about 1,059 kW of IT load, roughly 1,271 kW drawn at PUE 1.2, and about 2,542 kW contracted.
- Transceivers alone are about 31 kW for 2,048 modules at 15 W, and they sit on the switch rows.
- Give amps per rack to the electrician, IT load to facilities, reserved capacity to the contract.
- Training loads are synchronized, so size for about 1.4 times nominal; inference loads are not.