Nameplate tells you what the equipment is rated to draw. It does not tell you what real workloads consume, how high the facility will actually peak, or how much electricity it will use over a year. Measured H100 workload traces show that each of those questions has a different answer — and capacity factor is the number that connects the facility rating to the energy bill.

The headline

Most compute-to-energy models begin with a simple multiplication:

GPU nameplate power × hours of use × PUE

For an H100, that often becomes:

700 W × 1 GPU-hour × 1.3 PUE = 0.91 kWh per GPU-hour

The arithmetic is clean. The assumption is not.

A public dataset from the National Laboratory of the Rockies measured H100 training, fine-tuning, and inference workloads at 0.1-second resolution, then used those profiles to simulate year-long facility demand. The measurements show that real workloads draw less than nameplate, whole facilities peak below their rated IT capacity, and annual energy use falls further still below the “nameplate running 24×7” shortcut.

The distinction matters anywhere GPU-hours are converted into kilowatt-hours: data-center demand forecasts, interconnection studies, energy procurement, compute economics, and energy-normalized compute indices.

First, define the terms

The confusion in most compute-energy estimates is terminological rather than mathematical. Each of these means something specific, and they are not interchangeable.

The measured workload profiles are already embedded in the facility simulation. The capacity factor already reflects workload draw, idle consumption, node occupancy, scheduling, and temporal demand patterns. Multiplying it by the duty factor or the peak derate again would count the same effect twice. The dashboard below enforces this: it asks which question you are answering, then shows only the factor and formula that belong to it.

Real workloads are not stress tests

The paper reports an H100 stress-test result of 668.2 W against a 700 W TDP. That is only a 4.5% gap — and it is the wrong comparison for a GPU-hour energy model.

gpu-burn is designed to push the device toward maximum sustained draw. Real jobs include loading, evaluation, checkpointing, communication, batching changes, and pauses between phases. Across the full busy period, the five published workload traces produce duty factors from 0.795 to 0.880 — real workload energy running roughly 12% to 21% below nameplate, averaging about 16%.

Capacity factor is where the forecast changes

The device-level correction is important. The facility-level correction is larger.

Consider the simulated 10 MW colocation facility at 80% target node utilization: rated IT load 10.0 MW, maximum simulated IT load 7.32 MW, average simulated IT load 5.91 MW, capacity factor 59.1%.

A nameplate-based annual forecast assumes:

10 MW × 8,760 hours = 87.6 GWh

The measured-profile simulation implies:

10 MW × 59.1% × 8,760 hours = 51.8 GWh

The difference is 35.8 GWh per year before PUE — 40.9% below the continuous-nameplate estimate. For the 1 MW inference facility, annual IT energy becomes approximately 5.81 GWh rather than the 8.76 GWh implied by continuous nameplate.

That difference affects utility load forecasts, generation and transmission planning, energy procurement, emissions estimates, behind-the-meter generation sizing, demand-charge expectations, and the valuation of power hedges attached to compute.

Capacity factor also changes the shape of risk

Capacity factor is an annual ratio, but it is produced by an hourly and sub-hourly load shape. At low and moderate utilization the simulated facility follows daily, weekly, and seasonal patterns. At high utilization the load flattens, because nodes saturate and jobs queue.

That creates a tradeoff. Higher utilization raises the capacity factor and steadies the load, which is easier for a grid to serve — but saturation raises queue times for training jobs and leaves inference requests unserved. In the 80% target-utilization simulations the colocation case produced mean queue times above six hours, while the inference case left a material share of requests incomplete under the study’s latency constraints.

Capacity factor is therefore not only an energy statistic. It is an operating-policy statistic. A facility can raise it by filling more of the day, but the commercial value depends on whether that loading comes from productive work, longer queues, degraded service, or flexible jobs shifted into cheaper hours. The operating frontier is drawable inside the dashboard above.

What this changes for a GPU-hour

The old shortcut treated every H100 GPU-hour as roughly 0.91 kWh at a 1.3 PUE. Using the average measured duty factor:

700 W × 0.839 × 1 hour × 1.3 PUE ≈ 0.76 kWh

That reduces the estimated energy content by about 0.15 kWh per GPU-hour. At small scale the difference looks minor. Across one million GPU-hours it becomes 910 MWh on the nameplate method against 763 MWh measured — a 147 MWh difference. At $50/MWh that is about $7,350 per million GPU-hours; at $200/MWh, about $29,400.

Those figures address device-energy conversion. They should not be confused with the capacity-factor adjustment used to forecast whole-facility annual energy.

What this changes for an energy-normalized compute index

An energy-normalized compute index is structurally a ratio: compute price divided by modelled energy content. The compute price may be observable from transactions. The energy content is a methodology choice.

A nameplate-derived denominator overstates device energy by 12% to 21% across the measured H100 workloads. A fixed energy-per-GPU-hour assumption also misses a finding from the inference traces: as request rate rises, power can flatten while throughput continues to improve, so energy per token falls even when server power barely changes. Two facilities running identical H100 hardware can deliver different energy per unit of compute because workload mix, batching, request rate, and operating policy differ.

The conclusion is not that energy normalization is impossible. It is that normalization moves basis risk into the denominator — which is a tradeable position rather than a removed assumption. Any benchmark normalizing compute by energy should disclose the hardware generation, workload basket and weights, utilization and request-rate assumptions, facility-overhead treatment, and its update process as hardware and software change.

The caveat that matters

This is an H100 calibration point, not a universal GPU law. The measurements do not cover H200, B200, B300, GB200 NVL, liquid-cooled rack systems, high-voltage DC architectures, or every training and inference workload.

The facility model also excludes cooling and other non-IT loads, and its utilization shapes come from external workload datasets rather than direct observation of a commercial hyperscale facility. The results should be used as measured evidence for H100 workloads, as a better calibration than nameplate-only arithmetic, and as a framework for asking the right question — not as a forecast for every AI data center.

The open dataset and tooling make the next step possible: repeat the measurement for newer hardware, more workload types, and real commercial operating profiles.

Use the right denominator

For equipment and infrastructure ceilings, start with nameplate. For a realistic facility peak, use measured peak behaviour. For annual energy, use capacity factor. For a GPU-hour, use a measured workload duty factor. And never multiply factors that already contain the same workload effect.

Data and methodology. Primary workload and facility data derived from Vercellino, Willard, Campos, da Silva Pereira, Hull, Selensky & Mueller, “Measurement of Generative AI Workload Power Profiles for Whole-Facility Data Center Infrastructure Planning”, arXiv:2604.07345, and the associated public dataset, DOI 10.7799/3025227 (CC-BY-4.0). The paper measured NVIDIA H100 training, fine-tuning, and inference workloads at 0.1-second resolution and scaled them through the DIPLOEE discrete-event facility model; the colocation and inference simulations cover one year at one-minute resolution and exclude cooling and auxiliary loads. Duty factors, capacity factors, nameplate comparisons, and derived energy examples on this page are analytical transformations of the published traces and facility tables, reproducible via scripts/nlr/build_nlr_data.py. Electricity-price examples are illustrative. Research and education only — not investment advice.