GPU data center power: from GPU TDP to rack PDU to facility feed

A GPU cluster fails at the power layer before it fails anywhere else. You can have a clean InfiniBand fabric, a healthy NVLink topology, and a pristine driver stack — and still trip a 60 A breaker on the third synthetic NCCL allreduce of bring-up because nobody added up the per-PSU peaks correctly. This page is the planning sheet, with the public numbers from NVIDIA reference architectures, OCP specs, and ASHRAE.

If you've already designed the network and you're working on physical install, also see rack design and physical network. For the cooling side of the same equation see cooling.

The hierarchy

Every number you care about lives at one of five levels. Mix them up and the math comes out wrong by a factor of two.

+----------------------------------------------------------+
| 5. Facility feed (utility transformer, generator, ATS)   |
+----------------------------------------------------------+
| 4. Switchgear / UPS / PDU room                           |
+----------------------------------------------------------+
| 3. Row / busbar (overhead bus or floor-mount RPP)        |
+----------------------------------------------------------+
| 2. Rack PDU (vertical strip, busbar tap, or ORv3 shelf)  |
+----------------------------------------------------------+
| 1. Server PSU (per node, 4-6 PSU at 2.7-3.3 kW each)     |
+----------------------------------------------------------+

Each layer has a sizing rule, a redundancy convention, and a failure mode. The rest of this page walks them bottom up.

Node-level: GPU TDP plus everything else

The GPU is the loud part of the bill but never the whole bill. A real node draws what its eight GPUs draw, plus the system around them.

Two numbers, both real, both useful in different places:

• Sustained draw is what you bill, what your CRAH has to remove, what your PUE is calculated against. For a DGX H100 under a real training workload that's roughly 6.5 kW even though the nameplate is 10.2 kW.
• Design budget is what you size breakers and PDU outlets against. NVIDIA's published electrical spec for the DGX H100 chassis is six 3.3 kW PSUs at 200-240 V / 16 A — the chassis can pull 10.2 kW peak, and your rack PDU has to be able to deliver that without tripping.

The gap between sustained and peak is real. NCCL allreduce kernels on a fully loaded node will spike GPU current draw by 20-30% over steady-state for milliseconds at a time. If your breaker margin is 10%, you're going to find out about it the hard way.

Where the wattage actually comes from on a B200 node

People assume the GPUs are 100% of the node bill. They're 80-85%. The remaining ~15-20% is non-trivial:

• Two host CPUs at 350 W TDP each = 700 W (often Sapphire Rapids or Emerald Rapids on H100/H200, Granite Rapids or Genoa on B200/B300).
• DRAM: a B200 node typically has 2 TB of DDR5 across 32 DIMMs, at ~5-8 W per loaded 64 GB DIMM = 200-250 W.
• NVMe local storage: 8× 7.68 TB U.2 drives at ~10-15 W each = 80-120 W under load.
• NICs: 8× ConnectX-7 NDR HCAs at ~25 W each = 200 W. ConnectX-8 XDR is higher, around 35-40 W per HCA.
• PSU conversion losses: even at 96% titanium-rated PSUs, you lose ~4% of the input. On a 10 kW load that's 400 W of pure heat that doesn't show up in nvidia-smi.
• Fans: variable, but at full ramp on a hot day a B200 chassis can pull 600-800 W in fans alone.

If your power model only counts GPUs you'll be 18-22% short. Plan accordingly.

Rack-level: density is set by cooling, not by U budget

The U budget says you can put eight 4U boxes in a 42U rack. The cooling and power budget says you can't. Density limits look like this:

Air-cooled GPU racks max out around 40-50 kW in practice. NVIDIA's H100 SuperPOD reference architecture cites "power consumption per rack exceeds 40 kW" for the air-cooled SU layout, which is a polite way of saying you're at the ragged edge of what room-air cooling can carry.

The GB200 NVL72 is 120 kW in a single rack. Public numbers: four 30 kW (+1) power shelves feeding the busbar, 480 V three-phase input, full liquid cooling at the cold plate level. That's not a rack you "fit into" an existing room — it's a building decision. Coolant arrives at the manifold around 25 °C and leaves about 20 °C warmer at design flow.

