Your weather AI is quietly guzzling the planet it's trying to model

The same AI model, trained to forecast the weather, can produce up to 30 times more carbon dioxide depending on where in the world its GPUs draw their power. Nothing about the model changes — not the architecture, not the data, not the math. The only variable is which electricity grid happens to be feeding the data center. And yet, in the booming field of AI for Earth system modeling, almost nobody is keeping track.

This is the message at the heart of a new practical guide from the Barcelona Supercomputing Center, written by Filippo Dainelli, Amirpasha Mozaffari, and colleagues. Their paper isn't a new model or a new dataset. It's something rarer and arguably more useful: an operational checklist for researchers who want to know what their code is actually costing the planetbies.

The paper arrives at a strange moment. Machine learning has conquered much of climate science. AI weather models now run 10-day global forecasts in minutes on a single GPU — work that once required thousands of CPUs. Ocean emulators simulate state-of-the-art climate components roughly 150 times faster than the numerical models they replace. These are remarkable efficiency gains. But the models are also enormous, trained on ever-larger hardware, and their training runs carry a carbon cost that is almost never reported. The researchers argue that if AI is to be a tool for understanding the environment, it cannot silently be a consumer of the very resources it studies.

The Science

Dainelli and Mozaffari (equal contributors, both at BSC) are not proposing new algorithms. Instead, they've done something methodologically humble and practically ambitious: they've gathered the scattered best practices from the "Green AI" literature — papers on sustainable machine learning, carbon accounting, energy-efficient model design — and distilled them into a single, stage-by-stage checklist for Earth system science.

The checklist is organized around six phases that track the natural life of an ML project: Scoping (problem definition and architecture choice), Data (collection and preprocessing), Training (model fitting and optimization), Evaluation (validation and benchmarking), Reporting (documentation), and Deployment (sharing and downstream use).

Eleven questions span these stages, each tagged to the earliest phase where it becomes actionable — a deliberate choice, because the researchers note that "the cost of revisiting an issue grows the further downstream it is caught." Five questions are flagged as "core": those marked with a star that demand attention first.

The paper grounds each question in real examples drawn from recent literature. When asking whether a practitioner really needs to train a model from scratch, they cite Aurora, a foundation model pretrained once over 2.5 weeks on 32 A100 GPUs, then fine-tuned to outperform from-scratch training by 54% on average. When asking whether all input features are necessary, they reference a cloud-cover parameterization study where sequential feature selection showed that just 4–10 of 24 candidate inputs matched the full network's performance.

What They Found

The paper's most striking findings come from pulling together numbers that are normally scattered across separate studies. Take scaling efficiency — a core question flagged for immediate attention. When you measure how much arithmetic work a model actually squeezes out of its hardware, the spread is extreme: one model (Aurora) sustains 37.2% of its GPUs' theoretical peak floating-point throughput, while another (GraphCast) manages just 1.03%, and a third (SFNO) a barely measurable 0.022%. Per GPU-hour, Aurora extracts roughly 36 times more useful arithmetic than GraphCast.

Much of this underperformance isn't a fundamental limitation of the models themselves — it's an input-pipeline artifact. Simply swapping in synthetic data to remove the data-loading bottleneck raised throughput for two different models by factors of 44 and 10 respectively. In one case, the researchers describe a data layout that required about ninety file opens per sample, leaving GPUs idle for most of each training step. Consolidating the data into fewer, larger files cut that to nine opens, raised weak-scaling efficiency from 69% to 86%, and was projected to cut a full training run from 54 hours to 1.3 hours — on bit-for-bit identical data.

GPU utilization: how efficiently three AI weather models use their hardware

Label	Value
Aurora	37.2
GraphCast	1.03
SFNO	0.022

Data: Yu et al., as reported in Dainelli & Mozaffari et al. (2026)

Training costs, when reported at all, are systematically understated. The researchers cite an analysis showing that final training runs accounted for only 9.6% of one major AI developer's 2024 R&D compute spending — and 12.3% and 22.6% at two smaller developers. That implies a reported training cost understates the real development footprint by roughly a factor of four to ten)Skip the failed experiments, the debugging, the hyperparameter searches, and you get a rosy picture. The researchers surveyed twelve frontier weather and climate models and found that three report no compute figure at all, and the rest report only the final run — no cumulative project total.

The paper also introduces a pragmatic answer to this undercounting: the Pragmatic Scaling Factor (PSF), a deliberately rough multiplier researchers can apply to a single reported training run to estimate the real project-wide footprint. It's not elegant — it's an explicit, honest guess — but it's far better than pretending the final run is the whole story.

The final training run is a fraction of the real compute cost

