Every compute-to-energy model in circulation runs on the same multiplication: nameplate TDP × hours × PUE. For an H100 that produces 0.91 kilowatt-hours per GPU-hour. That number is the denominator underneath data-center demand forecasts, interconnection studies, compute economics, and every energy-normalized compute index currently being designed.

It was also the denominator underneath four dashboards on this site.

A public dataset from the National Laboratory of the Rockies measured H100 training, fine-tuning, and inference workloads at 0.1-second resolution, then scaled those profiles into year-long facility demand. We rebuilt our compute energy layer on it. The short version: the nameplate denominator is wrong in three different ways, because a facility rating gets asked three different questions and only one of them is about energy.

The six terms this turns on

Most of the confusion in compute-energy estimates is terminological rather than mathematical. These six are not interchangeable, and picking the wrong one is what produces a forecast that is off by 40%.

The measured workload profiles are already embedded in the facility simulation. Capacity factor already reflects workload draw, idle consumption, node occupancy, scheduling, and temporal demand patterns. Multiplying it by duty factor or peak derate counts the same effect twice. The calculator below enforces this — it asks which question you are answering, then shows only the denominator that belongs 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 denominator.

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 traces produce duty factors from 0.795 to 0.880 — real workload energy running roughly 12% to 21% below nameplate, averaging about 16%. Anyone quoting the 4.5% figure as an energy correction is quoting a ceiling as if it were an average.

At facility scale the correction gets larger

The device-level denominator is off by 12–21%. The facility-level one is off by more.

Take 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 = 51.8 GWh — a difference of 35.8 GWh per year before PUE, or 40.9% below the continuous-nameplate estimate. For the 1 MW inference facility, annual IT energy is roughly 5.81 GWh rather than 8.76 GWh.

That gap propagates into utility load forecasts, generation and transmission planning, energy procurement, emissions estimates, behind-the-meter sizing, demand-charge expectations, and the valuation of any power hedge attached to compute.

One nuance worth carrying: capacity factor is an annual ratio produced by an hourly load shape, so raising it is an operating decision rather than a free improvement. At high utilization the load flattens — easier for a grid to serve — but the colocation case reaches mean queue times above six hours and the inference case leaves a material share of requests unserved. The operating frontier is drawable inside the calculator above. Higher utilization is not automatically better.

What this changed in our own numbers

This site’s energy-normalized compute analysis says it plainly in its own footer: “GPU TDP figures are nameplate.” The Compute × Power workbench used the same convention, as did the compute supply-curve work behind it. Every energy figure those tools produced inherited the 0.91 kWh denominator.

Rebuilt on measured duty factors, the same calculation gives roughly 0.76 kWh per GPU-hour at a 1.3 PUE — about 16% lower. Across one million GPU-hours that is 910 MWh on the old denominator against 763 MWh measured, a 147 MWh difference worth about $7,350 at $50/MWh or $29,400 at $200/MWh. The second tab of the calculator runs both conventions side by side against real hub prices, so the correction is inspectable rather than quietly patched.

Worth stating directly: the direction of that error is not intuitive, and it reverses depending on what you are computing. A lower energy denominator reduces the estimated energy cost of a GPU-hour — but it raises the implied compute heat rate, because the same rental is now supported by less electricity. One measurement correction, two headline numbers moving in opposite directions. That is precisely why a denominator has to be published rather than assumed.

That is a fair question to put to any benchmark administrator, and it maps cleanly onto IOSCO’s benchmark principles — Principles 6 and 7 on design and data sufficiency, and Principle 11 on methodology content. Does a denominator derived from nameplate ratings adequately reflect the underlying interest? Six things would need disclosing before that question can be answered from the outside:

We ask having just corrected the same error in our own published work. The COIL methodology document is not out yet; if it already uses measured or transaction-derived energy content, this becomes corroboration rather than critique and the underlying point stands either way — the denominator deserves to be published, whatever it turns out to be.

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 excludes cooling and other non-IT loads, and its utilization shapes come from external workload datasets rather than direct observation of a commercial hyperscale site.

Use it 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 dataset and tooling are open, which makes the next step available to anyone: repeat the measurement on 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 the measured peak ratio. 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. Hourly power prices from ERCOT MIS and PJM Data Miner 2. Electricity-price examples are illustrative. Research and education only — not investment advice.