PUE, in depth: meter boundaries, partial-load behaviour of GPU halls, pPUE and WUE, the reporting rules, and charging facility energy to a training job

The definition, precisely

PUE is standardised in ISO/IEC 30134-2 and goes back to The Green Grid's original definition. The standard form is energy, not power: kilowatt-hours over a period, normally a full year, because an instantaneous ratio swings with weather and load. The denominator is IT equipment energy, meaning servers, storage and network gear. The numerator is everything that the facility draws, including the IT energy itself, so PUE can never be below 1.0.

Two consequences follow. First, PUE improves when overhead falls or when IT energy rises with overhead fixed; a hall can score better simply by being busier. Second, it is a facility metric. It cannot tell you whether a GPU at 30 percent utilisation is doing useful training, and a site that halves its IT energy through better software can see its PUE get worse while its total bill falls.

For context, Uptime Institute's 2025 global survey put the average reported PUE at about 1.54, essentially flat for six years, because most operating floor space is older air-cooled capacity. Large cloud operators publish fleet figures around 1.1. New liquid-cooled AI halls are typically designed for the low 1.1s to 1.2s, but design PUE and operated PUE are different numbers.

Meter boundaries decide the answer

The diagram shows the four places you can measure. M0 at the utility connection captures everything. IT energy can be read at the UPS output (M1), at the PDU or busway output (M2), or at the rack or server input (M3). The further upstream you measure IT, the more distribution losses you count as IT, and the better PUE looks. The Green Grid formalised this as measurement categories; whichever you use, state it next to every published figure.

The boundary also moves with cooling technology. Server fans are IT load; room fans and pumps are overhead. When a GPU server moves from air to direct-to-chip liquid, internal fan power falls sharply and that saving comes off the denominator, which by itself makes PUE look slightly worse even as total energy falls. The cooling article covers that bias; the practical rule is to compare total facility energy per unit of work, not PUE alone, when evaluating a cooling change.

Interval PUE versus annual PUE

Regulators and marketing use annual PUE. Operations and job accounting need interval PUE, computed from the same meters over 15-minute or hourly windows, because overhead varies with outside temperature and load. A hall that reports 1.20 annually may run at 1.12 on a cold night and 1.35 on a hot afternoon when chillers carry the load instead of free cooling. If you charge a summer training run at the annual figure, you undercount its facility energy.

Compute annual PUE as total facility energy over total IT energy for the year, never as the mean of interval PUEs. The mean of ratios overweights low-load intervals and gives a different, wrong number.

import pandas as pd

def load_meters(path):
    # Columns: ts, m0_kwh (facility), m3_kwh (IT at rack input); one row per 15 minutes.
    df = pd.read_csv(path, parse_dates=["ts"]).set_index("ts").sort_index()
    expected = pd.date_range(df.index.min(), df.index.max(), freq="15min")
    missing = expected.difference(df.index)
    if len(missing) > 0.001 * len(expected):
        raise ValueError(f"{len(missing)} intervals missing; refusing to report")
    bad = df[(df.m3_kwh <= 0) | (df.m0_kwh < df.m3_kwh)]
    if not bad.empty:
        raise ValueError(f"{len(bad)} intervals where IT exceeds facility: check meter scope")
    return df

def pue_report(df):
    hourly = df.resample("1h").sum()
    hourly["pue"] = hourly.m0_kwh / hourly.m3_kwh
    return {
        "annual_pue": df.m0_kwh.sum() / df.m3_kwh.sum(),          # ratio of sums
        "mean_of_ratios": hourly.pue.mean(),                      # for contrast only
        "p95_hourly": hourly.pue.quantile(0.95),
        "it_utilisation": hourly.m3_kwh.mean() / hourly.m3_kwh.max(),
    }

The two sanity checks matter more than the arithmetic. Missing intervals are common after meter firmware updates, and a facility meter that reads less than the IT meter means one of them is scoped wrongly, usually because a new hall's IT feeds were added to the IT sum but its cooling feed is metered elsewhere.

Why GPU halls score badly at partial load

Overhead has a fixed part and a variable part. Transformer and UPS no-load losses, minimum pump flow, controls, lighting and security systems draw roughly the same power whether the hall is full or nearly empty. Cooling and conversion losses scale with IT load. AI halls are often commissioned in phases and sit lightly loaded for months while GPUs arrive, so the fixed part dominates.

