Quantifying the Carbon Emissions of Machine Learning

## 5. Experimental Analysis

### Evaluation Methodology

This paper does not conform to the standard experimental design of a machine learning research paper — there is no dataset of prompts, no model to evaluate, no accuracy metric to optimize. The "experiment" is the construction and validation of the calculator itself, and the "results" are the empirical patterns that emerge from the calculator's underlying data tables. The appropriate evaluation framework is therefore **data quality assessment** rather than model benchmarking.

- **Dataset.** The calculator is built on three data tables: (i) a grid carbon intensity table mapping 57 cloud provider regions to gCO₂eq/kWh values (Appendix A), sourced primarily from Brander et al. (2011) [5] with supplementary data from To and Lee (2017) [4]; (ii) a hardware efficiency table listing 11 devices with their TDP, TFLOPS32, TFLOPS16, and computed GFLOPS/W (Appendix B), sourced from manufacturer specification sheets; and (iii) a cloud provider region-to-city mapping compiled from Google Cloud Platform, Microsoft Azure, and Amazon Web Services documentation. There is no train/test split — the data tables are the complete artifact being evaluated.

- **Base model(s).** Not applicable. The calculator performs arithmetic multiplication (`TDP × time × grid_intensity`), not machine learning inference. There is no trained model under evaluation.

