The Carbon Footprint of an AI Search Query: Inference Emissions Methodology and Calculation Approach
A reference for estimating the energy and emissions of a single AI/LLM inference query — the per-query “quotient problem,” the boundary that determines what a quoted figure includes, the four estimation tiers from instrumented telemetry to order-of-magnitude scaling, grid allocation for inference workloads, and the roll-up from one query into a corporate Scope 2 or Scope 3 Category 1 inventory line. Anchored to live MasterBrain inference data (Epoch AI 2025) and aligned to the AI compute methodology, Software Carbon Intensity (SCI), and the GHG Protocol.
The most-cited number in this field — “an AI search uses about ten times the energy of a regular search” — is not a measurement. It is a quotient: total data-centre energy divided by a query count, with the boundary and the denominator almost never disclosed. Change the output length, the model, the hardware, or the accounting boundary, and the figure moves by an order of magnitude.
A per-query carbon figure you cannot interrogate is a press release, not an inventory input. This page gives you the apparatus to interrogate one.
A single frontier-class text query draws roughly 0.3 Wh of energy (central estimate, Epoch AI 2025). Multiply by the grid intensity where the datacentre sits to get carbon per query.
The Per-Query Quotient Problem
Named concept · Citable definition
The per-query quotient problem
A per-query AI energy or emissions figure is almost never measured directly; it is computed as total measured infrastructure energy ÷ a query count, and is therefore only interpretable when both the boundary of the numerator (what infrastructure is counted) and the basis of the denominator (how a “query” is defined, and at what output length) are disclosed. A figure quoted without its boundary and its output-token basis is not auditable, regardless of how precise it appears.
Nearly every public claim about AI query energy traces back to a quotient. A researcher or operator takes a measurable quantity — the electricity drawn by a cluster over a period — and divides it by a count of requests served. The result is a tidy “X watt-hours per query.” The arithmetic is sound; the interpretability is not. The numerator’s boundary (does it include data-centre cooling overhead, the retrieval index, the training cost amortised over the model’s life?) and the denominator’s basis (is a “query” one prompt, one full conversation, one API call returning 50 tokens or 5,000?) are the two levers that move the headline figure by more than an order of magnitude — and they are the two things most reporting omits.
This is why the same underlying technology has been reported at figures spanning from a fraction of a watt-hour to several watt-hours per query. The MasterBrain inference data this page is built on makes the levers explicit rather than hiding them: the central per-query estimate of 0.3 Wh carries an attached output-token basis of 500 tokens and a stated range up to 3 Wh. The range is not noise — it is the visible footprint of the boundary and denominator choices. A defensible per-query figure is one where those choices are written down.
The question is never “how many grams per query.” The question is “how many grams per query, counting what, divided by what.” The first has no answer; the second has an auditable one.
Provider directory
Need help keeping this up all year?
See who does this work. Every listing names the standards it works to, and paid placements are labelled. Including Attain Zero and Small World Consulting.
Browse 6 carbon accounting & inventory providers →Do this work? A listing is US$390 a year. Get listed →
What One Query Actually Does
To know where a per-query figure comes from, you have to know where the energy is spent inside a single inference. A large-language-model query is not a uniform block of compute; it has two phases with very different cost profiles, and the lever that dominates the total is the one most figures never mention.
Figure 2.1 — The inference lifecycle of one query, with relative energy weighting
Tokenise
Prompt text is split into tokens. Negligible compute — CPU-side, sub-millisecond.
Energy: trivial
Prefill
The full prompt is processed in one parallel forward pass to build the attention cache. Cost scales with input length, but it is a single pass.
Energy: moderate, input-bound
Decode
Output tokens are generated one at a time, each requiring a full forward pass over the model. This is the dominant cost and it scales linearly with output length.
Energy: dominant, output-bound
Return
Response is detokenised and streamed to the user. Network + serving overhead, small relative to decode.
Energy: small
Prefill versus decode
Prefill processes the entire prompt in a single parallelised pass — long inputs cost more, but the cost is paid once. Decode is autoregressive: every output token requires its own forward pass through the model’s parameters, so a 1,000-token answer costs roughly ten times the decode energy of a 100-token answer to the same prompt. For typical assistant-style traffic, decode dominates the per-query total. This is the single most important structural fact about inference energy, and it is why output length, not input length, is the lever a reporter most needs to disclose.
Output length as the dominant lever
Because decode scales with output tokens, the per-query figure is really a per-token figure in disguise. MasterBrain carries the lever directly: the marginal cost is 0.0006 Wh per output token (Epoch AI 2025), and the headline per-query figure assumes a basis of 500 output tokens. Multiply the per-token value by your actual mean output length and you get a workload-specific per-query figure that a generic headline cannot give you. A short factual lookup and a long generated essay are not the same “query,” and a methodology that treats them identically is hiding its largest source of variance.
Two structural consequences follow. First, any per-query figure is only comparable to another at the same output-token basis — comparing a 100-token-basis figure to a 500-token-basis figure is comparing different units. Second, the cheapest real lever on inference emissions is output brevity: capping or shortening responses cuts decode energy close to linearly, which is why it appears in the calculator’s decision list rather than as an automated default.
The Boundary Problem
The numerator of the quotient is a boundary choice. Six components could be counted toward “the footprint of a query,” and different published figures count different subsets — which is most of why they disagree. The table sets out each component, whether it belongs in a per-query inference figure, and which actor’s inventory it lands in.
| Component | In a per-query inference figure? | Why | Whose inventory | MB-backed? |
|---|---|---|---|---|
| Inference compute (GPU/accelerator) | Yes — core | The forward passes that produce the answer. This is the irreducible per-query cost. | Operator Scope 2 | Yes — digital.ai.inference.* |
| Host server overhead (CPU, memory, NIC) | Yes | Non-accelerator server draw supporting the inference. Folded into measured node energy. | Operator Scope 2 | Partial — within node energy |
| Data-centre overhead (cooling, power loss) | Yes — via PUE | Applied as a PUE multiplier on IT energy. Omitting it understates by 10–60%. | Operator Scope 2 | Yes — digital.data_centre.pue.* |
| Training cost (amortised) | Separate line — do not fold in | One-off model cost amortised over its inference life. Belongs in a distinct training line, not the marginal per-query figure. | Operator Scope 2 (energy) / Scope 3 for buyers | Yes — digital.ai.training.* |
| Retrieval / RAG / index serving | Yes if used — usually omitted | For search-augmented queries, the retrieval index draws energy too. Materially under-reported. | Operator Scope 2 | No — genuine MB gap |
| End-user device + network transport | No — out of operator boundary | The user’s device and the network path are the user’s footprint, not the operator’s per-query figure. | User / end-user devices | No — genuine MB gap |
Inference compute — the core
The accelerator’s forward passes are the one component every credible figure includes. It is the energy MasterBrain’s digital.ai.inference.* family quantifies directly, and it is the only component that scales one-to-one with the work the query actually requested.
Data-centre overhead via PUE
IT energy is not facility energy. Cooling, power conversion losses, and lighting add overhead captured by Power Usage Effectiveness — facility energy ÷ IT energy. A hyperscale data centre may run a PUE near 1.1; an enterprise facility closer to 1.7 (MasterBrain digital.data_centre.pue.enterprise.high = 1.7). A per-query figure that omits PUE silently undercounts by the overhead fraction, and the same query “costs more” in a less efficient facility. PUE is multiplicative on the energy chain in §4 and is a genuine boundary choice, not a rounding detail.
Training amortisation — a separate line
Training is a large one-off: MasterBrain records 3.2 tCO₂e for a single reference training run (Patterson 2021, AR6 basis). Amortised across the billions of inferences a deployed model serves, the per-query share of training is small — but it is real, and it belongs in its own line so that the marginal inference figure stays clean. Folding amortised training into the per-query number is failure mode 8.2 below: it double-counts when both a training line and an inflated per-query line are reported.
Retrieval, device, and network — the honest gaps
Three components have no MasterBrain factor row today. Retrieval/RAG index-serving energy (real, operator-side, usually omitted), end-user device energy attributable to a query, and network transport energy are all genuine data gaps. This page does not invent values for them. Where a complete boundary requires them, treat them as not available in our data, so they need a dedicated source check, and disclose the omission rather than papering over it.
The Energy-to-Emissions Chain
The per-query figure is built in two moves: assemble facility energy from IT energy and overhead, then convert energy to emissions with a grid intensity factor. MasterBrain supplies the energy term; the grid factor supplies the conversion.
E_query — per-query IT energy in Wh, from digital.ai.inference.frontier_class.per_query_wh (or per-token × output tokens for a workload-specific figure).PUE — facility overhead multiplier, from digital.data_centre.pue.*. Hyperscale ≈ 1.1; enterprise high ≈ 1.7.grid factor — location-based grid intensity for the serving region, from [gc_grid country="..."] (kg CO₂e/kWh).× 1000 — kg→g for a per-query figure that is naturally sub-gram. Drop for tonne-scale roll-ups.Two cautions on units, both of which trip up published figures. First, energy is in watt-hours; the grid factor is per kilowatt-hour — convert (÷1000) before multiplying, or the result is off by three orders of magnitude. Second, the MasterBrain region rows (digital.gcp.region.*) are expressed in grams CO₂e/kWh, whereas [gc_grid] is in kilograms CO₂e/kWh — do not mix the two scales in one calculation. The worked examples in §9 carry the units explicitly at every step for exactly this reason.
The Four Estimation Tiers
Named concept · Citable definition
The inference estimation tier ladder
An ordered preference for sourcing the per-query energy term, from Tier 1 instrumented measurement (telemetry on the serving hardware), through Tier 2 vendor-disclosed (model-card or operator figures), Tier 3 published benchmark proxy (independent reassessments such as Epoch AI 2025), to Tier 4 order-of-magnitude scaling (analogy from a known model). Specificity descends and audit risk rises down the ladder; the reporter uses the highest tier for which evidence exists.
You cannot always measure a query directly — most API consumers never see the serving hardware. The tier ladder mirrors the evidence hierarchy used elsewhere in GHG accounting: pick the most specific tier you can evidence, and document why a higher tier was unavailable.
digital.ai.accelerator.* — TDP × utilisation × wall-clock per query.digital.ai.inference.* family (Epoch AI 2025 reassessment of frontier-class query energy).Two rules govern the ladder. First, tier selection is downward-only — never use a less specific tier when a more specific one is evidenced. Second, the tier travels with the number: a per-query figure disclosed without its tier is as uninterpretable as one disclosed without its boundary. State both.
Grid Allocation for Inference
Energy becomes emissions at the grid intensity of the place and time the query was served. The same query that costs a fraction of a gram on a low-carbon grid costs several times more on a coal-heavy one — so where inference runs is itself an emissions lever, and the location-based / market-based distinction from Scope 2 accounting carries straight over.
Location-based
The location-based figure uses the published average grid intensity for the serving region — the physical grid the data centre draws from. For a UK-served query, that is 0.131 kg CO₂e/kWh; for a US-served query, 0.350 kg CO₂e/kWh. This is the conservative, physically grounded number and the one to anchor a per-query estimate on. Because inference is dispatched to data centres in known regions, the serving region’s grid factor is usually identifiable in a way that, say, an end-user’s grid is not.
Market-based and carbon-free energy matching
Operators frequently report inference against a market-based figure reflecting renewable procurement or a region’s carbon-free-energy (CFE) percentage. MasterBrain carries per-region CFE context (digital.gcp.region.*, Google CFE 2026) but no market-based or CFE-percentage factor row that resolves to a usable kg/kWh — so a market-based inference figure here is narrative plus external citation, not a factor call. Treat any operator’s market-based per-query claim the way Scope 2 treats a bundled-instrument claim: valid as disclosed, but read alongside the location-based figure, never instead of it.
The 24/7 matching question
Annual renewable matching can show a region as “100% renewable” on a yearly average while individual queries at night run on fossil generation. Hourly or 24/7 carbon-free-energy matching is the emerging rigour here, and it matters more for inference than for most workloads because query traffic has strong diurnal patterns. This is a forward-looking governance point rather than a calculation step today — there is no hourly-matching factor in the reference data — but it is the direction operator disclosures are moving, and an audit-grade report should state whether its grid figure is an annual average or time-matched.
From One Query to an Inventory Line
A per-query figure is a unit cost; an inventory needs a total. The roll-up is arithmetically simple — per-query energy × query volume × grid factor — but whose inventory the total lands in depends on who you are in the transaction.
| Actor | Relationship to the query | Scope | What they count |
|---|---|---|---|
| Model operator | Runs the inference cluster; buys the electricity. | Scope 2 (electricity) | Facility energy (E_query × PUE) × grid factor, summed over all queries served. |
| Enterprise API buyer | Calls a hosted model; does not own the hardware. | Scope 3 Category 1 (purchased goods & services) | Their share of the operator’s emissions, by query volume. A purchased service, upstream. |
| Application vendor (reseller) | Embeds a model in a product sold on. | Scope 3 Cat 1 upstream; informs product carbon footprint downstream | Upstream inference cost as Cat 1; may pass through to a product/service footprint. |
| End user | Types the prompt; consumes the answer. | Generally none for the inference itself | Only their own device + network energy — not the operator’s inference, which is not the user’s to claim. |
The roll-up arithmetic
For an enterprise counting API usage in Scope 3 Cat 1, the annual figure is mean per-query energy × annual query count × PUE × serving-region grid factor. The two terms that most change the total are output length (via per-query energy) and query volume — and because both are usually known to the buyer from their own API logs, an enterprise often has a better denominator than the operator’s public average. Worked Example B carries this through. The discipline is to use a per-query energy figure at the buyer’s actual mean output length, not a generic headline at someone else’s token basis.
Failure Modes
Named concept · Citable definition
The inference-figure failure taxonomy
Six structurally distinct ways a per-query AI emissions figure misleads — each named, numbered, and identifiable from the figure’s stated (or unstated) boundary and basis, so a reader can detect the failure without access to the underlying telemetry.
The taxonomy below is the canonical six. Each is citable as “GreenCalculus AI Search Query Methodology v1.0, failure mode 8.n.” Failure mode 8.1 is the most common in popular reporting; 8.6 is the most damaging in a corporate disclosure.
output_tokens_assumed = 500 basis is the model for what disclosure looks like.3 Wh) with no per-token decomposition often has training baked in. Training (digital.ai.training.*) belongs in its own line.digital.data_centre.pue.* for a plausible facility multiplier.[gc_grid] factor for the real serving region(s); report market-based as a companion, not a replacement.digital.ai.inference.* family is designed to be re-read, not snapshotted.Worked Examples — Audit Records
Three audit-record snapshots at this page’s review date. Per-query energy terms reconcile to the live digital.ai.inference.* family; all numerics are fixed in these examples (they must reconcile to the stated inputs at the snapshot date regardless of future MasterBrain updates). Each is replicable in the AI Compute Calculator.
Per-query IT energy: 0.3 Wh (central estimate) · PUE: 1.2 (efficient cloud facility) · Grid: UK location-based The base case. Demonstrates that a single query at the central estimate is a sub-gram quantity, and that the dominant uncertainty is the energy basis, not the grid factor.
0.131. At the range high end (3 Wh) the same query is ≈ 0.75 gCO₂e — a 10× spread driven entirely by the energy basis, which is exactly why the output-token basis must travel with the figure. Replicate in the calculator →Per-token energy: 0.0006 Wh/token (Epoch AI 2025) → per-query 500 × 0.0006 = 0.3 Wh (reconciles to the central per-query value) The roll-up. Shows the buyer using their own query count and mean output length — a better denominator than a generic headline — to land a Scope 3 Cat 1 figure.
digital.ai.inference.* family and the current [gc_grid] factor (failure mode 8.6). Boundary note: this counts inference compute + PUE only — retrieval, device, and network are out of the operator boundary or are genuine data gaps. Replicate in the calculator →Stated boundary: none · Output-token basis: none · PUE: unstated · Grid: none · Vintage: unstated The audit. Walks the quoted number through the apparatus and shows which disclosures are missing — not to prove it wrong, but to show it is uninterpretable as given.
Standards Alignment
No single standard yet governs per-query AI inference accounting end to end; the methodology assembles from a digital-emissions standards cluster plus the GHG Protocol scope rules.
| Standard | Role for per-query inference accounting |
|---|---|
| GHG Protocol Corporate Standard | Defines the Scope 2 / Scope 3 Cat 1 boundary that decides whose inventory a query lands in (Table 7.1). |
| Software Carbon Intensity (ISO/IEC 21031) | The SCI specification frames per-functional-unit software emissions — the closest formal analogue to a per-query figure (operational + embodied per unit of work). |
| ISO/IEC 30134 + Uptime PUE | Define PUE and related data-centre KPIs — the overhead multiplier in the energy chain (§4). |
| ML CO₂ Impact | Machine-learning emissions estimation conventions — methodological grounding for the training-amortisation contrast and the accelerator bottom-up path. |
| CSRD / ESRS E1 | For EU enterprises, the disclosure regime under which API-inference Scope 3 Cat 1 emissions are reported, with location-based grid citation expectations. |
| Ember / grid factor sources | Supply the location-based grid intensity factors resolved via [gc_grid] for the energy-to-emissions conversion. |
What the Calculator Handles vs What You Decide
The AI Compute Calculator automates the mechanical energy-to-emissions chain. This methodology page covers the boundary and tier decisions the calculator cannot make for you.
- Per-query and per-token energy lookup from the live
digital.ai.inference.*family - PUE multiplier application from
digital.data_centre.pue.* - Energy → emissions conversion at the serving-region
[gc_grid]factor with unit handling (Wh→kWh, kg→g) - Output-length scaling via the per-token lever
- Annual roll-up from per-query energy × query volume
- Bottom-up accelerator path from
digital.ai.accelerator.*(TDP × utilisation) for a Tier-1 estimate - Range display (0.3–3 Wh) to surface the uncertainty band, not a false-precision point
- Boundary — which components of Table 3.1 you count; disclose retrieval/device/network omissions
- Estimation tier — the most specific tier you can evidence (§5); document why a higher tier was unavailable
- Output-token basis — your workload’s real mean output length, not a generic headline basis
- Query definition — per API call, per turn, or per session (failure mode 8.5)
- Serving region — where inference actually runs, for the right grid factor (failure mode 8.4)
- Location- vs market-based — anchor location-based; report any market-based figure as a companion
- Training treatment — keep amortised training a separate line (failure mode 8.2)
- Vintage — re-source the per-query basis each inventory year (failure mode 8.6)
Ready to compute? Open the AI Compute Calculator →
Audit Checklist — Per-Query Inference Pre-Flight
Eight items to run before submitting any per-query or rolled-up AI inference figure for review or disclosure.
- 01Output-token basis stated. Every per-query figure carries its output-token denominator. A figure without one is not comparable and not auditable (failure mode 8.1).
- 02Estimation tier documented. The tier (§5) is stated, with evidence for it and a note on why a higher tier was unavailable.
- 03Boundary disclosed. Table 3.1 components counted are listed; retrieval, device, and network omissions are stated rather than silently dropped.
- 04PUE applied and stated. Facility energy = IT energy × a stated PUE — measured for Tier 1, sourced default otherwise (failure mode 8.3).
- 05Training kept separate. Amortised training is a distinct line, never folded into the marginal per-query figure (failure mode 8.2).
- 06Grid factor matches serving region. Location-based factor for where queries actually run; any market-based figure shown alongside, not instead (failure mode 8.4).
- 07Query unit consistent. Per call / per turn / per session is defined once and held constant across the report (failure mode 8.5).
- 08Vintage current. The per-query energy basis is re-sourced for the inventory year against the live
digital.ai.inference.*family (failure mode 8.6).
Methodology Metadata — for Inventory Documentation
Copy into your inventory methodology statement; adjust the tier, boundary, and grid lines to match your choices.
digital.ai.inference.* (Epoch AI 2025 reassessment). Central 0.3 Wh; per-token 0.0006 Wh; range 0.3–3 Wh at a 500-token basis.digital.data_centre.pue.* default]. Facility energy = IT energy × PUE.[gc_grid country="..."] kg CO₂e/kWh for the serving region (Ember). Market-based / CFE figure, if reported, cited externally as a companion.
Frequently Asked Questions
A frontier-class text query draws roughly 0.3 Wh as a central estimate (Epoch AI 2025), within a published range of 0.3 to 3 Wh. That is energy, not emissions — convert it at the serving region’s grid intensity (energy in kWh × grid factor) to get grams of CO₂e. The figure only means something at a stated output-token basis: the central estimate assumes 500 output tokens, and a longer answer costs proportionally more because decode energy scales with output length.
Because almost all of them are quotients with undisclosed boundaries and denominators (the per-query quotient problem, §1). Two figures can differ by 10× purely from different output-token assumptions, whether PUE is included, whether amortised training is folded in, and which grid region is used. The disagreement is mostly an artefact of undisclosed accounting choices, not of the underlying technology. A figure you can interrogate — with its boundary, tier, output-token basis, PUE, and grid region stated — is comparable; one without those is not.
The “10×” claim traces to early figures near the top of the range that have since been reassessed downward (the Epoch AI 2025 work underlying the MasterBrain data revisited exactly this). At the central per-query estimate the multiple is far smaller, and the honest answer is that the comparison is only meaningful when both sides state their boundary and basis. Worked Example C walks a quoted “10×” claim through the apparatus and shows it is uninterpretable as usually stated — not necessarily wrong, but missing every disclosure needed to verify it.
It should not. Training is a large one-off — MasterBrain records 3.2 tCO₂e for a reference training run — that belongs in its own inventory line, amortised across the model’s inference life. Folding amortised training into the marginal per-query figure inflates it and risks double-counting if a training line is also reported (failure mode 8.2). Keep marginal inference and amortised training as separate lines.
It depends who you are. The model operator who runs the cluster and buys the electricity counts inference in Scope 2. An enterprise that calls a hosted model via API counts its share in Scope 3 Category 1 (purchased goods and services) — a purchased upstream service. An application vendor reselling a model treats inference as upstream Cat 1 and may pass it into a downstream product footprint. The end user generally counts nothing for the inference itself — only their own device and network energy. Table 7.1 sets out each case.
Power Usage Effectiveness is facility energy ÷ IT energy — the overhead from cooling, power conversion, and lighting. A hyperscale facility may sit near 1.1; an enterprise one near 1.7 (MasterBrain digital.data_centre.pue.enterprise.high = 1.7). A per-query figure that reports only IT energy and omits PUE understates the real facility draw by the overhead fraction — 10% to 60% depending on the site. Because PUE is multiplicative on the energy chain (§4), omitting it is a common and material error (failure mode 8.3). Always apply and state the PUE used. For the full treatment see the data-centre PUE methodology.
Multiply per-query IT energy × PUE × annual query count to get facility energy, then × the serving-region grid factor. As an API buyer you usually have a better denominator than any public average, because your own logs give you exact query counts and mean output length — so use a per-query energy figure at your mean output length, not a generic headline at someone else’s token basis. Worked Example B carries this through: 20 million queries at a 500-token basis on a UK grid lands near 1.5 tCO₂e/year. Re-run it each year against the live data (failure mode 8.6).
Yes — substantially. The same query’s energy is fixed, but its emissions are energy × grid intensity, and grid intensity varies several-fold across regions. A query served on a low-carbon grid emits a fraction of the same query on a coal-heavy one, so serving region is itself an emissions lever. Anchor on the location-based factor for where inference actually runs via [gc_grid]; if an operator reports a market-based figure reflecting renewable procurement, read it alongside the location-based number, never as a replacement (failure mode 8.4). Time-matching (24/7 carbon-free energy) is the emerging rigour, since query traffic is diurnal and an annual average can hide nighttime fossil generation.