Why AI footprint estimates differ: published figures, each with its boundary and its date

Because they count different things. Google's August 2025 report gives 0.24 Wh for the median Gemini Apps text prompt when the whole serving stack is counted, and 0.10 Wh for the same prompt on a narrower accelerator-only method, a gap of 2.4 times inside one paper. Across the sources below, energy per response runs from about 0.02 Wh to about 40 Wh, carbon from under 0.01 g to about 17 g, and water from 0.12 mL to over 200 mL. Five choices drive that spread. They are what a prompt contains, which parts of the stack count, which grid and accounting basis apply, which lifecycle stages are included, and which water is counted. Each figure below carries its boundary and its date.

The three tables list figures in order of publication, each as its publisher stated it, and each linked to the document that states it. A value in one row is not a correction of a value in another. Most rows answer a different question, and the boundary column says which.

The AI Energy Score methodology is set out on the project's own page, and the Google narrower figures also appear in its blog post of the same date.

Usually an undisclosed number of tokens, and that number moves the result almost in proportion. Epoch AI assumes 500 output tokens, Jegham and co-authors use 100 input and 300 output for a short prompt, Mistral reports a 400-token response and Oviedo and co-authors sample around a median of 300 output tokens. SAEF's default exchange is 928 input and 282 output tokens. Google's paper does not state a token count for its median prompt and Altman's post does not state one for his average query. A median and an average are also different statistics of the same traffic.

The arithmetic on one factor shows the size of this choice. For SAEF class C, with nothing changed but the token counts, 100 input and 300 output tokens come to 0.216 Wh, 928 and 282 come to 0.367 Wh, and 10,000 and 1,500 come to 2.95 Wh. That is 13.6 times from the definition of a prompt alone. SAEF weights input tokens below output tokens, which is why the middle case is not simply three times the first.

Reasoning is the extreme case of the same effect. In the AI Energy Score post, DeepSeek-R1-Distill-Llama-70B goes from 49.53 to 7,626.53 Wh per 1,000 queries when reasoning is switched on, or 154 times. Oviedo and co-authors estimate a rise of 13 times for queries about 15 times longer than typical. The two figures rest on different models and workloads and do not need to agree.

Anything from the accelerator alone to the whole facility. Google's own comparison is the cleanest illustration, because the prompt does not change. Its Existing Approach gives 0.10 Wh and its Comprehensive Approach, which adds host CPU and DRAM, idle machines and data-centre overhead, gives 0.24 Wh.

The same step appears elsewhere as a stated multiplier. MIT Technology Review doubles a GPU reading of 57 J to 114 J, so 0.016 Wh becomes 0.032 Wh. The AI Energy Score keeps GPU energy on its own, because that is what it uses to compare models. SAEF applies three published uplifts to accelerator energy. For class C that is 0.186 Wh × 1.5 (host) × 1.1 (idle) × 1.2 (facility) = 0.367 Wh per exchange, so about 49% of the final figure sits outside the accelerator.

A location-based factor describes the grid where the electricity is drawn. A market-based factor nets off the buyer's contracted clean energy. Google's paper publishes both for 2024, which makes the difference easy to compute for one prompt. At the location-based 345 g per kWh, 0.24 Wh is 0.083 g CO₂e. At the market-based 94 g per kWh, it is 0.023 g. Google's published 0.03 g uses the market-based factor and adds its Scope 1 and embodied Scope 3 terms. The location-based sum above is our arithmetic and is not a figure Google publishes.

Region then does the rest. SAEF's implied electricity intensity runs from 0.038 kg CO₂e per kWh in EU North - Sweden to 0.501 in Asia Pacific - Singapore, which is 13.0 times. For a class B exchange of 0.099 Wh, electricity alone is 0.0038 g in the first and 0.049 g in the second. Berget AI's published comparison of one request in Sweden and in Texas shows the same lever on a different model and hardware.

Electricity at the point of use is the common core, and sources differ on what they add. Epoch AI excludes embodied hardware and training. Google adds embodied Scope 3 and leaves training to future work. Mistral reports inference and training as separate results. Tomlinson and co-authors amortise training into the query, so 1.84 g of their 2.22 g is training.

The share of these extra terms depends on the grid. For a SAEF class B exchange, electricity is 90% of the 0.053 g total at the world-average grid and 40% of the 0.0094 g total in EU North - Sweden. The cleaner the grid, the more of the result is hardware and training, so an electricity-only figure and a lifecycle figure drift further apart exactly where the electricity is cleanest. SAEF reports model development as a separate line that is never added to these totals.

On-site cooling, or that plus the water consumed in generating the electricity. Li and co-authors publish both for GPT-3. Their US average is 2.2 mL on-site plus 14.7 mL off-site, 16.9 mL in total, so 87% of that figure is off-site. Google's 0.26 mL is water consumed at the data centre. Those two values also differ in model, year and hardware, so their ratio does not describe a change in efficiency.