Worked example. Model overhead as 0.6 MW fixed plus 12 percent of IT load. At a design load of 8 MW, overhead is 0.6 + 0.96 = 1.56 MW and PUE is 9.56 / 8 = 1.195. At 40 percent load, 3.2 MW of IT, overhead is 0.6 + 0.384 = 0.984 MW and PUE is 4.184 / 3.2 = 1.31. Nothing is broken; the hall is simply carrying its fixed costs over less work. Over a year at 8 MW average, IT energy is 8 × 8,760 = 70,080 MWh and overhead about 13,666 MWh.

Training workloads add a second effect. A synchronised job steps between compute and communication phases, and a large cluster can swing several megawatts in seconds. Cooling plant responds over minutes, so it is sized and run for the peak, and the overhead it consumes during troughs is wasted. Power capping, covered in the power article, flattens those swings and improves interval PUE as a side effect.

Partial PUE, WUE and the metrics around PUE

WUE is the most important companion. Evaporative cooling towers and adiabatic coolers lower electricity use, and therefore PUE, by evaporating water. In a water-stressed region a site with PUE 1.15 and high WUE may be a worse choice than one at 1.25 with closed dry coolers. Report the pair.

Reporting rules and limits

PUE has become a regulated number in Europe. Under the EU Energy Efficiency Directive and its Delegated Regulation 2024/1364, datacenters with installed IT power of at least 500 kW report key performance indicators, PUE among them, to a European database each year. Germany's Energy Efficiency Act goes further and sets limits: datacenters commissioned before 1 July 2026 must reach an annual PUE of 1.5 or better from 1 July 2027 and 1.3 from 1 July 2030, and new datacenters commissioned from 1 July 2026 must be built to reach 1.2 within two years of commissioning, alongside rising energy reuse shares. A draft amendment to that act was published in April 2026, so check the current text before using these figures in a design.

For engineers the practical implication is that meter scope, data retention and the calculation must be auditable. The code above, its input files and the meter scope diagram belong in version control next to the report they produced.

Charging facility energy to a training job

Teams increasingly need energy per job for cost and carbon reporting. Measure IT energy as close to the work as possible, from node or rack telemetry, then scale by the interval PUE of the hours in which the job ran rather than the annual average.

def job_facility_energy(job_it_kwh_by_hour, hourly):
    # job_it_kwh_by_hour: Series indexed by hour, IT energy of the job's nodes
    # hourly: output of resample above, with a 'pue' column
    joined = hourly.reindex(job_it_kwh_by_hour.index)
    if joined.pue.isna().any():
        raise ValueError("job ran in hours with no meter data")
    return float((job_it_kwh_by_hour * joined.pue).sum())

# 64 nodes x 8 GPUs, about 10 kW per node, 72 hours
# IT energy:        64 * 10 * 72      = 46,080 kWh
# at annual PUE 1.20                  = 55,296 kWh
# at the hours' actual PUE (avg 1.31) = 60,365 kWh   -> about 9 percent more

If your provider reports energy that already includes facility overhead, do not multiply again; double-applying PUE is the most frequent error in per-job carbon numbers. Cloud tenants rarely get interval PUE and usually have to use the provider's published annual figure, which should be labelled as such.

Operational guidance

• Publish PUE with its period, meter category and boundary, every time.
• Track interval PUE alongside IT load on the same dashboard; a PUE rise with flat IT load points to cooling plant, a rise with falling load is the fixed-overhead effect.
• Raise supply water and air temperatures to the hardware's allowed range; warmer loops extend free-cooling hours and are usually the largest single lever.
• Consolidate load during phased build-outs so fewer cooling zones run lightly loaded.
• Reconcile meter sums monthly against utility bills; a drift of more than a percent or two means a scope change nobody recorded.

Failure modes and trade-offs

The classic failures are measurement ones: IT read at the UPS, a cooling feed left off the facility sum, offices included in one year and not the next, the mean of ratios reported as annual PUE, and a single cold-month figure presented as typical. The design trade-offs are real too: chasing PUE with evaporative cooling spends water, deleting redundancy lowers losses but raises outage risk, and running GPUs hotter to save cooling energy can cost clock speed if the parts throttle. The question to ask of any proposal is whether total energy per unit of useful work falls, which is a question about utilisation as much as facilities; GPU cost optimization covers the software side.

What to do next

1. Draw your meter diagram: where M0 is and at which point IT is measured; write the category beside every figure.
2. Load 15-minute meter data into the script above, fix every missing interval and scope error, and compute annual PUE as a ratio of sums.
3. Plot interval PUE against IT load and outside temperature to separate fixed overhead from cooling behaviour.
4. Report WUE next to PUE if you use evaporative cooling.
5. Charge jobs using interval PUE for the hours they ran, and never apply PUE twice.
6. If you operate in the EU, confirm your reporting obligation and, in Germany, the current limits for your commissioning date.