A useful rule of thumb when sizing rooms:

rack_power_kw = node_count_per_rack * node_power_kw + switch_power_kw + overhead

Air-cooled H100 example:
  4 * 6.5 kW (sustained) + 2 * 1.5 kW (leaf switches) + 0.5 kW (mgmt) = 29.5 kW sustained
  4 * 10.2 kW (peak)     + 2 * 1.5 kW + 0.5 kW                       = 44.3 kW peak

Liquid-cooled GB200 NVL72 example:
  18 * 5.4 kW (compute trays) + 9 * 2.5 kW (NVSwitch trays) + overhead = ~120 kW design

The peak number is the one that has to fit on the breaker. The sustained number is what you write into the colo contract.

PDU types: 240 V single-phase, 415 V three-phase, busbar

There are three styles of getting power from the row to the rack, in increasing density order.

240 V / 230 V single-phase

What it is: a single hot, a neutral, ground. Typical North-America 208 V derived from 120 V/208 V three-phase wye, or EU 230 V phase-to-neutral. PDU strips look like the strip under your home desk, just with C13/C19 outlets and an inlet plug like an IEC 60309 32 A or NEMA L6-30/L6-60.

Capacity per circuit:

• 30 A at 208 V = 6.2 kW (5 kW derated at 80%)
• 60 A at 208 V = 12.5 kW (10 kW derated)
• 32 A at 230 V = 7.4 kW (5.9 kW derated)

A single 30 A 208 V circuit can't even feed one DGX H100. You'd need two for a single chassis at peak, and you'd be running the rack at 5+ circuits per side just to feed four nodes. That's a lot of inlets, a lot of cabling, and a lot of breakers to keep track of.

415 V / 400 V three-phase

What it is: three hot legs, a neutral, ground. Phase-to-phase voltage is 415 V (NA) or 400 V (EU); phase-to-neutral is 240 V / 230 V. Each PDU phase feeds a third of the rack outlets.

Capacity per PDU:

• 30 A 415 V three-phase = 21.6 kW (17.3 kW derated)
• 60 A 415 V three-phase = 43.1 kW (34.5 kW derated)

A 60 A 415 V three-phase PDU on each side of a rack (2 PDUs total, dual-corded) gives you 86 kW of name-plate capacity, which after derating and N+1 is enough to host one of those 40 kW air-cooled H100 racks comfortably with headroom for spikes. This is the standard for GPU racks today.

A single rack with 2× 60 A 415 V whips arriving from the row — one A-side, one B-side — is the dominant pattern in colos that host AI workloads. Each whip terminates at an inlet, the inlet feeds an intelligent vertical PDU, and outlets are distributed across the rack height.

Busbar systems (overhead or vertical)

What it is: a continuous metal bar carrying current along the length of a row (overhead) or down the height of a rack (vertical). Tap boxes drop power off the bar at any point. There's no fixed cable length, no whip, no termination at a panel.

Two flavors that matter:

Overhead AC busway (Starline, Universal Electric, etc.): 600-1200 A at 415 V three-phase, runs the length of an aisle, racks tap off it with plug-in modules. Lets you change rack power capacity by sliding a tap unit, without a facility electrician.

