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

Tue, 16 Jun 2026 08:00:00 +0200

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:

Segment	Typical PUE	Source
Global average	1.54 (6th consecutive year unchanged)	Uptime Institute 2025
Hyperscale (Google, Meta, Microsoft, Amazon)	1.10–1.15	Uptime Institute 2025
Colocation / enterprise	1.58–1.80	Uptime Institute 2025
Unoptimised on-premise	1.6–2.0	industry, various
Theoretical limit (cold air, favourable climate)	1.10–1.20	ASHRAE / 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):

PUE	Total datacenter power	Inflation factor over board
1.10	3,520 W	+10 %
1.40	4,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.

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:

Tool	Signal type	Coverage	Access
ElectricityMaps	Hourly average (production-based and flow-traced)	60+ countries in real time	API (limited free plan); OSS on GitHub
WattTime	Hourly marginal (MOER)	US + growing global coverage	API; free data since 2025 (REsurety-WattTime partnership)
Carbon Aware SDK (Green Software Foundation)	Wrapper over ElectricityMaps and WattTime	Same sources	OSS, 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)

Country	Average intensity 2024 (gCO₂eq/kWh)	Approximate hourly range	Source
Spain	~108	30–250	Nowtricity / REE 2025
France	~21.7 (2024); ~19.6 (2025)	5–80	RTE Bilan Électrique 2025
Germany	~363 (2024); ~328 (2025)	100–600	Fraunhofer 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 day	Typical condition	Estimated intensity (gCO₂eq/kWh)
Solar midday (11:00–15:00, summer)	Solar covers >40 % of demand	30–80
Night-time trough (02:00–06:00, summer)	Zero solar; variable wind	80–180
Demand peak (19:00–21:00, winter)	Gas as the marginal plant	180–280
Cold windless small hours (winter)	Gas + combined cycle dominate	220–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.

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 / hour	Intensity (gCO₂/kWh)	gCO₂ per 1,000 tokens	gCO₂ per 1M tokens
France (2025 average)	19.6	0.025	25.3
Spain solar (summer midday)	~50	0.064	64.5
Spain 2024 average	~108	0.140	139.3
Spain night-time gas (winter)	~220	0.284	283.8
Germany 2025 average	~328	0.423	423.0
Germany coal peak	~550	0.709	709.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:

Scope	Definition	Datacenter example
Scope 1	Direct emissions from owned or controlled sources	Emergency diesel generators
Scope 2	Indirect emissions from purchased electricity consumption	Electricity consumption of the cluster
Scope 3	Other indirect emissions in the value chain	Hardware 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:

Method	What it measures	How it is obtained
Location-based	Actual intensity of the electricity grid where the facility sits	Emission factor of the national or regional grid (published by operators such as REE, RTE)
Market-based	Intensity according to the contractual instruments for energy purchase	Guarantees 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:

Type	Definition	When to use
Average	The share of all grid emissions attributable to the consumer according to their quota	Location-based Scope 2 carbon reporting
Marginal (MOER)	Emissions of the generator that would respond to a marginal increase in load	Evaluating 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:

Item	Indicative value	Source
Service life of a datacenter server	3–5 years	AWS / industry
Service life of the datacenter facility	15–20 years	industry
Amortisation methodology	Embodied carbon / years of service life	GHG 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

Scenario	PUE	Grid intensity (gCO₂/kWh)	gCO₂/1,000 tok	gCO₂/1M tok
France 2025 average	1.45	19.6	0.025	25.3
Spain solar (summer midday)	1.45	50	0.064	64.5
Spain 2024 average	1.45	108	0.139	139.3
Spain night-time gas (winter)	1.45	220	0.284	283.8
Germany 2025 average	1.45	328	0.423	423.0
Germany coal peak	1.45	550	0.709	709.0
Spain solar + hyperscale PUE	1.12	50	0.050	50.0
Spain night-time gas + legacy PUE	1.80	220	0.354	354.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:

Type	Description	Applicable to
Temporal	Delaying or advancing execution within the same datacenter to a lower-carbon hour	Batch, training, deferrable tasks with a loose deadline
Spatial	Moving the load to a geographic region with lower intensity at that moment	Multi-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 / case	Emissions saving	Conditions
Batch load with 24 h shifting (simulation, several grids)	20–40 % emissions reduction	24 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 optimum	Simple one-migration or greedy deferral
UBS + Microsoft, Azure Batch, 24 h window	Validated with the Carbon Aware SDK	Real 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:

Scenario	Intensity (gCO₂/kWh)	Emissions per batch hour	Saving vs non-deferred execution
No shifting (Spain average)	108	501 gCO₂	—
Shifted to a solar hour (50 gCO₂/kWh)	50	232 gCO₂	−54 %
Shifted to a night-time gas hour (220 gCO₂/kWh)	220	1,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:

Symbol	Meaning	Units
$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 percentage	gCO₂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:

