The AI Megawatt Is Not a Megawatt

Direct answer: AI data center power

AI data center power claims are not interchangeable: a requested grid interconnection, total-facility nameplate, IT nameplate, installed accelerator fleet, and average utilized load describe different boundaries. A defensible GPU estimate requires the electrical boundary, PUE, network overhead, rack design, accelerator configuration, and utilization assumptions.

Original research artifact

A downloadable GB300 capacity model, sensitivity table, source ledger, methodology note, and three boundary diagrams.

What this page adds

Replace one-ratio gigawatt-to-GPU estimates with an explicit capacity ladder, sensitivity range, and boundary-specific evidence requirements.

Related research

• U.S. rare-earth magnet manufacturing capacity
• hardware startup financing
• Waymo financing structure
• can AI run a business

One gigawatt names several different assets

The same unit appears in utility filings, construction announcements, hardware plans, and investor models, but the numerator changes. An interconnection request is a right or request at the grid boundary. Facility nameplate includes cooling, power conversion, lighting, and other infrastructure. IT nameplate excludes that facility layer. Rack nameplate excludes much of the network, storage, and control plane. Average demand is a time-weighted flow. None is a synonym for the others.

LBNL explicitly warns that annual energy, average demand, maximum demand, facility nameplate, and requested interconnection capacity are difficult to convert without project-specific relationships. Its glossary defines grid interconnection capacity as the maximum power requested at the connection point, including total facility needs and design margins. It also estimates current interconnection utilization around 50% because of redundancy and maintenance, while stressing that the value is not well documented. That estimate is useful for a worked example, not a universal ratio. [S8]

This creates a strict stopping rule: the source must state boundary, status, and time basis. “Announced 1 GW” is weaker than “1 GW requested.” Requested is weaker than firm. Firm is weaker than energized. Energized is weaker than commissioned and occupied. An installed fleet can be smaller still when the site is phased or reserves space and power for later equipment.

The conversion contract

The unit of analysis is one nominal “1 GW” statement. The primary reference case treats it as 1,000 MW of total facility nameplate. That choice is not a claim about how most announcements are written. It is a controlled starting point that permits PUE to be applied exactly once.

The hardware population is homogeneous GB300 NVL72. Real campuses mix accelerators, CPU fleets, storage systems, network generations, development clusters, spares, and partially occupied halls. Homogeneity is useful because it isolates the boundary problem. It is not a forecast of a specific company’s asset register.

The model has three explicit transformations. First, facility MW becomes IT MW by dividing by PUE. Second, IT MW becomes compute-rack MW by reserving an external-IT allowance for scale-out network, storage, support servers, and management. Third, compute-rack MW becomes rack equivalents and installed GPUs using NVIDIA’s rack specification. Every result is therefore conditional on the stated boundary and factors.

Start at the rack, not the GPU TDP

NVIDIA’s current enterprise reference architecture defines one GB300 NVL72 scalable unit as one liquid-cooled rack with 18 compute trays, 72 B300 GPUs, and 36 Grace CPUs. The full rack can require up to 142 kW. Each tray contains four B300 GPUs, two Grace CPUs, ConnectX-8 adapters, a BlueField DPU, boot storage, and local cache. The rack boundary already includes far more than accelerator silicon. [S1][S2]

This is why dividing one gigawatt by a per-GPU thermal design figure is structurally wrong. The electrical system serves CPUs, memory, NVLink, local storage, network adapters, management hardware, and power-conversion losses inside the rack before it serves anything outside the cabinet. Rack density is the appropriate first hardware unit for this model.

The phrase “up to 142 kW” also matters. It is a nameplate or maximum requirement, not an assertion that every occupied rack draws 142 kW every hour. Using it for installed-fleet capacity is conservative with respect to rack count at a fixed compute-rack nameplate. Using it for annual energy without a utilization model would be wrong.

The external network is not a rounding error

