How to Calculate PUE, WUE, GPU Energy 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 arithmetic is easy. The hard part 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, and 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 of time.

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, and 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, and in AI infrastructure that gap matters. A data center can have an efficient PUE while many GPUs sit idle. The facility is delivering power to IT efficiently, but the compute may still be economically inefficient.

So pair PUE with GPU utilization, useful workload output, card-hours, and service metrics. PUE is a facility efficiency metric and does not give a complete picture of compute productivity.

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 window consistent, document the measurement boundary, and know which water streams are included. WUE numbers are not comparable until you understand the accounting method behind each one.

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, and that comparison can help identify differences in energy and water behavior.

A zone KPI should not be presented as if it were directly equivalent to a formal site-wide metric when the measurement method differs. Label it clearly, and state the numerator, the denominator, which meters feed the calculation, and the time window it covers.

The source operations model uses zonal PUE and WUE for operations comparison, along with liquid-cooling telemetry and workload cost. That works 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, so a monitoring system 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, while very frequent sampling creates more telemetry volume. Choose a resolution that fits your operations and billing accuracy needs.

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

No single allocation is correct for every business model, but the definition has to be 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. Keep these terms separate.

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 window. A more precise model can use interval PUE or zone-specific overhead where metering supports it.

What you want is consistency. If you use annual PUE for one project and hourly PUE for another, you cannot 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, which is why timestamp alignment matters.

If a flexible batch training task can run during a lower-price window, 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, or assigned but below a utilization threshold for a minimum time, or a training task waiting on network or storage. Those are different kinds of idle time.

Then integrate power across the idle interval. For 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.

Do not 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, which is less than 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, so that "energy cost per Token" means energy cost and nobody reads it as 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, so some organizations keep separate counts while others report total Tokens for operational simplicity. Whichever you choose, apply it consistently.

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 is 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 the workload consumed. 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 that defines PUE, WUE, GPU energy, idle, Token, tariff, project attribution, and the time zone and billing cycle. 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.