Direct answer: AI electricity use ranges from small on-device tasks to large data-center workloads. A single request cannot be assigned one universal number because models, tokens, images, hardware, batching, utilization, and facility overhead differ. At system scale, data centers are a meaningful and growing electricity load, but public totals usually combine AI with other computing.
Define what you are trying to count
A model training run, an individual inference, a user session, a deployed product, and the entire AI sector are different measurement objects. Decide whether the estimate includes accelerators only, complete servers, networking, storage, cooling, power conversion, model development experiments, failed runs, and user devices.
State the time period and functional unit, such as kilowatt-hours per thousand completed classifications or per resolved customer case. Requests are weak units because one may contain ten tokens and another millions of tokens plus generated video. A clear boundary prevents precise-looking figures from describing different systems.
Training is visible, but inference accumulates
Training a large model can require substantial computation concentrated into a development period, along with experiments and evaluations that may not appear in a published final-run figure. Once deployed, inference happens whenever users or automated systems request output. A popular model’s repeated inference can become a major share of lifetime energy.
Do not allocate training energy to one prompt without assumptions about lifetime usage. The answer changes drastically with adoption and retirement date. Report development and serving separately, then combine them for an explicitly defined product period when that supports a real decision.
Hardware power is not workload electricity
A chip’s rated maximum power is not the energy consumed by a job. Energy equals power over time, and actual power changes with utilization, memory movement, precision, software, and idle periods. Several accelerators may share requests through batching, while reserved capacity can sit underused between them.
Measure at the narrowest reliable meter and reconcile with server or facility totals. Include CPU, memory, networking, and storage when material. If only rated power and run time are available, label the result as a rough upper-bound style assumption rather than an observed measurement.
Facility overhead changes the total
Data centers consume electricity beyond computing equipment for cooling, fans, pumps, power conversion, lighting, and other infrastructure. Power usage effectiveness, or PUE, compares total facility energy with information-technology equipment energy. Multiplying IT energy by an appropriate PUE can estimate included facility energy, but PUE varies by site, season, loading, and methodology.
PUE does not measure carbon emissions, water impact, hardware manufacture, or computational usefulness. A low PUE facility can still consume a large absolute amount of electricity. Use site-specific and time-relevant values where available rather than a favorable industry number copied from a different climate and operation.
Sector forecasts are scenarios, not model meters
The International Energy Agency and national laboratories analyze data-center electricity demand using available capacity, hardware shipments, utilization, and market projections. These estimates are valuable for grid planning, but uncertainty is substantial and published categories may combine traditional servers, cloud services, cryptocurrency, and AI differently.
Quote the year, geography, scenario, and definition whenever using a total. Do not divide a national forecast by a guessed number of prompts to manufacture individual energy precision. Capacity announcements can also differ from actual energized, utilized load, while efficiency improvements and demand growth can move in opposite directions.
Build a useful estimate and then reduce it
Record the model and version, input and output units, batch size, hardware, job duration, measured IT energy, facility factor, repetitions, and success rate. Present low, central, and high cases when inputs are uncertain. Divide by successful completed outcomes, not attempts, and retain the raw total so efficiency does not hide growth.
Reduce energy by choosing the smallest model that meets tested quality, avoiding unnecessary generation, limiting context and output, caching stable responses, batching, quantizing where appropriate, and turning off unused capacity. Re-measure after model or traffic changes. The best number is not a viral prompt estimate; it is a transparent workload measurement that informs an architectural or operating choice. Keep the calculation reproducible by saving meter intervals, traffic counts, software versions, and allocation logic. Separate idle capacity from active jobs instead of silently assigning it away. When a shared service prevents direct metering, disclose the proxy used, test how sensitive the answer is to utilization, and avoid presenting the midpoint as an observed fact.