An AI megawatt is not a megawatt

A grid request starts before a facility nameplate

A grid request concerns the connection point and its margins. Facility nameplate covers the building, including cooling, power conversion, and lighting. IT nameplate covers servers and supporting IT; rack nameplate draws a tighter circle around the cabinet. Average demand measures the flow over time. Each can be quoted in megawatts while describing a different purchase.

LBNL says conversions among annual energy, average and maximum demand, facility nameplate, and requested connection capacity need project-specific relationships. Its illustrative interconnection utilization is about 50%, allowing for redundancy and maintenance, with the value described as poorly documented. I would use the project’s own design and power agreement before converting a request into equipment. LBNL definitions.

I need the statement’s connection point, operating state, and time basis before calculating a GPU count. Requested power and occupied halls can both describe a real project at different dates. The interval between them is time when capital is committed and the proposed service is still waiting.

The calculator follows the power into the rack

The calculator and workbook use NVIDIA’s whole-rack requirement of up to 142 kW for 72 B300 GPUs. The examples scale 1, 10, 100, and 1,000 MW at the selected electrical point. I use the conversion to compare assumptions about equipment that could fit. NVIDIA’s rack specification supplies the denominator.

Facility nameplate divides by PUE once; IT nameplate skips that division. A 10% external-IT allowance divides the IT budget by 1.10 because it adds to rack power. Whole racks round down from the workbook’s rack equivalents. Computational utilization changes annual GPU-hours while the installed rack count stays fixed.

Once the physical capacity is bounded, follow the data-center financing waterfall from construction and power delivery to customer acceptance, debt service and the cash left for equity.

Facility power funds IT, then racks

I start with 1,000 MW of total facility nameplate, then use PUE to allocate IT power and an external-IT factor to reserve the network, storage, support servers, and management outside the racks.

Holding every rack at GB300 NVL72 isolates the electrical conversion. A campus mixing accelerators, CPUs, generations, spares, and partially occupied halls needs its own equipment inventory.

The order matters. Dividing facility power by PUE pays for building overhead. Reserving the IT outside the rack pays for supporting equipment. The remaining power buys rack equivalents. Charging building overhead again would shrink the modeled fleet twice.

PUE is an energy ratio measured over a period. Peak electrical and cooling design also needs its load point, weather, redundancy, and power caps. I would keep the annual allocation calculation beside the project’s electrical one-line, cooling design, and vendor configuration. Those documents determine whether the counted machines can run together under the chosen policy.

An annual average can coexist with a more demanding peak. I would require the installation design to support the operating policy before assigning value to every modeled GPU.

Scroll horizontally to inspect the figure →

The whole rack needs up to 142 kW

One liquid-cooled GB300 NVL72 rack contains 18 compute trays, 72 B300 GPUs, and 36 Grace CPUs, with a requirement of up to 142 kW. Each tray includes ConnectX-8 adapters, a BlueField DPU, boot storage, and local cache alongside four GPUs and two CPUs. NVIDIA’s rack and tray specifications count the equipment inside that cabinet.

I start with rack power because per-GPU thermal design power leaves out CPUs, memory, NVLink, storage, adapters, management hardware, and internal conversion losses. Those components draw from the same electricity budget.

The “up to” requirement sizes this rack-count exercise. Annual energy needs the workload’s power profile. I would credit lower average draw as additional installed capacity only when the electrical design supports that policy, rather than also claiming the same reduction as an energy saving.

Eight racks leave the campus network unresolved

NVIDIA’s eight-rack bill of materials totals 576 GPUs, 44 compute-core switches, 11 converged-core switches, and 16 out-of-band management switches. The lower-input case uses SN5600 switches at 940 W and gives 53.27 kW, or 4.69% of the racks’ combined 1.136 MW nameplate, before storage, support servers, customer-edge equipment, or further tiers. The bill of materials, SN5000 power specifications, and SN2201 specification let you reconstruct that floor.

The bill of materials and logical architecture name SN5600, while the hardware page names SN5610. The latter specifies 900 W with passive cables and 2.08 kW with 64 optical modules. Using that optical comparator for 55 high-speed switches raises the total to 115.97 kW, or 10.21% of rack nameplate. I treat that as a comparison of optics assumptions, with each model named in the BOM, hardware page, and specification.

The campus fleet has roughly 100,000 compute trays, far beyond the eight-rack design point. NVIDIA introduces a super-spine around 1,024 nodes and divides fabrics in larger designs. I would price the scale-out, storage, customer, support, and management networks for the proposed campus instead of multiplying the small design unchanged. Scaling architecture.

I test external-IT allowances of 6%, 10%, and 14%. Six percent clears the passive-switch floor; ten approaches the optical comparator before unquantified support equipment. Fourteen comes from a GB200-era Epoch IT/server decomposition, which checks magnitude across generations. The table preserves the underlying switch reconstruction.

The facility reference yields 402,574 B300 GPUs

I get 402,574 installed modeled B300 GPUs from the facility reference: divide by PUE, reserve external IT, and convert the rack power at NVIDIA’s requirement. The table gives each intermediate result. LBNL’s 1.145 PUE describes its estimated 2024 average for AI facilities; NVIDIA supplies the rack specification and LBNL supplies that energy-ratio input.

The efficient and conservative assumptions span 434,856 to 355,819 GPU equivalents. Their 79,037-GPU gap is about 1,098 racks. I use that spread to compare the overhead assumptions; the scenarios assign no probabilities.

The wrong electrical starting point can overwhelm that sensitivity. A grid request leaves equipment unknown. Dividing an IT figure by PUE charges for building overhead a second time.

Scroll horizontally to inspect the figure →

