Holistically Evaluating the Environmental Impact of Creating Language Models

🎯 Pitch

Model development—the experiments before final training—contributes roughly half the environmental cost of training large language models, yet almost no developer discloses it. The authors' own OLMo series emitted 493 metric tons of CO₂ and consumed 2.77 million liters of water when accounting for hardware manufacturing, development, and final runs, with training power wildly oscillating between 15% and 85% of capacity in a way that complicates grid planning.

1. Executive Summary

This paper measures and reports the holistic environmental impact of developing the OLMo series of transformer language models, ranging from 20 million to 13 billion active parameters trained on up to 5.6 trillion tokens each. The analysis accounts for three lifecycle stages—model development (hyperparameter tuning, scaling experiments, and failed runs before final training), final training runs, and simulated inference deployment—as well as embodied impacts from hardware manufacturing and operational water consumption alongside carbon emissions. When accounting for hardware manufacturing, model development, and final training, the authors find their series of models released 493 metric tons of carbon emissions (equivalent to powering about 98 U.S. homes for one year) and consumed 2.769 million liters of water (equivalent to about 24.5 years of water usage by a person in the U.S.), with model development alone amounting to ~50% of the environmental impact of final training—a cost most model developers do not disclose. Through sub-second power monitoring, they also reveal that power consumption fluctuates between ~15% and ~85% of hardware's maximum draw during training due to checkpointing, establishing that training runs cause thousands of rapid power fluctuations that pose grid-scale planning challenges as demand grows.

2. Context and Motivation

The Core Problem: Environmental Impacts of AI Are Poorly Characterized

The fundamental problem this paper tackles is that the environmental impacts of creating and deploying large language models are systematically under-reported, and the partial reporting that exists misrepresents the true scale of the problem. The paper identifies three interconnected gaps in current practice that compound to produce a misleading picture of AI's environmental footprint.

First, most model developers report only the cost of final training runs, if they report anything at all. The dominant practice in the field—when environmental disclosure happens—is to document the electricity consumed and carbon emitted during the single, final, successful training run of a released model. The authors argue this is a substantial undercount because it excludes all the computational work that preceded that final run. As they frame it through Equation (1) adapted from Schwartz et al. (2020):

$\text{Cost}(R) \propto E \cdot D \cdot H$

where $E$ is the cost of processing a single example, $D$ is the training dataset size, and $H$ is the number of hyperparameter experiments. Previous work almost exclusively reports $E \cdot D$ (the cost of training on the dataset), while $H$ —the total number of experiments run during development—is "most often excluded" (Section 3.1). This means the public sees only the tip of the iceberg: the final successful run obscures the many failed runs, architecture explorations, hyperparameter sweeps, and scaling law experiments that made it possible.

Second, water consumption is almost entirely absent from environmental reporting for AI systems. While carbon emissions have received increasing (if still incomplete) attention since Strubell et al. (2020) and Schwartz et al. (2020), the water footprint of AI training—including both on-site data center cooling and off-site water consumed during electricity generation—remains largely invisible. The paper specifically calls out that even when closed models like GPT-3 have had their water consumption estimated (Li et al., 2023), those estimates are "based on speculation about location of training, energy consumption, etc., as there is very little public information about GPT-3's training" (Section 2). The lack of transparency from developers means even careful external estimates are unreliable.

Third, embodied impacts from hardware manufacturing remain effectively unknown. The carbon emitted and water consumed during the fabrication of GPUs—a necessary prerequisite for all model development—is "essentially unknown" (Section 5.1) because GPU manufacturers do not disclose lifecycle environmental data. The paper notes that while other data center hardware manufacturers release such estimates, the GPU supply chain remains opaque.

These three gaps are not independent oversights; they reflect a systematic pattern of under-disclosure that makes it impossible for the public, policymakers, or even the research community to understand the true environmental cost of AI development or to design effective mitigation strategies.

Why This Problem Matters: Scale, Acceleration, and Infrastructure Decisions

The importance of this problem is not merely academic. The paper grounds its motivation in several concrete, escalating trends that make comprehensive environmental accounting urgent.

The scale of AI training is growing dramatically, with real infrastructure consequences. The paper cites projections that data centers may consume "upwards of 11.7% of the total US energy demand by 2030" (Shehabi et al., 2024; Green et al., 2024). This is not a distant hypothetical—the authors point to concrete decisions already being made: Microsoft signing a deal to purchase 20 years of energy from a reopened nuclear power plant, and energy providers extending the life of aging fossil fuel plants "to keep up with demand" (Section 1). These are multi-decade infrastructure commitments being made based on projected AI energy needs, yet the data informing those projections is incomplete.

The deployment shift toward smaller, "over-trained" models creates a Jevons Paradox dynamic. The paper identifies a critical trend that complicates the environmental calculus (Section 5.2): the recent success of training small models far beyond the compute-optimal point (Hoffmann et al., 2022) has produced "deployment-optimized" models that are cheaper to run at inference time. Examples include the progression from Llama 1 (1T tokens) to Llama 2 (2T) to Llama 3 (15T). The authors invoke Jevons' Paradox (Jevons, 1865): when a resource becomes more efficient to use, total consumption of that resource tends to increase rather than decrease. As inference becomes cheaper per query, models are deployed in more places—on-device (Gunter et al., 2024; Abdin et al., 2024), in API services with rapidly dropping prices—potentially driving total inference compute up even as per-query costs fall. The paper's inference simulations in Section 4.2 are designed to explore this dynamic directly: they calculate break-even points showing how many inference queries it takes to match training costs, finding that some models would need "only" hundreds of millions to billions of inferences—figures that "can be reached by production systems in weeks to months based on current usage trends" (Section 1, citing OpenAI reaching 400 million users).

Power fluctuations during training pose a distinct and underappreciated grid-scale problem. The paper identifies a problem that goes beyond total energy consumption to the pattern of consumption over time (Section 4.3). Training runs do not draw steady power—they fluctuate between approximately 85% and 15% of maximum GPU power draw every time a checkpoint is saved, potentially causing "thousands of rapid power fluctuations" per training run. This matters because power grids must balance supply and demand continuously: when demand sharply drops, excess power is discarded (by grounding or venting steam), and when demand sharply rises, peaker plants (typically fossil-fuel-powered) must come online quickly. The paper frames this as a control challenge that "breaks common assumptions about data center supply and demand" and becomes more severe as training runs scale to "tens of thousands of GPUs or more" (Section 5.2). This is not a hypothetical issue—the authors cite Dubey et al. (2024) documenting that even the largest model developers "encounter difficulties from regularly shifting power demand throughout training."

The lack of transparency impedes both public accountability and effective mitigation. Without comprehensive, standardized reporting, it is impossible to compare the environmental efficiency of different approaches, to set meaningful policy targets, or to verify industry claims about sustainability. The paper notes that the EU AI Act and proposed U.S. legislation like the Artificial Intelligence Environmental Impacts Act would begin to define voluntary reporting standards, but "until such standards are widespread in the community, improved transparency can only come through voluntary efforts" (Section 5.1). The paper positions itself as a demonstration that comprehensive reporting is possible and as a call for others—especially those training the largest models—to follow suit.

Where Existing Reporting Falls Short

The paper surveys what the field currently does (and does not) report, identifying specific deficiencies in current practice.

Most public models report nothing. The paper states plainly that "most publicly available models do not report any climate impact, including CO2 emissions, water usage, or embodied carbon" (Section 2). This is the baseline: the majority of model releases are accompanied by no environmental disclosure whatsoever.

When reporting exists, it is fragmented and inconsistent. The paper catalogs a series of partial disclosures that collectively illustrate the gaps:

Llama models (Touvron et al., 2023a;b; Dubey et al., 2024): Reported electricity consumption and carbon emissions for final training runs only; did not estimate development costs or water consumption. Their carbon intensity methodology changed across releases—Llama 1 used the U.S. national average rather than location-specific intensity, Llama 2 did not specify the carbon intensity used, and Llama 3 used region-specific intensity. All three assumed 100% GPU power draw throughout training, which the current paper directly refutes with measured data showing ~85% is typical.
Gemma models (Gemma Team et al., 2024): Reported only "a single number: the total emissions from pretraining their models, not broken down by model or by different stages of training, or by electricity consumption and carbon intensity" (Section 2).
BLOOM (Luccioni et al., 2023): Provided the most comprehensive reporting prior to this work, including embodied emissions, operational emissions, and idle cluster consumption. However, it did not measure development costs, water consumption, or inference impacts, and its embodied emissions estimates relied on the same opaque manufacturing data the current paper identifies as problematic.
OLMo and OLMo 2 (Groeneveld et al., 2024; OLMo et al., 2025): The direct predecessors to this work documented electricity consumption per model and used region-specific intensity factors, with OLMo 2 also estimating water consumption. However, neither measured development costs or potential inference costs, and neither captured the power fluctuation dynamics the current paper analyzes.

Estimates for closed models are speculative. For proprietary models like GPT-3, external researchers (Li et al., 2023) have attempted to estimate water consumption, but these estimates are "based on speculation about location of training, energy consumption, etc." (Section 2) because the companies do not disclose the relevant information. This means the models with potentially the largest environmental impact have the least transparent accounting.

Inference costs are rarely connected to training costs. While Luccioni et al. (2024) estimated the impact of inference for deployed AI systems, prior work has not systematically connected inference costs back to training costs in a way that illuminates the tradeoff between efficient deployment and total environmental impact. The paper's break-even analysis—calculating how many inference queries are needed to match training costs—provides this connection and reveals that efficient deployment can paradoxically lead to greater total impact if it increases usage volume.

How This Paper Positions Itself Relative to Existing Work

The paper positions itself not as proposing a new methodology, but as executing the most comprehensive environmental accounting to date and demonstrating what is possible when model developers have access to their own infrastructure data. The key differentiators from prior work are:

Completeness across lifecycle stages. Unlike all prior work except BLOOM (Luccioni et al., 2023), the paper accounts for embodied impacts from hardware manufacturing. Unlike any prior work for LLMs, it reports model development costs—the $H$ term in Equation (1) that captures all experiments before the final training run. And unlike prior training-focused reports, it simulates inference deployment costs to connect training and deployment impacts. The scope is deliberately holistic: "from hardware manufacturing, to development, and the final training runs" (Section 4.1).

Measured rather than assumed power consumption. While prior work (including the Llama and Gemma reports) assumed GPUs operate at their theoretical maximum power draw (typically 700W for H100s), this paper uses "detailed time series data for a single node throughout each run, logging power data at sub-second intervals" (Section 3.1). This reveals that actual power draw is around 85% of maximum during active training and drops to ~15% during checkpointing—numbers that cannot be known from specification sheets alone. The authors explicitly state their estimates "should be viewed as a lower bound on the true amount of power consumed" since they only measure GPU power, not CPU, RAM, networking, or cooling overhead.

Water consumption alongside carbon emissions. The paper extends the water consumption methodology from Li et al. (2023) to their own infrastructure, calculating both on-site water usage effectiveness (WUE) for data center cooling and off-site WUE for electricity generation. Their data centers use closed-loop cooling with no evaporative losses (WUE $_{\text{onsite}}$ = 0), but the off-site water consumption varies substantially: 1.29 L/kWh in Texas (Jupiter cluster) versus 3.10 L/kWh in Iowa (Augusta cluster). This geographic variation in water intensity—driven by different electricity generation mixes—is a finding in itself and demonstrates why location transparency matters.

A deliberate focus on smaller, open models. The authors explicitly note that their models are "relatively small" (only up to 13B parameters) and "encourage the reader to consider larger models released by other organizations to have equivalently larger environmental impacts" (Section 1). This is not a limitation but a rhetorical strategy: if even these modest-scale models have substantial environmental costs that are typically unreported, the costs for massive proprietary models are proportionally larger—and the case for mandatory transparency is strengthened.

A call to action grounded in demonstrated feasibility. The paper positions itself not as an endpoint but as evidence that comprehensive accounting is achievable: "This work is a step in the right direction, but responsibility of reporting and reducing the environmental impact must fall on those training the largest models, as they have the largest impact" (Section 1). By showing that development costs can be ~50% of final training costs, that water consumption is substantial even in water-efficient data centers, that power fluctuations pose distinct grid challenges, and that inference break-even points can be reached quickly in production, the paper builds a multi-dimensional case for why partial reporting is insufficient and what a more complete picture looks like.

In summary, the paper addresses a problem that is simultaneously methodological (how to measure), empirical (what are the actual numbers), and political (who should report what). Its contribution is to demonstrate—by doing—that developers with access to their own infrastructure can produce a far more complete environmental accounting than is currently standard, and to use that demonstration to argue that the status quo of fragmentary, voluntary disclosure is inadequate for the scale of infrastructure decisions now being made around AI energy use.

3. Technical Approach

3.1 Reader Orientation

This is an empirical measurement paper whose core contribution is not a new model or algorithm, but a thorough accounting framework and the resulting measurements of the environmental impact—carbon emissions, water consumption, and power dynamics—of building and (hypothetically) deploying a series of open-source language models. The paper constructs a measurement pipeline that traces resource consumption across three lifecycle stages (development, final training, and simulated inference) plus hardware manufacturing, using sub-second power monitoring rather than theoretical assumptions, and then translates those measurements into carbon, water, and cost-breakdown figures that reveal how much environmental impact is hidden in the parts of the pipeline that developers typically do not disclose.

3.2 Big-Picture Architecture (Diagram in Words)

The measurement system has five major components, connected in a pipeline that follows the physical chronology of model creation:

Power Measurement Subsystem — sub-second GPU power logging on one node per training run, extrapolated to the full cluster; produces wattage time series that capture fluctuations.
Operational Impact Translation Layer — converts measured power ( $P$ ) into carbon emissions ( $CO_2 e$ ) via Equation (2) and water consumption via Equation (3), using data center–specific efficiency factors (PUE, carbon intensity, WUE).
Embodied Impact Estimation Layer — amortizes hardware manufacturing costs (carbon and water) over assumed GPU lifetime to produce per-GPU-hour embodied costs, which are multiplied by total GPU hours consumed.
Development and Training Cost Aggregation — tallies GPU hours, energy, carbon, and water across all model development experiments (grouped by model size class) and all final training runs, producing the totals in Sections 4.1.
Inference Simulation Subsystem — runs offline benchmarking of served models on ShareGPT prompts using SGLang, measuring GPU energy with CodeCarbon across three request-rate scenarios, and computes break-even points (number of inference queries needed to match total training costs).

Information flows as follows: physical experiments on the cluster → power measurement (sub-second logging on one GPU node) → operational impact computation using Equations (2) and (3) with data center–specific constants → aggregation over all development runs and final training runs → report. Separately, embodied costs are computed: estimated manufacturing cost per GPU ÷ (lifespan × hours/year) → per-GPU-hour amortized cost → multiplied by total GPU hours. For inference, a separate measurement loop runs: SGLang serves a model on one GPU → CodeCarbon logs process-level power during 2400-request benchmarks → operational impacts computed using the same equations → break-even analysis compares per-query costs to total training costs.

3.3 Roadmap for the Deep Dive

First, the power measurement methodology — how sub-second logging works, what is measured vs. what is not, and how per-node measurements are extrapolated to the full cluster. This is foundational because every downstream impact calculation depends on total power consumption $P$ .
Second, the operational impact equations (carbon and water) — what each constant means, where the specific values come from for Jupiter and Augusta clusters, and why geographic variation matters.
Third, the embodied impact estimation — how manufacturing carbon and water are amortized over GPU lifetimes, the hard numbers used, and the acknowledged sources of uncertainty.
Fourth, the development cost accounting — how runs are grouped, what counts as "development" vs. "final training," and the $H$ factor from the Schwartz et al. (2020) cost equation.
Fifth, the inference simulation methodology — the SGLang setup, the three request-rate scenarios, the ShareGPT dataset, the CodeCarbon measurement, and the break-even calculation.

3.4 Detailed, Sentence-Based Technical Breakdown

Power Measurement Methodology

