From watt to carbon, honestly: PUE, grid intensity and gCO₂ per token

· By José Manuel Román
Contents

Notation: amounts in euros (N €), decimals with a point. The dollar symbol is not used (on this site it is a formula delimiter). Generic example hardware (4×H100 SXM 80 GB); no real infrastructure. Emission figures in gCO₂eq/kWh (CO₂ equivalents).

TL;DR

A model that consumes 2 J/token at the board (4×H100 SXM, PUE 1.45) emits between \(0.08\) and \(1.05\) gCO₂ per 1,000 tokens depending on the region and the hour: \(0.08\) in nuclear France in the small hours, \(0.22\) in solar Spain at midday, \(0.72\) in Spain on night-time gas, and \(1.05\) in Germany on coal. The difference, a factor of ×13, is set by three variables external to the hardware: the datacenter PUE (Uptime Institute 2025: global average 1.54; hyperscale 1.10–1.15), the grid carbon intensity (which varies in real time, from 5 to 600+ gCO₂/kWh depending on zone and hour), and the type of emissions being counted (location-based, market-based, marginal). Moving batch work to hours of lower carbon intensity, temporal carbon-aware shifting, cuts the emissions of deferrable work by between 20 % and 65 % without touching the hardware. The SCI specification (Software Carbon Intensity, Green Software Foundation, ISO/IEC 21031:2022) formalises the metric as \(\text{SCI} = (E \times I + M) / R\), where \(M\) captures the embodied carbon of the hardware, the part that almost no LLM inference analysis includes today.

Track context

This article is C6 of the energy pillar. The previous ones:

The starting point is the J/token already measured (methodology in C2, tools in C3). This article converts that number into gCO₂/token.

PUE: the first multiplier

Definition

PUE (Power Usage Effectiveness) measures what fraction of the total energy consumed by a datacenter actually reaches the IT equipment:

$$\text{PUE} = \frac{\text{total datacenter energy (W)}}{\text{IT equipment energy (W)}}$$

A PUE of 1.0 would be perfect (all energy going to compute). A PUE of 2.0 means that for every watt the GPU consumes, another watt is consumed in cooling, electrical distribution, lighting and conversion losses. PUE turns board power, the figure DCGM or NVML measure, into the total datacenter power drawn from the grid.

Current values

The Uptime Institute Global Data Center Survey 2025 (15th annual edition) reports:

SegmentTypical PUESource
Global average1.54 (6th consecutive year unchanged)Uptime Institute 2025
Hyperscale (Google, Meta, Microsoft, Amazon)1.10–1.15Uptime Institute 2025
Colocation / enterprise1.58–1.80Uptime Institute 2025
Unoptimised on-premise1.6–2.0industry, various
Theoretical limit (cold air, favourable climate)1.10–1.20ASHRAE / industry

The stagnation of average PUE at 1.54 reflects the fact that legacy facilities, with inefficient cooling, keep operating alongside the new ones. For a typical on-premise platform with no specific investment in efficiency, assuming a PUE between 1.4 and 1.6 is reasonable. Facilities with direct liquid cooling can reach 1.10–1.20.

How it inflates J/token

If the reference node (4×H100 SXM) consumes 3,200 W at full load (GPU + CPU + DRAM + fans):

PUETotal datacenter powerInflation factor over board
1.103,520 W+10 %
1.404,480 W+40 %
1.54 (global average)4,928 W+54 %
1.80 (enterprise legacy)5,760 W+80 %

The energy per token on a leaderboard, measured at GPU or node level, does not include PUE. The impact: going from PUE 1.10 (hyperscale) to PUE 1.54 (global average) multiplies effective energy consumption by 1.40×. It is the same GPU, the same model, the same throughput; the difference comes from the facility.

Power (W)PUE 1.03,200PUE 1.103,520PUE 1.404,480PUE 1.544,928PUE 1.805,7604×H100 SXM node at 3,200 W IT. Each bar adds cooling and distribution overhead per PUE.

Grid carbon intensity

What it measures and why it varies

The carbon intensity of the electricity grid expresses how many grams of CO₂eq are emitted per kilowatt-hour generated, as a function of the source mix (nuclear, wind, solar, gas, coal, hydro). It is the most heterogeneous variable in the calculation: it varies by country, by region within a country, and by hour of the day.