- **Metrics.** The calculator outputs a single number: estimated grams of CO₂-equivalent (gCO₂eq) emitted during training. The paper does not empirically validate this estimate against ground-truth measurements (e.g., by instrumenting actual GPUs with power meters and comparing the calculator's estimate to measured consumption). Instead, the metric is presented as a **first-order approximation** whose quality depends on the accuracy of the underlying data tables. The implicit evaluation criterion is **data coverage and reasonableness**: do the tables span the major cloud providers, do the grid intensities align with known energy economics patterns (hydro-rich regions low, coal-rich regions high), and do the hardware efficiencies capture the right order-of-magnitude differences between device classes.

- **Baselines.** There are no algorithmic baselines in the traditional sense. The paper's implicit baseline is **the status quo of no estimation** — practitioners making infrastructure decisions without any emissions information. The calculator's "performance" is measured by whether it surfaces actionable patterns (the 40× geographic lever, the two-order-of-magnitude hardware efficiency range) that would otherwise remain invisible. A more structured evaluation might have compared the calculator's estimates against measured emissions from Strubell et al. (2019) [1] to assess calibration, but this comparison is not performed.

- **Generation budget / compute accounting.** The calculator models energy consumption as `TDP (watts) × training_time (hours)`, producing watt-hours, then converts to kWh (dividing by 1000) and multiplies by gCO₂eq/kWh. This is a **nameplate accounting model**: it uses manufacturer-rated maximum power draw (TDP) rather than measured average power draw, and it does not model PUE overhead, CPU/memory/network energy, or idle power consumption. The paper acknowledges the PUE gap in Section 3 but does not incorporate it into the computation. Multi-GPU training is not explicitly modeled; the interface takes a single GPU type and training time, implying single-GPU workloads unless the user manually adjusts.

- **Cross-validation / statistical protocol.** There is no cross-validation or statistical testing. The data tables are treated as fixed reference data, not as samples from a distribution whose variance needs to be estimated. The paper reports point estimates for grid intensities and hardware efficiencies with no confidence intervals or error bounds. The paper's commitment to transparency is expressed through version control (commit hash `e692e28` recorded for reproducibility) and open data hosting (GitHub repository accepting corrections via pull requests) rather than through statistical quantification of uncertainty.

### Main Quantitative Results

The paper's quantitative results are not experimental measurements but rather **descriptive statistics computed from the assembled data tables**. These statistics characterize the distribution of grid carbon intensities across cloud provider regions and the distribution of computational efficiency across hardware platforms. The purpose is to demonstrate that the variation in both dimensions is large enough — and the levers for controlling them accessible enough — that emissions estimation is both necessary (because emissions vary dramatically with choices) and actionable (because practitioners can control those choices).

#### Geographic Variation in Grid Carbon Intensity

The central quantitative finding is the range and distribution of gCO₂eq/kWh values across the 57 cloud provider regions cataloged in Appendix A. Figure 1 (a box-and-whisker plot by continent/region) visualizes this distribution, and Tables A1–A3 (Google Cloud, AWS, Azure) provide the underlying point estimates.

**Headline statistic:** The grid carbon intensity across major cloud provider data center locations spans from **16 gCO₂eq/kWh** (Google Cloud europe-west6, Zürich, Switzerland) to **1,009 gCO₂eq/kWh** (Azure southafricanorth and southafricawest, South Africa), a ratio of approximately **63:1**.

The paper focuses on a more conservative comparison within widely-used cloud regions, quoting a **40× factor** between "20g CO₂eq/kWh in Quebec, Canada to 820g CO₂eq/kWh" in fossil-fuel-dependent regions (Section 2.1 and Section 3). The 820 gCO₂eq/kWh figure corresponds approximately to Australian data centers (Azure australiasoutheast at 805 gCO₂eq/kWh, AWS ap-southeast-2 at 802 gCO₂eq/kWh), which the paper uses as the representative high-emissions endpoint.

**Within-provider variation.** The data tables demonstrate that a practitioner can achieve large emissions reductions without switching cloud providers — only switching regions within the same provider:

- **Google Cloud Platform (Table A1):** 16 gCO₂eq/kWh (Zürich) to 920 gCO₂eq/kWh (Mumbai, asia-south1). Ratio: **57.5:1**.
- **Amazon Web Services (Table A2):** 20 gCO₂eq/kWh (Montreal, ca-central-1) to 920 gCO₂eq/kWh (Mumbai, ap-south-1). Ratio: **46:1**.
- **Microsoft Azure (Table A3):** 20 gCO₂eq/kWh (Quebec, canadaeast) to 1,009 gCO₂eq/kWh (South Africa). Ratio: **50.5:1**.

This within-provider variation is the most actionable finding for practitioners, since switching regions within an existing provider requires no organizational procurement changes — it is purely a deployment configuration choice.

**Within-continent variation.** Figure 1 and the data tables reveal substantial variation even within single continents, meaning that data locality requirements (e.g., keeping data within Europe or North America for regulatory reasons) do not preclude emissions optimization:

- **North America:** 20 gCO₂eq/kWh (Montreal, Google/AWS; Quebec, Azure) to 736.6 gCO₂eq/kWh (Azure centralus, Des Moines, Iowa). Factor: **~37×** within one continent.
- **Europe:** 16 gCO₂eq/kWh (Zürich) to 623 gCO₂eq/kWh (UK regions across all three providers). Factor: **~39×** within Europe.
- **Asia-Pacific:** 419 gCO₂eq/kWh (Singapore, all three providers) to 920 gCO₂eq/kWh (Mumbai). Factor: **~2.2×** — notably smaller than the North American or European ranges, reflecting the region's heavier overall reliance on fossil fuels and fewer hydro/nuclear-rich grids.

**Interpretation of the distribution (Figure 1).** The box-and-whisker plot shows regional medians with substantial spread. Regions with hydroelectric or nuclear-dominated grids (Canada, South America, Europe) cluster at the low end (medians below ~200 gCO₂eq/kWh), while regions with coal-heavy grids (Asia-Pacific, parts of the US) show higher medians and larger variance. The paper uses this figure to make the visual argument that geography is not a binary clean/dirty choice but a **continuous spectrum**, and that the variation within provider regions means that even "carbon-neutral" cloud providers offer data centers spanning this full spectrum.

#### Hardware Efficiency Variation

The hardware comparison in Appendix B (Table 4) provides the second empirical pillar: the range of computational efficiency across device classes, measured in GFLOPS32/W.

**Headline statistic:** Computational efficiency spans from **4.83 GFLOPS32/W** (Intel Xeon E5-2699 CPU) to **533.33 GFLOPS32/W** (AGX Xavier embedded GPU) in single-precision (FP32), a ratio of approximately **110:1**. In half-precision (FP16), the range extends to **1,066.67 GFLOPS32/W** for the AGX Xavier versus **0.68 GFLOPS16/W** for a GTX 1080 Ti — a ratio of approximately **1,570:1**, though this is largely an artifact of the GTX 1080 Ti's poor FP16 support (0.17 TFLOPS16) rather than a meaningful efficiency comparison.

**Representative comparisons reported in the paper (Section 2.2 and Section 3):**
- CPUs can be 10× less efficient than GPUs (Xeon E5-2699 at 4.83 GFLOPS32/W vs. RTX 2080 Ti at 53.80 GFLOPS32/W: ratio **11.1:1**).
- TPU v3 can be 4 to 8× more efficient than GPUs (TPU v3 at 225 GFLOPS32/W vs. V100 at 50.00 GFLOPS32/W: ratio **4.5:1**; vs. RTX 2080 Ti at 53.80 GFLOPS32/W: ratio **4.2:1**).
- Embedded GPUs (AGX Xavier) can be 10 to 20× more efficient than traditional GPUs (533.33 GFLOPS32/W vs. V100 at 50.00: ratio **10.7:1**).

The paper cautions that these are **peak theoretical efficiency** comparisons and that "empirical measurement of GFLOPS/W on various ML architecture would provide more accurate numbers" (Section 2.2 footnote 3). The practical implication is that real-world training workloads may not achieve the peak FLOPS rates assumed in the manufacturer specifications, meaning the efficiency ratios reported here are best-case comparisons. However, the paper argues that the order-of-magnitude differences between device *classes* (CPU vs. GPU vs. TPU vs. embedded GPU) are robust to this imprecision — a CPU will never approach GPU efficiency on matrix-multiply-heavy ML workloads regardless of how peak FLOPS is estimated.

**Combined effect of geography and hardware.** The paper does not explicitly compute a combined emissions range (geographic 40× × hardware 110× in FP32 = 4,400×), but the implication is clear: a training run on a Xeon CPU in South Africa (worst-case) versus a training run on an AGX Xavier in Switzerland (best-case) would differ in emissions per unit of computation by approximately **7,000×** (`1009/16 × 533.33/4.83 ≈ 63 × 110 ≈ 7,000`). Even within more practical comparisons — a V100 GPU in Iowa (566.3 gCO₂eq/kWh, 50 GFLOPS32/W) versus a TPU v3 in Montreal (20 gCO₂eq/kWh, 225 GFLOPS32/W) — the combined factor is approximately **128×** (`566.3/20 × 225/50 ≈ 28.3 × 4.5 ≈ 127.4`).

#### Concrete Emissions Estimates (Worked Examples)

The paper provides several worked examples to ground the abstract emissions factors in recognizable ML training runs (Section 3):

- **VGG or BERT-scale training:** For "a model such as VGG or BERT, which are trained on multiple GPUs for several weeks," the paper states that choosing a hydroelectric-powered server location over a fossil-fuel one "can correspond to avoiding emitting several hundreds of kilograms of CO₂eq." Using the calculator's implicit formula: a single V100 (300 W) training for 3 weeks (504 hours) in Iowa (566.3 gCO₂eq/kWh) produces `300 × 504 × 566.3 / 1000 = 85,695 gCO₂eq ≈ 85.7 kgCO₂eq`. The same run in Montreal (20 gCO₂eq/kWh) produces `300 × 504 × 20 / 1000 = 3,024 gCO₂eq ≈ 3.0 kgCO₂eq`, a difference of approximately 82.7 kgCO₂eq. For a multi-GPU run (e.g., 8 GPUs), the difference scales to approximately 662 kgCO₂eq, consistent with the "several hundreds of kilograms" claim.

These worked examples are the closest the paper comes to empirical validation — they demonstrate that the calculator produces physically plausible estimates and that the geographic lever produces differences large enough to matter for individual decision-making. However, they are not validated against measured emissions from actual BERT or VGG training runs, which means they should be interpreted as **illustrative order-of-magnitude estimates** rather than precise empirical measurements.

### Ablation Studies and Robustness Checks

The paper does not conduct ablation studies in the standard ML sense — there is no model component to remove, no hyperparameter to vary, no architecture variant to compare. However, the paper's **data quality choices** constitute implicit robustness checks: the deliberate selection of location-based over market-based accounting, the choice of TDP over measured power draw, and the use of average rather than marginal grid emissions factors each represent a methodological decision that could have been made differently. The paper's transparency about these choices serves the function of an ablation — it allows the reader to assess how the calculator's estimates would change under alternative assumptions.

**Location-based vs. market-based accounting.** The paper's most consequential methodological choice is using grid-level (location-based) emissions factors rather than provider-reported (market-based) emissions after offset purchases. The paper does not quantify the difference this choice makes, but it is implicitly enormous: if carbon-neutral providers with REC portfolios reported near-zero emissions, the geographic 40× lever would collapse to near-zero variation, and the calculator would report effectively identical emissions for all provider regions regardless of their physical grid intensity. The paper's transparent rejection of this approach (Section 2.1, Section 3) is the functional equivalent of showing that the choice of accounting framework determines whether the calculator surfaces actionable variation or collapses to a uniform (and misleading) near-zero estimate.

**TDP vs. measured power draw.** The paper uses TDP as an upper-bound proxy for actual power consumption rather than requiring empirical power metering. The implicit ablation is: how much does this choice affect the estimate? The paper does not quantify this, but the direction of error is clear — TDP overestimates actual GPU power draw for most workloads (which typically run at 70–95% of TDP depending on utilization), meaning the calculator's energy estimates are conservatively high. This error partially offsets the exclusion of infrastructure overhead (PUE, CPU, memory), which would increase the estimate. The net effect of these two opposing simplifications (TDP overestimate vs. no infrastructure overhead) is unknown and not quantified.

**Average vs. marginal grid emissions factors.** The calculator uses annual average grid carbon intensity rather than time-varying marginal intensity. The paper does not test the sensitivity of estimates to this choice, nor does it discuss scenarios where the two diverge significantly (e.g., grids with high solar penetration where daytime marginal intensity is much lower than the daily average). This is a genuine limitation — a practitioner who schedules training jobs to run during daytime hours on a solar-rich grid might have substantially lower actual emissions than the calculator's average-based estimate would suggest. The paper's implicit defense is pragmatic: marginal emissions factors are not available in a standardized global database, so using averages is the only approach that can provide universal coverage. This is a reasonable trade-off but should be understood as a source of systematic error whose magnitude varies by grid and by training schedule.

**Data currency and versioning.** The paper records the data's commit hash (`e692e28`) at publication time and hosts the data in a public GitHub repository, enabling reproducibility and community-driven updates. This is a robustness mechanism of a different kind — it ensures that the data underlying the paper's claims is not a one-time snapshot that becomes stale as grids decarbonize and new hardware is released, but rather a living reference that can be corrected and updated. The paper invites corrections through pull requests, which is a form of continuous validation. However, the paper does not report how frequently the underlying data sources (Brander et al.) are updated, nor does it establish a protocol for regularly refreshing the calculator's data tables — a gap that matters given the multi-year timescale over which grid decarbonization can meaningfully shift emissions factors.

**Cross-provider consistency check.** A useful implicit validation is the consistency of grid intensity estimates for the same physical location across different cloud providers. Montreal appears in all three providers' tables: Google Cloud northamerica-northeast1 (20 gCO₂eq/kWh), AWS ca-central-1 (20 gCO₂eq/kWh), and Azure canadaeast (20 gCO₂eq/kWh). Frankfurt appears as Google Cloud europe-west3 (615 gCO₂eq/kWh) and AWS eu-central-1 (615 gCO₂eq/kWh). London appears as Google Cloud europe-west2 (623 gCO₂eq/kWh), AWS eu-west-2 (623 gCO₂eq/kWh), and Azure uksouth/ukwest (both 623 gCO₂eq/kWh). This perfect consistency for co-located data centers suggests that the mapping methodology — identify city, look up corresponding regional grid factor — is being applied uniformly and that the grid factor data source (Brander et al.) provides consistent values at the city/country level. Inconsistencies would have indicated mapping errors or different data sources; the consistency is a reassuring sanity check, though not a formal validation.

### Critical Assessment

The paper makes one central empirical claim: **geographic choice of data center location is the dominant lever for reducing ML training emissions, capable of varying emissions by a factor of ~40× for identical computation.** This claim is grounded in the data tables of Appendix A and visualized in Figure 1, and the evidence supports it straightforwardly — the 57 cloud provider regions cataloged span from 16 to 1,009 gCO₂eq/kWh, and even within single providers the range is 46–58×. The claim is fundamentally a data-compilation claim rather than an experimental one: the authors are reporting what the public emissions factor data says about the cloud provider regions, not measuring anything new. The strength of the claim rests on (a) the accuracy of the Brander et al. grid intensity data, (b) the correctness of the cloud provider region-to-city mapping, and (c) the appropriateness of using average grid emissions factors for computing workloads. The paper is transparent about the data sources and mapping methodology, enabling verification. However, the grid intensity data itself is not independently validated — the paper does not cross-reference Brander et al.'s values against alternative databases (e.g., eGRID for US regions, European Environment Agency data for EU regions) to assess consistency. A single-source data compilation is inherently vulnerable to systematic errors in that source, and the paper does not quantify this risk.

A secondary claim is that **the calculator provides a usable estimate of carbon emissions for individual ML training runs.** This claim is **not empirically validated** in the paper. No comparison is made between the calculator's estimates and ground-truth emissions measurements from instrumented training runs. The Strubell et al. (2019) paper, which the current paper cites as motivation, provides measured energy consumption and estimated emissions for specific NLP training runs — these would have constituted a natural validation dataset. Why this comparison was not performed is unclear. Without validation, the calculator's estimates remain **uncalibrated approximations** — the paper explicitly acknowledges the approximations (TDP as power proxy, no PUE, no infrastructure overhead, average grid factors) but does not assess their combined effect on estimation accuracy. A practitioner using the calculator cannot know whether their actual emissions are likely to be within 20%, 50%, or 200% of the reported estimate. This is the most significant weakness in the paper's experimental (or data) evaluation.

The paper's third implicit claim — that **the calculator will motivate better infrastructure decisions** — is a behavioral claim about user response to information, and the paper conducts no user study or deployment analysis to evaluate it. This is understandable for a tool paper introducing version 0.1 of a new resource, but it means that the paper's ultimate theory of change (awareness → estimation → better choices → reduced emissions) is asserted rather than tested.

**Genuine weaknesses and missing analyses:**

- **No ground-truth validation.** The calculator's estimates are never compared against measured emissions from real training runs. At minimum, a comparison against Strubell et al.'s published figures for BERT, Transformer, and ELMo training would have provided a calibration check. This omission is notable given that the Strubell et al. paper is the primary motivation for the current work.

- **Single source for grid intensity data.** All grid emissions factors are sourced from Brander et al. (2011) [5]. While this is a widely-cited reference, emissions factors can differ meaningfully between data sources depending on methodology (production-based vs. consumption-based accounting, inclusion or exclusion of transmission losses, treatment of combined heat and power). Cross-referencing against at least one alternative database (e.g., IEA emissions factors, EPA eGRID for US regions) would strengthen confidence in the reported values.

- **No quantification of error bounds.** The paper acknowledges that its estimates are approximate but provides no error analysis. What is the uncertainty in the TDP-based energy estimate? How much does PUE vary across data centers, and what is the resulting emissions uncertainty? How much do grid emissions factors vary seasonally, and does this affect the ranking of locations? Without error quantification, the calculator's estimates are single points with unknown reliability.

- **No modeling of multi-GPU or distributed training.** The interface models a single-GPU training run. For the large-scale distributed training runs that the paper cites as particularly concerning (e.g., BERT on multiple GPUs for weeks), the calculator provides no guidance on how to aggregate across devices. A practitioner training on 64 GPUs would need to manually multiply — and may not know whether to use 64× the single-GPU energy estimate (which ignores inter-GPU communication overhead and scaling inefficiency) or some other factor.

- **No accounting for training dynamics.** The energy consumption model assumes constant power draw at TDP for the full training duration. Real training runs have varying GPU utilization — data loading bottlenecks, checkpointing, evaluation phases, and learning rate warmup all produce periods of lower utilization. The TDP × time formula is a rough upper bound that may overestimate energy consumption substantially for workflows with significant I/O or evaluation phases.

- **Hardware table is incomplete and dated.** The table covers 11 devices at a specific moment in GPU evolution (circa 2018–2019 hardware). Modern data center GPUs (A100, H100), cloud TPU configurations (TPU v4, TPU v5), and Apple Silicon (M1/M2/M3 series) are absent. This is expected for a 2019 paper but limits its current applicability without community updates.

**Missing experiments that would have strengthened the paper:**

1. **Calibration against Strubell et al. (2019).** Input the hardware, training time, and grid assumptions from the Strubell et al. paper into the calculator and compare the output to the reported emissions estimates. This would quantify the calculator's accuracy against published, peer-reviewed measurements. Any systematic discrepancy would illuminate which simplifying assumptions (TDP, no PUE, no infrastructure overhead) dominate the estimation error.

2. **Sensitivity analysis.** Vary each input (GPU TDP ±20%, grid intensity ±1 standard deviation if temporal data were available, training time ±10%) and report the resulting range in emissions estimates. This would provide practitioners with a sense of which inputs drive estimation uncertainty and how much confidence to place in the output.

3. **Cross-source grid intensity validation.** Compare Brander et al. emissions factors against at least one alternative database for a subset of high-importance regions (US, EU, Canada). Report any systematic differences and their impact on the ranking of provider regions by emissions intensity.

4. **PUE sensitivity.** While the calculator excludes PUE, the paper could estimate its impact by computing emissions under a range of plausible PUE values (1.1, Google's reported average, versus 1.5–2.0 for less efficient data centers). This would show practitioners how much additional emissions the cooling and infrastructure overhead adds, and whether PUE variation changes the geographic ranking.

5. **Inference emissions case study.** The paper identifies inference emissions as an important omitted factor (Section 4). A brief case study — estimating the training vs. inference emissions for a widely-deployed model serving millions of predictions — would demonstrate the relative magnitude of these two lifecycle phases and help practitioners prioritize between optimizing training location versus inference deployment efficiency.

**Conditional nature of the paper's claims.** The 40× geographic lever claim holds under the specific assumption that cloud provider data centers draw power from the local grid at the average emissions intensity reported by Brander et al. This assumption breaks when: (a) the provider has direct renewable energy supply (e.g., on-site solar or wind, direct PPA with a specific renewable generator) that is not captured by the regional grid average, or (b) the grid's marginal emissions factor (what additional generation is dispatched when the data center consumes more power) differs substantially from the average factor. The paper's location-based accounting choice means the claim is about **physical grid intensity**, not about the provider's net carbon accounting, which is the right framing for estimating atmospheric impact but may not align with how providers report their own emissions. Practitioners relying on the calculator for decision-making should understand that the estimate represents grid-average physical emissions, not the provider's reported carbon footprint under their chosen accounting standard.

## 6. Limitations and Trade-offs

### Limitation 1: Emissions Estimates Are Unvalidated and Uncalibrated

**The assumption or constraint.** The calculator produces emissions estimates by multiplying TDP by training time by grid carbon intensity, but the paper never validates these estimates against ground-truth measurements from actual training runs. The authors are explicit that the TDP-based energy consumption model is a simplification:

> "Empirical measurement of GFLOPS/W on various ML architecture would provide more accurate numbers but we are only interested in approximate values to compare classes of devices." (Section 2.2, footnote 3)

They further acknowledge that "our calculator remains simply an approximation of the true emissions produced by ML training for several reasons" (Section 4), citing lack of provider transparency and the unmodeled effects of global load balancing.

**The consequence.** A practitioner using the calculator cannot know whether their actual emissions are within 20%, 50%, or 200% of the reported estimate. The energy estimate uses TDP — the manufacturer-rated **maximum** sustained power draw — which overestimates consumption for workloads that don't saturate the GPU, while simultaneously omitting CPU, memory, networking, and cooling overhead (PUE), which would underestimate total data center energy consumption. These errors pull in opposite directions with unknown relative magnitude. Without calibration, the calculator's outputs are **relative ordering signals** (Montreal is cleaner than Iowa) rather than **absolute measurement instruments** (this training run emitted 42.3 kgCO₂eq ± X). The difference matters: relative ordering is sufficient for location selection decisions, but absolute estimates are needed for carbon budgeting, offset purchasing, or regulatory reporting.

**What evidence exists in the paper.** No validation data is presented. The Strubell et al. (2019) paper [1] — which the authors cite as motivation and which provides measured energy consumption and estimated emissions for specific NLP training runs (Transformer, ELMo, BERT) — constitutes a natural calibration dataset that is never used. The hardware efficiency table (Appendix B) reports peak theoretical FLOPS, which the authors acknowledge may not reflect real ML workload throughput, but they do not quantify this gap. The PUE discussion in Section 3 notes that Google achieves 1.1 PUE, implying that cooling and power conversion add at least 11% energy overhead for even the most efficient data centers (and potentially 50–100% for less efficient ones), but this multiplier is not incorporated into the calculator's computation or even estimated for different providers.

**Mitigation status.** The paper does not attempt to address this limitation, nor does it propose a calibration study as future work. The authors' strategy is transparency rather than validation: they open-source the data on GitHub, record the commit hash for reproducibility, and invite corrections through pull requests. This enables community-driven improvement of the data tables but does not address the fundamental gap between the calculator's TDP-based energy model and actual measured energy consumption. A practitioner who needs calibrated absolute emissions estimates receives no guidance from this paper on how to obtain them or how much error to expect from the calculator's output.

---

### Limitation 2: Difficulty Estimation Cost Is Ignored in the Workflow

**The assumption or constraint.** The calculator assumes the practitioner knows their total training time in hours — a reasonable input for a completed training run being evaluated retrospectively. However, for the paper's stated use case of **prospective decision-making** (selecting a data center location *before* training, choosing hardware *before* launching a job), the training time itself is often unknown. The paper provides no guidance on estimating training time a priori, and the educational framing (Section 3) treats the calculator as a tool for quantifying emissions after the fact to build awareness, rather than for optimizing decisions before the fact.

**The consequence.** This creates a circular dependency that undermines the calculator's utility for the very decisions the paper argues are most impactful. A practitioner deciding between training on a V100 in Iowa versus a TPU v3 in Montreal needs to know the training time on each hardware configuration to compare estimated emissions. But training time depends on hardware efficiency, model architecture, data pipeline throughput, and software stack optimizations — factors the calculator does not model. The tool can tell you that Montreal is 28× cleaner per kWh than Iowa, but it cannot tell you whether a TPU v3 in Montreal will train your model faster than a V100 in Iowa, which determines total energy consumption. The paper's hardware efficiency comparison (Appendix B) provides peak GFLOPS/W, which is a throughput proxy, but the mapping from GFLOPS/W to wall-clock training time for a specific model is left entirely to the practitioner.

Furthermore, the paper suggests (Section 3) that practitioners should "consciously select the server location before dispatching your jobs," implying that location choice is a pre-training decision. But the emissions estimate requires training time, which is only known after training completes. The calculator is thus better suited for **post-hoc accounting** (what did my completed training run emit?) than for **ex-ante optimization** (which location should I choose for my upcoming training run?), yet the paper's rhetoric and recommendations emphasize the latter.

**What evidence exists in the paper.** The paper does not address this circularity. The worked examples in Section 3 (VGG/BERT training for "several weeks") use vague time ranges rather than precise estimates, illustrating the tool's operation without solving the estimation problem. The hardware table (Appendix B) reports peak FLOPS and GFLOPS/W, but there is no discussion of how to translate these into training time estimates for specific model architectures. The paper does not reference any training time estimation methodology or tool.

**Mitigation status.** Not addressed. The paper treats training time as a known input to be supplied by the user, focusing its contribution on the other two multiplicative factors (hardware power draw, grid carbon intensity) where the data integration challenge is the primary barrier. The training time estimation problem is arguably a harder challenge — it requires modeling the computational requirements of arbitrary ML workloads on arbitrary hardware — and the paper's silence on it is understandable given scope. However, for the paper's stated goal of enabling practitioners to "mitigate their carbon emissions" through infrastructure choices (Section 1), the inability to estimate training time a priori is a practical barrier that limits the calculator's impact to retrospective awareness rather than prospective optimization.

---

### Limitation 3: No Accounting for Inference Emissions Despite Its Dominance in Total Lifecycle Impact

**The assumption or constraint.** The calculator estimates emissions from **training** only. Emissions from model deployment and inference — serving predictions to users — are explicitly excluded:

> "while in the current version of our tool, we focus on quantifying the emissions of training ML models, there is still the issue of deploying them, since the inference process is also energy-expensive, especially if done continuously and on a large scale. This is something that should be taken into account by ML practitioners in their products that are deployed in real-world settings." (Section 4)

**The consequence.** For many production ML systems, inference emissions dominate total lifecycle emissions. A model that is trained once on 8 GPUs for two weeks may then serve billions of predictions over months or years on hundreds or thousands of inference servers. The energy consumption of the inference fleet can exceed the training energy consumption by orders of magnitude. The calculator, by focusing exclusively on training, directs practitioner attention toward a potentially small fraction of total emissions while leaving the dominant source unmeasured and unoptimized.

This limitation creates a risk of **moral licensing**: a practitioner who conscientiously trains their model in a low-carbon data center (reducing training emissions by 40×) may feel they have addressed the environmental impact of their work, while the deployed model silently emits far more carbon through inference. The paper's educational framing (Section 3) and recommendations (Section 3) center on training decisions (location, hardware, hyperparameter search efficiency), potentially reinforcing the misperception that training is the primary emissions source. The Strubell et al. (2019) paper that motivates this work focused on training emissions for large NLP models, but those models were research artifacts without large-scale deployment; for deployed production models, the training/inference emissions ratio is a critical but unexamined variable.

**What evidence exists in the paper.** The paper provides no estimate of the relative magnitude of training versus inference emissions for any workload, no case study comparing the two lifecycle phases, and no guidance on how practitioners might estimate inference emissions. The limitation is acknowledged in a single sentence in Section 4 with the suggestion that practitioners use "energy-efficient architectures and computing infrastructure" for deployment. No methodology, tool, or data source for inference emissions estimation is proposed.

**Mitigation status.** The paper identifies inference emissions as future work ("This is something that should be taken into account") but makes no attempt to scope the problem or provide even a back-of-the-envelope methodology. Given the calculator's approach for training emissions (TDP × time × grid intensity), a natural extension would be to estimate inference emissions as (inference latency per request × number of requests × hardware power draw × grid intensity), but the paper does not develop this. The limitation is flagged honestly but left entirely unresolved, meaning the calculator provides a **partial view** of ML carbon emissions that may systematically underestimate total lifecycle impact for deployed models by a factor that could range from modest (for research models trained once and evaluated offline) to enormous (for high-traffic production services).

---

### Limitation 4: Static Average Grid Factors Ignore Temporal Variation and Marginal Emissions

**The assumption or constraint.** The calculator uses **annual average** grid carbon intensity (gCO₂eq/kWh) for each data center location, sourced from Brander et al. (2011) [5]. This assumes that every kilowatt-hour consumed by the training job has the same carbon intensity, regardless of when it is consumed:

> "if we assume that all servers are connected to local grids at their physical location, we are able to make an estimation of the amount of CO₂eq that they emit using public data sources." (Section 2.1)

**The consequence.** In electricity grids with significant renewable penetration, the carbon intensity of generation varies dramatically with time — solar generation peaks at midday and disappears at night, wind generation varies with weather patterns, and hydroelectric availability fluctuates seasonally with snowmelt and rainfall. The **marginal** emissions factor (the carbon intensity of the *additional* generation dispatched to meet the data center's load) can differ substantially from the annual average, particularly in grids where baseload generation is low-carbon (nuclear, hydro) and peak demand is met with fossil fuels. The calculator's use of average factors means that:

- **Temporal scheduling opportunities are invisible.** A practitioner who could schedule training jobs to run during high-renewable periods (daytime in solar-rich grids, windy seasons) would achieve lower actual emissions than the calculator reports, but the tool provides no signal to motivate or enable this optimization.
- **Rankings of locations may be distorted.** Two locations with similar annual average grid intensity may have very different marginal intensity profiles — one might be clean on average but dirty at the margin (nuclear baseload + gas peakers), while another might be clean on both average and margin (hydro-dominated). The calculator's average-based ranking cannot distinguish these cases.
- **Long training runs are reasonably modeled; short runs are not.** For training jobs that run continuously for weeks, the annual average is a reasonable approximation because the job spans many diurnal cycles and weather patterns. For shorter jobs (hours to a day), the actual emissions can deviate substantially from the average-based estimate, and the calculator provides no error bounds.

**What evidence exists in the paper.** The paper does not analyze temporal variation in grid carbon intensity. The Brander et al. (2011) source provides annual average emissions factors; the paper does not cross-reference these against sources that provide higher temporal resolution (e.g., real-time grid emissions APIs that have become available since the paper's publication). The paper does not discuss marginal versus average emissions factors, nor does it quantify the potential magnitude of temporal variation for any of the regions in its database.

**Mitigation status.** The paper does not address this limitation. The choice of annual average factors is defended implicitly by pragmatism — average factors are available in standardized global databases, while marginal and time-varying factors are not. This is a reasonable trade-off for a tool aiming for universal coverage, but the paper does not explicitly articulate this trade-off or caution users about the limitation. For a 2019 paper, this gap is understandable — real-time grid carbon intensity APIs and time-aware carbon accounting were not yet established in the ML community. However, from a contemporary perspective, this limitation means the calculator's estimates are most reliable for long-running training jobs and least reliable for short, schedulable workloads where temporal optimization could yield substantial additional emissions reductions beyond the static geographic lever the paper emphasizes.

---

### Limitation 5: Multi-GPU and Distributed Training Not Modeled

**The assumption or constraint.** The calculator's interface takes a single GPU type and a single training time as inputs. The implicit energy model is therefore `TDP_single_GPU × training_hours`, which represents a single-GPU training run. The paper does not provide explicit guidance for multi-GPU or distributed training scenarios:

> "This tool, currently in its alpha version, takes as input the details regarding the training of an ML model: the geographical zone of the server, the type of GPU, and the training time, and gives as output the approximate amount of CO₂eq produced." (Section 3)

**The consequence.** The large-scale training runs that the paper cites as particularly concerning — and that motivated the prior work by Strubell et al. (2019) — are multi-GPU by nature. BERT training, which the paper uses as a worked example (Section 3: "a model such as VGG or BERT, which are trained on multiple GPUs for several weeks"), is typically done on 8–64 GPUs or TPU pods. A practitioner training on 16 V100 GPUs for 2 weeks would need to decide whether to:

- Enter "16 GPUs" as the hardware type (not supported — only single devices are listed in Appendix B).
- Enter the single-GPU training time (2 weeks) and mentally multiply the output by 16.
- Enter a combined GPU-hours value (16 GPUs × 336 hours = 5,376 hours) as the training time.

Option (c) is the most natural mapping to the calculator's interface but assumes **perfect linear scaling** — that 16 GPUs training for 1 hour consumes exactly 16× the energy of 1 GPU training for 1 hour. Real distributed training incurs communication overhead (gradient synchronization via all-reduce, parameter server communication), which consumes additional energy in networking equipment and may reduce GPU utilization (GPUs waiting for communication to complete), meaning the energy consumption scales **super-linearly** with GPU count. The calculator's single-GPU model cannot capture this overhead, and the paper provides no guidance on how to adjust estimates for multi-GPU scenarios.

Furthermore, different parallelism strategies (data parallelism, model parallelism, pipeline parallelism) have different communication patterns and scaling efficiencies. A practitioner using model parallelism on 64 GPUs (where GPUs spend significant time waiting for inter-device communication) versus data parallelism on 64 GPUs (where GPUs are more independently utilized) would have different energy consumption profiles, but the calculator collapses all multi-GPU scenarios into a single-TDP model with no parallelism-awareness.

**What evidence exists in the paper.** The paper provides no analysis of multi-GPU scaling, no communication overhead model, and no estimates of how energy consumption scales with GPU count for realistic distributed training workloads. The hardware table (Appendix B) lists only individual device specifications, with no information about interconnect energy costs or multi-device efficiency. The worked examples in Section 3 mention "multiple GPUs" qualitatively but do not demonstrate how to use the calculator for such scenarios.

**Mitigation status.** The paper does not address this limitation. The "alpha version" designation suggests awareness of the tool's incompleteness, but multi-GPU support is not identified as a planned improvement. For a tool targeting awareness-raising among individual practitioners (who may typically train on 1–4 GPUs), the single-GPU model may be adequate. For the paper's motivating examples (large-scale NLP training) and for organizational decision-making about large training clusters, the single-GPU limitation means the calculator **systematically underestimates** emissions for the most carbon-intensive training runs — the very runs the paper argues are most important to measure.

---

### Limitation 6: Provider Carbon Neutrality Claims Are Dismissed Rather Than Interrogated

**The assumption or constraint.** The paper adopts location-based accounting, using physical grid carbon intensity regardless of cloud provider offset purchases. The justification is that Renewable Energy Certificates (RECs) are financial instruments that do not physically displace emissions:

> "we assume that all servers are connected to local grids at their physical location" (Section 2.1)
> "while many cloud providers are carbon neutral, some of their data centers may still be carbon intensive due to the local grid that they are connected to" (Section 3)

The paper acknowledges that providers purchase RECs and fund renewable energy projects (Section 3, discussing Google's carbon neutrality, Microsoft's 44% direct renewable consumption, and AWS's renewable investments) but treats these as separate from the physical emissions estimate.

**The consequence.** This methodological choice creates a **communication challenge** for practitioners using the calculator in organizational contexts. A practitioner who reports that training on Google Cloud in Iowa emitted 85 kgCO₂eq (based on the calculator's location-based estimate) may be contradicted by their organization's sustainability team, which reports zero emissions for that job because Google is a carbon-neutral provider under the market-based accounting standard the organization uses. The practitioner is left in the awkward position of explaining why their estimate differs from the provider's reported emissions and from their organization's carbon accounting framework.

The paper does not provide guidance on how to reconcile the location-based estimate with market-based claims, nor does it help practitioners understand when each accounting framework is appropriate. The choice to use location-based accounting is well-motivated for estimating **physical atmospheric impact**, but organizational decision-making often operates within market-based accounting frameworks (for regulatory compliance, carbon budgeting, or sustainability reporting). A tool that produces estimates incompatible with those frameworks may see limited adoption in organizational settings, regardless of its physical accuracy.

Furthermore, the paper's dismissal of RECs as purely financial instruments overlooks the more nuanced reality that **some** RECs and power purchase agreements (PPAs) do drive additional renewable generation — particularly long-term PPAs that provide revenue certainty for new wind and solar projects. The blanket treatment of all offsets as financially real but physically meaningless is an oversimplification that may unfairly dismiss cloud providers' genuine contributions to grid decarbonization.

**What evidence exists in the paper.** The paper does not provide a comparative analysis of location-based versus market-based emissions estimates for the same training run across different providers. It does not quantify the gap between the two accounting frameworks for any provider region, nor does it assess the additionality of specific providers' offset portfolios. The educational sections of the calculator website (mentioned in Section 3) are described as covering "RECs, carbon neutrality, etc." but their content is not included in the paper, so the depth and nuance of the discussion cannot be evaluated.

**Mitigation status.** The paper acknowledges the tension implicitly by including provider offset information alongside grid intensity data (Section 3: Google is carbon neutral, Microsoft is carbon neutral with 44% direct renewable, AWS is not yet 100% carbon neutral). However, it does not attempt to resolve or even fully articulate the tension. A more complete treatment would have provided **both** location-based and market-based estimates where data permits, allowing practitioners to understand the physical emissions, the accounting treatment, and the gap between them. Alternatively, the paper could have provided a decision framework: use location-based estimates for personal carbon footprint awareness and for comparing infrastructure options on a physical basis; use market-based estimates for organizational carbon reporting aligned with provider claims. Neither is provided, leaving practitioners to navigate the accounting framework conflict on their own.

## 7. Implications and Future Directions

### How This Work Changes the Landscape

This paper does not introduce a new machine learning algorithm, architecture, or theoretical result. Its contribution is infrastructural rather than algorithmic: it assembles fragmented public data into a tool that makes carbon emissions estimable by any ML practitioner, and in doing so, it **converts an invisible externality into a visible decision variable**. Before this work, the carbon emissions produced by training a neural network were something that only specialized researchers (Strubell et al., 2019) could estimate for specific high-profile models after the fact. After this work, any practitioner with a web browser can estimate their training emissions in 30 seconds by selecting three dropdown values.

The conceptual shift this enables is subtle but consequential. The paper demonstrates that **geographic choice is the dominant emissions lever** — a ~40× range in grid carbon intensity across cloud provider data center locations, compared to a ~4.5× improvement from switching a V100 GPU to a TPU v3 or a ~11× improvement from switching a CPU to a GPU. This inverts the implicit priority ordering that the "Green AI" framing (Schwartz et al., 2019) had established. That framing emphasized algorithmic efficiency — use fewer FLOPs, adopt more efficient architectures, reduce computation. This paper shows that FLOPs and carbon emissions are not interchangeable units, because the conversion factor between them varies by 40× depending on where the computation happens. A model that uses 2× fewer FLOPs but trains on a 5× dirtier grid is a net emissions loss relative to the less efficient model on a cleaner grid. This decoupling means that **algorithmic efficiency alone is insufficient as an environmental strategy** — it must be paired with carbon-aware infrastructure decisions to translate efficiency gains into actual emissions reductions.

The paper also introduces a **methodological precedent for location-based accounting in ML emissions**, deliberately rejecting the market-based accounting framework (RECs, carbon offsets) that cloud providers use to claim carbon neutrality. This choice is more than a technical detail; it is a normative stance that the relevant quantity for practitioner decision-making is physical atmospheric impact, not corporate carbon accounting. By showing that Google Cloud's carbon-neutral certification does not eliminate the 40× variation in grid intensity across its data centers, the paper gives practitioners a reason to care about location choice even when using a "carbon-neutral" provider. This reframing — that cloud provider carbon neutrality is a corporate-level claim that does not necessarily reflect the marginal emissions of your specific training job — has become standard in the subsequent ML carbon accounting literature (e.g., CodeCarbon, experiment-impact-tracker, the ML CO2 Impact tool's successors).

The reconciliation of prior contradictions is implicit but important. Strubell et al. (2019) showed that training large NLP models produces material emissions (hundreds of tonnes of CO₂eq), establishing that there is a problem. Schwartz et al. (2019) argued that the field should treat efficiency as an evaluation criterion, establishing that we should care. But neither provided a mechanism for individual practitioners to act on that awareness. The gap between "this is a problem" and "here is what you can do about it" is where this paper intervenes. The calculator is the bridge: it takes the abstract concern raised by Strubell et al. and the normative framework proposed by Schwartz et al. and operationalizes them into a concrete workflow that produces individualized, actionable estimates.

The paper redirects research attention in several ways that have proven prescient. It makes **verifier and accounting infrastructure** a first-class research concern — not the glamorous work of designing new architectures, but the essential plumbing of measuring and attributing environmental costs. It shifts focus from **training emissions alone** toward the broader lifecycle, explicitly flagging inference emissions as a critical gap (Section 4). And it establishes that **data integration**, not data scarcity, is the primary barrier to ML carbon awareness — the data exists in public sources, but no one had connected it to practitioner workflows. This reframing has influenced a generation of tools (CodeCarbon, CarbonTracker, experiment-impact-tracker) that follow the same pattern: integrate public emissions data with ML workflow instrumentation to make carbon visible.

The magnitude of the contribution is **not a paradigm shift** — the underlying science (grid emissions factors, hardware power specifications) was well-established before this paper. It is an **infrastructure contribution with reframing effects**: the tool is a simple multiplication, but the act of building it and making it public changes what information is available to practitioners making infrastructure decisions, which in turn changes what decisions are possible. The paper's most enduring contribution may be the **data tables themselves** (Appendices A and B) — a manually curated cross-reference of cloud provider regions to grid carbon intensities that, despite being a snapshot from 2019, established the template that subsequent tools have refined and expanded.

### Follow-Up Research This Work Enables

**Calibration of the TDP-based energy model against measured GPU power consumption during real ML training workloads.** The paper's fundamental energy model (`TDP × training_time`) is unvalidated: no comparison is made between the calculator's estimates and measured power draw from instrumented GPUs during actual training runs. A calibration study would instrument a representative set of GPU models (V100, A100, RTX 2080 Ti) with power meters during training of standard architectures (ResNet-50, BERT-base, a Transformer) and compare measured energy consumption to the calculator's TDP-based estimate. The key measurement would be the **utilization ratio** — actual average power draw divided by TDP — and how it varies with GPU model, batch size, model architecture, and framework (PyTorch vs. TensorFlow). The Strubell et al. (2019) paper provides a natural calibration dataset: its reported energy measurements for Transformer, ELMo, and BERT training could be compared directly against the calculator's estimates using the same hardware, training times, and grid assumptions. The outcome would be either (a) a set of correction factors that practitioners can apply to the calculator's output for more accurate absolute estimates, or (b) an upper bound on the estimation error that would let practitioners report uncertainty intervals alongside point estimates. This work is newly tractable because the calculator provides a standardized estimation methodology against which measured values can be compared, and the open-source data tables make the comparison fully reproducible.

**Time-aware grid carbon intensity for schedulable ML workloads.** The calculator uses static annual average grid emissions factors from Brander et al. (2011), which ignores the substantial temporal variation in grid carbon intensity driven by renewable generation (solar peaks at midday, wind varies with weather). A follow-up would integrate real-time or forecast grid carbon intensity data — now available through APIs like Electricity Maps, WattTime, or the UK National Grid's carbon intensity API — into the calculator's location lookup. The research question is: for training jobs that can be flexibly scheduled (e.g., hyperparameter sweeps, ablation studies, periodic retraining), how much additional emissions reduction is achievable by shifting the job to low-carbon-intensity hours, beyond the static geographic lever the paper documents? The experiment would compare three scheduling strategies — (1) run immediately regardless of grid intensity, (2) run at the historically cleanest time of day based on average diurnal patterns, and (3) run when a real-time API predicts below-threshold carbon intensity — and measure the emissions reduction achieved by each relative to the annual average baseline. This work is enabled by the paper's location-based accounting framework, which provides the baseline (annual average) against which temporal optimization can be measured. The paper's limitation discussion (Section 6) explicitly identifies this gap, noting that "the calculator's estimates are most reliable for long-running training jobs and least reliable for short, schedulable workloads."

**Inference emissions estimation and the training/inference lifecycle ratio.** The paper explicitly identifies inference emissions as an unaddressed gap: "there is still the issue of deploying [models], since the inference process is also energy-expensive, especially if done continuously and on a large scale" (Section 4). A direct extension would extend the calculator's multiplicative framework to inference: estimate inference emissions as `(inference_latency_per_request × number_of_requests × hardware_power_draw × grid_intensity)`. The research contribution would be developing reasonable defaults for inference latency and hardware power draw across common deployment hardware (CPU inference, GPU inference, TPU inference, edge devices) and combining these with the existing grid intensity database to produce a unified training + inference lifecycle emissions estimate. The key open question — one the paper raises but cannot answer — is **what is the typical ratio of inference to training emissions** for deployed ML systems? A case study measuring this ratio for several production systems (a deployed NLP model serving millions of API requests, a recommendation model retrained weekly, an image classification model in a mobile app with on-device inference) would provide the first empirical characterization of where practitioner attention should be focused across the ML lifecycle. This work is directly enabled by the paper's training emissions methodology, which provides one half of the lifecycle equation.

**Provider-specific PUE integration and multi-GPU scaling factors.** The calculator's energy model uses only GPU TDP, ignoring data center Power Usage Effectiveness (PUE) — the ratio of total facility energy to IT equipment energy. The paper notes that Google achieves 1.1 PUE while less efficient data centers can exceed 1.5, a difference of 36%+ in total energy consumption for the same GPU workload. A follow-up would augment the calculator's data tables with provider-specific PUE estimates (where publicly available), multi-GPU scaling overhead factors (the additional energy consumed by inter-GPU communication in distributed training), and CPU/memory overhead (the base server power consumption independent of GPU load). The research contribution would be a more complete energy model:

$$E_{\text{total}} = \text{PUE} \times (n \times \text{TDP}_{\text{GPU}} \times u \times t_{\text{training}} + P_{\text{CPU+mem}} \times t_{\text{training}} + E_{\text{communication}})$$

where $u$ is GPU utilization, $n$ is number of GPUs, and $E_{\text{communication}}$ captures networking energy for gradient synchronization. The experiment would measure each term for a representative distributed training workload (e.g., BERT-large on 8–64 GPUs) and quantify how much the TDP-only estimate undercounts total energy. This work is enabled by the paper's open-source data structure (GitHub repository accepting pull requests), which can accommodate additional data columns without architectural changes.

**Cross-source validation of grid emissions factors and sensitivity analysis.** The paper's entire geographic lever claim rests on a single data source: Brander et al. (2011) [5]. Emissions factors for the same region can differ meaningfully across databases due to methodological differences (production vs. consumption-based accounting, inclusion of transmission losses, treatment of imports/exports). A validation study would cross-reference the calculator's grid intensity values against at least two alternative databases — for US regions, EPA's eGRID database; for EU regions, the European Environment Agency's emissions factors; for global coverage, the IEA's CO₂ emissions from fuel combustion database — and quantify the divergence. For each cloud provider region, the study would report the range of emissions factors across sources and assess whether the **rank ordering** of regions (Montreal cleaner than Iowa cleaner than Mumbai) is robust to choice of data source. This is the most direct stress test of the paper's central empirical claim, and it is enabled by the paper's transparent documentation of which emissions factor source it uses for each region (Appendix A).

### Practical Applications and Downstream Use Cases

**Data center region selection as a standard part of the ML job launch checklist.** The paper's most immediately actionable finding is that choosing a low-carbon data center region can reduce training emissions by up to 40× with no code changes, no architectural modifications, and no additional cost (cloud GPU pricing is typically similar across regions within a continent). This finding can be operationalized by integrating an emissions estimate — using the calculator's methodology — directly into cloud provider consoles (e.g., a "carbon impact" field next to the "estimated cost" field in the GPU instance launch screen) or into MLOps platforms (e.g., a pre-launch check in Weights & Biases or MLflow that flags when a job is being launched in a high-carbon region and suggests a lower-carbon alternative). The specific lever: a practitioner launching a multi-GPU training job in `us-central1` (Iowa, ~566 gCO₂eq/kWh) sees an estimated emissions of ~86 kgCO₂eq for a single V100 over 3 weeks and a suggestion to switch to `northamerica-northeast1` (Montreal, 20 gCO₂eq/kWh) for an estimated ~3 kgCO₂eq — a 28× reduction. This integration requires only the calculator's data tables (provided in the GitHub repository) and a simple multiplication, making it a low-engineering-effort addition to existing cloud tooling.

**Carbon budgeting for ML research labs and organizational ML programs.** Organizations that have committed to carbon reduction targets need to account for ML training emissions in their scope 2 or scope 3 inventories. The calculator provides a standardized methodology — however approximate — for estimating these emissions when direct power metering is unavailable. An ML research lab could implement a policy requiring all training runs above a certain threshold (e.g., >10 GPU-hours) to report their estimated emissions using the calculator (or its methodology) at job completion, building an emissions baseline over time. The baseline enables two downstream actions: (1) identifying the largest emissions sources across multiple projects and prioritizing them for optimization (location switching, hardware upgrades, training efficiency improvements), and (2) purchasing carbon offsets calibrated to the estimated emissions for unavoidable high-carbon training runs. The specific number: if a lab trains 100 BERT-scale models per year on 8-V100 instances for 2 weeks each in a moderate-carbon region (~400 gCO₂eq/kWh), the calculator estimates `100 × 8 × 300 W × 336 hours × 400 gCO₂eq/kWh / 1000 ≈ 32,256 kgCO₂eq ≈ 32 tonnes` annually. Switching all jobs to a hydro-powered region (20 gCO₂eq/kWh) brings this to ~1.6 tonnes — a 95% reduction. Even switching half the jobs produces a ~16-tonne reduction, which may represent a material fraction of a small organization's total carbon footprint.

**Hardware procurement decisions informed by efficiency per watt.** The hardware efficiency comparison in Appendix B — showing a ~110× range in GFLOPS/W from a Xeon CPU (4.83) to an AGX Xavier embedded GPU (533.33) — provides a quantitative basis for hardware purchasing decisions that account for environmental impact alongside performance and cost. An organization planning to purchase GPU hardware for a training cluster could compute the expected emissions per training run on different hardware options using the calculator's methodology: for a fixed training job that requires $F$ total FLOPs, the energy consumption is approximately $F / \text{GFLOPS/W}$, and the emissions are $(F / \text{GFLOPS/W}) \times I_{\text{grid}}$. The TPU v3 (225 GFLOPS32/W) requires ~4.5× less energy than a V100 (50 GFLOPS32/W) for the same computation, translating directly to a 4.5× emissions reduction at any given grid intensity. For an organization on a fossil-heavy grid, this efficiency multiplier may be the dominant lever after location choice. The calculator makes this comparison explicit by providing both the TDP and the GFLOPS/W in the same table, enabling practitioners to select hardware based on emissions efficiency rather than raw performance alone.

**Teaching and advocacy in ML education.** The calculator's dual-purpose design — simultaneously a computation tool and an educational instrument — makes it suitable for integration into ML courses, tutorials, and workshops as a concrete entry point for discussing the environmental impacts of computational research. A course assignment could ask students to estimate the emissions of their project's training runs, compare the impact of different infrastructure choices (location, hardware, training duration), and propose a strategy for reducing emissions while maintaining model quality. The specific pedagogical value is that the calculator makes the environmental cost **personal and concrete** rather than abstract and aggregate: a student sees that their specific training run emitted 2.3 kgCO₂eq (equivalent to driving ~5 miles in a typical car) or 230 kgCO₂eq (equivalent to driving ~575 miles), connecting computational choices to tangible environmental consequences. The educational sections on the calculator website (RECs, carbon neutrality, actionable items) provide the conceptual background, and the tool itself provides the quantification. This use case is directly aligned with the paper's stated goal of "raising awareness around the carbon emissions of ML" and reaching practitioners "to make positive changes" (Section 3).