AI Training Carbon Footprint Calculator

What this calculator measures

Training a modern AI model can use a surprising amount of electricity, but the environmental impact is rarely obvious from a cloud bill or a line in a training log. Teams often know how many GPUs they used and how long a run lasted, yet they do not immediately see what that means in kilowatt-hours, carbon emissions, or direct power cost. This calculator turns those pieces into one estimate. It is meant for planning, comparison, and communication: you can use it before a run to set expectations, after a run to document impact, or between runs to compare a faster model, a cleaner grid, or a more efficient hardware choice.

The core idea is simple. A training job consumes electrical energy. The local grid supplies that energy with some carbon intensity, usually measured in kilograms of CO₂ per kilowatt-hour. Once you know the energy used and the emissions factor of the electricity, you can estimate the training run’s carbon footprint. If you also know your electricity price, you can estimate the portion of cost that comes from energy itself. None of that replaces a formal sustainability accounting process, but it does make the tradeoff much easier to see while you are still deciding how and where to train.

How the inputs map to a real training run

GPU Hours is the total amount of GPU time consumed across all GPUs, not just the wall-clock duration of one machine. If you trained for 20 hours on 16 GPUs, that is 320 GPU hours. If you used multiple nodes, add up all GPUs across all nodes first, then multiply by the wall-clock time. This is the number people most often undercount, because it is natural to remember “the run took 20 hours” and forget that 20 hours on many GPUs is a much larger energy footprint than 20 hours on one card.

Power per GPU (kW) should represent the average electrical draw of one GPU during the run, expressed in kilowatts. If your monitoring shows about 700 watts on average, enter 0.7 kW. If you only know the device TDP, treat it as an upper bound and consider using a lower average if utilization was not pinned at full load. The calculator keeps this field at the per-GPU level so it works cleanly with total GPU hours. In effect, you are saying: “each GPU-hour consumed this many kilowatts for one hour.”

Carbon Intensity (kg CO₂/kWh) is the emissions factor of the electricity source. Cleaner grids have lower numbers; fossil-heavy grids have higher ones. This is the field that captures the value of location and timing. The same model trained with the same hardware can have meaningfully different emissions if one run happens in a region with hydro, nuclear, wind, or solar support and another happens where coal or gas sets more of the marginal power mix. If you can choose between regions or delay a flexible job to a lower-carbon time window, this input is often where the benefit appears.

Electricity Cost per kWh is optional in the sense that the calculator will still estimate emissions if you leave it at zero or use the default. It is included because carbon and cost are often discussed together. Energy price is not the same as total cloud cost, but it is still useful. A run can look inexpensive in total spend when the model is small, yet still be carbon-heavy if it happens on a dirty grid. Conversely, a cleaner region may or may not be the cheapest region. Seeing both numbers together helps you understand whether the greener choice is also the lower-energy-cost choice.

Formula behind the estimate

The calculator first converts your training run into energy use. Energy is the product of total GPU hours and average power per GPU. Because the power input is already in kilowatts, the result is directly in kilowatt-hours:

Here, E is energy in kWh, H is total GPU hours, and P is the average power draw of one GPU in kW. Once energy is known, emissions follow by multiplying energy by carbon intensity:

The emissions result from that formula is in kilograms of CO₂. The script on this page then displays the result in metric tons by dividing by 1,000, because larger projects are easier to compare in tons than in kilograms. Electricity cost is computed from the same energy estimate:

In that expression, R is the electricity rate per kWh. The page also shows a rough “flights” equivalence for intuition. Treat that final comparison as illustrative only. It is useful for storytelling, but it is much less precise than the direct estimate built from energy and carbon intensity.

The calculator's result R can be represented as a function of the inputs x₁ … x_n:

That more general notation is useful when you compare several design choices at once. You might change training time, the number of GPUs, average utilization, checkpointing strategy, batch size, or region. The calculator itself only needs four direct inputs, but those four values summarize many operational decisions. In practice, the tool is helping you compress the complicated story of a training run into a small set of measurable drivers.

A very common special case is a “total” that sums contributions from multiple components, sometimes after scaling each component by a factor:

That is relevant when a run includes several hardware classes or phases. For example, you might pretrain on one group of GPUs, fine-tune on another, and perform a long evaluation pass later. In that case, each stage can be thought of as a separate contribution with its own weight or conversion factor, and the full footprint is the sum of the parts. This calculator focuses on the single-average case, but the same logic extends to multi-stage workflows.

Worked example