The reference OSS tools are:

ToolSignal typeCoverageAccess
ElectricityMapsHourly average (production-based and flow-traced)60+ countries in real timeAPI (limited free plan); OSS on GitHub
WattTimeHourly marginal (MOER)US + growing global coverageAPI; free data since 2025 (REsurety-WattTime partnership)
Carbon Aware SDK (Green Software Foundation)Wrapper over ElectricityMaps and WattTimeSame sourcesOSS, Apache 2.0; github.com/Green-Software-Foundation/carbon-aware-sdk

ElectricityMaps (formerly electricityMap) publishes carbon intensity in gCO₂eq/kWh hour by hour via API and on its interactive map (app.electricitymaps.com). WattTime publishes the marginal operating emissions rate (MOER), useful for calculating the causal impact of adding or removing load. The GSF Carbon Aware SDK integrates both signals as interchangeable backends.

Country data (annual averages 2024–2025)

CountryAverage intensity 2024 (gCO₂eq/kWh)Approximate hourly rangeSource
Spain~10830–250Nowtricity / REE 2025
France~21.7 (2024); ~19.6 (2025)5–80RTE Bilan Électrique 2025
Germany~363 (2024); ~328 (2025)100–600Fraunhofer ISE 2025
EU average~213—Ember European Electricity Review 2025

France has the lowest intensity in continental Europe thanks to its nuclear fleet (>90 % low-carbon generation in 2025, according to RTE). Spain closed 2024 with a historic record: 56.8 % renewable generation, with an average intensity of 108 gCO₂/kWh, among the lowest in the non-nuclear EU. Germany, in accelerated transition but still dependent on lignite and gas, has three times Spain’s average intensity.

Hourly variation: the figure that matters most for scheduling

Within a single country, the hourly variation in carbon intensity is enormous. Data from the ElectricityMaps 2025 grid review for Spain:

Time of dayTypical conditionEstimated intensity (gCO₂eq/kWh)
Solar midday (11:00–15:00, summer)Solar covers >40 % of demand30–80
Night-time trough (02:00–06:00, summer)Zero solar; variable wind80–180
Demand peak (19:00–21:00, winter)Gas as the marginal plant180–280
Cold windless small hours (winter)Gas + combined cycle dominate220–300

The price-carbon correlation in Spain is strong and negative (coefficient −0.70 in 2025 according to ElectricityMaps): cheap hours are also the cleanest, because both are driven by renewable penetration. The 477 hours with negative prices in 2025 were also the hours of lowest carbon intensity.

gCO₂/kWhhour of day →0h6h12h18h24h|||||300150solar minimum (~50 gCO₂/kWh)night gas (~150–200)Schematic summer day curve, Spain. Source: ElectricityMaps grid review 2025 + REE.

Spain vs France vs Germany: impact on gCO₂/token

To anchor the difference in operational terms, with the reference node (4×H100 SXM, indicative throughput 1,000 tok/s under load, PUE 1.45):

Energy per token at the datacenter:

$$E_{\text{DC}} = \frac{3{,}200\ \text{W} \times 1{.}45}{1{,}000\ \text{tok/s}} = 4{.}64\ \text{J/tok} = 1{.}29 \times 10^{-3}\ \text{Wh/tok}$$
Country / hourIntensity (gCO₂/kWh)gCO₂ per 1,000 tokensgCO₂ per 1M tokens
France (2025 average)19.60.02525.3
Spain solar (summer midday)~500.06464.5
Spain 2024 average~1080.140139.3
Spain night-time gas (winter)~2200.284283.8
Germany 2025 average~3280.423423.0
Germany coal peak~5500.709709.0

The range is ×28 between the French average and the German peak. Between the two hourly extremes in Spain (solar vs winter night-time gas) the difference is ×4.4. The choice of country and of execution hour moves carbon per token more than any hardware or engine optimisation within that range.

Scope 2 and Scope 3: what counts and what does not

GHG Protocol scopes

The GHG Protocol defines three scopes for corporate emissions:

