# GPU, CPU and server energy: where measurement boundaries lie

GPU power, CPU-package energy, and server AC input use different measurement boundaries.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-board-server-power-boundary/
Language: en

GPU power, CPU-package energy, and server AC input use different measurement boundaries. Adding them without a coverage map can double-count nested domains while omitting other consumers. Identify each observation's physical scope and units first. Then choose either a system total or a non-overlapping component set. Otherwise a report can count some energy twice while missing fans, storage, or conversion losses.

## Label sensor boundaries

[NVML device queries](https://docs.nvidia.com/deploy/nvml-api/latest/api/group__nvmlDeviceQueries.html) defines GPU and associated-circuitry power for the relevant API; that is not whole-server AC consumption. Keep function or field name, units, and device scope. Do not label it simply “server watts.” If the source reports energy rather than power, preserve the interval and averaging calculation. Matching watt units do not make sensors interchangeable because they may cover different components and time windows. State both boundaries before attempting to reconcile apparently inconsistent values.

## Identify nested CPU zones

The [Linux powercap framework](https://docs.kernel.org/power/powercap/powercap.html) describes zones and subzones. A parent can include child regions, so adding them can count the same energy again. Preserve the hierarchy and meaning of each zone name before aggregation. RAPL package does not automatically mean the whole node, and processor platforms need not expose identical coverage. Cross-node comparisons require matched domains; otherwise a numerical difference may reflect only which regions are represented by available counters. Missing coverage is a measurement limitation, not zero consumption.

## Demonstrate double counting

Suppose a parent records 100 J during a test and an included child records 40 J. These are illustrative arithmetic values. Reporting 140 J as the parent's total plus an independent consumer is incorrect if the 40 J already belongs inside the 100 J. Likewise, server AC energy cannot be added to GPU-board energy and called total system energy. The record should identify parent relationships and exclude overlap before comparing model efficiency or runtime settings. No performance conclusion can repair an invalid physical sum.

## Choose the measurement objective

Electricity accounting may require the relevant AC boundary, while component analysis needs its sensor domain. Keep separate reports where objectives differ. Use `Pavg = deltaE / deltaT` with consistent units and intervals when deriving average power from energy. The gap between AC input and selected component totals cannot be assigned entirely to PSU loss: omitted consumers and measurement uncertainty also contribute. Do not fill missing domains with advertised TDP unless the result is explicitly an estimate with justified assumptions, rather than measured consumption.

## Preserve the coverage map

Record sensor, object, parent, units, interval, and acquisition method. Label unknown coverage and unsupported fields explicitly. Compare operating modes using the same boundary and workload, and rebuild the inventory on another server. The artifact should make every value an observation of a specific region rather than universal inference energy. Keeping board power, package energy, and AC input distinct prevents attractive but physically invalid sums and apparent savings caused by changed sensors, nested-domain duplication, or disappearing coverage rather than an actual reduction in server energy.

## Related reading

[Energy per LLM request: measuring without false precision](/journal/measuring-energy-per-inference/); [GPU Server Electricity Costs: Reconcile an Actual Bill](/journal/own-server-electricity-invoice/).