Suppose you train on 8 GPUs for 40 hours. That equals 320 GPU hours. If each GPU averages 0.7 kW, the total energy use is 320 × 0.7 = 224 kWh. Now assume the electricity carbon intensity is 0.40 kg CO₂/kWh. Emissions are 224 × 0.40 = 89.6 kg CO₂, which the calculator reports as about 0.090 metric tons CO₂. If the electricity rate is $0.12/kWh, the energy cost is 224 × 0.12 = $26.88.

This example is useful because it shows which levers matter most. If you keep the training job exactly the same but move it to a cleaner grid, only the carbon-intensity term changes. If you keep the grid the same but shorten the run, then GPU hours drop and both emissions and cost fall together. If you use a more power-hungry GPU but it reduces training time enough, the total energy could still go down. The calculator does not tell you which engineering choice is best in the abstract; it gives you a consistent way to evaluate each scenario with numbers instead of intuition alone.

Scenario comparison: same run, different grid carbon intensity

The table below keeps the training job fixed at 320 GPU hours and 0.7 kW per GPU. Only the grid carbon intensity changes. Notice that electricity cost stays the same, because the energy use stays the same, while emissions move a great deal. That is why the carbon-intensity input is so important when teams are choosing a region or scheduling flexible training jobs.

For many teams, this is the first useful sanity check. If you change only one input, does the result move the way you expect? In proportional models like this one, doubling GPU hours doubles energy, cost, and emissions. Doubling average power also doubles energy, cost, and emissions. Doubling carbon intensity affects emissions only, not electricity use. When the response matches that intuition, you can be more confident that the units and assumptions are lined up correctly.

How to use the result in practice

The most helpful way to read the result is not as a moral verdict but as a planning number. If one experiment produces 0.03 metric tons and another produces 0.30 metric tons, the gap tells you something real about scale. That might affect how often you retrain, whether you run an ablation at full size, or whether it is worth reserving time in a cleaner region. If you are comparing two model architectures, the calculator can help you decide whether a modest quality improvement is worth a much larger energy footprint. If you are talking with a manager or customer, the estimate gives you a plain-language number that is easier to communicate than raw GPU logs.

It is also worth checking the result against your cloud bill and monitoring data. If the calculator says a run used very little energy but your observed infrastructure cost was high, that does not necessarily mean the estimate is wrong. It may mean the run included CPU-heavy preprocessing, storage overhead, networking, idle reservation time, or a large premium above raw electricity price. This tool focuses on the GPU training portion and the direct energy logic. It is best for comparing training scenarios on a like-for-like basis rather than reproducing every detail of a provider invoice.

Ways to lower the number without guessing

There are four straightforward levers behind the estimate. First, reduce GPU hours by shortening training time, using smaller experiments before scaling up, or stopping weak runs early. Second, reduce average power draw by improving utilization, choosing more efficient hardware, or avoiding long idle periods with reserved accelerators. Third, reduce carbon intensity by picking a cleaner region or shifting flexible jobs to lower-carbon hours. Fourth, if you care about spending as well as emissions, compare electricity cost separately from total cloud price so you can see whether an operational change helps both.

One subtle but important point is that “bigger GPU” does not automatically mean “higher footprint.” A more powerful GPU can finish the same job sooner. What matters to this calculator is total energy, which is power multiplied by time. A 1.0 kW GPU that finishes in half the time may use less energy than a 0.6 kW GPU that runs for much longer. That is why scenario testing is so valuable. Enter one configuration, write down the result, then change only one assumption at a time. The difference between runs usually teaches more than the absolute number alone.

Assumptions and limits

This estimate is intentionally lightweight. It does not explicitly model cooling overhead, power distribution losses, networking, CPU work, storage, or embodied hardware emissions. If you know a data center’s PUE, you can approximate overhead by inflating the power figure or the resulting energy before applying carbon intensity. The page’s current formula also assumes average power is reasonably stable across the run. That is often good enough for comparison, but bursty or highly variable workloads may differ from the average more than you expect.

Another limitation is that carbon intensity is treated as one number for the whole run. Real grids vary by hour, and some providers use market instruments or accounting methods that complicate the picture. For precise reporting, you would want better temporal and geographic data, plus a documented methodology. For day-to-day engineering decisions, though, a transparent estimate based on average values is often exactly what you need. It helps you ask better questions early, before choices become expensive or hard to reverse.

Use this calculator as a decision aid, not as a replacement for formal sustainability reporting. Its strength is clarity. You can see the variables, understand the units, and explain the result to someone else without hiding the math. That makes it useful for research teams, ML engineers, product managers, students, and anyone who wants a fast sense of what a training run costs the grid as well as the budget.