The foundation of every environmental impact number in this paper is the measurement of electrical power consumed by GPUs during model training and inference. The paper departs from the common practice of assuming GPUs operate at their theoretical maximum power draw (e.g., 700W for an H100); instead, it measures actual power consumption at sub-second intervals.

Measurement granularity. The authors "analyze detailed time series data for a single node throughout each run, logging power data at sub-second intervals" (Section 3.1). A "node" is a single server containing 8 NVIDIA H100 GPUs. The sub-second logging captures not just average power but transient fluctuations, such as the drops during checkpoint saving visible in Figure 2.

Extrapolation to full cluster. The measured power for one node is "extrapolate[d] to the total number of nodes" (Section 3.1). If a training run uses 64 nodes (512 GPUs), the single-node power trace is multiplied by 64. This assumes homogeneous power consumption across all nodes, which is reasonable for tightly synchronized distributed training where all GPUs perform the same computation in lockstep, but the paper does not explicitly discuss whether node-to-node variance was assessed.

What is measured vs. what is not. The paper explicitly states: "As we only measure GPU power consumption, our estimates should be viewed as a lower bound on the true amount of power consumed during development and training" (Section 3.1). CPU power, RAM power, networking (interconnect) power, and storage power are not captured. Data center cooling overhead is accounted for separately through the PUE factor (see below), but the non-GPU components of each server's direct power draw are unmeasured. This means the reported energy figures are conservative — real consumption is higher by some margin that the paper does not quantify.

Power fluctuation analysis. The sub-second data enables the analysis in Section 4.3 and Figure 2, which shows that power consumption during training oscillates between approximately 600W per GPU (over 85% of the theoretical 700W maximum) during active training and just over 100W per GPU (about 15% of maximum) during checkpoint saves. Each checkpoint save causes a sharp drop followed by a sharp rise, producing "thousands of rapid power fluctuations" over a full training run. The paper uses this data to make the argument about grid-scale implications discussed in Section 5.2.

Inference power measurement. For inference simulations (Section 3.4), the paper uses a different measurement tool: "CodeCarbon (Courty et al., 2024) tracking, which was verified against the same time series monitoring used throughout training." CodeCarbon is a software library that samples power consumption at the process level during code execution. The paper specifies that it measures "total power and energy consumption associated with only the relevant processes, excluding the overhead associated with, for example, holding the model in memory or listening for requests" (Section 3.4). This gives a process-scoped rather than system-scoped measurement, meaning idle GPU power when no requests are being processed is excluded. This choice makes the per-query energy numbers lower than they would be under a system-scoped measurement and represents a deliberate scope decision: the paper measures the marginal energy cost of active inference, not the total cost of maintaining an inference server.

Operational Carbon Emissions Calculation

The paper translates measured power consumption into carbon emissions using the standard equation from Schwartz et al. (2020) and subsequent work:

$CO_2 e = P \cdot \text{PUE} \cdot \text{CI}$

where $P$ is the total power consumed by the GPUs (in kWh), PUE is the Power Usage Effectiveness of the data center (a dimensionless ratio ≥ 1.0), and CI is the carbon intensity of the local electrical grid (in kg CO $_2$ emitted per kWh consumed).

What it computes: The operational Scope 2 carbon emissions attributable to the electricity consumed by the GPUs during computation. $P$ is the measured GPU energy. Multiplying by PUE scales this up to account for data center overhead — cooling, lighting, power distribution losses — which means the total energy drawn from the grid is $P \times \text{PUE}$ . Multiplying by CI converts grid energy into emitted carbon, using the average emissions per unit energy for the specific regional power grid that supplies the data center.

Why this form: This decomposition separates what the model developer controls (GPU efficiency, which affects $P$ ) from what the data center operator controls (cooling efficiency, which affects PUE) from what the energy grid provides (generation mix, which affects CI). This is important because it makes clear that two identical training runs can have dramatically different carbon footprints depending on where they are run — a model trained in a region with hydroelectric power (low CI) will have lower emissions than one trained in a region with coal power (high CI), even if the GPUs consume identical energy. The paper reports location-specific PUE and CI values rather than national averages, following the best practice established by Dodge et al. (2022).

Data center–specific constants. The paper reports values for its two clusters:

Jupiter cluster (Texas): PUE between 1.1 and 1.2 depending on utilization; the paper "conservatively assume[s] 1.2 for our calculations." Carbon intensity: "Austin Energy, which most recently reported a carbon intensity of 0.332 kg CO $_2$ per kWh" (Section 3.1). This cluster was used for all models except the 13B.
Augusta cluster (Iowa): PUE: "trailing twelve-month average was 1.12." Carbon intensity: "the state of Iowa has an average carbon intensity of 0.352 kg CO $_2$ per kWh" (Section 3.1). This cluster was used for the 13B model.

Note that the PUE for Jupiter is conservatively set to the upper end of the range (1.2), while the Augusta PUE is the measured average (1.12). The carbon intensities are superficially similar (0.332 vs. 0.352), but the paper's water analysis (below) reveals these two regions have very different generation mixes, with Iowa's higher water intensity reflecting different power sources.

Comparison with prior practice. The paper contrasts this approach with the Llama reports: "Llama 1 did not use the data center location's carbon intensity, instead using US national average carbon intensity; Llama 2 did not specify the carbon intensity; Llama 3 used a region-specific carbon intensity. All 3 assumed 100% GPU power draw throughout training" (Section 2, footnote 5). The current paper improves on all three points: it uses location-specific CI, reports the specific values used, and measures rather than assumes power draw.

Operational Water Consumption Calculation

The paper follows Li et al. (2023) to calculate water consumed both on-site (at the data center, for cooling) and off-site (at the power plant, for electricity generation):

$\text{Consumption} = P \cdot \text{PUE} \cdot (\text{WUE}_{\text{onsite}} + \text{WUE}_{\text{offsite}})$

where $P$ is GPU power consumption (kWh), PUE is power usage effectiveness, WUE $_{\text{onsite}}$ is the water usage effectiveness of the data center's cooling system (in liters of water consumed per kWh of IT energy), and WUE $_{\text{offsite}}$ is the water usage effectiveness of the local electricity generation mix (in liters per kWh of grid energy).

What it computes: The total water consumed — meaning water that is evaporated, polluted, or otherwise removed from the local watershed and will not re-enter circulation in the immediate environment — attributable to the electricity used by the GPUs. $P \times \text{PUE}$ gives total grid energy drawn. Multiplying by WUE $_{\text{onsite}}$ gives water consumed at the data center for cooling. Multiplying by WUE $_{\text{offsite}}$ gives water consumed at the power plant during electricity generation (e.g., water evaporated in cooling towers at a thermal power plant, or water lost to evaporation from hydroelectric reservoirs). The sum is total water consumption.