ScopeDefinitionDatacenter example
Scope 1Direct emissions from owned or controlled sourcesEmergency diesel generators
Scope 2Indirect emissions from purchased electricity consumptionElectricity consumption of the cluster
Scope 3Other indirect emissions in the value chainHardware manufacturing (embodied carbon)

For an on-premise inference platform, Scope 2 is the dominant item in operation; upstream Scope 3 (manufacturing of servers and GPUs) is typically the second largest item over the hardware life cycle.

Scope 2: location-based vs market-based

The GHG Protocol Scope 2 Guidance (2015, under public revision 2025–2027) establishes two accounting methods, both mandatory in corporate reporting:

MethodWhat it measuresHow it is obtained
Location-basedActual intensity of the electricity grid where the facility sitsEmission factor of the national or regional grid (published by operators such as REE, RTE)
Market-basedIntensity according to the contractual instruments for energy purchaseGuarantees of Origin (GoO), PPAs or tariffs with a renewable attribute

The revision under public consultation (October 2025) proposes requiring, for the first time, hourly matching for the market-based method: buying 100 MWh of solar over a year is not enough if it is consumed in hours without sun. The aim is for market-based to reflect physical electricity and not just accounting certificates.

For an inference cluster, the location-based method with hourly intensity (not an annual average) is the most informative for carbon-aware operation: it shows in real time what emissions each token generates.

Marginal vs average emissions

This distinction, documented by ElectricityMaps and WattTime, is fundamental for evaluating the real impact of scheduling decisions:

TypeDefinitionWhen to use
AverageThe share of all grid emissions attributable to the consumer according to their quotaLocation-based Scope 2 carbon reporting
Marginal (MOER)Emissions of the generator that would respond to a marginal increase in loadEvaluating the causal impact of adding or moving load

Textbook example from ElectricityMaps: in a grid with 50 % wind (0 gCO₂/kWh) and 50 % gas (500 gCO₂/kWh), the average intensity is 250 gCO₂/kWh, but the marginal factor is ~500 gCO₂/kWh (gas is the plant that responds to the demand increase). Reducing load avoids 500 gCO₂/kWh, even though the Scope 2 report records only 250 gCO₂/kWh.

Marginal and average must never be mixed in the same accounting: they represent different attribution paradigms (the GHG Protocol and ElectricityMaps both say so explicitly).

Scope 3: the embodied carbon of the hardware

Embodied carbon is the CO₂eq footprint generated during manufacturing, transport and end of life of the hardware. For GPUs and high-performance servers, this item is significant:

ItemIndicative valueSource
Service life of a datacenter server3–5 yearsAWS / industry
Service life of the datacenter facility15–20 yearsindustry
Amortisation methodologyEmbodied carbon / years of service lifeGHG Protocol / AWS methodology 2025
Embodied carbon of an AI server (indicative)1,000–3,000 kgCO₂eq (cradle-to-gate)AWS Embodied Carbon methodology

Embodied carbon is amortised over the service life of the hardware: a server with 1,500 kgCO₂eq of embodied carbon and a 4-year service life contributes 375 kgCO₂eq/year of Scope 3, regardless of how much it is used. A high utilisation rate reduces the embodied carbon per token (the same hardware produces more functional value).

None of the public LLM energy leaderboards (HF AI Energy Score, ML.ENERGY, MLPerf Power) include Scope 3 in their metrics. The SCI specification incorporates it explicitly.

The full conversion: from J/token to gCO₂/token

The equation

$$\text{gCO}_{2}\text{/token} = \frac{E_{\text{board}}\ [\text{Wh/tok}] \times \text{PUE} \times I_{\text{grid}}\ [\text{gCO}_{2}\text{/kWh}]}{1{,}000}$$

where:

  • \(E_{\text{board}}\) is the energy per token measured at GPU/node level (without PUE)
  • \(\text{PUE}\) multiplies by the datacenter overhead
  • \(I_{\text{grid}}\) is the grid carbon intensity at the moment of execution
  • Dividing by 1,000 converts Wh to kWh

For the reference node (4×H100 SXM, throughput 1,000 tok/s, GPU+CPU+RAM consumption 3,200 W, PUE 1.45):