Limit	Description
Annual average vs hourly intensity	Using 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 PUE	PUE 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 throughput	The 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 3	Embodied 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 factors	The 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 GPUs	Lifecycle 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 omitted	This 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 impacts	gCO₂eq does not capture cooling water consumption (WUE, Water Usage Effectiveness), another environmental impact indicator relevant to arid zones such as southern Spain.

Sources

Uptime Institute · Global Data Center Survey 2025 (PUE medio global 1,54, 15.ª edición) — https://uptimeinstitute.com/resources/research-and-reports/uptime-institute-global-data-center-survey-results-2025
Uptime Institute Blog · Global PUEs — are they going anywhere? — https://journal.uptimeinstitute.com/global-pues-are-they-going-anywhere/
Uptime Institute Blog · Large data centers are mostly more efficient — https://journal.uptimeinstitute.com/large-data-centers-are-mostly-more-efficient-analysis-confirms/
ElectricityMaps · Electricity Grid Review 2025: Spain (precio, intensidad, correlación precio-carbono −0,70) — https://www.electricitymaps.com/grid-in-review-2025/spain
ElectricityMaps · Marginal emissions — what they are, and when to use them (actualizado enero 2025) — https://www.electricitymaps.com/resources/publications/marginal-emissions-introduction
ElectricityMaps · Interactive map and API — https://app.electricitymaps.com
WattTime · Average vs marginal emissions — https://watttime.org/data-science/data-signals/average-vs-marginal/
WattTime · REsurety-WattTime free global marginal emissions platform (marzo 2025) — https://watttime.org/news-and-insights/resurety-and-watttime-announce-release-of-free-electricity-marginal-carbon-platform/
Red Eléctrica de España (REE) · Renewable energies generated 56 % of Spain’s electricity mix in 2024 — https://www.ree.es/en/press-office/press-release/news/press-release/2025/01/renewable-energies-generated-56-per-cent-spains-electricity-mix-2024
Nowtricity · CO₂ emissions per kWh in Spain (media 2024: 108 gCO₂eq/kWh) — https://www.nowtricity.com/country/spain/
RTE · Bilan électrique 2025 — GHG Emissions (Francia 2025: 19,6 gCO₂eq/kWh) — https://analysesetdonnees.rte-france.com/en/annual-review-2025/ghg-emissions
RTE · Bilan électrique 2024 key findings (Francia 2024: 21,7 gCO₂eq/kWh) — https://assets.rte-france.com/analyse-et-donnees/2025-11/RTE%20-%20Annual%20electricity%20review%202024%20-%20Key%20findings.pdf
Fraunhofer ISE · German Public Electricity Generation in 2025 (Alemania 2025: ~328 gCO₂/kWh) — https://www.ise.fraunhofer.de/en/press-media/press-releases/2026/german-public-electricity-generation-in-2025-wind-and-solar-power-take-the-lead.html
Ember · European Electricity Review 2025 (intensidad UE media: 213 gCO₂/kWh) — https://ember-energy.org/latest-insights/european-electricity-review-2025/five-years-of-progress/
GHG Protocol · Scope 2 Standard Advances (consulta pública 2025, hourly matching, market-based revisions) — https://ghgprotocol.org/blog/scope-2-standard-advances-isb-approves-consultation-market-and-location-based-revisions
GHG Protocol · Public Consultation Scope 2 (octubre 2025) — https://ghgprotocol.org/sites/default/files/2025-10/GHG-Protocol-Scope2-Public-Consultation.pdf
Green Software Foundation · Software Carbon Intensity (SCI) Specification — https://sci.greensoftware.foundation/
Green Software Foundation · SCI GitHub (ISO/IEC 21031:2022) — https://github.com/Green-Software-Foundation/sci
Green Software Foundation · SCI for AI — https://github.com/Green-Software-Foundation/sci-ai
Green Software Foundation · Carbon Aware SDK (Apache 2.0) — https://github.com/Green-Software-Foundation/carbon-aware-sdk
Green Software Foundation · Carbon-Aware Computing Whitepaper — UBS/Microsoft Azure Batch case — https://greensoftware.foundation/articles/carbon-aware-computing-whitepaper-how-ubs-succeeded-in-measuring-and-reducing-car/
arXiv 2512.07799 · Quantifying the Carbon Reduction of DAG Workloads: A Job Shop Scheduling Perspective — https://arxiv.org/abs/2512.07799
arXiv 2512.08725 · Spatio-Temporal Shifting to Reduce Carbon, Water, and Land-Use Footprints of Cloud Workloads — https://arxiv.org/abs/2512.08725
AWS · How AWS estimates embodied emissions of IT hardware (Scope 3 methodology, 2025) — https://aws.amazon.com/blogs/infrastructure-sustainability/how-aws-estimates-embodied-emissions-of-it-hardware-the-science-and-technology-behind-the-latest-customer-carbon-footprint-methodology/
CodeCarbon · Track and reduce CO₂ emissions from your local computing — https://codecarbon.io/

Sci on lo0 — Tech Blog