Day 23 — The Model Keeps Its Environmental Receipts
Day 22 opened the first embodied category by putting the silicon in the rack on the ledger, and named the two levers behind it: how long the hardware runs, and the grid it runs on. Today’s issue turns to the second embodied category. The model itself.
Every model in production was trained. That training was a paid event. It drew power, generated heat, and left an emissions footprint that closed the moment the run finished. The model then went into service, carrying that footprint with it for the rest of its life. Every subsequent inference is drawn against the training bill that has already been paid. The model keeps a receipt for what its existence cost, and that receipt sits on the ledger whether the model serves a billion queries or ten thousand. This issue is about that receipt: what is on it, who carries it, how thinly it can be spread, and how it sits alongside the operational cost the model draws every time it runs.
Foundation models were trained on thousands of accelerators for weeks or months. Fine-tuned variants were trained on smaller fleets for shorter runs. Distilled models were trained by having larger models teach them. Embedding models, reranker models, safety classifiers, guardrail models, and every specialized head sitting alongside the primary model in a production stack. All of them arrived in production carrying a receipt.
For low-volume models, the training footprint can dominate lifetime emissions. For high-volume models, cumulative inference emissions surpass training emissions, often within months of deployment. Training carbon is a fixed cost that amortizes across the queries the model serves: the more inferences, the smaller the training-share-per-query. Operational inference carbon is a variable cost paid fresh from the grid on every query: the more inferences, the higher the total. Both belong on the ledger. Confusing the two produces the wrong decision.
A product team ships an AI feature backed by three models. The primary model is a proprietary foundation model accessed by API. The retrieval layer uses an open-weights embedding model, self-hosted. A safety classifier, fine-tuned in house on a smaller open-weights base, runs alongside every request. The team has been diligent about operational efficiency. Prompt caching is enabled. Right-sizing is done. Utilization is monitored.
The sustainability review asks a question the team has not yet costed. What is the training footprint of each model in this feature, and how is that training-share being amortized against the feature’s inference volume?
The answers surface three distinct sub-patterns, each with a different receipt.
The foundation model, borrowed at scale. The primary model was trained by the vendor. The published estimates for training runs at that model class fall in the range of hundreds to low thousands of tonnes of carbon dioxide equivalent, depending on the run and the grid it ran on. That fixed training footprint is amortized by the vendor across every customer using the model, so the team’s training-carbon-share per inference is small. The team’s operational inference carbon, the electricity drawn every time a query runs, is a separate number that scales with volume and belongs entirely to the team’s own bill. The team had not asked the vendor for a per-inference training-share number, and the vendor had not published one.
The open-weights model, adopted freely. The embedding model was open weights. The training footprint had been paid, once, by the original research team that produced it. Every downstream user, including this team, inherited the model with its training cost already spread across the entire community of adopters. A widely-used open-weights model amortizes its training footprint into a small share per inference. A rarely-used one does not. This says nothing about operational inference carbon, which every query pays fresh from the grid every time it runs. High adoption thins the training share. It does not touch the operational one.
The fine-tune, paid in full. The safety classifier was fine-tuned in house. The training run was modest compared to a foundation model, but it was paid entirely by this team, against this feature, on this fleet. If the feature served ten million inferences a year, the fine-tune’s training share per inference was small. If the feature was quietly retired in nine months, that same training footprint landed against a much smaller denominator. Operational inference carbon on the safety classifier is again a separate line, drawn from the grid on every request.
A trained model is a fixed cost paid in advance. Its training carbon amortizes across every inference the model serves. Its operational carbon is paid fresh on each query. Both are on the ledger. Confusing the two produces the wrong decision.
The obvious objection is that training footprints are the vendor’s problem, and open-weights models arrive free of embodied cost to the adopter. Neither is quite true. The vendor’s training footprint is disclosed (increasingly) and adopters can and should account for their training-share. Open-weights training is paid by someone, and the community of adopters collectively determines whether that payment was worth its emissions. A model downloaded a hundred million times amortized its training footprint into a small share per inference. A model downloaded a hundred times did not. The operational inference carbon each downloader pays is a separate number, unaffected by how many others also use the model.
The Grid the Model Was Trained On
Training carbon depends on the grid the training ran on, in the same way inference carbon depends on the grid the inference runs on. The two grids are not always the same.
A foundation model trained on a hyperscaler’s clean-grid region carries a fraction of the training carbon of an identical model trained on a coal-heavy grid. Vendors that publish training-region and grid intensity make it possible to distinguish a low-carbon training run from a high-carbon one. Vendors that do not publish it leave the number to estimation.
For a team choosing between models of comparable capability, the training grid is a legitimate decision input. For a team producing its own training or fine-tuning runs, the training grid is a lever the team directly controls, by choosing when and where to schedule long runs. Batch training is a natural candidate for carbon-aware scheduling: it is not latency-sensitive, and it can wait for a cleaner window on the grid.
Four rungs move training footprint from an off-book cost into a first-class number, sitting alongside the operational number rather than replacing it.
Attribute. Every model in the production stack has a training footprint that belongs somewhere. Foundation models carry an attributable training-share from the vendor’s disclosed run, apportioned across customers. Open-weights models carry a community-amortized share, small when adoption is wide and larger when it is not. Self-trained and fine-tuned models carry the full training footprint against the team that trained them. The attribution rule does not need to be exact. It needs to be written down. And it must sit alongside the operational per-inference number, not replace it.
Reuse. The single largest training-footprint lever is not training again. Reusing an existing model, whether a foundation model, an open-weights base, or a previously fine-tuned artifact, avoids a full training run. Every project that starts by asking “what can we adopt or fine-tune?” instead of “what can we train?” is a project that has taken the largest embodied action available before writing a line of code. The reuse decision is often framed as an engineering trade-off. It is also a carbon decision. Note that reuse changes the training footprint, not the operational one. A reused model still draws power on every inference.
Right-size the Run. When training or fine-tuning is genuinely justified, the size of the run is a choice. Training a model larger than the task requires wastes both compute and embodied footprint, and often adds operational cost on every subsequent inference too, because a larger model draws more power per query. Fine-tuning on more data than the task requires wastes both. Choosing efficient training strategies (LoRA and other parameter-efficient methods, distillation from an existing capable model, curriculum sampling to reduce total training tokens) reduces the footprint of the run without reducing the quality of the outcome. The greenest training run is the one sized to the problem, not to the ambition.
Amortize. A training footprint is only carried lightly if the model serves enough inferences to spread it. A model that ships and is used heavily amortizes its training footprint against billions of queries. A model that ships and is quickly deprecated carries the full training footprint against a small denominator. Model lifecycle decisions (which model to promote to production, which to retire, which to replace with a fine-tune of a newer base) are amortization decisions. Retiring a model that no longer serves its purpose frees the artifact, but it does not free the carbon. That carbon was paid at training time and lives on the ledger regardless.
Training footprint crosses every seat at the table. It has usually been claimed by none of them by default.
Engineering. The choice between adopting a model, fine-tuning a base, or training from scratch becomes a design-review question with a carbon dimension. Every new model in the stack carries a training-footprint share that engineering owns during design and platform inherits during operation. Every model in the stack also draws operational carbon on every inference, which is a separate number owned in parallel.
Architecture and CTO. Model portfolio management joins the architecture conversation. A stack with three models has three training footprints and three operational profiles. A stack that consolidates to two has two of each. Model consolidation is an embodied-carbon decision and an operational one, not only a complexity one.
Platform and Infrastructure. Training and fine-tuning runs are provisioned, scheduled, and metered. Scheduling long training runs into clean-grid windows becomes a first-class capability, not an afterthought. Model registries carry an embodied number and an operational-per-inference number alongside the version tag.
Sustainability and ESG. The reporting boundary extends from operational inference and hardware embodied carbon to trained-model embodied carbon. Vendor disclosure requests now include per-model training footprints and training-region grid intensity. Reports distinguish training-share-per-inference from operational-carbon-per-inference, because collapsing them understates the true operational cost of high-volume models.
Business and Product. The decision to launch a new model-backed feature is a decision to carry a training footprint until the feature is retired, and to pay operational carbon on every inference the feature serves for as long as it lives. Features that ship and grow spread their training footprint thin but grow their operational total. Features that ship and stall do neither well. Product roadmap and Total Footprint of Ownership are the same conversation.
Five seats, one model.
The work begins with a model inventory and ends with two numbers per model, kept separate.
List every model in the production AI stack. For each, record five items. Training origin (vendor, open-weights community, or in-house). Training footprint (disclosed, estimated, or community-amortized). Training grid intensity (where known). Current inference volume served by the model. Operational carbon per inference (from the operational bill).
For each model, compute two numbers. The training-share-per-inference by dividing the attributable training footprint by expected lifetime inferences. And the operational-carbon-per-inference from the current operational bill. Order the list by the sum of the two, but present them as two columns so the trade-off between them stays visible.
Pick the top entry. If it is a self-trained or fine-tuned model, ask two questions. Could an adopted alternative have served? And is the inference volume large enough to amortize the training footprint the team paid? If either answer is uncomfortable, the decision to train that model is worth revisiting for the next iteration.
Document the model inventory, both numbers, and the reuse policy in the AI model governance guidelines.
One inventory, two numbers, one policy. That is the work.
Training is a fixed cost that amortizes. Inference is a variable cost that accumulates. The ledger needs both.
Day 24 continues the embodied arc, staying with the receipts that get left on the ledger long after the decision that created them has been forgotten.