Carbon budgets for AI model training runs

A carbon budget turns sustainability from a reporting afterthought into a design constraint for machine learning teams. The request usually arrives from three directions at once: the sustainability team needs energy and emissions figures it can defend in CSRD disclosures, customers and partners ask how much carbon their models carry, and the ML platform team wants to compare hardware, region and checkpointing choices on something other than wall-clock time. A budget makes those trade-offs explicit before a run starts rather than after the invoice.

The data is not naturally available. Training runs spread across many GPUs and nodes, power draw varies with utilisation, shared clusters run other tenants, the facility adds cooling and distribution losses through PUE, and the grid intensity at the training location changes hour by hour. Embodied emissions from the hardware add a further allocation problem. Tools either measure power at the node or GPU level and multiply by an intensity factor, or estimate from configuration and duration; the difference decides whether the number can survive an audit.

The common failures are scope failures. A tool measures only the training process while the node idles at high power, uses a national annual average instead of the hourly regional signal, or amortises embodied emissions on assumptions that nobody recorded. Budgets are rarely enforced: the tool reports after the fact but cannot stop or throttle a run that has already exceeded its allowance, and the resulting figure cannot be reproduced when a customer asks for the basis of a claim.

Evaluate tools on measurement coverage, intensity data, embodied emissions method, budget enforcement, reproducible reporting and integration with the training stack.