The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →There is no single energy or water figure that applies to every AI query. A useful estimate must identify the service and workload, the measurement method, and what the accounting includes. For a dated real-world example, Google reports that a median Gemini Apps text prompt using May 2025 data required 0.24 Wh of energy and 0.26 mL of water under its comprehensive methodology. That is a company-reported result for a particular service and workload—not a universal value for an AI prompt.
What an estimate needs to specify
“One AI query” is not a consistent unit of work. A short text exchange, a long response, extended reasoning, and an image or audio request can require different amounts of computation. Before estimating, define the workload and the system boundary rather than attaching a number to the word “query.”
As an Amazon Associate I earn from qualifying purchases.
- Service and model: Name them when known; model choice affects serving demand.
- Workload: Record prompt and response size, and note whether the query uses tools, generates images or audio, or involves extended reasoning.
- Date or period: Model serving systems and their efficiency change over time.
- Energy boundary: Specify whether the estimate covers active accelerators only or also host CPU and memory, idle or reserved capacity, and data-center overhead.
- Water boundary: Say whether it covers direct data-center water consumption alone or also indirect water associated with electricity generation.
Without these details, two figures may look comparable while measuring different workloads or different parts of the system.
Choose a measurement route
Use a provider’s production measurement when it matches
A provider measurement can reflect real serving conditions, including utilization and infrastructure that a chip-only estimate omits. Google’s 2025 report is a useful example because it identifies the workload period and explains its accounting boundary. Google says the result is not representative of every prompt or future performance, and its announcement states that the figures were not independently verified. Treat the numbers as Google’s measurements, not as an industry-wide standard. See Google’s announcement and the accompanying technical paper.
Use a transparent model if provider data is unavailable
A bottom-up estimate can relate workload to serving capacity:
Estimated query energy ≈ workload tokens ÷ effective serving throughput × allocated serving power
This is a conceptual accounting relationship, not a plug-in formula with public values for every AI service. To apply it, an analyst needs assumptions or measurements for token demand, throughput, serving hardware, allocated power, utilization, and the chosen facility boundary. Public information usually does not disclose every provider-specific input needed to calculate an arbitrary live query precisely.
Benchmarks and modeled estimates can still help compare workloads under stated assumptions. Microsoft Research’s September 2025 analysis models frontier-scale inference using H100-node assumptions; Jegham and coauthors’ May 2025 benchmark estimates energy for specified model and prompt setups. Neither should be mistaken for direct metering of every query on a proprietary service.
Set the energy boundary before comparing figures
An active-accelerator-only number is narrower than a full-stack operational estimate. A fuller account may include host CPU and memory, machines kept idle or reserved for reliability, and facility overhead. Google’s figures illustrate how much the boundary matters: for the median Gemini text prompt, its narrower active-TPU-and-GPU calculation was 0.10 Wh, while its comprehensive estimate was 0.24 Wh. The latter includes actual production utilization, idle machines held for reliability, CPU and RAM, and data-center overhead.
Power Usage Effectiveness (PUE) describes facility energy relative to IT energy and can be part of a facility-overhead calculation. It does not, by itself, make two estimates comparable: workload, utilization, hardware, and treatment of idle capacity may still differ. State which components are included rather than relying on a label such as “full stack” without an explanation.
Estimate water separately
Per-query water estimates are commonly derived from energy use and a water-use factor; they are not necessarily direct readings of water used for an individual prompt. Google derived its Gemini prompt estimate using energy per prompt and its 2024 fleet-average water usage effectiveness (WUE). That factor belongs to Google’s fleet and period, so it should not be transferred to another provider or location without evidence.
Recommended Free Tools
When estimating direct cooling water, identify the WUE or equivalent water-per-energy factor and the geography and time period it represents. If the estimate includes water associated with electricity generation, disclose that indirect component and its location-specific assumptions. Do not combine direct and indirect water values without making the boundary clear.
Best Value
- Used Book in Good Condition
Published figures—and why they differ
The figures below describe distinct workloads and methods. They are examples, not interchangeable measurements of a standard query.
| Source and workload | Reported energy | Water and other reported impact | What the figure represents |
|---|---|---|---|
| Google, median Gemini Apps text prompt; May 2025 data | 0.24 Wh | 0.26 mL water; 0.03 gCO2e | Comprehensive company methodology; water uses Google’s 2024 fleet-average WUE and emissions use its 2024 fleet-average grid carbon intensity. Google says the result is not representative of every prompt or future performance, and its announcement says it has not been independently verified. Google announcement; technical paper. |
| Google, median Gemini text prompt; May 2025 data | 0.10 Wh | 0.12 mL water; 0.02 gCO2e | Narrower active TPU/GPU-only boundary, not the comprehensive estimate. Google technical paper. |
| Microsoft Research, frontier-scale models larger than 200 billion parameters on an H100 node | 0.34 Wh median; interquartile range 0.18–0.67 Wh | Not stated in this energy estimate | September 2025 bottom-up estimate under stated realistic workload, GPU-utilization, and PUE assumptions; not a measured average across consumer queries. Microsoft Research paper. |
| Microsoft Research, modeled test-time-scaling case with 15 times more tokens | 4.32 Wh median, reported as 13 times the baseline median for this scenario | Not stated in this energy estimate | A modeled scenario, not a typical-query measurement. Microsoft Research paper. |
| Jegham et al., short GPT-4o query | About 0.42 Wh (±0.13 Wh) | Not stated here | Infrastructure-aware benchmark estimate with its own workload and assumptions; not directly comparable to Google’s production prompt result. Benchmark paper. |
| Jegham et al., some long prompts on o3 and DeepSeek-R1 | More than 33 Wh | Not stated here | Benchmark results for some long prompts; the paper also reports a greater-than-70-fold difference between these high long-prompt values and GPT-4.1 nano under its long-prompt setup. Benchmark paper. |
Google also reports that its median prompt energy was 33 times lower and its median prompt carbon footprint 44 times lower in May 2025 than in May 2024. These are Google’s own comparisons and attribution for that period, not independent industry-wide findings.
The Microsoft and Jegham estimates do not contradict Google’s number simply because their values differ: their models, workloads, and accounting methods are not identical. The long-prompt benchmark results also show why a short text prompt is a poor stand-in for reasoning-heavy work.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A practical reporting checklist
- Describe the workload: Give the service and model if known, date or period, prompt and response size, and any tool use, multimodal generation, or extended reasoning.
- Identify the method: Say whether the number comes from provider production data, a bottom-up model, or a benchmark, and link to the source.
- Name the energy boundary: State whether it includes active accelerators only or also host systems, idle capacity, and facility overhead.
- Explain the water factor: Identify the WUE or equivalent factor, its geography and time period, and whether the result is direct data-center water or includes indirect electricity-related water.
- Give units and uncertainty: Report energy in Wh, water in mL or another stated unit, and any range supplied by the method. Keep the workload and boundary attached to each value.
- Limit comparisons to like with like: Check workload, system boundary, production measurement versus modeled benchmark, utilization and PUE, and direct versus indirect water before comparing values.
Why a home electricity meter cannot measure a remote query
A plug-in meter or device battery reading measures local electricity use; it cannot isolate the share of remote server energy allocated to one query. That server-side estimate depends on hardware, real utilization, idle capacity, host systems, and facility overhead. Provider operational data or a transparent infrastructure model is needed to estimate that portion.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