$$E_{\text{board}} = \frac{3{,}200\ \text{W}}{1{,}000\ \text{tok/s}} = 3{.}2\ \text{J/tok} = 8{.}9 \times 10^{-4}\ \text{kWh/tok}$$

Then, applying PUE 1.45:

$$E_{\text{DC}} = 8{.}9 \times 10^{-4} \times 1{.}45 = 1{.}29 \times 10^{-3}\ \text{kWh/tok}$$

And the emissions:

$$\text{gCO}_{2}/\text{tok} = 1{.}29 \times 10^{-3} \times I_{\text{grid}}$$

Full table by region and hour

ScenarioPUEGrid intensity (gCO₂/kWh)gCO₂/1,000 tokgCO₂/1M tok
France 2025 average1.4519.60.02525.3
Spain solar (summer midday)1.45500.06464.5
Spain 2024 average1.451080.139139.3
Spain night-time gas (winter)1.452200.284283.8
Germany 2025 average1.453280.423423.0
Germany coal peak1.455500.709709.0
Spain solar + hyperscale PUE1.12500.05050.0
Spain night-time gas + legacy PUE1.802200.354354.0

The PUE factor matters more in high-intensity scenarios: going from PUE 1.12 to 1.80 at the German coal peak moves the result from ~617 to ~860 gCO₂/1M tok (+39 %). In solar Spain, the same PUE change moves it from 50 to 79 gCO₂/1M tok; the low grid intensity cushions the impact of poor PUE.

Carbon-aware shifting: temporal and spatial

Principle and tools

Carbon-aware computing means running flexible load (batch, training, fine-tuning, document ingestion) when and where the grid carbon intensity is lower. The reference OSS tool is the Carbon Aware SDK (Green Software Foundation, Apache 2.0): a wrapper that queries ElectricityMaps or WattTime and returns the current and forecast intensity for a zone and time window.

The SDK distinguishes two types of shifting:

TypeDescriptionApplicable to
TemporalDelaying or advancing execution within the same datacenter to a lower-carbon hourBatch, training, deferrable tasks with a loose deadline
SpatialMoving the load to a geographic region with lower intensity at that momentMulti-cloud or multi-datacenter; requires model/data replication

For an on-premise platform in a single datacenter, only temporal shifting is immediately applicable. Spatial shifting requires multi-site infrastructure.

Quantifying the temporal saving

Recent research (arXiv 2512.07799, 2512.08725; Microsoft Carbon-Aware Computing Whitepaper) quantifies the saving from temporal shifting of batch load:

Study / caseEmissions savingConditions
Batch load with 24 h shifting (simulation, several grids)20–40 % emissions reduction24 h window, grid with a renewable-fossil mix
ML training with shifting against grid forecast (Microsoft)~30 %Azure, shifting against forecast intensity
Greedy heuristics vs optimum (arXiv 2512.07799)≥ 90 % of the optimumSimple one-migration or greedy deferral
UBS + Microsoft, Azure Batch, 24 h windowValidated with the Carbon Aware SDKReal temporal shifting in production

For Spain, where the price-carbon correlation is −0.70, shifting to solar hours cuts both electricity cost and emissions per token at the same time. In the 477 hours with negative prices recorded in 2025 (ElectricityMaps / REE), carbon intensity was also at a minimum. The coincidence between clean hour and cheap hour means that carbon-aware scheduling has no economic opportunity cost in Spain: optimising carbon and cost point to the same time window.

Quantification for the reference node

For a 1-hour batch task on the reference node (4×H100 SXM, 4,640 W total with PUE 1.45), generating ~3,600 million tokens per hour:

ScenarioIntensity (gCO₂/kWh)Emissions per batch hourSaving vs non-deferred execution
No shifting (Spain average)108501 gCO₂—
Shifted to a solar hour (50 gCO₂/kWh)50232 gCO₂−54 %
Shifted to a night-time gas hour (220 gCO₂/kWh)2201,021 gCO₂+104 % (worst moment)

The range between the worst and the best moment to run that batch is ×4.4 in emissions. Shifting to the cleanest hour available in a 24-hour window in Spain typically avoids between 40 % and 60 % of the emissions of deferrable work.