NVIDIA’s eight-SU bill of materials provides a rare public anchor. Eight racks contain 576 GPUs and require 44 compute-core switches, 11 converged-core switches, and 16 OOB management switches. Applying NVIDIA’s stated typical power gives 53.27 kW for the high-speed switches at the SN5600 passive-cable figure plus the SN2201 units. That is 4.69% of the eight racks’ combined 1.136 MW nameplate before storage systems, support servers, customer-edge equipment, and additional network tiers. [S3][S6][S7]

The documentation contains a material inconsistency. The BOM and logical-architecture tables name SN5600. The networking-hardware page names SN5610. The SN5610 specification lists 900 W with passive cables and 2.08 kW with 64 optical modules. Substituting the optical figure for the 55 high-speed switches raises the comparator to 115.97 kW, or 10.21% of rack nameplate. That is not a claim that every port is populated. It shows why chassis-only figures and optical population cannot be collapsed into one silent assumption. [S3][S5][S6]

The small-cluster BOM cannot simply be multiplied by hundreds. NVIDIA says larger designs use separate fabrics and introduces a super-spine around 1,024 nodes. It also identifies storage, customer, support-server, and management networks outside the compute fabric. A one-gigawatt homogeneous reference fleet would contain roughly 100,000 compute trays, far beyond the tested eight-SU design point. The external-IT allowance must therefore be a range, not an eight-rack extrapolation. [S4]

The model uses 6%, 10%, and 14%. Six percent sits just above the documented passive-switch floor. Ten percent is close to the optical-switch comparator before unquantified support equipment. Fourteen percent matches the total-IT/server overhead factor in a GB200-era Epoch decomposition and serves as an external magnitude check, not a GB300 measurement. [S9]

A 1 GW facility supports about 356,000 to 435,000 B300 GPUs in the model

LBNL estimates an average PUE of 1.145 in 2024 for facilities serving AI equipment. PUE is total facility energy divided by IT energy. In the reference case, dividing 1,000 MW by 1.145 leaves 873.36 MW for all IT. Reserving 10% on top of compute-rack nameplate for external IT leaves 793.97 MW for GB300 racks. At 142 kW per rack and 72 GPUs per rack, the result is 5,591.31 rack equivalents and 402,574 installed B300 GPUs. [S1][S8]

The efficient case uses PUE 1.10 and 6% external IT overhead. It produces 434,856 GPUs. The conservative case uses PUE 1.25 and 14% external IT overhead. It produces 355,819. These endpoints are not statistical confidence bounds. They show how two engineering choices move the installed fleet while the facility headline stays fixed.

The sensitivity is economically large. The 79,037-GPU spread between the endpoints is equivalent to about 1,098 GB300 racks. Yet it is still smaller than the definitional error produced by treating a grid request as IT capacity or by applying PUE to a number that already sits at the IT boundary.

The same “1 GW” headline can imply 461,000 GPUs—or no GPU estimate at all

Epoch’s current one-gigawatt cost model defines its site as 1 GW of IT nameplate, then separately applies PUE and utilization to estimate operating energy. Under this article’s 10% external-IT allowance, 1 GW at the IT boundary leaves 909.09 MW for compute racks and supports about 460,948 B300 GPUs. That is roughly 58,000 more than the reference facility-nameplate result because facility overhead sits outside the named gigawatt. [S10]

At the other extreme, a 1 GW interconnection request does not reveal installed fleet. Applying LBNL’s illustrative 50% average utilization produces 500 MW of average facility draw and 4.38 TWh per year. It does not reveal whether the site has 1 GW of facility nameplate, 700 MW, 500 MW, or a staged set of halls with future reserved capacity. It also does not reveal PUE, external-IT share, rack density, or occupancy. [S8]

A completed campus claim can still be temporally ambiguous. Epoch’s Frontier Data Centers Hub notes that large campuses come online in stages and that companies do not always clarify incremental timelines. The model therefore treats announced, under-construction, energized, commissioned, and occupied capacity as different states. [S11]

Installed accelerators are not annual compute output

