ML CO2 Impact Calculator
The ML CO2 Impact Calculator is the tool that put a number on a question the machine-learning community had been avoiding: how much carbon does training a model emit? Published alongside a NeurIPS 2019 workshop paper by Alexandre Lacoste, Alexandra (Sasha) Luccioni, Victor Schmidt, and Thomas Dandres, it does something deliberately simple — it takes four inputs a researcher already knows (the hardware, the number of compute-hours, the cloud provider, and the region) and returns an estimate in kilograms of CO₂-equivalent, together with a ready-made LaTeX snippet to paste into a paper. That simplicity is why it became the default citation for ML carbon footprints, appearing in thousands of papers and most corporate AI-sustainability statements.
This page is the practitioner’s full reference for that tool — what it actually computes, what it leaves out, and how to turn its estimate into a figure that survives a corporate audit. It explains the four-input model and the grid-intensity dataset behind it, the assumptions that make it an estimator rather than a meter (most importantly, that it assumes every GPU runs at full power for the entire run), what it deliberately excludes (embodied hardware, inference, data movement, and — by default — the data centre’s own overhead), where it sits among the runtime measurement tools that have since overtaken it (CodeCarbon, CarbonTracker, Green Algorithms), and how an ML carbon figure maps onto Scope 2, Scope 3, and the Green Software Foundation’s Software Carbon Intensity specification. Built for ML researchers citing their footprint, MLOps and platform teams accounting for compute, and sustainability and disclosure teams folding AI workloads into CSRD, IFRS S2, and data-centre energy reporting.
The ML CO2 Impact Calculator (Lacoste et al., 2019; mlco2.github.io/impact) is an open-source, web-based estimator of the carbon emissions of training a machine-learning model. It multiplies the hardware’s thermal design power by the number of compute-hours to get energy, then multiplies by the grid carbon intensity of the selected cloud-provider region to get kilograms of CO₂-equivalent, and reports both a raw figure and an offset-adjusted figure. It is an a-priori estimator using four user inputs, not a runtime measurement tool — it assumes 100% hardware utilisation across all GPUs, covers operational training electricity only (no embodied hardware, no inference, no networking or storage), and by default does not apply the data centre’s power usage effectiveness (PUE), which the user must add manually. Its grid dataset is static and the project is passively maintained. For a corporate inventory, its output is a Scope 2 (own compute) or Scope 3 (cloud, or use of sold AI products) input that must be documented with its assumptions, its vintage, and a utilisation correction to be audit-grade.
Executive Summary
Before 2019, a researcher who wanted to report the carbon footprint of a training run had no convenient way to do it. The ML CO2 Impact Calculator closed that gap with a tool simple enough that there was no excuse not to use it: pick your GPU, enter your hours, pick your cloud region, and copy the resulting kilograms of CO₂e — and the accompanying LaTeX template — straight into your paper. That low friction, paired with an academic citation (Lacoste et al., arXiv:1910.09700), is why the calculator became the community standard for reporting ML emissions and why its figures propagate into corporate AI-sustainability disclosures today.
For a practitioner, the calculator is best understood as an honest first-order estimate with three properties that govern how it should be used. First, it is an estimator, not a meter: it works from four user inputs and a published power and grid dataset, not from runtime measurement of what the hardware actually drew. Second, it is scoped to operational training electricity — it does not count the carbon embodied in manufacturing the GPUs, the energy of running the model in production (inference), the data centre’s cooling and overhead (unless you add PUE yourself), or data movement and storage. Third, it is frozen in time: the project is passively maintained, its grid-intensity figures are static, and a figure produced today inherits a dataset that may be years old. None of this makes the tool wrong — it makes it a clearly bounded estimate that a careful user states the bounds of.
(1) The calculator estimates training emissions from four inputs — it does not measure them; runtime tools like CodeCarbon do. (2) It assumes 100% utilisation across all GPUs, which tends to over-estimate; real usage factors are far lower. (3) It covers operational training only — no embodied hardware, no inference, no data movement, and no PUE by default (you multiply by PUE yourself). (4) Its grid data is static and the project is passively maintained, so every figure must be cited with its assumptions and its vintage to be defensible.
Provider directory
Now it has to hold up all year.
See who does this work. Every listing names the standards it works to, and paid placements are labelled. Including The Carbon Trust and KERAMIDA.
Browse 6 carbon accounting & inventory providers →Do this work? A listing is US$390 a year. Get listed →
Where the Calculator Sits in the Carbon-Accounting Stack
The calculator is a Layer 3 factor-application tool: it does not define the accounting methodology and it is not the disclosure regime, but it is where a compute workload becomes a carbon number that the layers above consume. Seeing the chain is what tells a practitioner what the figure means — and what an auditor will ask about it.
| Layer | Source | What it produces | Example |
|---|---|---|---|
| 1. Physical inputs | Hardware power specifications + grid carbon-intensity data | The factors the estimate is built from | GPU thermal design power (W); regional grid intensity (kgCO₂e/kWh) |
| 2. Estimation tool | ML CO2 Impact Calculator (or CodeCarbon, Green Algorithms, etc.) | A per-run emissions estimate in kgCO₂e, raw and offset-adjusted | “This training run emitted X kgCO₂e” |
| 3. Software / system metric | Green Software Foundation SCI specification | A carbon-per-functional-unit rate, with operational and embodied terms | SCI = (E·I + M) per unit of work R |
| 4. Corporate / disclosure application | The reporting entity’s inventory or disclosure | The run’s emissions allocated to a scope and reported | Cloud compute in Scope 3 Cat 1; own data centre in Scope 2 |
Two consequences follow. First, a calculator figure is a Layer 2 estimate carrying that layer’s assumptions — it is not a meter reading, and a careful disclosure says so. Second, the jump from a per-run estimate (Layer 2) to a reported corporate figure (Layer 4) is an accounting decision, not an automatic step: you must choose the right scope, the right grid factor (location-based versus market-based), and whether to include the terms the calculator omits. That conversion uses the same electricity emission factor logic and the same GHG Protocol Scope 2 Guidance location-versus-market choice as any purchased-electricity figure. The calculator gives you the kilowatt-hours and a default grid factor; the reportable emissions are your accounting decision on top.
The calculator also has a sibling at this layer. Bitcoin mining and ML training are the two emerging compute loads that the energy world now tracks specifically — the Cambridge Bitcoin Electricity Consumption Index does for proof-of-work mining what this tool does for model training: turn a compute workload into an energy-and-carbon estimate with explicit, debatable assumptions.
What the ML CO2 Impact Calculator Is
The calculator is one of three connected artefacts produced by the same authors, and conflating them is a common citation error.
The calculator
A web tool at mlco2.github.io/impact. You select hardware, hours, a cloud provider, and a region; it returns a raw emissions figure and an offset-adjusted figure in kgCO₂e. This is the artefact in the strict sense.
The paper
“Quantifying the Carbon Emissions of Machine Learning” (Lacoste, Luccioni, Schmidt & Dandres), NeurIPS 2019 Climate Change AI workshop, arXiv:1910.09700. It sets out the metrics — server location, energy grid, training duration, hardware — and the mitigation actions, and is the work the BibTeX entry cites.
The LaTeX template
A generated snippet that drops the calculator’s output and the lacoste2019quantifying citation directly into a paper. This citation-mechanic feature is a large part of why the tool spread so widely through the literature.
The project is open source under the mlco2 GitHub organisation, with contributors associated with Mila (the Quebec AI institute) and the Climate Change AI community. Its public data — the hardware power list and the regional grid-intensity figures — lives in the repository and is open to pull requests. One status detail matters for any current use: the repository describes itself as passively maintained, meaning issues are addressed but there are no active updates to the data or code. The tool is a stable, citable reference point rather than a live, continuously-updated dataset, and that distinction shapes how its figures should be cited.
The BibTeX key is lacoste2019quantifying and the canonical reference is the arXiv paper, not the website URL alone. A disclosure or paper should cite the paper and note the calculator as the instrument — and, because the project is passively maintained, state the date the figure was generated so a reader knows which vintage of the grid dataset it reflects.
The Four Inputs and the Core Formula
The calculator’s entire model reduces to one chain: power × time × grid intensity. The four inputs feed exactly that.
| Input | What it sets | Role in the formula |
|---|---|---|
| Hardware | The GPU/accelerator model, mapped to a power draw (thermal design power, W) | The power term — how fast energy is consumed |
| Hours used | Cumulative compute-hours of the run | The time term — how long energy is consumed |
| Cloud provider | The provider (which sets available regions and any offset claim) | Determines the offset-adjusted figure |
| Region | The data-centre location, mapped to a grid carbon intensity | The intensity term — how dirty each kWh is |
The arithmetic is:
Energy (kWh) = power (kW) × hours
Emissions (kgCO₂e) = Energy (kWh) × grid carbon intensity (kgCO₂e/kWh)
The calculator returns two numbers from this: a raw emissions figure and an offset-adjusted figure. The offset figure is lower when the chosen cloud provider claims to directly offset some portion of the grid emissions for that region — the tool applies that claimed offset percentage. The single largest driver of the result is the region: the same run on the same hardware can differ by more than an order of magnitude between a coal-heavy grid and a hydro- or nuclear-heavy one, because the grid intensity term spans roughly that range.
The Methodology in Detail
Hardware power and the 100% utilisation assumption
The calculator maps each hardware model to a power figure (thermal design power) and assumes that power is drawn continuously for the whole run, across all the accelerators involved. This is the model’s most consequential simplification. In reality, a GPU rarely sits at its full rated power for an entire training job — memory transfers, data loading, synchronisation, and idle gaps mean the average usage factor is far below 100%. Peer-reviewed reviews of these tools have noted that the calculator effectively assumes 100% utilisation across every GPU, whereas measured average usage factors are often in the low double digits. The practical effect is a systematic tendency to over-estimate, sometimes substantially, relative to runtime tools that query actual power draw.
Grid carbon intensity by region
Each selectable region is mapped to a grid carbon-intensity value (kgCO₂e/kWh) drawn from the project’s embedded dataset. This is the term that makes location the dominant variable, and it is where the static-data limitation bites hardest: grids decarbonise year on year, so a fixed intensity figure drifts from reality as the underlying grid changes. The same logic that governs any electricity emission factor applies — the value is a snapshot of a moving target, and a stale snapshot understates the decarbonisation that has happened since.
Illustrative order-of-magnitude grid carbon intensities. Actual values vary by country, year, and time of day; these are rounded reference points to show why the region input dominates the result. A 17× spread between a coal-heavy and a hydro/nuclear grid means the same run can have wildly different reported emissions purely from where it ran. See the grid emission factors reference for current values.
Cloud-provider offsets
The offset-adjusted figure reflects a cloud provider’s claim to have directly offset a portion of the grid emissions for that region. This is a market-based adjustment — it depends on contractual offset or renewable claims, not on the physical grid the electrons came from. For corporate reporting this maps onto the market-based versus location-based distinction: the raw figure is the location-based view, the offset figure is a market-based view, and a complete disclosure reports both rather than quietly using the lower number.
What PUE is — and is not — doing here
A critical and frequently-missed detail: by default the calculator does not include the data centre’s power usage effectiveness (PUE). PUE is the multiplier that accounts for cooling, power distribution, and supporting infrastructure — a facility with a PUE of 1.5 uses 50% more energy than its IT load alone. The calculator’s authors state explicitly that the estimate excludes PUE and that the user must find their data centre’s PUE and multiply the result by it. A figure copied straight from the tool therefore understates facility energy unless the user has applied PUE manually. For what PUE means and how it is benchmarked, see the Uptime Institute PUE reference; for the facility standards that govern it, the ASHRAE 90.4 and EN 50600 / ISO-IEC 22237 data-centre references.
The calculator over-estimates through the 100%-utilisation assumption and under-estimates through the omitted-by-default PUE. These pull in opposite directions but they do not reliably cancel — their magnitudes are unrelated, and which dominates depends entirely on the real usage factor and the real PUE. Do not assume the two errors net out; correct each explicitly.
Worked Example
The arithmetic is deliberately transparent. The example below is illustrative — the numbers show the calculation chain and the citation discipline, not a current factor for any specific hardware or region.
| Step | Value | Source / note |
|---|---|---|
| Hardware power (1 GPU) | 0.300 kW | Illustrative TDP, 300 W |
| Compute-hours | 200 h | User input |
| Energy (raw) | 0.300 × 200 = 60 kWh | power × time |
| Grid intensity (region) | 0.30 kgCO₂e/kWh | Illustrative mixed grid |
| Raw emissions | 60 × 0.30 = 18 kgCO₂e | calculator’s raw output |
| Apply PUE (manual, e.g. 1.5) | 18 × 1.5 = 27 kgCO₂e | NOT in the default output — user adds |
| Apply real utilisation (e.g. 40%) | 27 × 0.40 = 10.8 kgCO₂e | correcting the 100% assumption (if known) |
The bare calculator output is 18 kgCO₂e. Adding PUE pushes it up to 27; correcting the 100%-utilisation assumption with a realistic usage factor pulls it back down. The default figure (18) is neither the highest nor the lowest plausible value — which is exactly why the assumptions must be stated alongside it.
For a corporate inventory, the same arithmetic runs through a Scope 2 electricity calculator once the kWh figure is fixed — the calculator supplies the activity data (energy) in place of a meter reading, and the rest is ordinary purchased-electricity accounting.
What the Calculator Deliberately Excludes
The calculator measures one slice of an ML system’s footprint: the electricity used by the accelerators during a training run. Several things practitioners look for are not in it, and using the tool as if it captured the whole footprint is the largest single error in ML carbon reporting.
| Excluded | Why it matters | Where it belongs |
|---|---|---|
| Embodied hardware carbon | Manufacturing GPUs, servers, and data-centre construction can rival operational emissions over a model’s life | Product/LCA accounting — ISO 14067; SCI’s M term |
| Inference | For a widely-deployed model, serving predictions can dwarf the one-off training cost over time | Operational accounting of production compute (Scope 2/3) |
| Data movement and storage | Dataset transfer, storage, and networking carry their own energy | Broader system boundary (e.g. cloud-footprint tools) |
| Idle and supporting compute | CPUs, memory, and idle GPU time during a job are not in the headline figure | Runtime tools that meter the full machine |
| PUE (by default) | Cooling and facility overhead — must be added manually | Multiply the output by the facility PUE |
The boundary the calculator draws — operational training electricity — is a legitimate and useful one, but it is a boundary, and a defensible figure names it. The most important exclusion for forward-looking reporting is inference: training is a one-time cost, while a deployed model emits every time it runs, and for popular models the lifetime inference footprint can exceed training many times over. A statement that reports only training carbon and calls it “the model’s footprint” is incomplete in a way that matters more every year as deployment scales.
Limitations and Known Biases
Five limitations govern how much weight a calculator figure can bear.
The model assumes every GPU runs at full rated power for the whole job. Real average usage factors are much lower (often well under 50%), so the raw figure tends to be high. Correct it with a measured or estimated usage factor where the stakes justify it.
The embedded grid-intensity dataset is a fixed snapshot. Grids decarbonise, so a figure produced today may apply a years-old intensity and overstate emissions in regions that have since cleaned up. Cross-check against a current grid factor source for material figures.
The project is passively maintained — no active data or code updates. New hardware and new regions may be missing, and the dataset will not track grid changes on its own. The tool is a stable reference, not a live service.
It uses average grid intensity (attributional accounting), not marginal/consequential intensity. For decisions about when or where to run a workload to reduce real-world emissions, a marginal signal is more actionable — a distinction the SCI specification makes explicit.
The output is a single number from a chain of assumptions with no uncertainty band. Treat it as an order-of-magnitude estimate; do not report it to a false precision that the underlying assumptions cannot support.
The Broader Tooling Ecosystem
The ML CO2 Impact Calculator was the first widely-used tool of its kind, and the field has since split into two families: a-priori estimators like this one, which compute a figure from a few inputs before or after a run, and runtime trackers, which instrument the code and measure actual power draw during execution. Knowing which family a tool belongs to is the key to interpreting its number.
| Tool | Type | How it gets energy | Notable trait |
|---|---|---|---|
| ML CO2 Impact Calculator | A-priori estimator (web) | Hardware TDP × hours, assumed 100% utilisation | Simplest to use; citation + LaTeX template; passively maintained |
| CodeCarbon | Runtime tracker (Python) | Queries actual GPU/CPU energy during execution | Per-component breakdown; widely used; tracks training and inference |
| CarbonTracker | Runtime tracker (Python) | Measures GPU/CPU consumption; can predict full-run cost early | Early-stopping prediction; GPU-runtime focused |
| Green Algorithms | A-priori estimator (web) | Hardware × time × usage factor, with PUE and component breakdown | Applies a usage factor and reports CPU/GPU/memory separately |
| Eco2AI / Experiment-Impact-Tracker | Runtime trackers (Python) | Query consumed energy, isolating the measured process | Process-level isolation; lower estimates than full-machine tools |
The practical guidance that falls out of this: use the ML CO2 Impact Calculator when you need a fast, citable estimate and you only know the high-level inputs (hardware, hours, region) — for example, to report a footprint in a paper after the fact. Use a runtime tracker like CodeCarbon when you control the training code and want a measured figure that reflects real utilisation and can also capture inference. The two are not competitors so much as different instruments for different moments: the calculator for an a-priori estimate, the tracker for a measurement. A corporate inventory that needs to be audit-grade should prefer measured data where it can get it, and reserve the calculator for cases where instrumentation was not possible.
From an Estimate to a Disclosure — SCI and the GHG Protocol
A calculator figure is a per-run estimate. Turning it into a disclosed metric requires a specification that defines the boundary and the functional unit — and that is what the Green Software Foundation’s Software Carbon Intensity (SCI) specification provides. SCI expresses software carbon as a rate per unit of work:
SCI = (E × I + M) per R
where E is energy consumed, I is the grid carbon intensity, M is the embodied emissions of the hardware, and R is the functional unit (per training run, per inference, per user). The ML CO2 Impact Calculator computes the E × I term for training and nothing else — it omits M entirely, and it does not divide by a functional unit. SCI also requires the grid intensity to be a physical grid value (short-run marginal, long-run marginal, or average), explicitly excluding market-based offsets from the core figure — which means the calculator’s offset-adjusted output is not SCI-conformant, and only its raw figure feeds an SCI calculation. SCI further leans toward a consequential (marginal) view of carbon to drive real reductions, in contrast to the calculator’s attributional (average-grid) approach.
For the GHG Protocol corporate frameworks, the allocation depends on whose compute it is:
| Compute context | Scope | Basis |
|---|---|---|
| Training in your own data centre | Scope 2 (purchased electricity) | Location-based and market-based per Scope 2 Guidance |
| Training on cloud (third-party) infrastructure | Scope 3 Category 1 (purchased services) | Supplier-specific or spend/usage-based, per the Scope 3 Standard |
| A model you sell or deploy for customers (inference) | Scope 3 Category 11 (use of sold products) | Lifetime inference energy — see the use-of-sold-products methodology |
| Embodied carbon of the AI hardware | Scope 3 Category 1/2 (purchased goods, capital goods) | Product LCA — ISO 14067 / SCI’s M term |
This is the step where the calculator’s narrow boundary becomes a reporting decision. A training estimate from the tool is a legitimate Scope 2 or Scope 3 Category 1 input — but a complete AI footprint also needs the inference (Category 11) and embodied (Category 1/2) terms the calculator does not provide. Citing only the training figure as the corporate AI footprint understates it.
Making an ML Carbon Figure Audit-Grade
An ML emissions figure becomes defensible when it carries its assumptions, its vintage, and its corrections. The discipline below turns a calculator output into something an assurance reviewer can sign off.
- State the tool, the version, and the date. “ML CO2 Impact Calculator (Lacoste et al., 2019), generated [date]” — the generation date matters because the grid dataset is static and ages.
- Declare the boundary. Say explicitly that the figure is operational training electricity only — excluding embodied hardware, inference, data movement, and (unless added) PUE.
- Apply PUE. Multiply the raw output by the data centre’s PUE; the default figure omits it. State the PUE used.
- Correct utilisation where material. The 100%-utilisation assumption over-estimates; apply a measured or estimated usage factor for material figures, and document it.
- Report both grid views. Give the raw (location-based) figure and, if claiming provider offsets, the market-based figure — never silently use the lower one.
- Allocate to the right scope. Own data centre → Scope 2; cloud → Scope 3 Cat 1; sold/deployed model → Scope 3 Cat 11; hardware → Scope 3 Cat 1/2.
- Cross-check the grid factor. Validate the embedded intensity against a current grid emission factors value; if the region has decarbonised, the static figure overstates.
Where a measured figure is achievable — that is, where you control the training code — a runtime tracker produces a more defensible number than the calculator, because it reflects real utilisation rather than the 100% assumption. Reserve the calculator for the case it was built for: a fast, citable a-priori estimate when measurement was not an option.
Compliance and Disclosure Implications
AI compute is moving from a reputational topic to a reported datapoint, and the regimes below are where an ML carbon figure now has to land.
| Framework | Where ML/AI compute appears | What it expects |
|---|---|---|
| CSRD / ESRS E1 | Energy and GHG datapoints for entities with material data-centre or AI compute; reasonable-assurance trajectory | Documented factor source, boundary, and vintage — a bare calculator number is not sufficient |
| IFRS S2 | Cross-industry GHG metrics; energy-intensity disclosure for affected sectors | Scope 2/3 figures with a defensible methodology behind the compute estimate |
| EU Energy Efficiency Directive — data-centre reporting | Mandatory energy and sustainability reporting for data centres above a size threshold | Facility-level energy, PUE, and increasingly carbon — the layer beneath an ML figure |
| Green Software Foundation SCI | A software-level carbon-intensity metric for AI products and services | E·I + M per functional unit — the calculator supplies only the E·I training term |
Across all of them, the assurance question is the same one that applies to any emission factor: which tool, which assumptions, which vintage, and which boundary? A disclosure that cites “we used the ML CO2 calculator” without the boundary (training-only), the PUE treatment, the utilisation assumption, and the generation date has the documentation gap a reasonable-assurance reviewer surfaces — the same gap that appears when any factor is cited without provenance under IFRS S2 or ESRS assurance. The data-centre energy reporting now coming into force in the EU sharpens this further, because it puts a regulated, audited facility-energy figure underneath the workload-level estimates the calculator produces.
Common Misinterpretations
Five recurring errors surface wherever calculator figures are reused.
Training is one slice. A complete footprint adds inference (often larger over a deployed model’s life), embodied hardware, and data movement. The calculator covers training electricity only.
It estimates them from four inputs and a static dataset. It does not measure actual power draw. For a measurement, use a runtime tracker (CodeCarbon, CarbonTracker).
The default output excludes data-centre overhead. Copying the raw number understates facility energy. Multiply by the PUE and state it.
Assuming every GPU runs flat-out for the whole job over-estimates. Real usage factors are far lower; correct where the figure is material.
The offset-adjusted number is a market-based claim, not the physical-grid figure. Report the raw (location-based) figure too, and never substitute the lower number silently.
Future Evolution
Three shifts are reshaping ML carbon accounting around the calculator. First, the centre of gravity is moving from training to inference: as models are deployed at scale, the recurring cost of serving them increasingly dominates the one-off cost of training, and the tooling and disclosure focus is following. A training-only estimator is, by construction, accounting for a shrinking share of the total. Second, embodied carbon is becoming tractable — newer work (for example, hardware-manufacturing models and LLM-specific lifecycle tools) is putting numbers on the M term that the calculator omits, moving the field toward the full SCI boundary. Third, real-time and marginal grid signals are maturing, enabling carbon-aware scheduling that shifts workloads to cleaner hours and regions — a consequential view the calculator’s static average-grid model cannot represent.
For the practitioner, the implication is that the calculator will remain a useful, citable first estimate for training, but that a complete and audit-grade AI footprint increasingly requires more than it provides: measured utilisation, embodied carbon, inference, and a current grid signal. The discipline of this page — state the boundary, apply PUE, correct utilisation, cite the vintage — is what keeps a calculator figure honest as the surrounding accounting expectations tighten.
Track the data-centre energy standards, grid factor releases, and disclosure frameworks that an ML carbon figure has to reconcile to, through the GreenCalculus changelog.
Frequently Asked Questions
It is an open-source web tool (mlco2.github.io/impact) that estimates the carbon emissions of training a machine-learning model, published with the 2019 paper “Quantifying the Carbon Emissions of Machine Learning” by Lacoste, Luccioni, Schmidt and Dandres. You enter four inputs — hardware, compute-hours, cloud provider, and region — and it returns an estimate in kilograms of CO₂-equivalent, plus a LaTeX template to cite the figure in a paper. It is an a-priori estimator, not a runtime measurement tool, and it covers operational training electricity only.
It multiplies the hardware’s power draw by the number of compute-hours to get energy in kilowatt-hours, then multiplies that energy by the grid carbon intensity of the selected region to get kilograms of CO₂e. It returns a raw figure and an offset-adjusted figure, the latter reflecting any direct offset the cloud provider claims for that region. The region is the dominant variable, because grid carbon intensity can vary by more than an order of magnitude between a coal-heavy grid and a hydro- or nuclear-heavy one.
No — by default it does not. The authors state explicitly that the estimate excludes power usage effectiveness (PUE) and that you must find your data centre’s PUE and multiply the result by it. PUE accounts for cooling, power distribution, and supporting infrastructure, so a figure copied straight from the tool understates facility energy until PUE is applied. A facility with a PUE of 1.5 uses 50% more energy than its IT load alone.
It has two opposing biases that do not reliably cancel. It over-estimates by assuming 100% hardware utilisation across all GPUs — real average usage factors are much lower, often well under half. It under-estimates by excluding PUE from the default output. Which bias dominates depends on the real usage factor and the real PUE, so the two should be corrected explicitly rather than assumed to net out. The raw output is best treated as an order-of-magnitude estimate.
It covers operational training electricity only. It excludes the embodied carbon of manufacturing the hardware, inference (running the model in production), data movement and storage, idle and supporting compute (CPU, memory), and — by default — the data centre’s PUE. For a deployed model, lifetime inference can exceed training many times over, so a training-only figure is an incomplete footprint that should be labelled as such.
The ML CO2 Impact Calculator is an a-priori estimator: it computes a figure from four user inputs and a static dataset, before or after a run. CodeCarbon and CarbonTracker are runtime trackers: they instrument your training code and measure the hardware’s actual power draw during execution, reflecting real utilisation and able to capture inference as well as training. Use the calculator for a fast, citable estimate when you only know the high-level inputs; use a runtime tracker when you control the code and want a measured figure.
It is passively maintained. The repository states that issues are addressed but there are no active updates to the data or code. In practice this means new hardware and regions may be missing, and the embedded grid-intensity dataset is a fixed snapshot that does not track grid decarbonisation over time. The tool is a stable, citable reference rather than a live service, which is why any figure should be cited with the date it was generated.
Cite the source paper — Lacoste, Luccioni, Schmidt and Dandres, “Quantifying the Carbon Emissions of Machine Learning,” arXiv:1910.09700 (BibTeX key lacoste2019quantifying) — and note the calculator as the instrument. The tool provides a ready-made LaTeX template that includes the citation and your computed figure. Because the project is passively maintained and its grid data is static, also state the date the figure was generated so a reader knows which vintage of the dataset it reflects.
Allocate it by context: training in your own data centre is Scope 2 (purchased electricity); training on cloud infrastructure is Scope 3 Category 1 (purchased services); a model you deploy for customers adds Scope 3 Category 11 (use of sold products) for inference; and the hardware’s embodied carbon is Scope 3 Category 1/2. Apply PUE, correct the 100%-utilisation assumption where material, report both location-based and market-based grid views, and document the boundary and vintage. Prefer measured data from a runtime tracker where you can get it.
The Green Software Foundation’s SCI expresses software carbon as (E × I + M) per functional unit R, where E is energy, I is grid intensity, M is embodied emissions, and R is the unit of work. The ML CO2 Impact Calculator computes the E × I term for training only — it omits M and does not divide by a functional unit. SCI also requires a physical grid intensity and excludes market-based offsets from the core figure, so only the calculator’s raw (not offset-adjusted) output feeds an SCI calculation, and SCI leans toward a marginal/consequential grid view rather than the calculator’s average-grid approach.
Because grid carbon intensity — the kilograms of CO₂e per kilowatt-hour — varies enormously by location, from roughly 0.85 kgCO₂e/kWh on a coal-heavy grid down to around 0.05 on a hydro- or nuclear-heavy one. That is more than a tenfold spread, so the same training run on the same hardware can have a reported footprint that differs by an order of magnitude purely from where the data centre sits. Choosing a low-carbon region is the single most effective lever a practitioner has to reduce a training run’s emissions.
Sources and References
Every figure and methodological statement on this page reconciles to the primary sources below, retrieved June 2026. Figures are hardcoded against the dated source — Standards pages are historical records and do not pull live values.
Primary sources
- Lacoste, A., Luccioni, A., Schmidt, V. & Dandres, T., Quantifying the Carbon Emissions of Machine Learning, NeurIPS 2019 Climate Change AI Workshop, arXiv:1910.09700.
- ML CO2 Impact Calculator, mlco2.github.io/impact (web tool and methodology notes, including the explicit PUE-exclusion note).
- mlco2/impact GitHub repository (README, hardware and grid data, passive-maintenance statement).
Corroborating and comparative sources
- Green Software Foundation, Software Carbon Intensity (SCI) Specification, v1.x — SCI = (E·I + M) per R; physical-grid requirement; consequential vs attributional accounting.
- How to estimate carbon footprint when training deep learning models? A guide and review, Environmental Research Communications (IOP), 2023 — tool comparison, usage-factor analysis, PUE handling (CodeCarbon, CarbonTracker, Green Algorithms, Eco2AI, Experiment-Impact-Tracker).
- Luccioni, A. S., Viguier, S. & Ligozat, A.-L., Estimating the Carbon Footprint of BLOOM — full-lifecycle ML emissions including embodied and inference terms.
- Strubell, E., Ganesh, A. & McCallum, A., Energy and Policy Considerations for Deep Learning in NLP, 2019 — early quantification of training energy costs.
Related GreenCalculus references
- Sustainable Web Design Model
- Cambridge Bitcoin Electricity Consumption Index
- GHG Protocol Scope 2 Guidance
- GHG Protocol Scope 3 Standard
- GHG Protocol Product Standard
- ISO 14067 Product Carbon Footprint
- CSRD / ESRS E1
- IFRS S2 Climate Disclosures
- Uptime Institute PUE
- ASHRAE 90.4 Data Centre Energy
- EN 50600 / ISO-IEC 22237 Data Centre Design
- Grid emission factors 2026
- Electricity emission factor
- Scope 2 emissions
- Scope 3 emissions
- Scope 2 location-based
- Scope 2 market-based
- CO₂e (carbon dioxide equivalent)
- Use-of-sold-products methodology
- Scope 2 Electricity Calculator
What changed in this revision
Published 20 June 2026. Initial publication. Documents the ML CO2 Impact Calculator (Lacoste et al., 2019; arXiv:1910.09700): the four-input power × time × grid-intensity model, the raw and offset-adjusted outputs, the 100%-utilisation assumption, the default PUE exclusion, and the static-dataset / passive-maintenance status. Sets out the exclusions (embodied hardware, inference, data movement, idle compute), the limitations and opposing biases, the broader tooling ecosystem (CodeCarbon, CarbonTracker, Green Algorithms, Eco2AI, Experiment-Impact-Tracker), and the mapping to the Green Software Foundation SCI specification and to GHG Protocol Scope 2 / Scope 3 Categories 1, 2, and 11. Positions the calculator as a Layer 3 factor-application tool upstream of corporate AI-compute disclosure under CSRD, IFRS S2, EU data-centre energy reporting, and SCI; cross-linked to the Cambridge CBECI as the sibling compute-energy index.