How can a data center calculate PUE, WUE, GPU energy consumption, and energy cost per Token?

A data center can calculate PUE by dividing total facility energy by IT equipment energy, WUE by dividing water use by IT equipment energy, GPU energy by integrating card power over time, and energy cost per Token by allocating the relevant electricity cost to the Tokens produced in the same period. The difficult part is not the arithmetic. It is keeping measurement boundaries, timestamps, workload ownership, and cost allocation consistent.

If the denominator comes from one system, the power data from another, and Token counts from a third, inconsistent time windows can make the final number meaningless. Build the data model first, then calculate the KPI.

How is PUE calculated?

Power Usage Effectiveness, or PUE, is calculated as:

PUE = Total data center energy / IT equipment energy

The Green Grid describes PUE as total energy used by a data center divided by the energy used by ICT equipment.

ISO/IEC 30134-2:2026 defines PUE as a standardized KPI for data center energy efficiency.

The numerator and denominator must cover the same period.

If the facility used 1,200 kWh during an hour and IT equipment used 1,000 kWh during that hour:

PUE = 1,200 / 1,000 = 1.20

That means the facility consumed 1.20 units of energy for every 1.00 unit delivered to IT equipment during the measurement interval.

The difference includes facility overhead within the defined measurement boundary, such as cooling and electrical losses.

Do not calculate a daily facility numerator against an hourly IT denominator.

Do not compare sites that use materially different measurement boundaries without explaining the difference.

What does a lower PUE mean?

A lower PUE generally means less facility energy is being consumed relative to IT equipment energy within the defined measurement boundary.

The theoretical lower limit approaches 1.0 because total facility energy cannot normally be less than the IT equipment energy included inside it.

PUE does not tell you whether the IT equipment itself is doing useful work.

That distinction matters in AI infrastructure.

A data center can have an efficient PUE while many GPUs sit idle.

The facility is efficiently delivering power to IT, but the compute may still be economically inefficient.

That is why PUE should be paired with GPU utilization, useful workload output, card-hours, and service metrics.

PUE is a facility efficiency metric.

It is not a complete compute productivity metric.

How is WUE calculated?

Water Usage Effectiveness, or WUE, measures water use relative to IT equipment energy.

The Green Grid's WUE white paper defines a high-level site WUE formula as:

WUE = Annual water usage / IT equipment energy

The documented unit is liters per kilowatt-hour.

ISO/IEC 30134-9:2022 specifies WUE as a data center KPI for quantifying water consumption during the use phase.

If a site uses 5,000,000 liters of water in a year and its IT equipment consumes 10,000,000 kWh during the same year:

WUE = 5,000,000 L / 10,000,000 kWh = 0.5 L/kWh

The same discipline applies as with PUE.

Keep the time period consistent.

Keep the measurement boundary documented.

Know which water streams are included.

Do not compare WUE numbers without understanding the accounting method behind them.

Should PUE and WUE be calculated by zone?

Zone-level PUE and WUE can be useful for internal operations if the facility has enough submetering to support a defensible boundary.

For example, a site may want to compare an air-cooled zone with a liquid-cooled zone.

That comparison can help identify differences in energy and water behavior.

But a zone KPI should not be presented as if it were directly equivalent to a formal site-wide metric when the measurement method differs.

Use clear labels.

State the numerator.

State the denominator.

State which meters feed the calculation.

State the time period.

The source operations model uses zonal PUE and WUE for operations comparison, along with liquid-cooling telemetry and workload cost.

That is useful when the purpose is internal optimization rather than marketing a single facility number.

How is GPU energy consumption calculated?

GPU energy consumption is the integral of GPU power over time.

In simple discrete form:

GPU energy (kWh) = Sum of [power in kW × time interval in hours]

Suppose a GPU averages 650 W for two hours.

Convert watts to kilowatts:

650 W = 0.65 kW

Then:

Energy = 0.65 kW × 2 h = 1.30 kWh

For real workloads, power changes continuously.

A monitoring system therefore samples card power at regular intervals and integrates those measurements over the workload window.

NVIDIA DCGM exposes instantaneous device power fields for supported GPUs, which can be used as one telemetry source.

The same concept applies to other accelerators when their vendor telemetry exposes reliable power readings.

The sampling interval matters.

Very sparse samples can miss short peaks and load changes.

Very frequent sampling creates more telemetry volume.

Choose a resolution that is appropriate for operations and billing accuracy.

How do you calculate energy for an entire GPU job?

Sum the energy consumed by all accelerators assigned to the job during the job interval.

If a training job uses eight GPUs, calculate each card's power-over-time energy and add them.

Then decide whether the job-level energy model includes only GPU energy or broader IT energy.

A complete compute-cost model may also include:

CPU energy
Memory
Local storage
Network
Shared storage
Server fans or pumps
Facility overhead

There is no one correct allocation for every business model.

The important requirement is that the definition is explicit.

If you report "GPU energy," use accelerator telemetry only.

If you report "IT energy attributable to the job," define how server and shared infrastructure energy are allocated.

If you report "facility electricity attributable to the job," decide whether and how PUE is applied.

Do not mix these terms.

Can PUE be used to estimate facility energy attributable to a workload?

PUE can be used as an allocation factor for an estimate when direct facility-level attribution is unavailable, but the result should be labeled as an estimate.

Suppose the IT energy attributable to a workload is 100 kWh and the applicable PUE is 1.20.

