AI training vs inference emissions
Training creates the model in a concentrated burst; inference serves it repeatedly. Which emits more depends mainly on lifetime use and electricity.
AI training emissions come from the concentrated computing used to create or substantially update a model. Inference emissions come from operating that model each time somebody requests an answer, prediction or image. Training can be a very large one-off job; inference is smaller per task but repeats throughout the model’s deployed life.
Neither is always the larger share. A popular model serving enormous traffic can accumulate more inference emissions than training. A costly model that is barely used may remain dominated by training. The result also depends on hardware efficiency, task length, data-centre overhead and the carbon intensity of electricity. Any universal claim such as “training is 90% of AI emissions” should be treated cautiously unless its model, time period and accounting boundary are attached.
What happens during training
Training feeds data through a model, compares its outputs with a learning objective and updates parameters. That cycle is repeated across many batches on clusters of accelerators. Large runs also use high-speed networking, storage and cooling.
The final training run is not necessarily the full development footprint. Teams test architectures, tune settings, prepare data and sometimes abandon runs. Fine-tuning and later model updates add more computation. Public reporting may include only the successful run, a wider research programme or nothing model-specific at all.
Carbon then depends on where and when this work occurs. A training run measured in megawatt-hours cannot be converted to emissions without an electricity-supply assumption.
What happens during inference
Inference uses the trained parameters without updating them. For a language model, the service processes the prompt and predicts output tokens one by one. Longer context and output generally require more work. Reasoning, search and agent features can trigger hidden tokens or several calls.
Serving also has operational complications. Hardware may wait for traffic, requests may be batched, and models may be split across accelerators. A heavily utilised server can spread fixed overhead across more responses than a lightly used one. Cooling, networking and power conversion add facility demand.
Luccioni, Jernite and Strubell’s inference comparison found substantial variation across tasks and model types, reinforcing that “one inference” is not a standard energy unit.
Lifetime use decides the balance
Imagine training as an upfront balance and inference as a meter that rises with every use. The point at which inference overtakes training depends on the initial training footprint divided by operational energy per request. Both numbers are uncertain, and lifetime request volume is unknowable at launch.
This makes per-message training allocation fragile. Divide by predicted lifetime traffic and the allocated footprint changes when adoption differs from the forecast or the model retires early. It can be useful for scenario analysis, but it should not be described as electricity consumed when a particular user pressed send.
Our guide to how much CO2 AI produces keeps this allocated life-cycle view separate from an operational response estimate.
Distillation trains a smaller model to reproduce useful behaviour from a larger one. That adds development computation but may reduce energy across many future inferences. Quantisation or pruning can also require preparation while lowering serving costs. Whether the trade pays back depends on scale.
Conversely, training a highly capable general model may avoid training many narrow ones, but serving it for simple tasks can be wasteful. Routing common requests to a smaller model and reserving the large system for difficult work can reduce continuing demand.
Do small AI models use less energy? examines why the answer is generally yes per comparable task, while capability and retries still belong in the total.
Carbon accounting changes both sides
Two equal-energy training runs can have different emissions on different grids. Inference can be geographically distributed, so its carbon intensity may vary across regions and hours. Renewable-energy contracts may change market-based company reporting without changing the physical grid mix at every moment.
Embodied emissions complicate the split further. Should manufacturing a training cluster be assigned to training, even if the hardware later serves inference? How should a shared data-centre building be allocated across AI and conventional workloads? There is no context-free answer.
The AI carbon footprint is therefore wider than training plus inference electricity. Chips, buildings and supply chains must appear somewhere in a full life-cycle assessment.
Why system forecasts rarely separate them cleanly
Grid planners see facility demand. A data centre may train one model while serving several others and running non-AI cloud workloads. Public capacity announcements do not always reveal utilisation or workload mix.
The International Energy Agency estimates that global data centres used about 415 TWh in 2024 and projects around 945 TWh in 2030 in its base case. It identifies accelerated servers, mainly driven by AI, as a major source of growth. Those figures contain training, inference and non-AI services rather than a clean split.
That combined view is suitable for electricity planning. It cannot tell a user how much of one answer belongs to a past training run.
Which emissions should you focus on?
Model developers should disclose training energy, location, hardware and development scope; improve training efficiency; and avoid unnecessary duplicate runs. Service operators should track inference, use appropriately sized models, increase utilisation, reduce needless tokens and obtain lower-carbon electricity. Hardware and construction emissions need their own reduction plans.
Users have more influence over inference: choosing a suitable model, limiting unneeded output and avoiding repeated generations. They cannot retroactively change the training run, but demand can influence which systems providers deploy.
Treechat’s per-answer receipt estimates operational inference rather than allocating historical training or embodied emissions. It uses model and token counts with published data-centre and grid assumptions. That narrower boundary is explicit on our methodology page.
Training versus inference is not a contest with one permanent winner. Report the concentrated upfront phase, the accumulating operational phase and the wider life cycle separately. Then decisions can target the emissions they can actually change.