The SCI standard: Software Carbon Intensity

Specification

Software Carbon Intensity (SCI) is a Green Software Foundation specification, published as standard ISO/IEC 21031:2022 and maintained on GitHub (github.com/Green-Software-Foundation/sci). It defines a rate of carbon emissions per functional unit of software:

$$\text{SCI} = \frac{(E \times I) + M}{R}$$

where:

SymbolMeaningUnits
\(E\)Energy consumed by the software system (servers, network, user devices)kWh
\(I\)Carbon intensity of the energy consumed (location-based or another declared basis)gCO₂eq/kWh
\(M\)Embodied carbon of the hardware, amortised by time of use and utilisation percentagegCO₂eq
\(R\)Functional unit (the denominator that normalises the rate)per API call, per token, per user, etc.

For an LLM inference platform, \(R\) is naturally the output token or the query. SCI in gCO₂eq/token therefore includes the three components that most current analyses omit: PUE implicit in \(E\), hourly intensity in \(I\), and embodied carbon in \(M\).

Key difference from the simple calculation

The calculation \(E \times I\) (energy × grid intensity) is operational Scope 2. SCI adds \(M\), the Scope 3 of the hardware, which has a different structure:

$$M = \frac{\text{total embodied carbon (gCO2eq)}}{\text{service life (hours)}} \times \frac{\text{hours of use}}{1} \times \frac{\text{allocated resources}}{\text{total server resources}}$$

For an AI server with 1,500 kgCO₂eq of embodied carbon, a 4-year service life (~35,040 hours) and 80 % utilisation:

$$M_{\text{hour}} = \frac{1{,}500{,}000\ \text{gCO2eq}}{35{,}040\ \text{h}} \times 0{.}80 \approx 34\ \text{gCO2eq/h}$$

With 3,600 million tokens per hour:

$$M_{\text{per token}} \approx \frac{34}{3{.}6 \times 10^{9}} \approx 9{.}4 \times 10^{-9}\ \text{gCO2eq/tok}$$

At this scale, embodied carbon per token is negligible against operational Scope 2 during operation. However, \(M\) becomes dominant in two cases: underutilised hardware (low utilisation amplifies the cost per token) and hardware with a very short life cycle (chips replaced every 2 years instead of 4).

SCI as the reference metric for the track

The SCI specification and its AI extension (github.com/Green-Software-Foundation/sci-ai) are being adopted as the reference metric for reporting the carbon footprint of AI systems in companies subject to CSRD. It provides a common denominator, gCO₂eq per functional unit, that allows architectures, regions and scheduling strategies to be compared on the same basis.

Limits of the calculation, and honesty

No gCO₂/token calculation captures the full reality. The limits of the model set out in this article:

LimitDescription
Annual average vs hourly intensityUsing the country’s annual average as the emission factor gives a stable but fictitious result. Intensity varies ×4–10× within a day. For location-based Scope 2 reporting with hourly data, the difference can be 30–50 % relative to the average.
Static PUEPUE varies with outdoor temperature (cooling works harder in summer) and with IT load. The declared PUE is an average; on hot days it can be 10–20 % worse.
Constant throughputThe calculation uses throughput at full load. In production, with variable demand, consumption does not scale linearly with throughput; efficiency per token gets worse at low load.
Partial Scope 3Embodied carbon here covers only the IT hardware. It does not include the construction of the datacenter building, the manufacture of cooling equipment, or the energy supply chain.
National emission factorsThe per-country values are annual averages. France has low intraday variation (nuclear dominates); Spain and Germany have high variation. The national factor is useful for order-of-magnitude comparisons, not for operational scheduling.
Embodied carbon of GPUsLifecycle assessment data for AI chips such as the H100 are not public. Estimates rely on die-area models, which carry ±30–50 % uncertainty.
Spatial shifting omittedThis article covers temporal shifting only. Spatial shifting (moving load between regions) can add another 20–40 % of reduction but requires multi-site infrastructure.
Cooling water and other impactsgCO₂eq does not capture cooling water consumption (WUE, Water Usage Effectiveness), another environmental impact indicator relevant to arid zones such as southern Spain.

See also

Sources