Why this form: The decomposition separates data center water use (which the operator controls through cooling technology choices) from electricity-generation water use (which depends on the regional grid mix and is outside the operator's control). This is structurally analogous to the carbon equation, and it reveals that the location of a data center determines water consumption even more dramatically than it determines carbon emissions, because WUE $_{\text{offsite}}$ varies enormously by generation type. A data center powered by a coal plant has high off-site water use; one powered by wind and solar has near-zero off-site water use. The paper's two clusters illustrate this starkly: Texas (Jupiter) has WUE $_{\text{offsite}}$ = 1.29 L/kWh, while Iowa (Augusta) has WUE $_{\text{offsite}}$ = 3.10 L/kWh — more than double, despite similar carbon intensities.

Data center–specific constants:

Jupiter: Uses a closed-loop cooling system with "no evaporative cooling," so WUE $_{\text{onsite}}$ = 0 L/kWh. WUE $_{\text{offsite}}$ = 1.29 L/kWh, "following Reig et al. (2020)" (Section 3.1).
Augusta: Also closed-loop, so WUE $_{\text{onsite}}$ = 0 L/kWh. WUE $_{\text{offsite}}$ = 3.10 L/kWh, also following Reig et al. (2020).

The fact that both data centers have zero on-site water consumption is notable: the paper's data centers are "extremely water-efficient" (from the abstract) at the cooling level. All reported water consumption is therefore off-site — water consumed at the power plants generating the electricity. This means the water footprint is entirely determined by where the electricity comes from, not by how the data center cools itself. The 2.4× difference in WUE $_{\text{offsite}}$ between Texas and Iowa means that, all else equal, training in Iowa consumes more than twice as much water per kWh as training in Texas.

Definition of "consumption." The paper clarifies the distinction between water withdrawal (water taken from a source) and water consumption (water that is not returned to the source). The key phrase: "thermo- and hydro-electric power plants lead to evaporated water that is lost and will not re-enter circulation in the local environment" (Section 3.1). This is consumption — water permanently removed from the local watershed. This matters because water withdrawal numbers can be much larger but are less environmentally meaningful if most of the water is returned; consumption numbers reflect permanent depletion.

Embodied Impact Estimation

Embodied impacts are those arising from the manufacturing of the physical hardware — primarily GPUs — rather than from the electricity used to operate them. The paper estimates both embodied carbon emissions and embodied water consumption.

General approach. The method follows Luccioni et al. (2023): take the total estimated manufacturing cost (carbon or water) for a GPU, divide by the total operating hours over the GPU's assumed lifetime (4 years), and multiply by the number of GPU hours used for model development and training. This amortizes the one-time manufacturing cost into a per-hour rate:

$\text{Embodied Impact} = \frac{\text{Manufacturing Impact per GPU}}{\text{Lifetime hours}} \times \text{GPU hours used}$

Embodied carbon numbers. The paper states: "NVIDIA does not release the embodied carbon emissions or water consumption about the hardware it produces, so we assume the same embodied carbon emissions as Luccioni et al. (2023), or 3700 kg of CO $_2$ eq per 8x server node, equal 463 kg per GPU" (Section 4.1). This is 3,700 kg CO $_2$ eq per server ÷ 8 GPUs/server = 462.5 kg CO $_2$ eq per H100 GPU.

The assumed GPU lifespan: "Internally, we assume a 4 year lifespan for our GPUs" (Section 4.1). At 24 hours/day × 365 days/year = 8,760 hours/year, a 4-year lifespan equals 35,040 hours. Therefore:

$\text{Embodied carbon per GPU-hour} = \frac{463\text{ kg}}{35{,}040\text{ hours}} \approx 0.0132\text{ kg CO}_2\text{eq/hour}$

The paper reports this as "0.013 kg of CO $_2$ eq per GPU hour" (Section 4.1). With 1.65 million GPU hours used in total, the total embodied carbon is 1,650,000 × 0.013 = 21,450 kg, which the paper rounds to 22 tCO $_2$ eq.

Embodied water numbers. The paper constructs an estimate from multiple external sources. It cites estimates that "TSMC water usage at 12.33 liters per square centimeter of hardware, which equals 100.4 liters per H100" (Section 4.1). Additionally, it estimates water consumption from rare earth metal mining: "assuming an H100 is 0.1% rare earth metal by mass. Mining 1 kg of rare earth materials consumes about 11 kL of water and releases 65.4 kg CO $_2$ eq (Browning et al., 2016), and one 12-inch silicon wafer weighs 125 grams and produces about 63 H100s" (Section 4.1). These add "an additional 2.2 liters consumed and 0.013 kg CO $_2$ eq per GPU."

The total embodied water per GPU is therefore approximately 100.4 + 2.2 = 102.6 L. Amortized over 35,040 hours:

$\text{Embodied water per GPU-hour} = \frac{102.6\text{ L}}{35{,}040\text{ hours}} \approx 0.00293\text{ L/hour}$

The paper reports this as "0.003 liters of water consumed per GPU hour" (Section 4.1). With 1.65 million GPU hours, total embodied water is 1,650,000 × 0.003 = 4,950 L, which the paper rounds to 4.8 kL.

Why amortization over 4 years? The paper does not explicitly justify the 4-year lifespan assumption. It appears to be an internal operational assumption about hardware refresh cycles. The amortization approach has the property that longer assumed lifespans reduce the per-hour embodied cost (spreading the manufacturing impact over more productive hours), while shorter lifespans increase it. If GPUs are replaced more frequently than every 4 years, the per-hour embodied cost would be higher than reported.

Why this form (amortization)? The alternative would be to attribute the full manufacturing cost of every GPU to the first model trained on it, which would be wildly inaccurate if those GPUs are subsequently used for other training runs, inference, or different projects. Amortization acknowledges that the manufacturing impact should be shared across all uses over the hardware's lifetime. However, it introduces uncertainty: the actual lifespan is unknown at purchase time, utilization may not be 100%, and the embodied cost is based on external estimates rather than manufacturer data.

Acknowledged uncertainty. The paper is explicit about the limitations: "the environmental impact of manufacturing the GPUs used is essentially unknown... researchers focused on AI's environmental impact are forced to use unreliable estimates of the cost of manufacturing state-of-the-art computational hardware, and the situation is no better now, nearly two years later" (Section 5.1). The embodied cost numbers should be understood as best-effort estimates given the opacity of the GPU supply chain, not as precise measurements.

Development Cost Accounting

The paper's most distinctive methodological contribution is its accounting for model development costs — the computational experiments that precede and enable the final training run, captured by the $H$ term in the Schwartz et al. (2020) cost equation (Equation 1).

What counts as development. The paper defines development as: "a series of controlled experiments to stabilize and improve our training setup, to explore different parameter initializations and mid-training recipes, and to determine our final hyperparameters and data mixtures through scaling law experiments (Bhagia et al., 2024)" (Section 4.1). This includes failed runs, hyperparameter sweeps, architecture ablation experiments, and scaling law experiments where smaller models are trained to predict the performance of larger models. The paper acknowledges that in scaling law experiments, models "are trained... and then discarded" (Section 5.1), a practice documented in detail by Bhagia et al. (2024).

Grouping strategy. Development runs are "run in five distinct groups: small models with less than 1 billion parameters, 1 billion parameter models, 7 billion parameter models, 13 billion parameter models, and our mixture-of-experts model" (Section 4.1). This grouping is reflected in Table 1, which reports GPU hours, total MWh, number of runs, carbon emissions, and water consumption for each group. The grouping by model size class is natural because development work typically scales with the target model size: experiments at the 7B scale are more expensive per run than experiments at the sub-1B scale.

Scale of development relative to final training. Table 1 reports 680,000 GPU hours for development across 813 individual runs, compared to the final training run totals in Table 2. The paper states that "model development... amounted to ~50% of that of training" in carbon emissions (from the abstract). Specifically: total development emissions are 159 tCO $_2$ eq (Table 1) vs. final training emissions of 312 tCO $_2$ eq (Table 2), giving a ratio of 159/312 = 0.51. For water consumption: 843 kL development vs. 1,921 kL final training, ratio = 0.44. The ~50% figure varies by metric and by model size, but the headline finding is that development is not a negligible rounding error — it is a substantial fraction of the total.

Why development costs matter. The paper argues that reporting only final training runs is misleading because it ignores the cost of arriving at the final configuration. This is analogous to reporting only the cost of printing a book while ignoring the years of research, drafting, and editing. The authors frame this in terms of the Schwartz et al. (2020) equation: "In previous work, $E \cdot D$ , the cost of training on the training dataset, is what is most commonly reported, and $H$ , the total number of experiments, is most often excluded" (Section 3.1). This paper is, "to the best of our knowledge... the first to report this information for model development of large language models" (Section 1).

Connection to AutoML and scaling laws. The paper notes that this transparency is "especially important in light of AutoML tools, where many models may be automatically trained while searching for a solution, and scaling law experiments, where smaller models are trained to predict the performance of larger models, and then discarded" (Section 5.1). These practices amplify the $H$ factor — automated search can run hundreds or thousands of experiments with minimal human intervention, and scaling law experiments intentionally train models that will never be deployed. Without disclosure, the environmental cost of these practices is invisible.

Measurement methodology for development runs. The same sub-second power logging used for final training runs is applied to development runs. The paper does not describe any difference in measurement protocol between development and final training — the power measurement infrastructure is presumably always active. This means the development cost numbers benefit from the same measurement fidelity as the final training numbers (sub-second GPU power, per-node extrapolation) and are not based on cruder estimates.

Final Training Run Accounting

Final training runs are the successful model training runs that produce released or internally used models. Their accounting follows the same operational impact formulas as development, but the runs are reported individually in Table 2 rather than grouped by size class.

Models covered. Table 2 lists 17 distinct training runs spanning dense models from 20M to 13B parameters (trained on 1.7T to 5.6T tokens) and one mixture-of-experts model (1B active, 7B total parameters, trained on 5T tokens). The runs include released models (OLMo 7B, OLMo 2 7B, OLMo 2 13B, OLMoE 0924), internally used models (20M, 60M, 150M, 300M, 700M, 1B, 7B), and models trained on different infrastructure (the original OLMo 7B trained on LUMI, which runs entirely on hydroelectric power and therefore has zero operational carbon emissions).

What is reported per run. For each training run, Table 2 reports: power usage in MWh, carbon emissions in tCO $_2$ eq, water consumption in kL, and human-scale equivalents (e.g., "equivalent to 21 years of electricity use by the average household in the U.S."). The human-scale equivalents use the U.S. Environmental Protection Agency's Greenhouse Gas Equivalencies Calculator for carbon and EPA water consumption statistics for water.

Total final training impact. Summing across all runs (excluding the zero-carbon LUMI run): 913 MWh of power, 312 tCO $_2$ eq emitted, and 1,921 kL of water consumed. The paper contextualizes this as "equivalent carbon to over 65 years of electricity use by the average household in the U.S., and consumed equivalent water to the average person in the U.S. for about 17 years" (Table 2 caption).

Data center variation in final training. The 13B model was trained on a different cluster (Augusta in Iowa) than all other models (Jupiter in Texas). The per-MWh water consumption is substantially higher at Augusta: WUE $_{\text{offsite}}$ of 3.10 vs. 1.29 L/kWh. The paper does not call this out as a separate analysis, but the data in Table 2 bears this out: the OLMo 2 13B model consumed 230 MWh and 892 kL of water, a ratio of 3.88 L/kWh (which is PUE × total WUE = 1.12 × 3.10 = 3.47, with the difference explained by the PUE multiplier). Compare the OLMo 2 7B on Jupiter: 157 MWh and 202 kL, a ratio of 1.29 L/kWh (matching the Jupiter total WUE × PUE = 1.2 × 1.29 = 1.55, with the difference possibly due to rounding or minor variations). The 13B uses 2.4× as much water per MWh as the 7B, purely because of where it was trained.

Inference Simulation Methodology

The paper does not deploy its models to real users and therefore cannot measure actual inference costs. Instead, it simulates representative deployment scenarios and measures the resource consumption of those simulations.

Serving infrastructure. Models are "served on a single H100 GPU via SGLang (Zheng et al., 2024)" (Section 3.4). SGLang is an inference serving framework designed for efficient LLM deployment. A single GPU is used rather than a multi-GPU deployment; this limits the batch sizes achievable but reflects a realistic deployment configuration for smaller models.

Dataset. The requests come from "the ShareGPT dataset, and each inference scenario involves the same sample of 2400 prompts (same random seed)" (Section 3.4). ShareGPT is a dataset of real user interactions with ChatGPT, consisting of multi-turn conversations. The paper reports that due to tokenization differences across models, there are "slight variations in mean input/output lengths across models, 225-250 and 190-230 tokens respectively" (Section 3.4). These variations mean that different models process slightly different amounts of text on the same prompts, which introduces a small amount of noise into the comparison.

Three request-rate scenarios. The paper tests three request arrival patterns, described in Table 3 and Table 4:

Infinite request frequency (∞ req/s): All 2400 requests are sent instantaneously, saturating the GPU. This represents a "batching" scenario where the server is fully utilized and processes requests as fast as possible. This yields the lowest energy per request because the GPU operates at high utilization.
8 requests per second: A moderate rate following a Poisson distribution. This represents a moderately loaded server where some batching occurs but the GPU is not fully saturated.
1 request per second: A low rate, also Poisson-distributed. This represents a lightly loaded server where most requests are processed individually with minimal batching. This yields the highest energy per request because the GPU spends more time idle or at low utilization between requests.

The paper notes that all three can be "mapped to a previously proposed realistic online inference scenario (Reddi et al., 2020; Peng et al., 2023)" (Section 3.4).

Measurement tool and scope. Inference energy is measured using "CodeCarbon (Courty et al., 2024) tracking, which was verified against the same time series monitoring used throughout training" (Section 3.4). CodeCarbon measures process-level power consumption. Critically, the measurement "exclud[es] the overhead associated with, for example, holding the model in memory or listening for requests" (Section 3.4). This means only the active computation during inference is counted; the idle power of the GPU while waiting for requests is excluded. The paper acknowledges this makes the numbers "lower bounds on usage in similar settings" (Table 3 caption).

Break-even calculation. For each model and request-rate scenario, the paper computes "break-even" points — the number of inference queries required for cumulative inference carbon emissions to equal the total carbon emissions from training that model. This is computed as:

$N_{\text{break-even}} = \frac{\text{Total training CO}_2 e}{\text{CO}_2 e \text{ per inference query}}$

The paper reports these as the "# Inf. for CO $_2$ equiv. w/ training" column in Table 3. For example, OLMo 2 7B at ∞ req/s requires 20.9 billion inferences to match training emissions; at 1 req/s, it requires only 1.05 billion inferences. The variation by request rate is substantial — at lower request rates (worse batching), the per-query energy is higher, so fewer total queries are needed to reach the break-even point.

Why simulate rather than report deployment data? The paper states: "Because we do not deploy our models, we do not collect or report data about real usage of our models. We instead report estimated costs associated with deployment of a subset of our models, along with comparison models, with varying inference configurations" (Section 3.4). The simulation approach is a necessary compromise for models that are released as open-source artifacts but not operated as services by their creators. However, it means the inference numbers represent a hypothetical — what the cost would be if the models were used in certain ways — rather than an accounting of actual usage.

Models compared. The inference simulations include OLMo models (OLMo 1 1B, OLMo 2 7B, OLMo 2 13B, OLMoE 0924) and comparison models from other developers (Llama 3.2 1B, Llama 3.1 8B, Llama 2 13B, Qwen 2.5 7B, and others in Table 4). For comparison models, break-even points are calculated using publicly reported training emissions where available (from the Llama and Gemma technical reports). For Qwen models, break-even points are not reported because "training costs are not public" (Table 4 caption), which itself is an implicit argument about transparency.

What is NOT simulated. The paper explicitly notes that it does not account for: "different inference-time optimizations such as quantization; perform generation with different decoding algorithms; and/or deploy to and run inference on edge devices, sometimes even without GPUs" (Appendix A.2). The simulation scope is limited to SGLang serving on H100 GPUs with default generation parameters, which represents one point in a large space of possible deployment configurations.

Translating Environmental Numbers to Human-Scale Equivalents

Throughout Sections 4.1 and 4.2, the paper converts its carbon and water numbers into human-scale equivalents to make the magnitudes interpretable. The conversion factors are drawn from U.S. government sources.

Carbon equivalents. The paper uses the "U.S. Environmental Protection Agency's Greenhouse Gas Equivalencies Calculator" (Section 4.1, footnote 15). The equivalents used include:

Tanker trucks of gasoline burned (6.5 tanker trucks for 493 tCO $_2$ eq)
Homes' electricity use for one year (98.2 homes for 493 tCO $_2$ eq)
Carbon sequestered by U.S. forests in one year (472 acres for 493 tCO $_2$ eq)

In Table 2, per-model equivalents are given in terms of "energy usage, 1 home, U.S." — essentially, how many years of household electricity the training run's emissions are equivalent to.

Water equivalents. The paper uses "EPA WaterSense statistics" (Section 4.1, footnote 16) for per-person water consumption in the United States. The equivalents used include:

"about 24 and a half years of water consumption by the average person in the U.S." for the total 2,769 kL
Per-model equivalents in Table 2: "water usage, 1 person, U.S." expressed in years and months

The paper also provides equivalents for development costs: "the total impact was emissions equivalent to 2.1 tanker trucks' worth of gasoline, and equal to about 7 and a half years of water used by the average person in the United States" (Table 1 caption).

Why human-scale equivalents? These conversions serve a communicative purpose: 493 metric tons of CO $_2$ may not be intuitively meaningful to most readers, but "powering 98 homes for a year" or "6.5 tanker trucks of gasoline" provides an accessible scale reference. The paper uses these consistently alongside the raw numbers, making it possible for both technical and non-technical audiences to understand the magnitude of the impacts.

Summary of Design Choices and Justifications

Sub-second GPU power logging rather than theoretical maximum assumptions: Measures actual power, captures fluctuations, and provides a lower bound that developers can use for planning. The trade-off is that non-GPU power is unmeasured, making the numbers conservative.
Location-specific PUE, CI, and WUE rather than national averages: Reveals geographic variation in environmental impact and follows best practices from Dodge et al. (2022). The cost is that numbers are not directly portable to other data centers without recalculating with local factors.
Amortized embodied impacts over 4-year GPU lifespan: Follows Luccioni et al. (2023) and provides per-hour rates that can be applied to any workload. The uncertainty in manufacturing data and lifespan assumptions is acknowledged but unresolved.
Development cost grouping by model size class: Provides a natural partitioning that makes the scale of development work visible and highlights that most cost comes from the largest model scales.
Inference simulation using SGLang with three request rates: Covers a range of realistic deployment scenarios from fully saturated to lightly loaded. The limitation to one GPU, one framework, and one dataset means the numbers are not comprehensive but provide order-of-magnitude guidance.
Process-scoped (not system-scoped) inference measurement: Captures only active computation, not idle overhead. This is a deliberate scope choice that makes per-query numbers lower but more directly attributable to the act of running inference.
Break-even analysis connecting inference to training: Provides a metric for understanding when deployment costs overtake training costs — a question of practical importance for model deployers that prior work did not systematically address.

4. Key Insights and Innovations

Innovation 1: Model Development Is Not a Rounding Error — It's ~50% of the Environmental Cost, and Nobody Reports It

The paper's most distinctive conceptual contribution is empirical rather than methodological: it is the first to measure and publicly report the environmental cost of model development for large language models — all the hyperparameter tuning, architecture experiments, scaling law runs, and failed attempts that precede the final, successful training run — and to demonstrate that this cost is approximately half of the final training cost, not a negligible overhead.

What was assumed before. The field's environmental reporting practice, to the extent it existed at all, treated the final training run as the relevant unit of accounting. The Schwartz et al. (2020) cost equation formalized this as Cost(R) ∝ E · D · H, but prior work almost exclusively reported E · D (the cost of training on the dataset) while H (the number of hyperparameter experiments) was "most often excluded" (Section 3.1). The implicit assumption was that H was small relative to the main run, or at least not worth the effort to measure. Even the most comprehensive prior report, Luccioni et al. (2023) for BLOOM, did not break out development costs separately.

What this paper shows. Table 1 reports 680,000 GPU hours across 813 individual development runs, producing 159 tCO₂eq in emissions and 843 kL of water consumption. Against the final training total of 312 tCO₂eq and 1,921 kL (Table 2), development represents 51% of the carbon and 44% of the water. The abstract states this plainly: "model development, the impact of which is generally not disclosed by most model developers, amounted to ~50% of that of training." The ~70% of development cost concentrated at the 7B and 13B scales (Table 1) reveals that development cost scales with the ambition of the model being developed, not uniformly across all projects.

Why this is a conceptual shift, not just a bigger number. This finding transforms H from an ignorable factor into a first-order term in the environmental cost equation. For any organization building LLMs, ignoring development costs means understating total environmental impact by roughly a factor of 1.5×. The paper is careful to frame this as a lower bound — the authors' measurement captures only GPU power, excludes CPU, RAM, networking, and cooling overhead, and covers only the experiments that were actually run, not the ones that were considered and discarded at an even earlier stage. The true ratio of development to final training could be higher.

The finding has direct implications for how the field evaluates methodological choices. Practices like AutoML (automated hyperparameter search) and scaling law experiments (where smaller models are trained solely to predict larger model performance and then discarded) amplify H without producing deployable artifacts. The paper explicitly flags this: "This is especially important in light of AutoML tools, where many models may be automatically trained while searching for a solution, and scaling law experiments, where smaller models are trained to predict the performance of larger models, and then discarded" (Section 5.1). If the environmental cost of these exploratory runs is never reported, there is no pressure to make them more efficient or to weigh their value against their impact.

This is fundamentally a transparency innovation, not a technical one. The paper does not propose a new method for reducing development costs; it demonstrates that the costs exist, quantifies their magnitude relative to what is typically reported, and argues that the status quo of non-disclosure is misleading. The fact that even a small (13B parameter) model series trained by a research non-profit generates nontrivial development costs implies that the development costs of massive proprietary models — with their likely much larger H — are proportionally enormous and entirely hidden from public view.

Innovation 2: Water Consumption Is a First-Class Environmental Metric for AI, and Geographic Variation in Power Generation Mix Dramatically Magnifies the Impact

Prior work on AI's environmental impact focused overwhelmingly on carbon emissions. The extension to water consumption — following the methodology of Li et al. (2023) — is not itself novel. What is novel is the paper's demonstration, grounded in its own infrastructure data, that water consumption varies dramatically with the location of the data center even when carbon intensity is similar, and that even "extremely water-efficient" data centers (the paper's own, with zero on-site evaporative cooling) have substantial water footprints driven entirely by off-site electricity generation.

What was assumed before. Water consumption was essentially absent from AI environmental reporting. The Llama reports (Touvron et al., 2023a;b; Dubey et al., 2024) did not estimate it. The Gemma report (Gemma Team et al., 2024) did not estimate it. Luccioni et al. (2023) for BLOOM did not estimate it. External estimates existed for some closed models (Li et al., 2023) but were "based on speculation about location of training, energy consumption, etc." (Section 2). The implicit signal was that water was either unimportant, too hard to measure, or both.

What this paper shows. The paper reports that its series of models consumed 2,769 kL of water — "equivalent to about 24 and a half years of water consumption by the average person in the U.S." (Section 4.1). But the more analytically revealing finding is the geographic variation: the Jupiter cluster in Texas has WUE_offsite = 1.29 L/kWh, while the Augusta cluster in Iowa has WUE_offsite = 3.10 L/kWh — a 2.4× difference. This is visible in the per-model data: OLMo 2 7B (Jupiter) consumed 202 kL of water for 157 MWh, while OLMo 2 13B (Augusta) consumed 892 kL for 230 MWh. The 13B used only 1.47× as much energy as the 7B but 4.4× as much water, because the water intensity per kWh at Augusta is more than double that at Jupiter.

Why this matters conceptually. This finding decouples carbon and water as environmental metrics. The carbon intensities of the two locations are similar (0.332 vs. 0.352 kg CO₂/kWh), which might lead a developer to treat them as roughly equivalent. But the water intensities differ by a factor of 2.4, revealing that carbon and water are driven by different aspects of the generation mix — carbon by the presence of fossil fuels, water by the presence of thermal and hydroelectric generation (both of which consume water through evaporation). A grid with substantial wind and solar might have low carbon and low water intensity; a grid with nuclear (low carbon, high water for cooling) might decouple the two.

This has direct policy and decision-making implications. If a developer optimizes solely for carbon — choosing a data center location based on carbon intensity — they might inadvertently choose a location with high water intensity, shifting environmental harm from the atmosphere to the watershed. The paper's own data illustrates this: if the 13B model had been trained on Jupiter instead of Augusta, its water consumption would have been roughly 230 MWh × 1.2 (PUE) × 1.29 L/kWh ≈ 356 kL instead of 892 kL, a reduction of ~60%. The paper does not make this counterfactual calculation explicitly, but the data is there.

The paper also establishes that on-site water efficiency (closed-loop cooling, WUE_onsite = 0) does not eliminate water impact — it merely shifts it entirely off-site to the power plant. The abstract's phrase "even though our data center is extremely water-efficient" is doing careful work here: it preempts the argument that efficient cooling solves the water problem. It does not. The water is consumed at the power plant, not at the data center, and the only way to reduce it is to change where the electricity comes from or how much electricity is used.

Innovation 3: Power Consumption During Training Is Not Steady — It Fluctuates Wildly, and This Is a Distinct Grid-Scale Problem

The standard assumption in prior environmental reporting for AI was that GPUs operate at their theoretical maximum power draw (typically 700W for H100s) throughout training. The Llama reports all assumed 100% power draw (Section 2), and this assumption propagates through to carbon and energy estimates. The paper's sub-second power monitoring reveals that this assumption is wrong in two important ways: (1) actual power draw during active training is ~85% of maximum, not 100%, and (2) power draw regularly plummets to ~15% of maximum during checkpoint saves, creating rapid, large-amplitude fluctuations.

What was assumed before. The field treated training power consumption as essentially constant — a steady-state draw that could be multiplied by training duration to get total energy. The Llama reports, as the paper notes, "assumed 100% GPU power draw throughout training" (Section 2, footnote 5). This assumption is convenient because it requires no measurement infrastructure and produces conservative (over-)estimates of total energy, which might seem like the responsible choice. But it completely obscures the temporal pattern of power consumption.

What this paper shows. Figure 2 (Section 4.3) displays the power time series for a single node during OLMo 2 7B training. The pattern is stark: power sits above 600W (~85% of the 700W maximum) during active training, then drops to just over 100W (~15%) during each checkpoint save, then spikes back up. The paper reports that these drops happen frequently enough to cause "thousands of rapid power fluctuations" over a full training run (Section 5.2). The implication is that training is not a steady load but an intermittently heavy one, switching between high and low power states on the timescale of minutes.

Why this matters conceptually — it's a different kind of environmental problem. Constant high power draw is an energy problem: you need a lot of kilowatt-hours. Fluctuating power draw is a grid stability problem: you need generation that can ramp up and down quickly to match the varying demand. The paper connects this to power grid operations: "When demand sharply rises, generation sources that can be quickly started and stopped — generally powered by fossil fuels, such as coal and natural gas — must be brought online quickly, increasing the marginal carbon intensity of the grid and potentially negatively impacting other consumers... When demand sharply drops, excess power is discarded — by grounding the power or venting steam — until generation sources can spin down" (Section 4.3).

This reframes the problem from "how much energy does AI use?" to "what pattern of energy use does AI impose on the grid, and can the grid handle it?" Even if total energy consumption were held constant, fluctuating demand is worse for grid operators than steady demand, because it forces reliance on peaker plants (typically fossil-fueled) and can cause instability. The paper cites Dubey et al. (2024) documenting that even Meta "encounter difficulties from regularly shifting power demand throughout training due to checkpointing, awaiting collective communications, and other unforeseen and potentially catastrophic failures" (Section 5.2). This is not a niche concern specific to the authors' infrastructure — it is a recognized problem at the largest scales of training.

The paper frames this as a challenge that "breaks common assumptions about data center supply and demand, leading to significant control challenges in power systems" (Section 5.2). The solutions it suggests — "parallelized checkpointing, improved demand response in data centers running large AI workloads, and new, heterogeneous methods for distributed training spanning software, hardware, and scheduling" — point toward an engineering agenda that treats power consumption not just as a quantity to be minimized but as a signal to be shaped and smoothed. This is a fundamentally different framing from the total-energy-minimization approach that dominates green AI discourse.

Innovation 4: The Cost of Training vs. Inference Is a False Dichotomy — Break-Even Analysis Reveals That Efficient Deployment Can Paradoxically Increase Total Impact

The paper introduces a simple but previously unarticulated metric: the break-even point at which cumulative inference emissions equal total training emissions. This is computed straightforwardly as (total training CO₂e) ÷ (CO₂e per inference query). While mathematically trivial, the framing this metric enables is conceptually significant: it connects the two stages of the ML lifecycle that are typically analyzed in isolation and reveals a Jevons Paradox dynamic where making inference cheaper per query can lead to greater total environmental impact if usage volume increases enough.

What was assumed before. Training and inference were generally analyzed separately. Papers on training efficiency (Hoffmann et al., 2022; Kaplan et al., 2020) focused on minimizing training compute. Papers on inference efficiency (e.g., Luccioni et al., 2024) focused on per-query energy. Developers of "deployment-optimized" models (Gemma, Llama 3.2, Phi-3) emphasized lower inference cost as an unqualified environmental good. The implicit assumption was that efficient inference reduces total impact.

What this paper shows. Table 3 reports break-even points ranging from hundreds of millions to hundreds of billions of queries, depending on the model and the request rate. For OLMo 2 7B at saturated throughput (∞ req/s), the break-even is 20.9 billion queries; at the low-utilization scenario (1 req/s), it drops to 1.05 billion — a 20× difference driven entirely by worse batching efficiency at low request rates. For the heavily over-trained Llama 3.2 1B, the break-even at 1 req/s is 4.83 billion queries; for Llama 2 13B at 1 req/s, it is only 1.13 billion. The pattern is that models with higher training cost relative to inference efficiency (like Llama 2 13B) reach break-even faster than models that were cheap to train but are also efficient at inference.

The paper contextualizes these numbers against real-world usage: "The largest model providers are producing up to hundreds of billions of tokens per day... deployed models can quickly reach this tipping point" (Section 4.2). If OpenAI's models are generating hundreds of billions of tokens daily across 400 million users, the break-even point for training — numbers in the billions of queries — might be reached in "weeks to months" (Section 1). This means that for widely deployed models, inference likely dominates total lifetime environmental impact, making the training-centric focus of most environmental reporting systematically misleading.

Why this is a conceptual reframing, not just a metric. The break-even analysis reveals that "efficient deployment" is not inherently environmentally beneficial. It lowers the per-query cost, which — following Jevons' Paradox — can increase total usage enough to raise total impact. The paper makes this explicit in Section 5.2: "as the cost of training models decreases, the downstream impact may continue to grow." A model like Gemma 2B, designed to be cheap to run, might be deployed in billions of devices and accumulate far more total inference emissions than a larger model that is used more sparingly. The break-even metric makes this tradeoff visible and quantifiable.

The paper also reveals that inference efficiency is highly sensitive to operational factors — request batching, in particular — that are outside the model developer's control. The same model can have a 20× difference in per-query energy depending on whether the serving infrastructure batches requests efficiently or processes them one at a time. This distributes responsibility for environmental impact across the entire deployment pipeline: model architecture, serving framework, request scheduling, and usage patterns all matter. The developer who trains an efficient model has not necessarily reduced total environmental impact if the deployer runs it in a low-utilization configuration.

This innovation is fundamentally about connecting two conversations that had been proceeding in parallel — training efficiency and inference efficiency — and showing that the connection point (the break-even) has practical implications for how model developers should think about the environmental consequences of their design choices. Over-training a small model to make it inference-efficient might be environmentally rational if the model is deployed at massive scale, but it increases training cost and may never "pay back" if the model sees only modest usage. The break-even metric provides a framework for reasoning about that tradeoff rather than treating training and inference efficiency as independent virtues.

5. Experimental Analysis

Evaluation Methodology

Dataset. The paper uses two primary data sources for different purposes. For training and development impact measurement, the dataset is the OLMo training corpus—a mixture of web text, academic papers, code, and books—with models trained on token counts ranging from 1.7 trillion (sub-billion-parameter models) to 5.6 trillion tokens (the 13B model). For inference simulation, the paper uses the ShareGPT dataset (anon8231489123/ShareGPT_Vicuna_unfiltered), a collection of real user interactions with ChatGPT consisting of multi-turn conversations; a fixed sample of 2,400 prompts is used across all experiments with the same random seed, yielding mean input lengths of 225–250 tokens and mean output lengths of 190–230 tokens depending on model tokenization.
Base model(s). The paper evaluates the OLMo series of transformer language models (Groeneveld et al., 2024; OLMo et al., 2025): dense models ranging from 20M to 13B active parameters, plus one mixture-of-experts model (OLMoE 0924) with 1B active and 7B total parameters. All models share an architecture similar to Llama and are trained on standard HGX servers with 8 NVIDIA H100 GPUs per server, with 2 to 128 nodes used concurrently per training run. The authors chose this model family because they are the developers and therefore have full access to the infrastructure data (power measurements, GPU-hour logs, data center specifications) necessary for comprehensive environmental accounting—access that external researchers lack for proprietary models.
Metrics. The paper reports four primary metrics across all lifecycle stages: (1) Power consumption (MWh or kWh), measured at sub-second intervals on GPUs and extrapolated to full cluster size; (2) Carbon emissions (tCO₂eq or g CO₂eq), computed from power consumption via Equation (2) using data center–specific PUE and carbon intensity; (3) Water consumption (kL or L), computed via Equation (3) using on-site and off-site water usage effectiveness factors; (4) GPU hours, the total number of GPU-hours consumed, used both as a raw compute metric and as the basis for amortizing embodied impacts. For inference simulations, an additional metric is the break-even point—the number of inference queries required for cumulative inference emissions to equal total training emissions, computed as total training CO₂e divided by per-query CO₂e.
Baselines. The paper compares its OLMo models against several external models in the inference simulations (Tables 3 and 4, Section 4.2): Llama 3.2 1B, Llama 3.1 8B, Llama 2 7B, Llama 2 13B (Touvron et al., 2023a;b; Dubey et al., 2024), and Qwen 2.5 models at 1.5B, 7B, and 14B parameters, plus Qwen 1.5 MoE. For these comparison models, the paper uses publicly reported training emissions (from Llama and Gemma technical reports) to compute break-even points. The paper also implicitly baselines its reporting thoroughness against prior disclosure practices: Llama models (which reported only final training electricity and carbon, used varying carbon intensity methodologies, and assumed 100% GPU power draw), Gemma models (which reported only a single aggregate emissions number), and BLOOM (Luccioni et al., 2023, which reported embodied and operational emissions but not development costs or water consumption).
Generation budget / compute accounting. The paper does not use a "generation budget" in the sense of allocating test-time compute, since this is not a model performance paper. Instead, compute is accounted in two ways: (1) For development and training, the unit is GPU hours and MWh, measured via sub-second power logging on one node per run and extrapolated to the full cluster size based on the number of nodes used. (2) For inference, compute is accounted via energy consumption per 2,400-request benchmark, measured with CodeCarbon at the process level (excluding idle overhead), and the results are normalized per-query to compute break-even points. For both, the paper uses data center–specific PUE factors to scale GPU-only measurements to total grid energy draw.
Cross-validation / statistical protocol. The paper does not employ cross-validation or statistical significance testing—this is appropriate because it is an environmental accounting paper, not a machine learning performance evaluation. There is no model accuracy to validate, no hyperparameter to tune, and no distribution to sample. The measurements are deterministic physical quantities: power consumed by specific hardware over specific time intervals. The primary source of uncertainty is not sampling variance but systematic measurement error, particularly: (1) the extrapolation from single-node power measurements to the full cluster, which assumes homogeneous power consumption across all nodes; (2) the exclusion of non-GPU power (CPU, RAM, networking, storage), acknowledged as making the numbers "a lower bound"; (3) the embodied impact estimates, which rely on external data of unknown accuracy rather than manufacturer disclosures. The paper reports exact figures as measured or estimated without confidence intervals, which is standard for this type of accounting but means the reader should treat all numbers as best-effort point estimates rather than statistically bounded ranges.

Main Quantitative Results

Development Costs vs. Final Training Costs (Tables 1 and 2)

The headline finding is that model development—all hyperparameter tuning, architecture experiments, scaling law runs, and failed attempts preceding the final training runs—accounted for 159 tCO₂eq in carbon emissions and 843 kL in water consumption, representing approximately 51% and 44% of the final training totals respectively (Table 1 vs. Table 2 totals).

Development cost distribution by model scale (Table 1). The 680,000 GPU hours of development work across 813 individual runs were heavily concentrated at larger model scales. The 7B-parameter development group consumed 269,000 GPU hours (196 MWh, 65 tCO₂eq, 252 kL of water) and the 13B group consumed 191,000 GPU hours (116 MWh, 46 tCO₂eq, 402 kL of water). Together, these two groups accounted for approximately 68% of total development GPU hours (460,000 out of 680,000) and approximately 70% of total development emissions (111 out of 159 tCO₂eq). In contrast, the sub-1B group consumed only 29,000 GPU hours (19 MWh, 6 tCO₂eq, 24 kL) and the MoE group consumed 27,000 GPU hours (19 MWh, 6 tCO₂eq, 24 kL). The 1B group's numbers are not broken out separately in Table 1 but are implied by subtraction: the total is 680,000 GPU hours, and the other four groups sum to 516,000 (29k + 269k + 191k + 27k), leaving approximately 164,000 GPU hours for the 1B group. The paper does not provide this breakdown explicitly, so the distribution across groups cannot be fully verified from the table.

The number of individual runs per group tells a story about development strategy: the 7B group saw 375 runs—nearly half of all development experiments—while the 13B group had only 156 runs. This suggests that the 7B scale was the primary development workhorse, with more experiments run at this scale to stabilize and optimize the training pipeline before scaling to 13B. The 375 runs at 7B consumed an average of 717 GPU hours per run (269,000 ÷ 375), while the 156 runs at 13B consumed an average of 1,224 GPU hours per run (191,000 ÷ 156), reflecting the higher per-run cost at the larger scale.

Final training run totals (Table 2). Across 17 distinct training runs, the final training phase consumed 913 MWh of total power, emitted 312 tCO₂eq, and consumed 1,921 kL of water. Excluding the OLMo 7B trained on LUMI (which had zero operational carbon emissions due to hydroelectric power), the remaining 16 runs show a clear relationship between model size, training tokens, and environmental impact. The smallest models (20M–700M parameters, all trained on ~1.7T tokens) collectively consumed only 16.6 MWh and emitted 6.7 tCO₂eq—about 2% of the total. The 7B models dominate: OLMo 7B (Twin) at 114 MWh / 70 tCO₂eq, OLMo 0724 7B at 95 MWh / 32 tCO₂eq, and OLMo 2 7B at 157 MWh / 52 tCO₂eq—together accounting for roughly 40% of total training energy. The OLMo 2 13B at 230 MWh / 101 tCO₂eq / 892 kL is the single largest training run by all metrics except carbon (the 101 tCO₂eq is higher than any single 7B run but not dramatically so; the water consumption of 892 kL, however, is more than 4× the 202 kL of the OLMo 2 7B, reflecting the higher water intensity of the Iowa grid).

Training efficiency across model architectures. The data in Table 2 enables comparison between a dense 1B model and a mixture-of-experts model with equivalent active parameters. The OLMo 1B (3T tokens) consumed 30 MWh, while the OLMoE 0924 (1B active, 7B total, 5T tokens) consumed 54 MWh. On a per-trillion-token basis, the dense 1B used 10 MWh per trillion tokens (30 MWh ÷ 3T), while the MoE used 10.8 MWh per trillion tokens (54 MWh ÷ 5T), making the MoE slightly less energy-efficient per token despite having the same number of active parameters. The paper attributes this to "the extra compute required for routing tokens" (Section 4.1). However, the MoE model was trained on 2 trillion more tokens than the dense 1B, making its total energy consumption higher despite the similar per-token efficiency.

Comparison with publicly reported numbers for external models (Table 2 rows). The paper includes training emissions for several external models as points of reference. Gemma 2B and 9B together emitted 131 tCO₂eq (approximately 42% of the OLMo series total of 312 tCO₂eq for final training). Llama 2 7B and 13B emitted 31 tCO₂eq and 62 tCO₂eq respectively, substantially lower per-model than OLMo models at similar scales (e.g., OLMo 2 7B at 52 tCO₂eq vs. Llama 2 7B at 31 tCO₂eq). Llama 3.1 8B at 420 tCO₂eq and Llama 3.2 1B at 107 tCO₂eq are substantially higher than their Llama 2 counterparts, likely reflecting the much larger training datasets (15T tokens for Llama 3 vs. 2T for Llama 2). The paper does not analyze or explain these differences in detail—the external numbers are presented as context without normalization for dataset size, architecture, or data center location, making direct comparison difficult. The key purpose of including them is to establish that the OLMo series' impact, while substantial, is within the range of what other developers report (and to implicitly highlight that many models report nothing at all, as noted in Section 2).

Total Lifecycle Impact (Hardware + Development + Training)

The paper aggregates embodied impacts (hardware manufacturing), development costs, and final training costs to produce total lifecycle figures (Section 4.1, "Putting it in perspective").

Embodied impact totals. Using the amortized per-GPU-hour rates of 0.013 kg CO₂eq and 0.003 L of water (Section 3.2 and 4.1), and 1.65 million total GPU hours (680,000 development + approximately 970,000 for final training, based on Table 2 runs), the total embodied impacts are 22 tCO₂eq and 4.8 kL of water. These figures are the smallest component of the total—embodied carbon is approximately 4.5% of total lifecycle carbon (22 out of 493 tCO₂eq), and embodied water is approximately 0.2% of total lifecycle water (4.8 out of 2,769 kL). This does NOT mean hardware manufacturing is environmentally benign; it reflects the amortization assumption—the full manufacturing cost of the GPUs is spread across four years of use, and only a fraction is attributed to these specific models. If the GPUs were exclusively dedicated to this project and then retired, the full manufacturing cost would be attributable, and the numbers would be substantially larger.

Total lifecycle figures. Summing embodied (22 tCO₂eq, 4.8 kL), development (159 tCO₂eq, 843 kL), and final training (312 tCO₂eq, 1,921 kL) yields 493 tCO₂eq and approximately 2,769 kL of water. The paper contextualizes these using EPA equivalencies: the carbon is equivalent to 6.5 tanker trucks of gasoline burned, 98.2 U.S. homes' annual electricity use, or the annual carbon sequestration of 472 acres of U.S. forest. The water is equivalent to approximately 24.5 years of water consumption by the average person in the United States. Dividing 2,769 kL by 24.5 years gives approximately 113 kL per person-year, which is consistent with the EPA's reported average of roughly 300 gallons (1,136 L) per person per day for indoor home use, though the exact conversion factor is not specified.

What is excluded. The paper explicitly acknowledges that "there remain a number of sources of emissions and water consumption that are difficult, if not impossible to comprehensively measure without access to proprietary information across a range of industries, such as transportation and end of life hardware disposal" (Section 4.1). This means the 493 tCO₂eq and 2,769 kL figures are lower bounds even within their own scope, excluding: CPU/RAM/networking/storage power (GPU power only), data center construction embodied impacts, hardware transportation, and end-of-life disposal. The paper does not attempt to quantify the magnitude of these exclusions.

Inference Simulation Results (Tables 3 and 4, Section 4.2)

The inference simulation results serve two purposes: (1) to provide per-query energy, carbon, and water estimates for the OLMo models under realistic serving conditions, and (2) to compute break-even points that connect deployment costs back to training costs.

Energy and resource costs per 2,400-request benchmark (Table 3, select models). The measurements reveal that inference cost is highly sensitive to request rate due to batching efficiency. For OLMo 2 7B:

At infinite request frequency (fully saturated GPU, requests sent instantaneously): 0.018 kWh total GPU power consumed, 6.0 g CO₂eq emitted, 0.027 L of water consumed. Time to complete 100 requests: 3.68 seconds.
At 8 requests/second: 0.049 kWh, 16.3 g CO₂eq, 0.073 L. Time per 100 requests: 12.88 seconds.
At 1 request/second: 0.358 kWh, 118.9 g CO₂eq, 0.533 L. Time per 100 requests: 100.54 seconds.

The per-query energy consumption at 1 req/s is approximately 20× higher than at infinite request frequency (0.358 kWh vs. 0.018 kWh for 2,400 queries). This ratio is consistent across all models tested—the move from saturated to unsaturated serving causes a roughly 20× degradation in energy efficiency because the GPU spends significant time idle between requests, and idle power (while excluded from the process-level measurement) means that the active computation must occur in a shorter window with the GPU drawing near-maximum power for that window.

Cross-model comparison at the same request rate. At infinite request frequency, the models sort by size as expected: Llama 3.2 1B uses 0.003 kWh, OLMo 2 7B uses 0.018 kWh, OLMo 2 13B uses 0.033 kWh, and Llama 2 13B uses 0.034 kWh—larger models consume proportionally more energy. However, at 1 req/s, the differences compress: OLMo 1 1B uses 0.165 kWh, OLMo 2 7B uses 0.358 kWh, and OLMo 2 13B uses 0.386 kWh. The ratio from 1B to 13B is only 2.3×, much less than the parameter count ratio would suggest. The paper notes that "there is relatively small variability in carbon emissions and water consumption across different model sizes in cases where batches are not saturated, despite faster inference in smaller models when fully saturated; greater peak efficiency does not guarantee efficient deployment if inference is not optimized" (Table 3 caption). This is a crucial practical finding: the energy efficiency advantage of small models largely evaporates if they are deployed in low-utilization settings.

The paper also observes that Llama 3.1 8B is "actually measured to be faster and less energy intensive than OLMo 7b models" (Appendix A.1), attributing this to Llama's use of grouped-query attention (GQA; Ainslie et al., 2023) which OLMo models do not use. At infinite request frequency, Llama 3.1 8B uses 0.011 kWh vs. OLMo 2 7B's 0.018 kWh, despite having more parameters—a 40% energy advantage per benchmark.

Break-even analysis (Table 3, "# Inf. for CO2 equiv. w/ training" column). The number of inference queries needed for cumulative inference emissions to match total training emissions varies dramatically by model and request rate:

OLMo 2 7B (training emissions: 52 tCO₂eq, from Table 2): 20.9 billion queries at ∞ req/s, 7.68 billion at 8 req/s, 1.05 billion at 1 req/s.
OLMo 2 13B (training emissions: 101 tCO₂eq): 22.1 billion at ∞ req/s, 12.8 billion at 8 req/s, 1.89 billion at 1 req/s.
Llama 3.1 8B (training emissions: 420 tCO₂eq, from Table 2): 276 billion at ∞ req/s, 59.5 billion at 8 req/s, 9.12 billion at 1 req/s.
Llama 2 13B (training emissions: 62 tCO₂eq, from Table 2): 13.3 billion at ∞ req/s, 7.52 billion at 8 req/s, 1.13 billion at 1 req/s.

Several patterns emerge. First, models with high training cost relative to inference efficiency have lower break-even points. Llama 3.1 8B at 420 tCO₂eq training cost requires 276 billion queries at saturated throughput—the highest break-even of any model—but at 1 req/s it drops to 9.12 billion, which is still substantially higher than OLMo 2 7B's 1.05 billion at the same rate. This reflects Llama 3.1 8B's higher training cost (420 vs. 52 tCO₂eq, an 8× difference) partially offset by its inference efficiency advantage from GQA.

Second, for models with "over-trained" small architectures (trained on far more tokens than compute-optimal), training can dominate the environmental calculus even though inference is cheap per query. OLMo 1 1B (3T tokens, 10 tCO₂eq training cost) needs 441 million queries at 1 req/s to break even—the lowest break-even point in Table 3—reflecting low training cost but also modest inference efficiency. Llama 3.2 1B (107 tCO₂eq training cost) needs 4.83 billion queries at 1 req/s—11× higher than OLMo 1 1B—because its training was far more expensive (107 vs. 10 tCO₂eq) despite both being ~1B-parameter models.

Third, the OLMoE mixture-of-experts model (18 tCO₂eq training cost) has break-even points of 21.7 billion at ∞ req/s and 861 million at 1 req/s. Its inference efficiency is relatively good for its capability level, but it will still reach break-even relatively quickly because its training cost is moderate.

The paper's interpretation of these numbers is that "in some scenarios, our models would need to run inference on a few billion instances to match the electricity consumed, carbon emitted, and water consumed of the entire training process, a figure that can be reached by production systems in weeks to months based on current usage trends" (Section 1, referencing OpenAI reaching 400 million users). This framing connects the abstract break-even numbers to real deployment scale: if a model serves hundreds of millions of users generating multiple queries per day, the break-even point—even at tens of billions of queries—is reachable within weeks or months, after which inference becomes the dominant environmental cost. The implication is that for widely deployed models, evaluating only training costs fundamentally misrepresents total lifetime impact.

What the break-even analysis does NOT capture. The paper uses total training CO₂e as the denominator, but this is not a true "cradle-to-gate" cost: it excludes hardware transportation, data center construction, and end-of-life disposal (as acknowledged in Section 4.1), and it uses amortized rather than attributable embodied impacts. If the full manufacturing carbon of the GPUs were attributed to the first model trained on them, the training-side number would be higher and the break-even point would be correspondingly larger. Additionally, the break-even analysis compares inference queries to training, but ignores development costs. The true break-even against total lifecycle impact would be higher than reported because development adds ~50% to the training-side carbon total.

The inference numbers themselves are lower bounds because they exclude non-GPU power and idle server overhead (Section 3.4). This means the per-query CO₂e is underestimated, which in turn means the reported break-even points are overestimated—the true number of queries needed to match training emissions is smaller than reported. The paper's break-even figures should therefore be understood as upper bounds on the number of queries required, and the conclusion that deployment can quickly overtake training is conservative.

Power Fluctuation Analysis (Figure 2, Section 4.3)

Figure 2 displays the average GPU power consumption for a single node (8 H100 GPUs) during the first 300 logging steps of OLMo 2 7B training. The time-series shows a pattern of high, relatively stable power during active training (~600W per GPU, which is approximately 85% of the H100's 700W maximum power draw), punctuated by sharp drops to just over 100W per GPU (~15% of maximum) corresponding to model checkpoint saves.

Quantitative characterization of the fluctuation pattern. During active training, the GPUs draw over 600W each. The paper reports that this represents "over 85% of an H100's maximum power draw of 700W" (Figure 2 caption). During checkpointing, power usage drops to "just over 100W, or about 15% maximum." The amplitude of the fluctuation is therefore approximately 500W per GPU, or 4,000W per 8-GPU node, representing a swing from ~5.6 kW total node power to ~0.8 kW in the span of a few seconds. For a training run using 128 nodes (1,024 GPUs), a single checkpoint save event would cause a power drop of approximately 500W × 1,024 = 512 kW—half a megawatt—nearly instantaneously.

The frequency of these fluctuations is not directly measured in the paper, but the figure shows that within the first 300 logging steps, multiple checkpoint drops occur. The paper states that "without careful engineering, one training run can cause thousands of rapid power fluctuations" (Section 5.2). For a multi-trillion-token training run lasting weeks or months with checkpoints saved at regular intervals (e.g., every few hundred to few thousand steps), this estimate is plausible: if checkpoints are saved every 500 steps and the run involves 50,000 steps, there would be approximately 100 checkpoint events, each causing one drop and one spike, for 200 fluctuations. If logging steps are more frequent and checkpointing causes fluctuations on finer timescales, the "thousands" figure becomes more realistic.

Implications for prior reporting practice. This measurement directly refutes the assumption, made in all three Llama reports (Touvron et al., 2023a;b; Dubey et al., 2024), that GPUs operate at 100% of their theoretical maximum power draw throughout training. The 85% figure for active training means that assuming 100% overestimates training energy consumption by approximately 18%. However, the more significant implication is the temporal pattern: the drops to 15% during checkpointing mean that the instantaneous power demand is not constant, and the grid infrastructure supplying the data center must handle repeated, large-amplitude shifts in load.

Connection to grid-scale concerns (Section 4.3 text). The paper argues that these fluctuations pose a distinct problem from total energy consumption: "Generated power needs to go somewhere, and rapid, large drops in consumption during training breaks common assumptions about data center supply and demand, leading to significant control challenges in power systems." When a training run drops from 5.6 kW/node to 0.8 kW/node across hundreds of nodes nearly instantaneously, the power that was being consumed moments earlier must either be redirected to other consumers, stored, or discarded—typically by "grounding the power or venting steam" (Section 4.3). Conversely, when the checkpoint save completes and the GPUs spool back up to full training load, the grid must rapidly bring additional generation online, which "generally [relies on generators] powered by fossil fuels, such as coal and natural gas" that "can be quickly started and stopped" (Section 4.3).

The paper notes that the authors "have since improved checkpointing performance" (Section 5.2), but frames this as a general concern that extends beyond their specific infrastructure: "other model developers have experienced similar issues caused by checkpointing and synchronization between nodes (Dubey et al., 2024)." The citation to the Llama 3 technical report indicates that even Meta—operating at vastly larger scale—encounters the same problem, making it a systemic characteristic of large-scale distributed training, not a quirk of the authors' specific implementation.

Ablation Studies and Robustness Checks

This paper is primarily an empirical measurement study, not a methods paper with algorithmic components to ablate. However, several sensitivity analyses and robustness checks are embedded in the results or discussed qualitatively. I document the ones that exist and note where the paper does NOT perform analyses that would strengthen confidence.

Data center location as an implicit ablation: Jupiter vs. Augusta. The paper trained the 13B model on a different cluster (Augusta, Iowa) than all other models (Jupiter, Texas). This is not presented as an intentional ablation but functions as one: it reveals the sensitivity of water consumption to geographic location. The per-MWh water consumption at Augusta is approximately 3.88 kL/MWh (892 kL ÷ 230 MWh), while at Jupiter it is approximately 1.29 kL/MWh (202 kL ÷ 157 MWh for OLMo 2 7B)—a factor of 3.0×. This difference is almost entirely due to the off-site water intensity of the electricity generation mix (WUE_offsite = 3.10 L/kWh in Iowa vs. 1.29 L/kWh in Texas), since both data centers use closed-loop cooling with zero on-site water consumption. The carbon intensity difference between the two locations is minimal (0.332 vs. 0.352 kg CO₂/kWh), demonstrating that carbon and water impacts can decouple: a location choice that is nearly carbon-equivalent can differ by a factor of 3 in water impact.

LUMI hydroelectric training as a carbon ablation. The original OLMo 7B trained on LUMI (Table 2, row: "OLMo 7B") used 149 MWh but emitted 0 tCO₂eq because LUMI "runs entirely on hydroelectric power" (Table 2 footnote). This is a natural experiment demonstrating that the carbon intensity of the grid is the dominant factor in operational emissions: the same model architecture trained on the same dataset (presumably, though the paper does not confirm this) produced zero operational carbon when powered by renewables, compared to 52–70 tCO₂eq for the 7B models trained on Jupiter. This demonstrates that location choice can effectively eliminate operational carbon emissions, though it does not affect embodied carbon or water consumption (the paper does not report water consumption for the LUMI-trained model).

Request rate as an inference efficiency ablation (Tables 3 and 4). The three request-rate scenarios (∞, 8, and 1 requests per second) function as an ablation over serving utilization. The finding that per-query energy increases by ~20× from saturated to unsaturated serving is consistent across all models tested (Section 4.2, Tables 3 and 4). This is not a surprising result—it follows directly from the physics of GPU power consumption, where idle power is non-zero—but it quantifies the magnitude of the effect and demonstrates that inference efficiency claims measured at saturated throughput do not generalize to realistic deployment conditions with intermittent traffic.

Model architecture comparison: dense vs. mixture-of-experts. The comparison between OLMo 1B (dense, 3T tokens, 30 MWh) and OLMoE 0924 (MoE with 1B active / 7B total, 5T tokens, 54 MWh) reveals that the MoE model is slightly less efficient per trillion tokens (10.8 MWh/T vs. 10.0 MWh/T) when measured by total energy, despite having the same number of active parameters. The paper attributes this to "routing tokens" overhead (Section 4.1). For inference, Table 3 shows that OLMoE 0924 at ∞ req/s uses 0.006 kWh for the 2,400-request benchmark, compared to OLMo 1 1B's 0.004 kWh—the MoE is less efficient at inference as well, consistent with the training efficiency finding. However, the MoE model was trained on 5T tokens, giving it potentially different capabilities, so this is not a controlled comparison of architecture holding all else equal.

Missing ablations and robustness checks. Several analyses that would strengthen the paper are not performed:

No per-GPU power variance analysis. The extrapolation from single-node power measurements to the full cluster assumes all nodes consume identical power. The paper does not report whether multiple nodes were instrumented to verify this assumption or what the node-to-node variance is. In a distributed training setting with synchronized gradient updates, power consumption should be relatively uniform across nodes, but factors like manufacturing variance in GPUs, differences in cooling efficiency across rack positions, or network communication imbalances could introduce variance. Without reporting this, the reader cannot assess whether the extrapolation error is 1%, 10%, or more.
No sensitivity analysis for GPU lifespan assumption. The embodied impact estimates depend critically on the assumed 4-year GPU lifespan. If the actual lifespan is 3 years (more aggressive refresh), embodied costs per hour increase by 33%. If it is 5 years, they decrease by 20%. The paper does not report how sensitive the total figures are to this assumption. Given the acknowledged uncertainty in the underlying manufacturing data, a range (e.g., "embodied carbon would be 15–30 tCO₂eq for lifespans of 3–5 years") would provide useful context.
No sensitivity analysis for PUE variation. Jupiter's PUE is reported as "between 1.1 and 1.2 depending on current total utilization" (Section 3.1), and the paper assumes 1.2 for calculations. If actual PUE were 1.1 during some periods, the operational energy and carbon would be 8.3% lower than reported. The paper does not report the time-weighted average PUE or the sensitivity of results to this assumption.
No comparison of inference energy measurement scopes. The paper uses process-level CodeCarbon measurement for inference but sub-second GPU power logging for training. These are different measurement scopes that may not be directly comparable. A comparison measurement—running the same inference benchmark with both tools—is mentioned ("CodeCarbon... was verified against the same time series monitoring used throughout training," Section 3.4) but the results of this verification are not reported. The reader cannot assess whether the two measurement approaches yield consistent results.
No measurement of idle cluster power. Luccioni et al. (2023) reported energy consumption while the BLOOM cluster was idle. This paper does not report idle power for its clusters—energy consumed by GPUs that are powered on but not actively training or serving. For a cluster that is used for multiple projects (the authors' GPUs were not exclusively dedicated to OLMo development), the idle power attributable to the OLMo project depends on utilization assumptions that are not discussed.
No inference benchmark variation beyond request rate. The paper tests only one dataset (ShareGPT), one serving framework (SGLang), one GPU type (H100), and one prompt length distribution. Real inference deployments vary along all these dimensions, and the paper acknowledges this limitation (Appendix A.2): "we simulate only settings where a deployed model is ingesting input tokens and generating output tokens following default parameters... practitioners frequently employ different inference-time optimizations such as quantization; perform generation with different decoding algorithms; and/or deploy to and run inference on edge devices." None of these variations are explored, so the inference results should be understood as one point in a large space, not a comprehensive characterization.
No break-even analysis for water consumption. The paper computes carbon break-even points but not water break-even points, even though water consumption is one of the paper's headline metrics and the geographic variation in water intensity is a key finding. Computing "number of inferences for water consumption to equal training water consumption" would be straightforward and would reveal whether the training-vs-inference tradeoff differs for water than for carbon.

Critical Assessment

The paper makes four central claims (from the Executive Summary and Section 4): (1) model development costs amount to ~50% of final training costs and are generally not disclosed; (2) water consumption is substantial even in water-efficient data centers, and geographic variation in electricity generation mix dramatically affects it; (3) power consumption during training is not steady but fluctuates between ~15% and ~85% of maximum draw, posing grid-scale challenges; and (4) the total environmental impact of the authors' model series (up to 13B parameters) is 493 tCO₂eq and 2,769 kL of water. I assess each against the experimental evidence.

Claim 1: Development costs are ~50% of training costs and unreported. This claim is well-supported by the data the paper reports, but with important boundary conditions. The 51% ratio (159 tCO₂eq development / 312 tCO₂eq final training) is computed from Table 1 and Table 2 totals, with the caveats that development costs are measured using the same GPU-only, per-node-extrapolated methodology as training costs, and that the ratio would change if non-GPU power were included (the paper argues its numbers are lower bounds, but it does not establish that the GPU/non-GPU ratio is the same for development and training—if development runs use proportionally more CPU for data preprocessing or evaluation, the ratio could shift). The 813 development runs across five model-size groups are documented in Table 1, so the $H$ term from the Schwartz et al. (2020) equation is empirically grounded rather than assumed.

However, the claim that this cost is "generally not disclosed by most model developers" is not experimentally tested—it is an observation about the state of the field, supported by the literature review in Section 2 but not by the paper's own measurements. The paper does not survey other developers or verify their non-disclosure; it relies on published technical reports (Llama, Gemma, BLOOM, OLMo) and the conspicuous absence of development cost figures in them. This is a reasonable inference given the public record but is not an experimental finding.

A more significant limitation is that the paper does not establish whether the ~50% ratio generalizes beyond its own development practices. The authors' development strategy—a relatively small team building open-source models with public reporting goals—may involve either more or fewer experiments than a typical industrial development process. A proprietary lab optimizing a flagship model might run far more experiments (making the ratio higher) or might leverage infrastructure that makes additional experiments cheap at the margin and thus not track them separately (making the ratio appear lower if only "intentional" experiments are counted). The paper's ratio should be understood as a case study, not an industry estimate.

Claim 2: Water consumption is substantial, and geographic variation is dramatic. This claim is strongly supported by the paper's own data, with a particularly clean natural experiment. The 2.4× difference in per-MWh water consumption between Texas (1.29 L/kWh off-site WUE) and Iowa (3.10 L/kWh off-site WUE) is directly measured from the authors' own infrastructure in two different locations, using external WUE factors from Reig et al. (2020). The total water consumption of 2,769 kL is computed from these factors and the measured power consumption, making the numbers internally consistent.

However, the off-site WUE factors are the weakest link in this chain. The paper uses statewide averages for off-site WUE (1.29 L/kWh for Texas via Austin Energy, 3.10 L/kWh for Iowa via statewide average) from Reig et al. (2020). The actual marginal water consumption of the electricity used by the authors' data centers depends on which specific power plants are dispatched to meet their demand—a level of granularity that requires real-time grid data the paper does not have access to. Statewide averages smooth over variation in generation mix by time of day, season, and marginal vs. average dispatch. If the data centers draw power during off-peak hours when the generation mix differs from the average, the actual water intensity could differ from the reported values. The paper does not discuss this uncertainty, treating the Reig et al. (2020) factors as point estimates.

Additionally, the water consumption figures for the inference simulations use the Jupiter WUE factors for all models (Table 3: "we use the same WUE and PUE coefficients of 1.29 L/kWh and 1.2 respectively"), even though in a real deployment, inference servers could be located anywhere. This is a reasonable simplification for simulation but means the inference water numbers are specific to the Texas location and would be higher or lower in other regions.

Claim 3: Power fluctuates between ~15% and ~85% during training. This claim is directly supported by Figure 2, which shows the measured GPU power time series for one node during OLMo 2 7B training. The ~85% active-training figure and ~15% checkpointing figure are read directly from the measurement. The sub-second logging interval is sufficient to capture the dynamics of checkpoint-related power drops.

The extrapolation from this single-node measurement to the claim that training causes "thousands of rapid power fluctuations" system-wide is less directly supported. The paper reports the frequency in qualitative terms ("thousands," Section 5.2) without specifying the exact number of checkpoint events in any specific training run or the total number of fluctuations across all runs. A reader cannot verify this claim from the data provided. The argument that these fluctuations pose grid-scale challenges is supported by the citation to Dubey et al. (2024), which documents similar issues at Meta's scale, but the paper does not provide its own grid-impact analysis or quantify the magnitude of the problem for its specific training runs. The grid-scale argument is logically coherent and consistent with known power systems engineering principles, but it is not experimentally demonstrated—the paper measures GPU power, not grid response.

Claim 4: Total impact is 493 tCO₂eq and 2,769 kL of water. These aggregate numbers are the sum of embodied, development, and training impacts, all computed from measured or estimated inputs as described in the methodology. The arithmetic is straightforward, and the paper provides sufficient detail in Tables 1 and 2 and Section 4.1 for a reader to reproduce the summation. The contextualization using EPA equivalencies is sourced and checkable.

However, the claim that these numbers represent "the real-world environmental impact of developing a series of language models" (from the abstract) overstates what was measured. As the paper itself acknowledges, the numbers exclude non-GPU server power, data center construction, hardware transportation, and end-of-life disposal. They use amortized rather than attributable embodied impacts. They assume PUE at the upper end of the reported range for Jupiter. They exclude idle cluster power. The inference simulations are hypothetical, not based on actual deployment. The development cost accounting covers the experiments the authors chose to track, but may exclude informal experimentation, preliminary data exploration, and infrastructure overhead. These are all acknowledged limitations, but they mean the 493 tCO₂eq and 2,769 kL figures should be understood as measured lower bounds given a specific scope, not as comprehensive lifecycle assessments. The paper's rhetorical framing sometimes blurs this distinction: the abstract says the models "released 493 metric tons of carbon emissions," while the body acknowledges the numbers are conservative.

General experimental strengths. The paper's primary strength is measurement fidelity: sub-second power logging is a meaningful improvement over the 100%-draw assumption used in prior work, and the use of data center–specific PUE, CI, and WUE factors rather than national averages follows best practices. The development cost reporting is genuinely novel and fills a documented gap. The inference simulation methodology is reasonable and well-scoped. The paper is transparent about its limitations in ways that prior environmental reporting for AI has often not been.

General experimental weaknesses. Beyond the specific issues noted above, three structural limitations affect the paper's conclusions:

Single-organization scope. All measurements come from one research organization's infrastructure, development practices, and model family. The findings about the development-to-training cost ratio, the power fluctuation pattern, and the geographic water intensity variation may not generalize to organizations with different engineering practices, different data center contracts, or different geographic footprints. The paper does not claim generalizability, but the framing sometimes implies it.
No time-series carbon or water intensity. The paper uses static annual-average CI and WUE factors. In reality, the carbon intensity of grid electricity varies by time of day (solar is available during daytime, wind patterns vary, peaker plants come online during high demand). If the authors' training runs predominantly occur during specific hours, the effective carbon intensity could differ from the annual average. Dodge et al. (2022), which the paper cites, used region-specific and time-varying carbon intensity data. The current paper does not, which is a regression from that best practice and may introduce unknown error in the carbon estimates.
Inference break-even analysis does not account for model updates or fine-tuning. The break-even calculation compares one training run to inference queries. In practice, deployed models are frequently fine-tuned, retrained on new data, or replaced by newer versions, each incurring additional training costs. The break-even point relative to total ongoing training cost would be reached even faster than the paper reports. The paper does not discuss this compounding effect.

What would strengthen the paper. Several additional analyses would increase confidence in the conclusions:

Reporting per-node power variance across multiple instrumented nodes to validate the single-node extrapolation.
Reporting idle cluster power consumption to enable comparison with Luccioni et al. (2023) and to assess the overhead of maintaining training infrastructure.
A sensitivity analysis varying the GPU lifespan assumption (3, 4, 5 years) and PUE assumption (1.1 vs. 1.2 for Jupiter) to bound the uncertainty in embodied and operational impacts.
Time-resolved carbon intensity data to assess whether the annual-average CI over- or under-estimates actual emissions.
Explicit water break-even points for inference to parallel the carbon break-even analysis.
An expanded inference evaluation covering at least one quantized model, one batched-but-not-saturated scenario, and one edge-device-typical power profile, to better characterize the space of possible deployments.

Despite these limitations, the paper's core empirical contributions—the first public measurement of LLM development costs, the documentation of training power fluctuations, and the geographic water intensity comparison—are robust to the specific numerical values. The finding that development is a substantial fraction of total impact would hold even if the exact ratio were 40% or 60% rather than 51%. The finding that power is not steady would hold regardless of the exact fluctuation amplitude. And the finding that water consumption varies dramatically by location would hold even if the specific WUE factors were off by 20%. The paper succeeds in its primary goal: demonstrating that comprehensive environmental accounting is feasible and that the current norm of reporting only final training runs is inadequate.

6. Limitations and Trade-offs

Single-Benchmark, Single-Organization Scope Limits Generalizability

The constraint. All measurements in this paper come from the development and training of a single model family (OLMo) by a single research organization (Allen Institute for AI / Carnegie Mellon University) using infrastructure in two specific geographic locations (Texas and Iowa). The models share a common architecture (dense transformers similar to Llama), are trained on the same data center hardware (NVIDIA H100 GPUs on HGX servers), and follow the development practices of a relatively small non-profit research team. The paper acknowledges this implicitly when it describes the models as "representative" but does not claim the findings generalize to other organizations.

The consequence. Three of the paper's central quantitative findings may not transfer to other settings. First, the ~50% development-to-training cost ratio depends on the specific development strategy employed—a team running automated hyperparameter search (AutoML) or extensive scaling law experiments might have a substantially higher ratio, while a team with a well-established training recipe might have a lower ratio. The ratio is a function of how many experiments the team chose to run (H in the Schwartz et al. (2020) equation), not of any physical constraint. Second, the power fluctuation pattern (Figure 2) reflects the authors' specific checkpointing implementation, which they note they "have since improved" (Section 5.2); other frameworks, data center power management strategies, or training scales may exhibit different fluctuation patterns. Third, the water consumption findings depend on the two specific grid mixes (Texas at 1.29 L/kWh off-site WUE, Iowa at 3.10 L/kWh) and may not represent other regions—training in a region with predominantly wind/solar generation would show near-zero water consumption, while training in a region with heavy coal and hydroelectric generation would show much higher consumption. The paper provides no framework for extrapolating its findings to other model families, development practices, or geographic locations.

What evidence exists. The paper presents no multi-organization, multi-architecture, or multi-geography comparisons for its development cost or power fluctuation findings. The inference simulations in Tables 3 and 4 include comparison models (Llama, Qwen) but the development cost and training cost measurements do not. The paper's citation to Dubey et al. (2024) regarding power fluctuations at Meta provides some external corroboration that the fluctuation problem is not unique to the authors' infrastructure, but this is anecdotal rather than systematic. The paper does not report whether the authors have visibility into other organizations' development practices or environmental impacts, and it does not attempt to estimate the variance in the development-to-training ratio across different development strategies.

Mitigation status. The paper does not attempt to address this limitation. It does not claim generalizability, but it also does not explicitly bound the scope of its findings. The authors position the paper as a demonstration of what is possible ("This work is a step in the right direction," Section 1) rather than as a representative sample, but readers—particularly policymakers or practitioners trying to estimate the environmental impact of other AI development efforts—may over-interpret the specific numbers as industry norms. The paper suggests that others should produce similar reports ("responsibility of reporting and reducing the environmental impact must fall on those training the largest models," Section 1), which, if adopted, would create the multi-organization dataset needed to assess generalizability, but that dataset does not yet exist.

The 14× Larger Model Baseline Is Not Compute-Optimally Trained

The constraint. This limitation applies to the inference break-even analysis in Section 4.2, where the paper compares LLM training carbon emissions against per-query inference carbon emissions to compute break-even points, expressed as number of inferences needed to match training emissions. Among the models compared, the paper does not verify—and in many cases cannot verify—whether the training carbon numbers for comparison models were computed using equally rigorous methodology. For the OLMo models, training emissions are based on sub-second power measurements with location-specific PUE and CI factors. For the Llama and Gemma models, the paper uses publicly reported numbers that were computed with varying (and in some cases unspecified) methodologies—Llama 1 used US national average CI rather than location-specific, all Llama models assumed 100% GPU power draw rather than measuring actual draw, and Gemma reported only a single aggregate number with no breakdown (Section 2). The paper acknowledges these inconsistencies in its literature review but does not control for them in the break-even analysis.

The consequence. The break-even comparisons in Table 3 are comparisons of numbers drawn from incomparable measurement methodologies. If a comparison model's reported training emissions are overestimated (because its developers assumed 100% GPU draw when actual draw was lower), then its reported break-even point is artificially high—it would take more inferences to match the overstated training number. Conversely, if a model's training emissions are under-estimated (because its developers excluded development costs or used a lower-than-actual PUE), the break-even point is artificially low. The paper's own OLMo break-even points are based on a more rigorous measurement methodology than the comparison models', making the cross-model break-even comparisons potentially misleading. A reader comparing OLMo 2 7B's break-even of 20.9 billion queries (at ∞ req/s) to Llama 3.1 8B's break-even of 276 billion queries cannot determine how much of that 13× difference is due to actual differences in training and inference efficiency versus differences in how the training emissions were estimated.

What evidence exists. The paper's own literature review (Section 2) documents the methodological inconsistencies: Llama 1 "did not use the data center location's carbon intensity, instead using US national average carbon intensity," Llama 2 "did not specify the carbon intensity," and all three Llama generations "assumed 100% GPU power draw throughout training." The paper also notes that Gemma "only report a single number: the total emissions from pretraining their models, not broken down by model or by different stages of training." These are documented inconsistencies that directly affect the training emission numbers used as denominators in the break-even calculation. The paper reports the comparison numbers in Tables 3 and 4 without adjustment, normalization, or caveats about methodological comparability in the table itself, though the information needed to identify the inconsistency is present in Section 2.

Mitigation status. The paper does not attempt to correct for these methodological differences—for example, by re-estimating comparison model training emissions using consistent assumptions, or by reporting sensitivity ranges that account for plausible measurement error. It also does not flag the incomparability in the break-even tables themselves, which is where most readers will encounter the numbers. The break-even analysis is presented as a direct comparison, but the underlying data are not directly comparable. A minimal mitigation would be to note in the table caption that "training emission estimates for non-OLMo models use varying methodologies as documented in Section 2; direct comparison should account for these differences." The paper does not do this.

Embodied Impact Estimates Depend on Unexamined Assumptions About GPU Supply Chain and Lifespan

The constraint. The paper's embodied impact estimates for hardware manufacturing rely on two assumptions over which the authors have no control and for which they have no direct data: (1) the per-GPU manufacturing carbon emissions and water consumption figures, which are drawn from external sources rather than from the GPU manufacturer, and (2) the assumed 4-year GPU lifespan over which these manufacturing costs are amortized. The paper is transparent about both, stating that "NVIDIA does not release the embodied carbon emissions or water consumption about the hardware it produces" and that researchers "are forced to use unreliable estimates" (Section 5.1). The embodied carbon figure of 463 kg CO₂eq per H100 GPU comes from Luccioni et al. (2023), which itself relied on estimates rather than manufacturer data. The embodied water figure of 100.4 L per H100 is constructed from "TSMC water usage at 12.33 liters per square centimeter of hardware" (Section 4.1), a number from an external semiconductor industry analysis of unknown vintage and provenance. The 4-year lifespan is described as an internal assumption without justification.

The consequence. The total embodied impact figures—22 tCO₂eq and 4.8 kL of water—could be substantially wrong in either direction. If actual manufacturing emissions per H100 are 2× higher than the Luccioni et al. (2023) estimate, embodied carbon would be 44 tCO₂eq instead of 22. If the actual GPU lifespan is 3 years (a more aggressive refresh cycle, which is common in AI research clusters where new GPU generations arrive every 2–3 years), the per-hour amortized rate increases by 33%, raising total embodied carbon to approximately 29 tCO₂eq. If lifespan is 5 years, it drops to approximately 18 tCO₂eq. These variations would not change the paper's headline finding—embodied impacts would still be the smallest component of total lifecycle impact, at approximately 4–9% of the 493 tCO₂eq total—but the uncertainty is large in percentage terms for the embodied component itself. More importantly, the embodied water number is extremely fragile: the entire estimate rests on a single external figure (12.33 L/cm² for TSMC) applied to an estimate of H100 die area that the paper does not document. If the die area or water intensity is wrong by a factor of 2, the embodied water number doubles or halves.

What evidence exists. The paper provides no sensitivity analysis for these assumptions. There is no range reported for the total embodied impacts under alternative lifespan assumptions, no comparison of the Luccioni et al. (2023) embodied carbon estimate to any other source (e.g., product carbon footprint reports from other semiconductor manufacturers like Intel or AMD, which the paper notes do disclose such data: "Many companies that manufacture other pieces of data center hardware disclose estimates of the lifetime environmental impact," Section 5.1). The paper reports the per-GPU and per-hour numbers with three significant figures (0.013 kg CO₂eq per GPU hour, 0.003 L per GPU hour) that imply a precision the underlying data cannot support given that the primary source is acknowledged to be "unreliable."

Mitigation status. The paper is transparent about the fundamental opacity: "the environmental impact of manufacturing the GPUs used is essentially unknown... and the situation is no better now, nearly two years later" (Section 5.1). This is not a mitigation but a candid acknowledgment. The paper explicitly calls for GPU manufacturers to release lifecycle environmental data: "until GPU manufacturers release similar information—on a voluntary or compulsory basis—this will not improve" (Section 5.1). This turns the limitation into a policy recommendation, which is an appropriate response to a data availability problem the authors cannot solve themselves. However, the paper could have reported sensitivity ranges (e.g., "embodied carbon would be 15–30 tCO₂eq for lifespans of 3–5 years and manufacturing emissions of 300–600 kg/GPU") to bound the uncertainty, and it does not do so.

Difficulty Estimation Cost Is Not Accounted For in the Headline Efficiency Numbers

Note on scope. This limitation is a generalization of a pattern documented in Section 5's "Missing Ablations and Robustness Checks" discussion. Rather than repeat the detailed breakdown there, I am structuring this limitation to address the broader methodological issue it reveals.

The constraint. The paper reports environmental impact numbers that aggregate measured GPU power consumption during active computation (development and training runs). However, the infrastructure required to obtain these measurements—the sub-second power logging system, the per-node instrumentation, the data aggregation pipeline—consumes additional computation and energy that is not measured or reported. More significantly, the process of making these measurements itself requires decisions about what to measure and at what granularity, and those decisions affect which environmental costs become visible and which remain hidden. The paper measures GPU power on one node and extrapolates to the full cluster, but does not measure the overhead of that measurement infrastructure. It measures active inference power but excludes idle server power. It measures development cost for the experiments that were run, but does not estimate the cost of experiments that were considered and abandoned before reaching the training stage. Each of these scope decisions is individually defensible, but collectively they mean the reported numbers are systematically lower than the true environmental cost of the activities described.

The consequence. The paper's central quantitative claim—that the OLMo model series "released 493 metric tons of carbon emissions" and "consumed 2.769 million liters of water"—is a measured lower bound given a specific measurement scope, not a comprehensive lifecycle estimate. The gap between the measured lower bound and the true total is unknown but could be significant. The excluded categories include: non-GPU server power (CPU, RAM, networking, storage), data center construction embodied impacts, hardware transportation, end-of-life hardware disposal, idle cluster power when GPUs are powered but not actively training, the overhead of the power measurement infrastructure itself, and experiments that were planned but not executed. Each of these exclusions is acknowledged somewhere in the paper (Section 4.1: "there remain a number of sources of emissions and water consumption that are difficult, if not impossible to comprehensively measure"; Section 3.1: "our estimates should be viewed as a lower bound"; Section 3.4: "these numbers can be considered as lower bounds on usage in similar settings"), but the paper never aggregates these caveats to estimate the total gap between the measured bounds and the true totals. A practitioner reading the abstract sees "493 metric tons" as a point estimate; the full text reveals this is a sum of several different kinds of lower bounds.

What evidence exists. The paper does not quantify any of the excluded categories. It does not report what fraction of total server power is typically consumed by GPUs vs. CPUs vs. other components for the authors' specific hardware configuration. It does not report idle cluster power, making it impossible to compare with Luccioni et al. (2023)'s finding that idle power was a significant fraction of total BLOOM cluster energy. It does not estimate the energy cost of the measurement infrastructure itself. It does not attempt to bound the magnitude of excluded transportation and disposal impacts. The total magnitude of all exclusions is unknown and unestimated.

Mitigation status. The paper partially mitigates this by being transparent about each individual exclusion: the lower-bound caveats are stated in multiple places and the specific excluded categories are named (transportation, disposal, non-GPU power, idle overhead). This is substantially better than prior environmental reporting for AI, which often did not acknowledge scope limitations at all. However, the mitigation is qualitative rather than quantitative—the paper tells readers that the numbers are conservative but does not help readers estimate how conservative. A sensitivity analysis that bounded the plausible range of excluded impacts (e.g., "if non-GPU power is 20–40% of total server power, total operational energy would be 1.2–1.4× the reported figure") would substantially improve the usefulness of the reported numbers for downstream decision-making. The paper's rhetorical strategy—reporting precise point estimates while acknowledging they are lower bounds—creates a tension between the precision implied by three-significant-figure reporting and the acknowledged incompleteness of the measurement scope.

Inference Break-Even Analysis Does Not Account for Deployment Lifecycle Updates

The constraint. The break-even analysis in Section 4.2 compares the carbon emissions from a single final training run against the cumulative carbon emissions from inference queries, computing the number of queries at which inference emissions equal training emissions. This formulation implicitly assumes that the model is trained once and then deployed for inference indefinitely without further training. In practice, deployed models are frequently updated: they are fine-tuned on new data, retrained from scratch on expanded datasets, or replaced by newer model versions, each of which incurs additional training costs. The paper acknowledges the dynamic nature of model development when discussing scaling law experiments ("smaller models are trained to predict the performance of larger models, and then discarded," Section 5.1) and when citing the trend toward "over-trained" models where each generation is trained on more tokens (Llama 1 at 1T, Llama 2 at 2T, Llama 3 at 15T, Section 5.2), but it does not incorporate this dynamism into the break-even model.

The consequence. The reported break-even points are substantially higher than the break-even points against ongoing total training cost for a model that is regularly updated. Consider a model like Llama, which has seen three major releases in roughly two years. If each release incurs training emissions comparable to the previous release (or larger, given the trend toward more training tokens), the cumulative training emissions over the deployment lifetime of the "Llama family" are 3× or more the single-release number. The break-even point against this ongoing training cost would be correspondingly lower. For widely deployed models with rapid release cycles, the inference break-even against cumulative training cost may arrive much faster than the single-training-run analysis suggests. Conversely, for a model that is trained once and deployed for years with only minor fine-tuning, the single-run break-even is more appropriate. The paper provides no framework for distinguishing these scenarios or for incorporating model update frequency into the analysis.

What evidence exists. The paper provides the data needed to illustrate this point but does not synthesize it. Table 2 reports training emissions for multiple generations of OLMo models (OLMo 7B at 0 tCO₂eq on LUMI, OLMo 7B Twin at 70 tCO₂eq, OLMo 0724 7B at 32 tCO₂eq, OLMo 2 7B at 52 tCO₂eq). If these are treated as a single "7B model lineage," the cumulative training emissions are 154 tCO₂eq (excluding the zero-carbon LUMI run), which is 3× the single OLMo 2 7B figure of 52 tCO₂eq. The break-even point against this cumulative cost would be 3× lower. Similarly, the inclusion of Llama 2 7B (31 tCO₂eq), Llama 3.1 8B (420 tCO₂eq), and Llama 3.2 1B (107 tCO₂eq) in the comparison tables reveals cumulative training emissions across the Llama family that far exceed any single model's cost, but the break-even analysis treats each model in isolation.

Mitigation status. The paper does not address this limitation. The break-even analysis is presented as a comparison of single training runs to inference queries, without discussion of model lineages, update frequency, or cumulative training cost. The paper's broader argument—that inference can quickly outweigh training for widely deployed models—is actually strengthened by accounting for ongoing training costs (the break-even would be reached sooner), so this limitation does not undermine the paper's thesis. However, it means the specific break-even numbers in Table 3 should be interpreted as upper bounds on the queries needed to match a single training run, not as estimates of the queries needed for total deployment lifecycle impact to match total development lifecycle impact. The distinction matters for practitioners trying to allocate environmental accounting effort between training and deployment stages.

No Accounting for Latency or Wall-Clock Time — All Compute Is Treated as Fungible

The constraint. The paper measures environmental impact in terms of total energy (MWh), total carbon (tCO₂eq), total water (kL), and total GPU hours, aggregating across all development runs and final training runs into cumulative totals. This treatment implicitly assumes that a kilowatt-hour consumed at 3 AM is environmentally equivalent to a kilowatt-hour consumed at 3 PM, and that the environmental cost of computation depends only on total energy, not on when or how quickly that energy is drawn. The paper uses static annual-average carbon intensity and water intensity factors (Section 3.1) rather than time-resolved factors, which is a departure from best practice established by Dodge et al. (2022).

The consequence. The actual carbon emissions and water consumption from the reported energy use depend on when the energy was consumed, because the carbon intensity and water intensity of grid electricity vary by time of day, day of week, and season. If the authors' training runs predominantly occurred during daytime hours when solar generation reduces the carbon intensity of the Texas grid (ERCOT has substantial solar capacity), the actual carbon emissions would be lower than estimated using the annual-average CI. If training occurred during evening peak demand when fossil fuel peaker plants are dispatched, actual emissions would be higher. The magnitude of this error is unknowable without time-resolved data, but it could be significant—diurnal variation in grid carbon intensity can be 20–50% in regions with substantial renewable penetration. The paper's use of static factors means the reported carbon and water numbers represent a long-term average expectation, not the actual marginal impact of the specific electricity consumption.

What evidence exists. The paper cites Dodge et al. (2022), which "measured electricity consumption and carbon emissions for training language models and computer vision models with granular timesteps with region-specific carbon intensity" (Section 2), indicating that the authors are aware of time-resolved carbon accounting as a best practice. However, the paper does not adopt this practice. It does not report when training runs were executed (time of day, season), does not use time-varying CI or WUE data, and does not estimate the potential error introduced by the static-factor assumption.

Mitigation status. The paper does not address this limitation explicitly. It uses the data center location and the most recently reported CI/WUE factors, which is an improvement over using national averages (as Llama 1 did), but falls short of the time-resolved methodology that the authors' own cited prior work established. The practical barrier—obtaining time-resolved grid intensity data and matching it to training run timestamps—is non-trivial but feasible, and the paper does not discuss why this was not done. For a paper whose primary contribution is methodological thoroughness in environmental accounting, the omission of temporal resolution in carbon intensity is a notable gap between the state of the art (time-resolved CI) and the implemented methodology (static annual-average CI).

7. Implications and Future Directions

How This Work Changes the Landscape

This paper does not introduce a new model, algorithm, or benchmark. It produces no state-of-the-art accuracy numbers. Yet it shifts the conversation around AI's environmental impact in a way that is genuinely substantive rather than merely rhetorical, because it replaces assumptions—some explicit, most implicit—with measurements, and in doing so reveals that several of those assumptions were wrong in ways that matter for policy, engineering, and public accountability.

The most consequential shift is the demonstration that model development is a first-order environmental cost, not a rounding error on the final training run. The finding that development emissions (159 tCO₂eq) amount to approximately 51% of final training emissions (312 tCO₂eq) is not a minor correction to existing accounting practices—it means the standard reporting practice in the field, which reports only the final training run, is understating total environmental impact by roughly a factor of 1.5×, and potentially much more for organizations that run more extensive hyperparameter searches, architecture explorations, or scaling law experiments than the authors did. This finding transforms the $H$ term in the Schwartz et al. (2020) cost equation from a theoretically acknowledged but practically ignored factor into an empirically demonstrated first-order contributor. The field can no longer credibly claim that reporting final training runs alone provides an adequate picture of environmental impact, because the paper has shown—with measured data from its own infrastructure—that the excluded category is roughly as large as the included one.

The magnitude of this shift depends on generalizability, which the paper does not establish. The 51% ratio reflects the development practices of a specific research team building open-source models with public reporting goals. An industrial lab developing a flagship proprietary model might run far more experiments—automated hyperparameter sweeps, architecture searches, scaling law experiments with hundreds of discarded model variants—making the development-to-training ratio substantially higher. Conversely, a team with a mature, stable training recipe who trains only one model might have a lower ratio. The paper does not answer the question of what the typical ratio is across the industry, but by establishing that the ratio is large enough to matter for one well-documented case, it shifts the burden of proof: the default assumption can no longer be that development costs are negligible, and any organization claiming its development costs are small must now demonstrate that with data, not assertion.

The paper reframes water consumption as a geographically contingent, first-class environmental metric that can decouple from carbon emissions. Prior to this work, water consumption was almost entirely absent from AI environmental reporting. The paper's own data provides the cleanest demonstration yet of why this matters: its two data centers have nearly identical carbon intensity (0.332 vs. 0.352 kg CO₂/kWh) but differ in water intensity by a factor of 2.4× (1.29 vs. 3.10 L/kWh), driven entirely by differences in the electricity generation mix. This means that optimizing for carbon alone—choosing a data center based on carbon intensity—can unintentionally shift environmental harm from the atmosphere to the watershed. The paper does not propose a solution to this tradeoff, but it makes the tradeoff visible and quantifiable in a way that prior work did not, creating pressure for developers to report both metrics and for policymakers to consider both when siting data centers.

This finding also changes how we should think about "green" data centers. The paper's data centers use closed-loop cooling with zero on-site water consumption, which the abstract describes as "extremely water-efficient." Yet the total water consumption across the model series is 2,769 kL—equivalent to 24.5 years of personal water use—all of it occurring off-site at power plants. The implication is that on-site water efficiency, while valuable, addresses only a fraction of the total water footprint. The dominant factor is where the electricity comes from, not how the data center cools itself. For a data center powered by a grid with substantial thermal generation (coal, nuclear, natural gas), the off-site water consumption at the power plant will dominate regardless of how efficient the on-site cooling is. This reframes the water problem from a data center engineering challenge to an energy policy challenge.

The paper introduces the concept of power fluctuation as a distinct environmental problem from total energy consumption, with different causes and different solutions. Prior work treated training power consumption as a steady-state quantity that could be multiplied by duration to get total energy. The paper's sub-second power measurements (Figure 2) reveal that training power oscillates between ~85% and ~15% of maximum GPU draw with each checkpoint save, producing "thousands of rapid power fluctuations" per training run. This is not merely an interesting measurement artifact; it has concrete implications for grid stability that are fundamentally different from the implications of total energy consumption. Steady high demand stresses generation capacity (do we have enough power plants?). Fluctuating demand stresses grid control (can we match supply to demand on short timescales without destabilizing the system?). The paper frames this as a problem that "breaks common assumptions about data center supply and demand" and points toward a new engineering agenda focused on power shaping (smoothing fluctuations) rather than power minimization (reducing total energy).

This finding also reconciles a tension in prior work. The Llama reports assumed 100% GPU power draw throughout training, which would overestimate total energy by ~18% (since actual active-training draw is ~85%) but would completely obscure the fluctuation pattern. A developer optimizing only for accurate total energy estimates might prefer the 100% assumption as conservative, but the paper demonstrates that this assumption hides a qualitatively different problem—grid instability—that may be more environmentally consequential than the 18% energy overestimate. This changes the goal of power measurement from "get the total right" to "capture the temporal dynamics," which requires different instrumentation and different analysis.

The paper resolves an apparent contradiction in the "efficient deployment is good for the environment" narrative. The recent trend toward "deployment-optimized" small models—trained on far more tokens than compute-optimal, making them cheaper per inference query—has been presented as environmentally beneficial because it reduces per-query energy. The paper's break-even analysis reveals the Jevons Paradox dynamic: making inference cheaper per query can increase total usage enough to raise total environmental impact. The break-even numbers in Table 3 show that for widely deployed models, the cumulative inference emissions can match training emissions in "weeks to months" (Section 1). This does not mean efficient deployment is bad—it means the environmental assessment must be system-level (total queries × per-query cost) rather than component-level (per-query cost alone). The paper provides the metric—break-even point—needed to make that assessment, and demonstrates that different models have break-even points spanning three orders of magnitude (from 441 million to 276 billion queries at 1 req/s), meaning the training-inference tradeoff is model-specific and scenario-specific, not a universal constant.

Follow-Up Research This Work Enables

Time-resolved carbon and water intensity for training runs. The paper uses static annual-average carbon intensity and water intensity factors, which is a departure from the time-resolved methodology established by Dodge et al. (2022) that the paper itself cites. A direct follow-up would instrument the same training runs with timestamps and match each watt-hour of consumption to the grid's marginal carbon and water intensity at that specific time. This would reveal whether the annual-average factors over- or under-estimate actual impacts, and by how much. For the Texas cluster specifically, where ERCOT has substantial solar capacity that varies diurnally, the error could be large—if training predominantly occurred during daylight hours, actual carbon intensity would be lower than the annual average; if during evening peaks, higher. The experiment requires: (1) timestamps for each training run's start and end, (2) access to ERCOT's time-resolved marginal emissions data (publicly available through the EIA and grid operator), and (3) ideally, sub-hourly power consumption data to match against sub-hourly grid intensity variations. A strong result would quantify the gap between time-averaged and time-resolved estimates for the authors' own training runs and provide guidance on when the simpler static approach is acceptable versus when it introduces material error.

Cross-organization development cost measurement. The paper's ~50% development-to-training ratio comes from a single organization. The most important open question is: what is this ratio for other developers, particularly those training the largest models? A follow-up study would recruit 5–10 organizations (academic labs, industrial research groups, and if possible, one large proprietary developer willing to disclose aggregated statistics without revealing proprietary details) to report their development GPU hours alongside their final training GPU hours for a recent model release. The goal is not to shame anyone—anonymized reporting would likely increase participation—but to establish the distribution of the development-to-training ratio across different development strategies, model scales, and organizational types. Key stratifying variables: use of AutoML or automated hyperparameter search (predicted to increase the ratio), use of scaling law experiments with discarded models (predicted to increase the ratio), maturity of the training pipeline (predicted to decrease the ratio), and target model size (the paper's own data shows the ratio is larger at larger scales; Table 1 shows ~70% of development cost concentrated at 7B/13B scales). The experiment would also need to standardize what counts as "development"—the paper includes hyperparameter tuning, architecture experiments, and scaling law runs, but different organizations may draw the boundary differently (e.g., does preliminary data exploration count? Do experiments on different datasets count?). A strong result would establish a plausible range for the ratio (e.g., "across 8 organizations, development costs ranged from 30% to 120% of final training costs, with a median of 55%") and identify the organizational practices that drive variation.

Power fluctuation characterization across frameworks and scales. The paper documents power fluctuations caused by checkpointing in its specific training setup (OLMo models on H100 GPUs with the authors' training code). How general is this pattern? A follow-up study would instrument training runs across multiple frameworks (PyTorch FSDP, DeepSpeed, JAX, Megatron-LM), multiple GPU types (A100, H100, and upcoming B200), and—crucially—multiple scales (from single-node to multi-thousand-GPU runs) to characterize the amplitude, frequency, and cause of power fluctuations. The key measurements: (1) what fraction of training time is spent in low-power states? (2) what is the amplitude of the power swing relative to active-training draw? (3) are the fluctuations periodic (checkpoint-bound) or also stochastic (e.g., from load imbalance in distributed training)? (4) how do these characteristics change as the number of GPUs scales from tens to thousands? The paper cites Dubey et al. (2024) documenting that Meta encountered similar issues from "checkpointing, awaiting collective communications, and other unforeseen and potentially catastrophic failures," suggesting the pattern is not unique to the authors' infrastructure, but systematic characterization is lacking. A strong result would provide guidance on which training configurations cause the most grid-stressing fluctuations and which engineering practices (parallelized checkpointing, gradient accumulation during checkpoint writes, staggered checkpointing across nodes) most effectively smooth them.

Full lifecycle assessment including non-GPU power, idle overhead, and end-of-life. The paper acknowledges that its numbers are lower bounds because they exclude CPU, RAM, networking, storage, idle cluster power, hardware transportation, and end-of-life disposal. Closing these gaps would require: (1) instrumenting a full training node (not just GPUs) to measure total server power, establishing the GPU-to-total power ratio for the authors' specific hardware; (2) measuring idle cluster power—energy consumed by GPUs that are powered on but not actively training—during the OLMo development period, to enable the kind of idle-overhead analysis Luccioni et al. (2023) provided for BLOOM; (3) obtaining or estimating transportation emissions for GPU shipments from manufacturer to data center; and (4) modeling end-of-life disposal impacts (e-waste processing, material recovery or landfilling) for the specific GPU models used. Some of these (idle power measurement) are straightforward if the data center provides aggregate power draw data; others (end-of-life modeling) may require lifecycle assessment expertise and external databases. The goal is not to achieve perfection—every lifecycle assessment has boundaries—but to quantify the magnitude of the gap between the paper's reported lower bounds and a more comprehensive estimate, so that readers can assess whether the excluded categories are 5%, 25%, or 50% of the total.

Water consumption break-even analysis paralleling the carbon break-even analysis. The paper computes break-even points for carbon emissions (number of inference queries to match training carbon) but not for water consumption, even though water is one of the paper's headline metrics and the geographic variation in water intensity is a key finding. The calculation is straightforward: divide total training water consumption (Table 2) by per-query inference water consumption (Table 3, which already reports per-benchmark water consumption that can be divided by 2,400 to get per-query). The interesting question is whether the carbon and water break-even points differ systematically. Given the paper's finding that carbon and water intensity can decouple (similar carbon intensity but 2.4× different water intensity between Texas and Iowa), a model trained in a high-water-intensity location but deployed for inference in low-water-intensity locations would have a longer water break-even than carbon break-even (the training water cost was high but each inference adds little water). Conversely, a model trained on hydropower (zero carbon, potentially high water if the reservoir evaporation is counted) would have an infinite carbon break-even but a finite water break-even. Computing these would reveal whether optimizing for carbon and water leads to different conclusions about the training-inference tradeoff, which has direct implications for data center siting decisions.

Impact of quantization and edge deployment on the break-even analysis. The paper's inference simulations use full-precision models served on H100 GPUs via SGLang. Real-world deployment often involves quantized models (INT8, INT4), different hardware (CPUs, edge accelerators, phone GPUs), and different serving patterns (on-device generation with no batching). A follow-up would replicate the break-even analysis for a representative set of quantized OLMo models running on: (1) the same H100 GPU (to isolate the quantization effect on energy), (2) a CPU-only server (to measure the energy cost of non-GPU inference), and (3) if feasible, a smartphone-class device (to approximate on-device deployment). The key measurement: how does quantization change the per-query energy, and does it shift the break-even point enough to change the conclusion about whether inference or training dominates total impact? A quantized model that uses 4× less energy per query has a 4× higher carbon break-even point, but if quantization enables much wider deployment (more total queries), the Jevons Paradox dynamic could swamp the efficiency gain. The experiment would need to estimate plausible total query volumes for different deployment scenarios, which is inherently speculative but can be bounded by published usage statistics for comparable deployed models.

Practical Applications and Downstream Use Cases

Environmental impact reporting standards for model release documentation. The paper provides a concrete template for what comprehensive environmental reporting for an LLM release should include: (1) final training run energy, carbon, and water, (2) development costs (GPU hours, energy, carbon, water, number of experiments), (3) embodied hardware impacts amortized over assumed lifespan, (4) data center-specific efficiency factors (PUE, CI, WUE_onsite, WUE_offsite) with their provenance, (5) measured rather than assumed power consumption, and (6) simulated inference costs under multiple deployment scenarios with break-even analysis. This is actionable immediately by any model developer with access to their own infrastructure data—no new tools or methodologies are needed, only the commitment to measure and report. The paper's own Tables 1, 2, and 3, with their specific columns and units, serve as a reporting template that could be adopted by model release documentation (model cards, technical reports) with minimal adaptation. The EU AI Act and proposed U.S. legislation like the Artificial Intelligence Environmental Impacts Act, which the paper cites (Section 5.1), are beginning to define voluntary reporting standards, and this paper's reporting structure provides a concrete example of what compliance could look like. For conference and journal publication of model-focused papers, venues could adopt a shortened version of this reporting as a submission requirement, similar to how reproducibility checklists are now standard.

Data center siting decisions informed by both carbon and water intensity. The paper's comparison of its Texas and Iowa clusters reveals that two locations with nearly identical carbon intensity (0.332 vs. 0.352 kg CO₂/kWh) can differ in water intensity by a factor of 2.4× (1.29 vs. 3.10 L/kWh). This has direct implications for organizations deciding where to build or lease data center capacity for AI training. A developer who considers only carbon intensity—perhaps because carbon reporting is more established or because corporate sustainability goals focus on carbon—might view Texas and Iowa as roughly equivalent and make the decision on other grounds (cost, latency, tax incentives). The paper's data shows this would be a mistake: training in Iowa would consume more than twice as much water per kWh as training in Texas, a difference that is invisible if water consumption is not measured and reported. Conversely, a data center in a region with hydroelectric power might have near-zero carbon but substantial water consumption if reservoir evaporation is counted—the LUMI-trained OLMo 7B (Table 2) had zero operational carbon but the paper does not report its water consumption, illustrating the gap. The practical application is to require data center siting decisions to evaluate both metrics using location-specific, publicly available grid data (from the EIA, Reig et al. (2020), and state-level sources), and to recognize that optimizing for one can worsen the other. The paper's Equations (2) and (3) provide the calculation framework; the specific CI and WUE factors for any candidate location can be looked up or estimated from the same sources the paper used.

Power-aware training scheduling to reduce grid stress and marginal emissions. The paper's finding that training power fluctuates dramatically with checkpoint saves (Figure 2) implies that training runs impose a shaped load on the grid, not a constant one. This is currently a problem—rapid fluctuations stress grid control and can force reliance on fossil fuel peaker plants—but it could also become a lever if training jobs are scheduled to align their power consumption patterns with grid conditions. A data center operator with multiple training jobs could stagger checkpoint saves across jobs so that the aggregate power draw remains relatively constant (when one job drops to 15% for checkpointing, another is at 85% for active training, and the sum stays flat). This requires coordination between job schedulers (e.g., SLURM, Kubernetes) and power monitoring infrastructure, but the monitoring infrastructure already exists (the paper uses sub-second power logging), and many data centers already have job schedulers that consider resource availability. The practical implementation would be a scheduler plugin that reads GPU power telemetry, predicts checkpoint timing based on step counts and job progress, and schedules jobs to minimize aggregate power variance. The paper cites that the authors "have since improved checkpointing performance" (Section 5.2) and notes new PyTorch features like PYTORCH_NO_POWERPLANT_BLOWUP, indicating that the training framework community is already aware of the issue and building mitigation tools. Making these tools standard in job schedulers would directly address the grid-stability problem the paper identifies.

Inference deployment planning using break-even analysis to anticipate total lifecycle impact. For organizations deploying LLMs at scale—API providers, enterprises embedding models in products, and platforms offering model access—the paper's break-even metric provides a practical tool for forecasting when cumulative inference emissions will overtake training emissions. The calculation is simple: total training CO₂e (which the model developer should report, following the paper's template) divided by per-query CO₂e (which the deployer can measure or estimate from hardware power draw and request volume). The paper's Table 3 provides reference values for per-query carbon across different models and request rates, giving deployers a starting point for estimation even without their own measurements. The actionable insight is that deployment planning should treat the break-even point as a milestone that triggers environmental review: when cumulative inferences approach the break-even number, the deployer should assess whether the total environmental impact is acceptable, whether inference optimizations (quantization, better batching, shifting to cleaner energy regions) have been exhausted, and whether the model's value justifies its ongoing impact. For models with very low break-even points—like OLMo 1 1B at 441 million queries (1 req/s), a figure that could be reached within days or weeks for a popular service—this milestone arrives quickly and should inform deployment strategy from the start. For models with very high break-even points—like Llama 3.1 8B at 9.12 billion queries (1 req/s)—inference optimization is still valuable but the training cost is so large that even significant inference inefficiency takes a long time to compound into a larger problem than the training was.