How the numbers are calculated
Most AI calculators multiply a single “0.3 Wh per query” constant, which breaks the moment a model reasons instead of chats. We build energy from the tokens up, using the throughput model from Microsoft Research’s Joule study, then run a Monte-Carlo over the uncertain coefficients so the answer is an honest range, not a false-precise number.
The model, end to end
tokens_eff = out + prefill·(in·(1−cache)) + cached·(in·cache)TPS = throughput(in, out)# long answers lower the batch → cost more per tokenE_query = PUE · P_node[kW] · (tokens_eff / TPS) / 3.6Water = E_IT[kWh]·WUE_onsite + E_total[kWh]·EWIF(region)CO2e_loc = E · grid_intensity(region)CO2e_market = E · provider_matched_intensityP_node is the steady-state power of a serving node (e.g. an 8×H100 box), modelled log-normally around ~70% utilisation. PUE is the data-center overhead. Throughput is fitted from public benchmarks as a function of input and output length. Node power, PUE and throughput are all sampled, so each result is a distribution, reported as P5 / median / P95.
What actually moves the number
Output length is the lever
Energy scales with the tokens a model generates, one at a time in the decode phase. A reasoning answer emits ~10× the tokens of a chat reply and stresses the KV-cache, measured up to 25× more energy for the same model.
Batching & caching
Serving many requests together spreads the fixed cost of loading model weights; cached prompt tokens skip recompute. Aggressive production batching can be 3-5× more efficient than a latency-first, single-stream self-host.
Where it runs
The same query is ~30× cleaner on France's grid than India's on carbon, and water depends on both data-center cooling and the power plants feeding it, weighted by local water stress.
Calibrated against real measurements
The engine replays published figures on every build, if a coefficient drifts a result outside its measured band, the build fails. These are the anchors it reproduces:
What we deliberately don’t do
- • We don’t use the debunked “500 mL bottle of water per query” figure, which was a per-conversation, GPT-3-era estimate off by ~1,000×.
- • We report consumption water (evaporated), not withdrawal, and split cooling from grid water.
- • We headline location-based carbon (what physically flowed through the grid) and show market-based separately.
- • Closed models publish no specs, so those figures are inferred from open models and flagged estimated. Read the range.
Primary sources
- • Oviedo et al., “Energy Use of AI Inference,” Joule (2026), the token-throughput energy model.
- • Google, “Measuring the environmental impact of AI inference” (2025), the only provider per-prompt disclosure.
- • ML.ENERGY Leaderboard v3.0 (2026), measured per-task energy across open models.
- • Li / Ren et al., “Making AI Less Thirsty”, the two-term water model.
- • EPA eGRID & Ember, grid carbon intensity; WRI Aqueduct, regional water stress.
Coefficients carry a source and date and are refreshed as new measurements are published.