The reference fleet contains 402,574 installed B300 GPUs. If they remain powered on for a full year, that is 3.53 billion powered-on GPU-hours. This number still says nothing about computational intensity. It counts time, not work.

LBNL defines utilization as average computational intensity relative to maximum. Its reference assumption is 80% for training, with a 75%–85% uncertainty range, and 20% for inference by 2030 with a 30% high-inference case. Applying those values to the same installed fleet produces 2.64–3.00 billion training full-load-equivalent GPU-hours, 0.705 billion at 20% inference utilization, and 1.06 billion at 30%. [S8]

Full-load-equivalent GPU-hours are still not useful-work units. They do not capture model architecture, precision, sparsity, communication overhead, checkpointing, failed jobs, software quality, thermal throttling, or generation-to-generation performance. They are best used to prevent an installed-fleet number from being mistaken for an annual output number.

They are even farther from revenue. Paid utilization depends on reservations, service-level obligations, internal workloads, customer mix, pricing, credits, and whether idle capacity is economically necessary to meet peak demand. Public engineering documentation does not answer those questions.

A minimum disclosure standard for every AI-capacity claim

A credible capacity statement should be reconstructable without private interpretation. The first field is the electrical boundary. The second is status. The third is time. Hardware, facility, and utilization fields follow. Without them, comparisons reward whoever uses the most expansive boundary.

For investors, the distinction changes capex intensity, commissioning risk, time to revenue, depreciation, and the meaning of utilization. For utilities, it changes load forecasts and reserve requirements. For operators, it changes whether a constraint sits in grid interconnection, mechanical plant, white space, power delivery, network fabric, storage, or workload scheduling.

The proposed standard is intentionally strict. A company can disclose ranges or mark fields unknown. It should not compress requested power, energized power, installed IT, and active compute into one promotional number.

• Boundary: interconnection, facility, IT, rack, or average draw.
• Status: announced, requested, firm, energized, commissioned, occupied, or active.
• Time basis: current, phase date, full-build date, peak, or annual average.
• Redundancy and margin: what is reserved and why.
• PUE: value, period, load point, and measurement boundary.
• IT allocation: server/rack, network, storage, support, and management shares.
• Hardware: accelerator generation, rack architecture, quantity, and mix.
• Utilization: computational, electrical, scheduling, and paid utilization kept separate.
• Staging: phase-by-phase energized and occupied capacity.
• Source: utility filing, one-line, vendor order, asset register, or management estimate.

What the model does not know

The model does not estimate a specific hyperscaler campus. It does not know the project’s firm interconnection, topology, PUE curve, cooling design, storage system, network port population, spares, power caps, rack-loading distribution, accelerator mix, occupancy, workload schedule, or customer bookings.

The 142 kW rack figure is a nameplate input. A site can install more racks than the nameplate arithmetic suggests if average or capped draw is lower, provided its electrical and thermal design permits that operating policy. The reverse can also occur when redundancy, stranded capacity, maintenance, or topology prevents full occupancy.

The external-IT range is not measured at gigawatt scale. It is bounded by a documented eight-SU switch reconstruction, an optics comparator, architecture requirements, and an external GB200-era sense-check. Storage and support infrastructure remain unquantified.

The final uncertainty is semantic. A “GPU” is not a stable performance unit across generations, precisions, models, software stacks, and workloads. This article therefore reports physical B300 units and B300 GPU-hours only. It does not convert them into H100-equivalents, FLOP/s, tokens, training runs, or revenue.

Downloads

The web article is the reading layer. These files preserve the supplied source package and model.

• Capacity conversion model (XLSX) — Formula-driven facility, IT, rack, network, utilization, and sensitivity workbook.
• Source ledger (CSV) — Primary and secondary sources with claims, definitions, limitations, and provenance.
• Claim ledger (CSV) — Load-bearing claims classified as observed, derived, scenario, or interpretation.
• Methodology appendix (MD) — Research contract, definitions, formulas, provenance, contradictions, and calculation checks.
• Sensitivity data (CSV) — PUE-by-external-IT-overhead matrix for installed B300 GPU equivalents.