Estimating AI's carbon footprint.

Or, generating equations with as few unknowns as possible.

The environmental impact of AI is huge. There’s an insatiable quest for power (I mean electricity, but you know, other types of power too). On the flipside, it’s clear that there are some use-cases (particularly software development) where there are benefits.

How do you quantify the impact of your usage of AI with your carbon footprint?

Neither Anthropic nor OpenAI publishes concrete information about their environmental impact. In this post, I’ll try to estimate some bounds.

First off, a disclaimer. I’m an arm-chair researcher writing things up based on publicly available information. Don’t take this as gospel; it’s an estimate and if I’ve made incorrect assumptions, tell me!

Tommaso.sansone91, CC0, via Wikimedia Commons

Everyone has a number

Sam Altman says an average ChatGPT query uses about 0.34 watt-hours. Google’s August 2025 paper on Gemini puts the median text prompt at 0.24 Wh.

The trouble is that any single number describes a population. A short factual question on a non-reasoning model, served from a hyper-scaler on a clean grid, sits at one end. An ARC-AGI puzzle solved by frontier model in high-compute mode sits at the other.

Once you fix the model and infrastructure, the dominant variable you actually control is the number of tokens the system burns.

The formula.

There is a simple way to think about the cost of an AI query:

How much computation did the model do, how much electricity did that require, and how dirty was the electricity?

For a transformer, generating one token takes roughly two floating-point operations per active parameter (one multiply and one add) per active parameter.

So, the first-order compute cost is:

\(\text{FLOPs} \approx 2 \times N_{\text{active}} \times T_{\text{effective}}\)

Where:

• N_active is the number of active parameters used per token.

• T_effective is the number of tokens the system actually burned.

T_effective is the part doing a lot of work. It’s not just the number of tokens you see on the screen. It includes the prompt, the answer, the hidden reasoning tokens, any agent loops, retries, tool calls and so on. A normal chat request might be a few hundred or a few thousand tokens, but a hard reasoning task could be many multiples of that.

That’s why thinking about as “what does a query cost” is the wrong question. A query isn’t a unit. Tokens are a bit closer, but even then, that hides the batching, hardware and datacentre effects.

To turn compute into energy, we need to account for how efficiently the GPU is actually being used. This looks more complicated than it is!

\(E_{\text{node}} \approx \frac{ 2 \times N_{\text{active}} \times T_{\text{effective}} }{ P_{\text{peak}} \times \epsilon_{\text{serve}} } \times P_{\text{GPU}} \times \alpha \times PUE \times \eta_{\text{node}}\)

The fraction gives us seconds of GPU time (total FLOPS needed divided by speed of GPU). The remaining terms turn seconds into joules.

In plain English:

• P_peak is the theoretical speed of the GPU.

• e_serve is the realised serving efficiency (how much of that peak bandwidth is used)

• P_GPU is the GPU’s power draw.

• α is the fraction of the GPU’s rated power actually used.

• PUE is the datacentre overhead. If the servers use 1 kWh and the building uses another 0.2 kWh for cooling and power conversion, the PUE is 1.2.

• η_node adds the rest of the server: CPU, memory, networking, power losses.

And now to get an estimate of the CO2 equivalent.

\(\text{gCO}_2\text{e} \approx \frac{E_{\text{node}}}{3{,}600{,}000} \times \text{CI} \)

The 3,600,000 is just the conversion from joules to kilowatt-hours. CI is the carbon intensity of the electricity grid, measured in grams of CO₂ per kWh.

What are some plausible numbers?

Let’s see if we can get anywhere near the numbers from Google and Sam Altman.

Let’s start making assumption. I’ll use an H100-ish GPU as the reference point because that was probably dominant at the time of those comments, and it’s a good baseline.

• Active model size: 100B parameters

• Accelerator peak throughput: 3.96 PFLOP/s

• Realised serving efficiency: 5%

• GPU rated power: 700W

• Actual power draw: 60% of rated power

• Node overhead: 1.3×

• Datacentre PUE: 1.1

5% efficiency sounds absolutely mad right? LLM serving is beyond just inference, there’s prefill, decoding, KV cache, memory bandwidth, batching and so on. NVIDIA published a benchmark for Llama 2 70B on 8 H100 GPUs. The server processed about 5 inferences per second, and that works out to about 5% of the peak throughput¹,

Plugging in all of those numbers into our formula gives this.

\(E_{\text{total}}(T) \approx \frac{ 2 \times 100{,}000{,}000{,}000 \times T }{ 3.96 \times 10^{15} \times 0.05 } \times 700 \times 0.6 \times 1.3 \times 1.1\)