A simple allocation model would estimate:

Facility-attributed energy = 100 kWh × 1.20 = 120 kWh

The implied facility overhead allocation is 20 kWh.

This approach is convenient, but it assumes the average PUE is a reasonable allocation factor for that workload and time period.

A more precise model can use interval PUE or zone-specific overhead where metering supports it.

The goal is consistency.

Do not use annual PUE for one project and hourly PUE for another, then compare their unit costs as if the methods were identical.

How is electricity cost calculated?

Electricity cost is energy multiplied by the applicable tariff.

For a simple flat tariff:

Electricity cost = Energy consumed × price per kWh

If 120 kWh is attributed to a workload and electricity costs $0.10 per kWh:

Cost = 120 × $0.10 = $12.00

Real tariffs can be more complicated.

A site may have peak and off-peak periods, demand charges, taxes, or other components.

For operational allocation, the system should map energy consumption to the tariff interval in which it occurred.

That is why timestamp alignment matters.

If a flexible batch training task can run during a lower-price period, the platform can calculate the actual savings rather than using an average electricity rate.

The source operations model specifically connects peak and off-peak pricing with interruptible workloads and itemized savings.

How do you calculate GPU idle energy?

GPU idle energy is the energy consumed while an allocated accelerator is producing little or no useful workload activity according to the organization's definition.

First, define idle.

It might mean no assigned workload.

It might mean assigned but below a utilization threshold for a minimum period.

It might mean a training task is waiting on network or storage.

Those are different kinds of idle time.

Then integrate power across the idle interval.

Example:

A card draws an average of 180 W during two hours classified as idle.

0.18 kW × 2 h = 0.36 kWh

Multiply that by the relevant electricity cost if you want idle electricity cost.

At scale, this is useful because the platform can rank wasted energy by project, owner, resource pool, or cause.

The important part is not to blame users automatically.

Low GPU activity can be caused by storage, network, scheduler fragmentation, or data loading.

The article on why GPU utilization is low explains how to find that underlying cause.

How do you calculate energy cost per Token?

Energy cost per Token requires three aligned measurements: attributable energy, electricity price, and Token output.

A simple model is:

Energy cost per Token = Attributable electricity cost / Number of Tokens

Suppose an inference service is allocated $25 of electricity cost during an hour and produces 50,000,000 billable Tokens during that same hour.

$25 / 50,000,000 = $0.0000005 per Token

For readability, you may report cost per million Tokens:

$0.50 per 1 million Tokens

This is an energy-only cost.

It is not the full cost of serving the model.

Full unit economics can also include hardware depreciation, colocation, software, network, labor, storage, and other costs.

Label the metric clearly.

"Energy cost per Token" should mean energy cost, not total model cost.

Should input and output Tokens be treated the same?

Only if that matches the model and business accounting method.

Input and output Token processing can have different compute characteristics.

Some organizations therefore keep separate counts.

Others report total Tokens for operational simplicity.

The method should be consistent.

At minimum, record input Tokens, output Tokens, request count, model, inference instance, project, API key or tenant, and time window where the service architecture allows it.

Then the cost model can support several views:

Energy cost per total Token
Energy cost per input Token
Energy cost per output Token
Energy cost per request
Energy cost by model
Energy cost by tenant

The correct view depends on what decision you are trying to make.

How do you allocate shared GPU energy to multiple inference users?

Allocate shared energy using a defined workload attribution rule.

If one GPU serves several model instances or tenants, direct physical power belongs to the shared device.

Possible allocation drivers include:

GPU time
Active execution time
Request count
Token count
Measured model-instance utilization
Reserved capacity share

Each method has tradeoffs.

Token-based allocation is easy to understand but may not reflect differences between model sizes.

Reserved-capacity allocation matches commercial reservation but may charge idle capacity to the tenant that reserved it.

Execution-time allocation can be more technically accurate but harder to measure.

Choose one model, publish it, and use it consistently.

For customer billing, simplicity and explainability matter as much as theoretical precision.

How should PUE, WUE, and Token energy be presented together?

Present them as different layers of efficiency.

PUE answers: how much facility energy is required relative to IT energy?

WUE answers: how much water is used relative to IT energy?

GPU energy answers: how much accelerator electrical energy did the workload consume?

Energy cost per Token answers: how much electricity cost was associated with a unit of AI service output?

Do not collapse them into one score.

An operations dashboard can show all four, but each should retain its formula and source.

The related article on how high density GPU data centers should manage power, rack capacity, cooling, and liquid cooling explains where the underlying facility telemetry comes from.

How do you prevent conflicting energy numbers across dashboards?

Use one metering source and one definition for each metric.

The source operations model makes this an explicit requirement: energy, liquid-cooling, metering, cost, and operations dashboards should share the same underlying data so different pages do not produce conflicting numbers.

Create a metric dictionary.

Define PUE.

Define WUE.

Define GPU energy.

Define idle.

Define Token.

Define tariff.

Define project attribution.

Define the time zone and billing period.

Then version the definitions when they change.

A platform example that connects facility telemetry, accelerator metering, and Token consumption is Sensaka.

If I were implementing this system, I would build the measurement lineage before the dashboard. Every displayed unit cost should be traceable back to a meter or telemetry field, a time interval, a workload or tenant, a tariff, and an output count. Once that chain is trustworthy, PUE, WUE, GPU energy, and cost per Token become useful operating metrics instead of disconnected numbers.