iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
There is no single energy or water figure that applies to every AI query. To estimate one responsibly, define the service and workload, choose a measurement method, and state what the calculation includes. Use a provider’s dated production measurement when it matches your question; otherwise, build a transparent estimate from token demand, serving throughput, hardware, utilization and facility assumptions.
What does an AI query’s footprint depend on?
A query is not a fixed unit of work. Its energy demand can change with the model, prompt length, generated response length, and whether the service uses extended reasoning or tools. Image, audio and video generation also should not be treated as equivalent to a short text exchange.
The accounting boundary matters, too. An active-accelerator estimate counts power used by GPUs or other AI chips while they are working. A broader estimate may also allocate energy for host CPUs and memory, idle or reserved machines, and data-center operations. A figure that leaves out those costs is not directly comparable with one that includes them.
Water needs its own boundary. A direct cooling-water estimate is different from one that also counts water associated with generating electricity. State which is included rather than combining unlike measures.
A practical method for estimating energy and water
- Describe the workload. Record the AI service and model if known, the date or period, approximate input and output size, and whether the query involves tools, multimodal generation or extended reasoning. If those details are unknown, say so.
- Choose the best available evidence. Prefer a provider’s dated production measurement if it describes a comparable workload and explains its boundary. If none is available, use a published benchmark or a bottom-up model, and identify the result as an estimate rather than a measurement of your particular query.
- Set the energy boundary. Specify whether the figure includes only active accelerator power or also host systems, idle capacity and data-center overhead. Power Usage Effectiveness (PUE) describes facility energy relative to IT energy, but PUE alone does not make two estimates comparable when their other assumptions differ.
- Estimate water separately. For direct data-center water, name the water-use effectiveness (WUE) factor or equivalent, plus the geography and period it represents. If you include indirect water from electricity generation, explain that addition and its location-specific assumptions.
- Report the result with its limits. Give units, workload, model, date, method, boundary, relevant geographic or fleet factors, and an uncertainty range where available. Avoid presenting a modeled estimate as a measured value for every user’s query.
Use published figures as examples, not universal answers
Google reported that the median Gemini Apps text prompt, based on May 2025 data, used 0.24 Wh of energy, emitted 0.03 gCO2e and consumed 0.26 mL of water under its comprehensive methodology. The company says the figures are point-in-time results that do not represent every prompt or future performance; it also says the claims were not verified by an independent third party. The water figure applies Google’s 2024 fleet-average WUE, while the emissions figure applies its 2024 fleet-average grid carbon intensity. See Google’s announcement and the technical paper.
The same Google analysis gives a narrower active-TPU-and-GPU-only result for the median text prompt: 0.10 Wh, 0.02 gCO2e and 0.12 mL. The comprehensive estimate adds production utilization, machines kept idle for reliability, CPU and RAM, and data-center overhead. The difference illustrates why a headline number is meaningful only alongside its boundary; the announcement and paper report the same underlying analysis, not independent replications.
Other published estimates use different workloads and methods. Microsoft Research’s September 2025 bottom-up analysis estimates a median of 0.34 Wh per query, with an interquartile range of 0.18–0.67 Wh, for frontier-scale models larger than 200 billion parameters on an H100 node under its stated workload, GPU-utilization and PUE assumptions. Its modeled test-time-scaling case, using 15 times more tokens, has a median of 4.32 Wh. These are model-based results, not metering across all consumer queries. Details are in Microsoft Research’s paper.
Free tools Windows power users keep installed
One-click scans. No signup required.
An infrastructure-aware benchmark by Jegham and colleagues estimated about 0.42 Wh (±0.13 Wh) for a short GPT-4o query. It also found that some long prompts on o3 and DeepSeek-R1 exceeded 33 Wh under its long-prompt setup. These estimates differ from Google’s and Microsoft’s because the models, workloads, methods and accounting boundaries differ; they should not be averaged into a supposed standard per-query value. Read the benchmark paper for its setup and comparisons.
A simple bottom-up model—and what it cannot tell you
A useful conceptual relationship is:
Query energy ≈ workload tokens ÷ effective serving throughput × allocated serving power
In practice, the estimate also depends on utilization and the chosen facility boundary. Throughput, power allocation and utilization must describe the relevant model and serving setup; public sources do not disclose all provider-specific inputs needed to calculate an arbitrary live query precisely. The expression is therefore a framework for transparent assumptions, not a universal calculator with known values for every service.
Once energy is estimated, direct cooling water can be estimated using a suitable WUE factor, provided the factor matches the facility or fleet and time period in question. This does not automatically account for water used to generate electricity or other lifecycle stages. Google’s prompt estimate, for example, uses its own 2024 fleet-average WUE; it is not a factor that can safely be applied to other providers without evidence.
Why a local electricity meter cannot measure a remote query
A plug-in meter or device power reading captures electricity used by the local computer and network equipment. It cannot isolate the share of remote server energy assigned to a specific query. That allocation depends on provider-side hardware, real utilization, idle capacity, host systems and facility overhead. Without operational data from the service or a stated model of those inputs, a consumer-side reading is not a measurement of the query’s data-center footprint.
Quick Recap
Best Value
- Used Book in Good Condition
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.
