The Compute Budget Your AI Team Is Not Reporting: Why Post-Training Costs Are Reshaping Infrastructure Decisions

Enterprise AI teams have become reasonably disciplined about estimating pretraining costs. GPU hours are tracked, cloud spend is reconciled, and carbon disclosures increasingly reference training runs as the primary unit of environmental impact. The problem is that pretraining is no longer where most of the compute goes. As post-training pipelines grow in complexity, the gap between what teams report and what they actually consume is widening in ways that directly affect infrastructure planning, vendor negotiations, and ESG commitments.

The 82% Problem: What Full Pipeline Accounting Reveals

The conventional framing treats a training run as the dominant cost event, with fine-tuning as a relatively minor line item. Recent empirical work challenges that framing directly. Morrison et al. (arXiv 2026) studied the full development pipeline for OLMo 3, a 7B and 32B parameter model family, and found that development costs including experimentation, failed runs, and ablations account for 82.2% of total compute. That figure represents roughly a 65% increase over the approximately 50% share attributed to non-pretraining activity in earlier pipeline analyses.

The mechanism is straightforward. Modern post-training pipelines are iterative by design. Teams run supervised fine-tuning experiments to identify optimal data mixtures, preference optimization passes to align model behaviour, and reinforcement learning stages to shape reasoning quality. Each of these stages generates failed runs and intermediate checkpoints that consume real compute even when they produce no deployable output.

For a CTO responsible for infrastructure cost governance, this means that any budget model anchored to training runs is systematically underestimating actual consumption. The error is not marginal. It is structural.

Reasoning Models Carry a Post-Training Penalty of a Different Order

Instruction-tuned models and reasoning models are not equivalent in their post-training cost profiles. Morrison et al. (arXiv 2026) found that reasoning model variants of OLMo 3 were 17 times more expensive to post-train than their instruction-tuned counterparts, measured in datacenter energy. The driver is reinforcement learning rollout generation, which requires the model to produce extended chain-of-thought outputs at scale during training, not just at inference time.

This matters because reasoning model adoption is accelerating across enterprise deployments. Teams commissioning reasoning-capable fine-tunes for complex document analysis, code generation, or multi-step decision support are implicitly accepting a post-training cost structure that is an order of magnitude larger than what they may have budgeted based on instruction-tuning benchmarks.

The infrastructure implication is that reasoning model development requires dedicated capacity planning for the RL training phase, not simply an extension of the compute allocation used for supervised fine-tuning.

The Environmental Accounting Gap

The full OLMo 3 development pipeline consumed approximately 12.3 GWh of datacenter energy, emitted 4,251 tCO2eq, and consumed 15,887 kL of water (Morrison et al., arXiv 2026). Notably, the water consumption figure is driven by power generation infrastructure upstream of the data center, not by on-site cooling systems. This distinction matters for scope 3 emissions reporting, where the boundary between direct and indirect consumption is often contested.

What Goes Unreported

The authors note that these costs are almost entirely unreported by model developers. The pattern is consistent with how environmental disclosures have historically treated AI: pretraining gets counted because it is a discrete, visible event. Experimentation and ablations do not get counted because they are diffuse, iterative, and harder to attribute.

The ESG Reporting Consequence

For enterprises with public sustainability commitments, this is a material reporting risk. If your AI development activity is commissioning or running fine-tuned model development, and your carbon accounting captures only the final training run, your disclosed figures are likely understating actual emissions by a factor that scales with pipeline complexity.

What Accurate Accounting Requires in Practice

Closing the measurement gap requires instrumentation at the experiment level, not just the job level. GPU utilisation, energy draw, and wall-clock time need to be captured for every run in the development pipeline, including the ones that are cancelled or discarded. Most MLOps platforms support this in principle, but teams rarely configure cost and energy tagging with the granularity needed for full attribution.

Compute budgets should be structured to distinguish between four categories: pretraining, post-training development (experimentation and ablations), post-training production runs (the final fine-tuning and alignment passes), and inference. Each has a different cost profile and a different relationship to model quality outcomes. Conflating them makes it impossible to identify where efficiency improvements would have the largest impact.

Teams adopting reasoning models specifically should model post-training compute as a multiplier on their instruction-tuning baseline, not as a fixed overhead. The 17x figure from Morrison et al. (arXiv 2026) is a reference point for a specific model family and pipeline, but the directional implication holds across architectures: RL-heavy post-training is expensive in ways that standard fine-tuning cost models do not capture.

Infrastructure Planning Under Full-Cost Visibility

Once teams have accurate pipeline-level cost data, several infrastructure decisions become clearer. On-premise GPU capacity sizing needs to account for the burst demand of RL rollout generation, which is both compute-intensive and difficult to schedule predictably. Cloud burst strategies that look cost-effective when scoped to training runs may look less attractive when the full experimentation overhead is included.

Vendor negotiations for reserved capacity also change character when you have full pipeline visibility. If 82% of your compute is consumed by development activity rather than production training, the utilisation profile you present to a cloud provider is fundamentally different from what a training-run-centric model would suggest. That affects the economics of reserved versus on-demand pricing.

The broader point is that infrastructure decisions made on incomplete cost data will be systematically miscalibrated. Full pipeline accounting is not primarily an environmental compliance exercise. It is the foundation for making defensible infrastructure investment decisions.