OCP ORv3 vertical 48 V DC busbar: a 44OU rolled-form bar inside the rack, fed by 33 kW power shelves (one shelf gives 33 kW, with N+1 it's ~26.5 kW usable). Busbars come rated 400 A, 700 A, or 1400 A. Compute trays blind-mate to the bar and pull 48 V DC directly. This is what GB200 NVL72 racks use — four 33 kW shelves stacked at the bottom, feeding a vertical bar that all 18 compute trays + 9 NVSwitch trays mate into.

Why DC busbars matter for high density: every conversion stage costs you 2-4% in heat. AC -> rack PDU -> server PSU -> 12 V rail -> point-of-load is four stages. AC -> shelf -> 48 V bar -> point-of-load is three. Over a 120 kW rack, one stage saved is ~3 kW of heat removed from the rack.

PSU redundancy: N+1 vs 2N, single-corded vs dual-corded

The PSU layout inside a node and the cord plan into the rack PDU are independent decisions. Both matter.

Inside the node: N+N or N+1

A DGX H100 has six 3.3 kW PSUs. N+1 means five active, one spare, total nameplate 5 × 3.3 = 16.5 kW which comfortably covers the 10.2 kW peak. With N+N you'd run three active and three spare, getting 9.9 kW of active capacity — too tight against a 10.2 kW peak, so DGX H100 uses N+1.

B200 nodes ship with 6-8 PSUs depending on form factor. Operators almost always run N+1 internally. The spare PSU exists so you can hot-swap a failed unit without taking the node offline.

Outside the node: cord topology

A node has multiple PSUs; the question is how many independent power feeds (A-side and B-side, sometimes more) those PSUs are split across.

The ground rule for production GPU: dual-corded, with each cord landing on a different PDU on a different upstream feed. A and B sides should be independent breakers, ideally independent UPS modules, ideally independent utility feeds.

What goes wrong: someone runs both cords of a "dual-corded" node into the same rack PDU because the other side's outlet was occupied. When that PDU's breaker trips, the node is gone — and you wasted the dual-corded design. Audit cord routing at install time, with photos. Then audit again after every maintenance window.

Power capping as a redundancy lever

Modern GPUs let you cap power via nvidia-smi -pl <watts> or the equivalent SMBPBI/MIG profile. If you size a rack to draw 80 kW peak but you only have 72 kW of A-side capacity (because B-side is your fail-over budget), you can cap the GPUs to 80% TDP and stay under both feeds.

What the cap costs: roughly proportional throughput loss. A 700 W H100 capped at 560 W (80%) does about 85% of its uncapped training throughput on most large-batch workloads — the relationship is sublinear because memory bandwidth, not compute, is often the bottleneck. For B200 the curve is similar.

UPS sizing and graceful shutdown

You don't run a 120 kW rack on UPS for an hour. You run it on UPS long enough to either ride through a transfer (a few seconds) or to gracefully shut it down (a few minutes). The question is which one.

Transfer-only UPS

Sized for ~30 seconds of full load. Job: hold the racks up while the ATS swings the facility from utility to generator. Generators take 8-15 seconds to come online and synchronize, so 30 s gives margin. UPS topology is typically static double-conversion (online) so there's no transfer time at the UPS itself.

Capacity math:

ups_kVA = total_load_kW / power_factor / efficiency
        = 120 kW / 0.95 / 0.94 ~= 134 kVA per rack of GB200 NVL72

For a 1 MW (~8 NVL72 racks + switching + storage) hall:
ups_kVA = 1000 / 0.95 / 0.94 ~= 1120 kVA, round up to 1.25 MVA

For 30 s of runtime at 1.25 MVA you need a battery bank of approximately:

energy_kWh = load_kW * runtime_hr = 1000 * (30/3600) = 8.3 kWh

That's small — a single rack of lithium batteries.

Graceful-shutdown UPS

Sized for 10-15 minutes. Used when there's no generator backup, or when you want to be sure GPU jobs can checkpoint before power dies. Now you need:

energy_kWh = 1000 * (15/60) = 250 kWh

That's a serious battery room — multiple racks of cells, dedicated cooling, fire suppression, monthly testing.

For most AI build-outs the answer is transfer-only UPS plus generator, sized for the full IT load plus cooling. Going graceful-shutdown-only and skipping the generator saves capex but it means every utility blip becomes a checkpoint loss for every running job. At GPU prices, that's expensive insurance to skip.

Generator vs grid-only

Grid-only is fine for dev and pre-prod tiers. For production AI training you want generator. Sizing rule:

gen_kW = (it_load_kw + cooling_load_kw) * 1.25 (margin)

For 1 MW IT load with PUE 1.20 (200 kW cooling overhead):
gen_kW = (1000 + 200) * 1.25 = 1500 kW = 1.5 MW

For 1 MW IT load with PUE 1.45 (450 kW air-cooled overhead):
gen_kW = (1000 + 450) * 1.25 = 1812 kW, round to 2.0 MW

The generator sizing math is one of the cleanest arguments for liquid cooling: lower PUE means a smaller generator means lower capex and a smaller fuel tank.

Power monitoring: what to instrument

Bare minimum, per rack:

• PDU SNMP per outlet: amps, volts, watts, phase. Most intelligent strips support SNMPv3 or the CDU-IEC standard. Poll at 30-60 s intervals. Alert on >85% of outlet rating sustained.
• PDU SNMP per inlet/breaker: total amps per phase. This is what tells you you're about to trip. Alert on >70% sustained, page on >85%.
• PDU outlet on/off control: someone will need to power-cycle a hung node remotely at 3 AM. Make sure remote outlet control works and is auditable.
• Per-PSU telemetry: from BMC / Redfish on each node. This catches a single failed PSU before it becomes "the node died because the second PSU failed too."

Bonus, and worth it:

• Branch circuit monitoring (BCM) at the RPP feeding the row. Per-circuit current at 1-second resolution. Tells you which row tripped and why.
• Building Management System (BMS) integration: tie PDU readings to the BMS so cooling can scale with load.
• InfluxDB / Prometheus / your TSDB of choice with retention long enough to do post-incident forensics. 90 days minimum, 1-year preferable.

The fastest way to find an under-engineered power plant is to plot rack inlet current against time during a multi-node NCCL test. You'll see clean stair-steps as nodes come online, then a fuzzy ceiling when something's clipping. If the ceiling isn't where you think it is, you have a problem upstream.

PUE for AI factories: what's actually achievable

Power Usage Effectiveness is total_facility_energy / IT_energy. A PUE of 1.0 is a thermodynamic impossibility (you have to remove heat somewhere). What you can hit depends entirely on cooling.

For AI factories at scale, liquid is the only path to PUE under 1.2. Hyperscalers public numbers cluster around 1.1-1.2 for their newest AI campuses. AWS reported 1.15 globally in 2024. CoreWeave designs all 2025+ facilities for liquid cooling at densities up to 130 kW/rack, and targets PUE in the 1.1-1.15 band.

The PUE delta is real money:

1 MW IT load, 1 year (8760 hr):
  PUE 1.45 = 1.45 MW * 8760 hr = 12.7 GWh facility energy
  PUE 1.15 = 1.15 MW * 8760 hr = 10.1 GWh facility energy
  Delta:    2.6 GWh saved per MW of IT per year

At $0.10/kWh that's $260k/year per MW of IT load.
For a 50 MW campus: $13M/year.

That's the capex case for liquid in one number.

WUE: water as the other number

Water Usage Effectiveness is liters_water / IT_kWh. PUE alone doesn't tell you the full picture — a facility can hit PUE 1.10 with evaporative cooling that drinks water by the megaliter, or PUE 1.20 with closed-loop dry cooling that uses essentially zero water once filled.

For AI build-outs in water-stressed regions (US Southwest, parts of EMEA), WUE drives site selection as much as land cost. A 50 MW AI campus at WUE 2.0 drinks ~875 megaliters/year — about 230 million gallons, or the residential water bill of a town of 5,000 people. At WUE 0.3 it's 130 megaliters, six times less. The same load.

Closed-loop direct-to-chip liquid + dry coolers is the design pattern that gives you both PUE 1.15 and WUE near zero, at the cost of capacity headroom in extreme heat. Most colos in 2025+ are quoting this combination for new AI halls.

Phase balancing on three-phase PDUs

A 415 V three-phase PDU has three hot legs (L1, L2, L3) and outlets distributed across them — typically every third outlet shares a phase. A rack drawing 30 kW total wants ~10 kW per phase. If the load is unbalanced (say 15 kW on L1, 8 kW on L2, 7 kW on L3), the breaker on L1 can trip even though the rack total is below the rack budget.

How to balance:

• Document outlet-to-phase mapping for every PDU model. Most intelligent strips publish this in their MIB or web UI.
• When seating PSU cords, alternate phases as you go (PSU1->L1, PSU2->L2, PSU3->L3, PSU4->L1, ...).
• After install, read per-phase current at sustained load and verify within 10% of mean. Re-route cords if not.

Worked example for a DGX H100 with 6 PSUs at ~1 kW sustained each:

Bad layout (typical mistake):
  PSU1->L1, PSU2->L1, PSU3->L1   = 3 kW on L1
  PSU4->L2, PSU5->L2             = 2 kW on L2
  PSU6->L3                       = 1 kW on L3
  Phase imbalance: ~50% — L1 is at 3x of L3.

Good layout:
  PSU1->L1, PSU2->L2, PSU3->L3   = 1 kW each
  PSU4->L1, PSU5->L2, PSU6->L3   = +1 kW each, total 2 kW per phase
  Phase imbalance: 0% — perfectly even.

The "good" layout takes the same install time and never trips a phase breaker prematurely.

Power for the rest of the rack: switches, storage, management

People plan power around the GPU nodes and forget the supporting cast.

For a typical compute rack with two leaves, the non-compute power is ~3 kW. On a 30 kW air-cooled H100 rack that's 10% of the budget. On a 120 kW NVL72 (where switches usually live in adjacent racks) it's 0% — but the adjacent network rack pulls 15-25 kW that has to be planned for too.

A common oversight: the switch uses 800G OSFP optics that pull 13-15 W each. A 64-port leaf fully populated with 800G OSFP burns ~1 kW in optics alone, on top of the switch ASIC. Make sure your switch power budget includes optics.

Rack weight and floor loading

Power planning sometimes forgets weight. A loaded GPU rack is heavy enough to be a structural concern.

Floor load classes:

• Standard raised floor: 750-1200 kg per tile (~370-600 kg/m²).
• Hyperscale slab: 1500-2500 kg/m² typical.
• AI-class slab: 3000+ kg/m² in newer purpose-built halls.

A rack of 4 DGX H100 (4 × 130 kg = 520 kg) plus the rack itself (~150 kg) plus PDUs + cables = ~700 kg. Comfortable on most modern floors. A GB200 NVL72 at 1800 kg loaded is at or above the rated capacity of older raised floors. Check the floor rating before you wheel one in.

For raised-floor halls hosting NVL72-class racks, the standard mitigation is to remove the raised floor under those racks and bolt directly to the slab, with cable trays going overhead instead of under. Some colos refuse NVL72 on existing raised floors entirely and require a slab pour.

Power monitoring metrics: what to put on the dashboard

Bare minimum, for every rack:

# Per outlet
pdu_outlet_amps{rack=R, side=A|B, outlet=N}
pdu_outlet_watts{rack=R, side=A|B, outlet=N}
pdu_outlet_state{rack=R, side=A|B, outlet=N} # on/off

# Per phase (for 3-phase PDUs)
pdu_phase_amps{rack=R, side=A|B, phase=L1|L2|L3}
pdu_phase_imbalance_pct{rack=R, side=A|B}

# Per inlet / breaker
pdu_inlet_amps{rack=R, side=A|B}
pdu_inlet_watts{rack=R, side=A|B}
pdu_inlet_pct_capacity{rack=R, side=A|B}

# Per node (from BMC / Redfish)
node_psu_watts{node=N, psu=1..6}
node_psu_state{node=N, psu=1..6} # ok / fail / absent
node_total_input_watts{node=N}

Alert rules that actually catch incidents:

• pdu_inlet_pct_capacity > 70 for 5 min: investigate
• pdu_inlet_pct_capacity > 85 for 1 min: page on-call
• pdu_phase_imbalance_pct > 25 sustained: rebalance during next maintenance
• node_psu_state == fail: ticket within 4 hours
• pdu_outlet_state changes outside maintenance window: audit (someone touched cords)

The single most useful chart is rack inlet amps as a stacked area, per phase, over time. You can see the load curve of a training job, the moment a phase imbalance creeps in, the spike when someone adds a new node, all at a glance.

Common power failure modes and how to detect them

What you see on a real cluster, in rough order of frequency:

1. Single PSU failure inside a node. BMC alerts; node keeps running on N+1. Replace at next maintenance window. If you don't have BMC alerting set up, you find out when the second PSU fails.
2. PDU outlet over-current trip. Single rack section dark. Nodes lost. Almost always: someone moved a node and didn't recompute the per-phase load, so one of the three phases is now 90% loaded while the other two are at 50%. Fix: rebalance phases.
3. PDU inlet breaker trip. Half the rack dark. Almost always: peak power sizing was done against sustained, not peak. Fix: cap GPU power, or migrate one node out of the rack.
4. A-side feed loss without B-side pickup. Every "dual-corded" node should ride through. Ones that don't are mis-cabled (both cords on A-side). Visit the cabinet, check, document.
5. Generator fails to start during a utility outage. If you didn't load-test the generator monthly, you find out at 4 AM. Quarterly black-building tests are cheap insurance.
6. UPS battery degraded. Battery monitoring should flag this 6 months ahead. If you skip the monitoring you find out during the only outage of the year.

Each of these has a corresponding alert. Build them.

Real-world capacity planning: from a customer ask to a rack count

The conversation usually starts with the customer saying "we need 256 H100s." The capacity planning translation:

Customer ask:    256 H100 GPUs
                 = 32 nodes (8 GPUs each)
                 = 32 * 6.5 kW sustained = 208 kW IT compute load
                 + 8 racks * 3 kW switching = 24 kW network
                 + 30 kW storage subsystem (NVMe-oF cluster)
                 = ~262 kW IT total

Cooling overhead at PUE 1.40 (air-cooled with containment):
                 = 262 * 0.40 = 105 kW cooling
Total facility:  262 + 105 = 367 kW

Rack count:      32 nodes / 4 nodes-per-rack = 8 compute racks
                 + 1 spine/network rack
                 + 1 storage rack
                 = 10 physical racks

Power feeds:     8 racks * 2 * 60A 415V whips = 16 whips at 60A 415V 3-phase
                 + 2 networking racks * 2 = 20 whips total
                 ~= 50 kVA per A-side feed, 50 kVA per B-side feed

Generator:       (262 + 105) * 1.25 = 460 kW, round to 500 kW
UPS:             500 kVA, transfer-only at 30 s runtime

If the customer pushes for 512 H100s instead, the math doubles. If they push for B200 or B300, you're suddenly above 1 MW, your rack density doubles or triples, and you've moved from "fits in a corner of the existing hall" to "needs its own row with new feeds."

The lesson: always do this math before quoting. A request for "512 GPUs" is two different builds depending on whether they're H100 or B300, and the second one needs cooling you may not have.

Power monitoring forensics: what a real outage looks like in the data

You only learn what to watch for after the first outage. Here's what to look for in three common scenarios.

Phase imbalance trip

Time     PDU-rk04-A-L1    PDU-rk04-A-L2   PDU-rk04-A-L3   PDU-rk04-inlet
14:32    18.2 A           14.1 A          12.8 A           45.1 A
14:33    21.3 A           14.0 A          12.7 A           48.0 A
14:34    24.7 A           14.0 A          12.7 A           51.4 A
14:35    27.9 A (TRIP)    14.0 A          12.7 A           54.6 A
14:35    --               --              --                -- (rack dark on A)

The total inlet (54 A) was below the 60 A breaker. But L1 alone hit 28 A which exceeded the per-phase limit. The signal: a phase climbing while the others stayed flat.

What was happening: a new node added to the rack went all on L1 because the installer didn't alternate phases. You catch it post-incident by walking the rack and checking outlet-to-phase mapping; you prevent it pre-incident with a phase-imbalance alert at >25%.

Single-side feed loss

Time     PDU-rk04-A-watts   PDU-rk04-B-watts   Sum-load    Node-PSU-fails
22:11    14400              14200              28600       0
22:12    0 (LOST)           14200              14200       0 (all PSUs riding through)
22:13    0                  28100 (DOUBLED!)   28100       0
22:14    0                  28100              28100       0

A-side feed lost, B-side picked up the load. The B-side now carries the full 28 kW. If B-side was sized for the full load (true 2N), this is graceful. If B-side was sized for normal load only (N+1), it's now at ~190% of its single-side capacity and at risk of tripping next.

The signal to watch: B-side load suddenly doubling. Means A-side died. Send the on-call before B-side trips.

Generator-not-online during utility loss

Time     Utility    Generator   UPS-batteries-runtime    Load
06:00    UP         OFFLINE     30 sec @ full load        1.0 MW
06:00:02 DOWN       STARTING    29 sec remaining          1.0 MW
06:00:08 DOWN       READY       21 sec remaining          1.0 MW
06:00:10 DOWN       (transfer)  20 sec                    1.0 MW (back online)

Or, the failure case:

06:00:02 DOWN       STARTING    29 sec
06:00:15 DOWN       FAILED-START                          1.0 MW (no generator)
06:00:25 DOWN       (still trying)  5 sec UPS left        1.0 MW
06:00:30 DOWN       (still trying)  0 sec — SHUTDOWN      0 (cluster off)

A black-building test once a quarter validates the generator actually starts. Skipping the test is how you find out at 6 AM that the battery failed two months ago.

Cost math: what a megawatt year actually costs

Power is one of the larger ongoing costs of an AI cluster, dwarfed only by depreciation on the GPUs themselves.

1 MW IT load, 24/7, 1 year (8760 hours):

  Energy at PUE 1.20:  1.20 MW * 8760 hr = 10,512 MWh = 10.5 GWh

  At $0.08/kWh (typical hyperscale wholesale): $841,000/year
  At $0.12/kWh (typical colo retail):          $1,261,000/year
  At $0.20/kWh (high-cost markets, EU peak):   $2,102,000/year

A 50 MW campus running 24/7 at PUE 1.20:

• $42M/year at $0.08/kWh
• $63M/year at $0.12/kWh
• $105M/year at $0.20/kWh

For comparison, the GPU depreciation cost on $200M of H100s over 4 years is ~$50M/year. Power is in the same order of magnitude. Site selection by power price is a five-to-nine-figure decision.

Cheaper power tends to come with:

• Cooler climate (lower cooling energy, free-cooling possible).
• Renewable generation nearby.
• Lower-density grid (sometimes).

Trade-offs include latency to user populations, network connectivity, and tax / labor regulations. AI campus site selection is now a multi-disciplinary team problem.

See also

• Cooling: air vs liquid — the heat side of the same equation
• Rack design — what a real GPU rack looks like with these power numbers baked in
• Physical network — cables, transceivers, BOM math
• InfiniBand architecture — fabric layer this power plant supports
• PCIe topology — node-internal bandwidth budget that lives on top of the PSU rails
• Health check runbook — daily checks include PSU and breaker status

Sources

• NVIDIA DGX H100 Electrical Specifications: 6× 3.3 kW PSU, 200-240 V, 16 A, 10.2 kW peak.
• NVIDIA DGX SuperPOD H100 Reference Architecture: 32 nodes per Scalable Unit, "rack power exceeds 40 kW" at air-cooled SU layout.
• NVIDIA GB200 NVL72: 72 GPUs/rack, 36 Grace CPUs, 13.4 TB HBM3E, 130 TB/s NVLink, ~120 kW continuous, 480 V 3-phase, four 30 kW power shelves, liquid cooling at the cold plate.
• NVIDIA Blackwell B200 datasheet: HGX B200 ~1000 W per GPU; full-spec B200 1200 W; B300 ~1400 W per GPU.
• Open Compute Project Open Rack v3: 33 kW power shelf (26.5 kW N+1), 48 V DC vertical busbar in 400/700/1400 A ratings, 44OU usable.
• ASHRAE TC 9.9 Thermal Guidelines (5th Edition): A1-A4 envelopes, recommended 18-27 °C, allowable up to 45 °C (A4).
• Hyperscale operator public PUE: AWS 1.15 global (2024); Microsoft WUE 0.30 L/kWh (FY24); CoreWeave new-build target 1.1-1.15 PUE at up to 130 kW/rack.