An IT gigawatt fits more GPUs than a facility gigawatt

Epoch’s gigawatt cost model begins with IT nameplate and applies PUE and utilization for operating energy. A 10% external-IT allowance then leaves 909.09 MW for racks and supports 460,948 modeled B300 GPUs, roughly 58,000 more than my facility case. Building overhead sits outside that gigawatt. Epoch’s model.

A one-gigawatt grid request yields no installed-fleet estimate. LBNL’s illustrative 50% utilization gives 500 MW of average facility draw and 4.38 TWh per year. Facility nameplate could still be 1 GW, 700 MW, 500 MW, or phased halls, with PUE, IT mix, density, and occupancy to determine. LBNL’s definitions.

A campus can be real without being complete. Epoch’s hub describes phased openings and uncertain incremental timelines. I would put requested, energized, commissioned, and occupied power on the project’s schedule, then price the capital needed to carry each interval. The full-build power number leaves the revenue start date open.

Busy accelerators can still waste work

Powering the reference fleet for a year counts 3.53 billion GPU-hours. The workload determines how much computation and preserved progress those hours buy.

LBNL assumes 80% computational utilization for training, within a 75%–85% range, and 20% for inference by 2030, with a 30% high-inference case. Those factors give the reference fleet 2.64–3.00 billion training full-load-equivalent GPU-hours, 0.705 billion at 20% inference, and 1.06 billion at 30%. I keep those workload cases in the LBNL framework.

The result depends on architecture and hardware generation. Precision, sparsity, and communication change the work behind it. Checkpointing and failed jobs decide how much of that work survives, while software and throttling change its delivery.

Google’s 2025 TPU fleet study distinguishes scheduling availability, runtime progress, and program efficiency. Work since the last saved checkpoint disappears on failure; an optimization can lower hardware utilization while shortening the job. I would measure preserved progress and completion time alongside chip activity. The fleet study supplies that measurement approach for this different hardware.

Idle capacity need not be useless capacity. Google’s earlier technical account recommends reserves and hot spares for availability and recovery. I would judge headroom by the peak or service commitment it protects. Maximizing utilization can remove the slack that makes the service dependable. Goodput and recovery.

A reserved machine can earn a payment while idle. A busy internal machine can earn no external revenue. I would connect equipment to cash through the customer contract, delivery obligations, prices, and service credits.

Scroll horizontally to inspect the figure →

The power needs a date and a paid job

I would ask for the phase’s power allocation and date, supported equipment, workload, and paid service obligation. Explicit assumptions make a range assessable. Combining a request, installed equipment, and active computation into one number hides the steps an investment still has to fund.

The time between those steps may matter more than a better overhead factor. Commissioning, scheduling, and recovery can make existing racks productive sooner. The following fields connect the power number to the installation and service behind it.

Texas has a date problem before it has a GPU count

ERCOT’s July 29, 2026 presentation reports about 474 GW of large-load requests using June data, roughly 90% from data centers. Its April preliminary forecast puts 2032 demand near 367,790 MW and says that planning snapshot exceeds expected growth. I would keep those populations and dates apart: subtracting them would invent spare power. The queue presentation and preliminary forecast describe different planning questions.

I would match equipment delivery to the allocation that can energize for that phase. ERCOT’s September 3 Batch Zero classifications remained conditional on verification and other requirements. The adopted large-load standards took effect October 8, with project treatment dependent on its agreements. The conditional classifications and adopted rule describe the commitment before power becomes usable.

The intermediate agreement requires a $100,000 study fee and $50,000 per requested MW in security. Agreement-stage security becomes the greater of $50,000 per contracted MW or allocated system-upgrade costs, while direct connection costs are nonrefundable construction contributions. Refundable security ties up liquidity; construction contributions spend it. I would credit the intermediate amount when moving to the next stage, as §25.194(d) and (f) require, to avoid charging the security twice.

Energization returns 20% of the remaining security balance, with later returns tied to milestones. A phased schedule missed by 24 months starts a notice and security process for the schedule as a whole. I would price that expensive option alongside the unresolved minimum-billing terms. The checked July proposal for at least 20 years of billing was still a proposal: the adopted interconnection rule assigns those charge details to the billing proceeding.

The archived site example uses 80 MW at 70% average load: 490,560 MWh in a non-leap year. At an assumed $65/MWh, supply costs $31.89 million before delivery and other bill items. A delay at $150,000 a month costs $2.7 million over 18 months. I would fund the wait as well as the eventual electricity bill.

A data-center certification leaves route-specific eligibility to check under the Texas tax rules. A water budget can cover a year and still leave the cooling system short in the week that matters. The water framework leaves that physical delivery question to the facility. I would tie equipment and customer promises to the phase’s usable power and cooling, then calculate its supported fleet.

The count earns its value when the service works

The engineering comparison leaves a named campus’s firm power, cooling envelope, topology, equipment mix, occupancy, and bookings to verify. Storage and support power also remain incompletely quantified outside the eight-rack reconstruction. I would resolve those design inputs before committing the whole installation budget.

I count 402,574 modeled B300 GPUs under the declared facility assumptions. I would value them through the dated installation and workload record, followed by the contract they can serve. A different generation or workload needs its own conversion; those B300 units and GPU-hours cannot be relabeled as H100-equivalents, tokens, training runs, or cash.

Once the power requirement is clear, the financing question begins. Hidden hardware financing compares debt, equipment, and parent-capital claims around physical AI infrastructure.

The power earns its return through the service

I would value the project through the dated commitments that turn power into supported machines and those machines into dependable service. The conditional GPU count sizes the equipment. An energized phase, preserved workload, and paying customer earn the return.