SAEF prints the components separately for the same reason. A class B exchange in US East - N. Virginia is 0.003 mL on-site and 0.24 mL in total. In EU North - Sweden it is 0.001 mL on-site and 0.59 mL in total, higher even as the carbon falls, because of the water allocated to hydropower. Altman's post does not say which water its 0.32 mL represents, so it cannot be placed on either side of this line from the post alone.

Change one term at a time and label the result as your own arithmetic. The first block takes Google's energy figure and applies each of its two published grid factors.

# Restate one published energy figure on two carbon bases.
# Google's 2024 factors, from Elsworth et al. (arXiv 2508.15734).
wh_per_prompt = 0.24
location_based_g_per_kwh = 345
market_based_g_per_kwh = 94

def grams(wh, g_per_kwh):
    return wh * g_per_kwh / 1000

print(grams(wh_per_prompt, location_based_g_per_kwh))  # 0.0828
print(grams(wh_per_prompt, market_based_g_per_kwh))    # 0.0226

The second block is the calculation behind an inventory line. The full table of factors is in the SAEF CSV and each column is explained on the methodology page.

# One inventory line from SAEF. Factors are class B, kg CO2e per million billed
# tokens at the dataset's default input and output mix, version soma-ai-ef-2026.10-dataset-v3.0.0.
FACTORS = {
    "us-east-1": 0.02606,
    "eu-north-1": 0.00714,
}

def inventory_line_kg(billed_tokens, region):
    return billed_tokens / 1_000_000 * FACTORS[region]

print(inventory_line_kg(1_000_000_000, "us-east-1"))   # 26.06
print(inventory_line_kg(1_000_000_000, "eu-north-1"))  # 7.14

One that scales with your own activity and whose boundary you can state. A per-prompt headline describes someone else's traffic, so multiplying it by your message count inherits assumptions you cannot see. These five checks narrow the choice.

1. Prefer a factor per token or per message over a per-prompt headline, and use your provider's token export where one exists.
2. Check the boundary against the standard you follow. The GHG Protocol Scope 3 Standard sets the minimum boundary of Category 1 as all upstream, cradle-to-gate emissions of purchased goods and services, so an electricity-only figure leaves part of that boundary uncounted and the exclusion should be disclosed and justified.
3. Use one accounting basis across the inventory where you can, and say so. A market-based figure for one service added to a location-based estimate for another produces a total that is hard to explain.
4. Record the source, the version and the date. A figure from a page that changes silently cannot be rebuilt next year.
5. Where a provider issues a figure for your own account and states its boundary, use that instead of a calculated estimate for that service.

The steps from usage export to finished line are in the Scope 3 guide.

In the same range for energy, and on a boundary that adds hardware and training for carbon. A class C exchange is 0.367 Wh, which is the same order as the 0.24 Wh, 0.3 Wh, 0.31 Wh and 0.34 Wh rows, although the token counts differ or are unstated. Class B is 0.099 Wh and class A is 0.030 Wh. Carbon includes embodied hardware, construction and amortised training on a location-based grid factor, so it should not be compared with a market-based figure without restating one of them first.

These are estimates built from public benchmarks, not readings from any provider's fleet. The method is under peer review (arXiv 2606.10660), and every value resolves to a versioned table at SOMA AI Emission Factors, so a reader can rebuild it.

The 4.32 g CO₂ per ChatGPT query traces to a Piktochart blog post, not to a study. It assumes 30,000 GPUs emitting 43,200 kg CO₂ a day spread over 10 million queries, and the post itself calls it an oversimplified calculation. It has no row in the tables above because it states no boundary.

The 3 Wh per query traces to de Vries, Joule, 18 October 2023, which takes a reported 0.3 Wh for a Google search and multiplies it by ten. It is a derived estimate from 2023, before providers published their own figures, and later work above sits roughly ten times lower for a short prompt.

A row needs a document we could open that states the value and enough of the method to fill the boundary column. Both origins were checked on 31 October 2026.

Ask the same questions of both. If either one cannot answer, the comparison is not available yet.

1. How many input and output tokens are in the unit, and is that stated or assumed?
2. Which model or class of model, with reasoning on or off?
3. Is the statistic a median, a mean or a single benchmark run?
4. What is inside the energy boundary: accelerators, the whole server, idle capacity, the facility?
5. Which region, and is the grid factor location-based or market-based?
6. Are embodied hardware and amortised training included?
7. For water, is it on-site cooling alone or also the water used to generate the electricity?
8. When was it published, and on what hardware?

• Methodology. How SOMA's own estimates are built
• How to account for AI usage in a Scope 3 inventory. Turning a chosen figure into an inventory line, and where CSRD applies
• SOMA AI Emission Factors table and download. The factors by region and model class