Label	Value
OpenAI 2024	9.6
Smaller developer A	12.3
Smaller developer B	22.6

Data: Denain & Wu (2024), as reported in Dainelli & Mozaffari et al. (2026)

Location matters enormously. Because grid carbon intensity varies so widely, the same energy consumption can produce vastly different emissions. The researchers recommend choosing computing locations with lower-carbon grids, noting that doing so requires "no change to the model" and has an immediate impact. They also flag the Power Usage Effectiveness (PUE) of data centers — the ratio of total energy consumed to energy delivered to IT equipment — with a global average around 1.57, meaning roughly 57% overhead on top of every kilowatt-hour that actually runs your code.

Why This Changes Things

The paper's deepest point is about the structure of decision-making in AI for climate science. Environmental impact isn't determined by optimization tricks at the end; it's locked in at the very beginning, often before a single line of code is written.

Consider the "data granularity" question. The researchers point out that ENSO-related sea surface temperature anomalies operate at basin scales that simply don't benefit from high-resolution data. Madden-Julian Oscillation tracking is well captured at daily or 5-day resolution given its 30–60 day propagation timescale. Seasonal-to-decadal variability studies only need monthly means. Yet the default in many projects is to grab the finest, densest, most expensive data available — which then needs to be stored, moved, and processed at every downstream step.

The same logic applies to input features. In the cloud-cover study, models using only 4–10 of 24 candidate inputs matched the performance of the full network — "demonstrating that the majority of the originally considered features contributed no significant improvement." Every unnecessary feature is compute time and storage that could have been spent elsewhere, or not spent at all.

Input pipeline, not the model, is often the bottleneck

Label	Value
GraphCast	1.03
SFNO (synthetic data)	44
Pangu (synthetic data)	10

Data: Yu et al., as reported in Dainelli & Mozaffari et al. (2026)

This is the paper's quiet radicalism: it reframes "efficiency" not as an afterthought but as a scientific virtue. A leaner model is not just cheaper — it's often more interpretable, more robust, and sometimes even more accurate. The researchers cite studies showing that models trained on compact feature subsets matched or exceeded the skill of models trained on larger candidate pools. Simpler 2D versions of the Pangu weather model achieved 20–30% computation reductionshol and a 40% smaller footprint. Training on a fraction of available data sometimes outperforms training on everything.

The framing also matters for the field's equity. "Red AI," as Schwartz et al. termed it, prioritizes accuracy at the expense of efficiency — which in practice means the field drifts toward whoever has access to the largest compute clusters. Green AI, by contrast, "lowers the barriers to participation." Efficiency isn't just environmentalism; it's democratization.

What's Next

The checklist is a starting point, not a finish line. The researchers are explicit about its limitations: the Pragmatic Scaling Factor is a guess, not a measurement. Embodied carbon — the emissions from manufacturing and disposing of hardware — relies on published life cycle assessments that vary in quality and are often hard to find. And the metrics, while well-established in the Green AI literature, still depend on researchers choosing to measure and report at all.

The biggest gap is cultural. The survey of twelve frontier weather and climate models — three reporting no compute figure, the rest reporting only final runs — shows how far the field is from transparency. The tools exist: CodeCarbon integrates directly into Python pipelines; the Green Algorithms calculator supports location-aware estimates; Electricity Maps gives real-time carbon intensity by region. What's missing is the habit of using them, and the expectation that they be used.

The paper's suggested next step is the model card — an extension of the framework Mitchell et al. proposed, adding energy and carbon footprint information to the standard documentation. For Earth science specifically, a datasheet format adapted for geoscience datasets (Connolly et al.) provides a starting point to which footprint data can be added. The ambition is modest: not a certification regime, just a norm. Report the full computational cost of the project, not just the final run. Share weights, code, and datasets so that expensive pretraining happens once and is reused indefinitely.

There's a pleasing symmetry to the argument. Climate science built its authority on measurement — on instruments, records, and rigorous accounting of the physical world. The paper asks that the field apply the same discipline to itself. If we can measure a tenth of a degree of warming to three significant figures, surely we can measure our own GPU-hours to one.

The open question the checklist circles but can't yet answer is whether AI's efficiency gains in Earth system modeling genuinely offset its training footprint. One early study found that, over a full lifecycle, the lower inference cost of data-driven weather models compensates for their training cost in the long term. Other figures complicate that: the 30x carbon multiplier based on grid location, the 36x gap in hardware utilization, the factor-of-four-to-ten understatement in reported training costs. The checklist exists precisely because the community doesn't yet have enough data to answer that question cleanly. The hope is that, with this tool in hand, researchers will start generating it.