And if we simplify this (and divide by 3.6M to get kilo-watt hours. We get.

\(E_{\text{total}}(T) \approx 0.00017T \text{ Wh}\)

So, under the assumptions I’ve made, every 1000 tokens costs about 0.17Wh. Which feels close enough to the numbers cited by Altman and Google. If I work backwards from their output, it’s 2000 effective tokens for ChatGPT and 1400 for Google and that sounds a plausible number of tokens to me!²

Translating into carbon footprint.

If we’ve got the Watt hours, we now have to multiply the Watt hours by the carbon intensity.

If you are using gas turbines to power your LLM then that’s one end of the spectrum (somewhere between 500-600 grams of CO2 per kilowatt hours, see here). In the UK, the carbon intensity was 125g CO2/Kwh (see 2024 energy review). And in Norway, it’s super clean at 2.2g CO2/KWh.

If we plug that into our formula we get:

\(\text{gCO}_2\text{e}(T) \approx 0.00017T \times \frac{\text{CI}}{1000}\)

I’ll use gCO₂e rather than just gCO₂. The “e” means equivalent: other greenhouse gases, especially methane, converted into the warming impact of CO₂.

So, a 2,000 effective-token query is:

• at 550 g/kWh: about 0.19 gCO₂e

• at 125 g/kWh: about 0.04 gCO₂e

• at 30 g/kWh: about 0.01 gCO₂e

These are tiny amounts for sure, but what happens at scale?

Tokenmaxxing

Meta used 60.2 trillion AI tokens in 30 days (via The Pragmatic Engineer).

\(\begin{aligned} T &= 60.2 \times 10^{12} \text{ tokens} \\[4pt] E(T) &\approx 0.00017T \text{ Wh} \\[4pt] E(T) &\approx 0.00017 \times 60.2 \times 10^{12} \text{ Wh} \\[4pt] &\approx 10.23 \times 10^{9} \text{ Wh} \\[4pt] &\approx 10.23 \times 10^{6} \text{ kWh} \\[4pt] &\approx 10.23 \text{ GWh} \\[8pt] \text{gCO}_2\text{e} &\approx 10.23 \times 10^{6} \times 125 \\[4pt] &\approx 1.28 \times 10^{9} \text{ gCO}_2\text{e} \\[4pt] &\approx 1.28 \times 10^{6} \text{ kgCO}_2\text{e} \\[4pt] &\approx 1{,}280 \text{ tonnes CO}_2\text{e} \\[4pt] &\approx 1.28 \text{ kilotonnes CO}_2\text{e} \end{aligned}\)

This is a staggeringly large impact³ - that’s 700 return economy trips between London and NY. Given that there are typically 20 or so flights per day between London and NY, this is clearly a pretty significant number. And that’s just Meta!

What does this mean?

The point is not that every AI query is an environmental disaster. Most aren’t. A single short prompt is tiny compared with flying, heating a house, or driving a car.

The problem is abstraction. Once tokens are hidden behind chat boxes, agents, IDE plugins and “autonomous” workflows, nobody notices when a simple question becomes a thousand-step computation.

That makes AI carbon a design problem.

Engineering leaders should stop asking, “Is AI good or bad for the environment?” and start asking better questions. Which model is appropriate for this task? How much context are we sending? Do we need reasoning mode? Are retries bounded? Are agents allowed to loop? Are we measuring tokens per useful outcome?

The useful distinction is not AI versus no AI. It is valuable tokens versus waste tokens.

1. OK, this feels like the weakest assumption I’ve made, and I’ve probably misunderstood something, but here’s my logic.

The workload was 2048 input tokens, and an output of 128. Llama 2 70B is a dense model, so the estimate of FLOPs per inference in this case is 2 x 2176 x 70B.

If we do five inferences per second, then we now get 5 x 2 x 2176 x 70B FLOP/second. If we take the peak throughput of 3.96 PFLOPS and multiply by 8 then we get the total.

Take the ratio of the two and we get:

\(\ e_{serve} \approx \frac{ 1.52 \times 10^{15} }{ 3.17 \times 10^{16} } \approx 0.048\)

I even checked with Wolfram Alpha.

2. If I run the numbers with the B200 I get a 0.11 vs. 0.17 impact (a roughly 50% improvement!). I would guess the TPUs and subsequent generations will be much more efficient.

3. Under the assumptions I have made of course - it’s very likely a vast over-estimate because I’d hope things like caching kick in and save a whole bunch of work.