How would you split extra compute across pretraining, RL post-training and test time?

## Why there are three curves now The original scaling story was one curve: loss against pretraining compute. That framing has been superseded. Compute is now discussed as three layered regimes, each with its own inputs, its own returns and its own cost structure: 1. **Pretraining compute** — next-token prediction over a huge corpus. Sets the base of everything: world knowledge, language, latent skills. 2. **Reinforcement-learning post-training compute** — training after pretraining against a reward, most productively where outcomes can be checked automatically (code that passes tests, maths with a known answer, a tool call that succeeds). 3. **Test-time compute** — letting the model do more work on a single request before answering: longer deliberation, sampling multiple attempts, verifying and revising. They are layered, not alternatives. RL sharpens capabilities that pretraining put there; test-time compute exploits behaviours that RL taught the model to use productively. A model that was never trained to use extra deliberation well does not get much from being given more of it. ## Diagnose before allocating The allocation question is unanswerable in the abstract and quite tractable once you look at failures. A rough triage: - **The model does not know the thing.** Missing domain facts, an unfamiliar language, a niche codebase. This is a data-and-pretraining problem. Neither RL nor deliberation invents knowledge that was never present. - **The model can do it but does not do it reliably.** It succeeds sometimes, fails in ways that a checker could catch, wanders off format, gives up early. This is the RL regime's home ground, provided you can *score* success automatically. - **The model succeeds when it works longer.** Accuracy climbs visibly with more deliberation or more sampled attempts. Test-time compute is buying real accuracy here. - **The model succeeds but the harness fails it.** Bad tool descriptions, missing context, poor retrieval. This is an engineering problem masquerading as a compute problem, and it is by far the cheapest one to fix. It is also the most commonly misdiagnosed. ## The cost asymmetry This is the part that separates a principal-level answer. Pretraining and RL are capital costs: paid once, amortised across every request the model will ever serve. Test-time compute is an operating cost: paid on every single call, in money and in latency, forever. The consequence is that a quality improvement worth a fixed amount has wildly different prices depending on which curve you buy it from. At high traffic, moving a capability from test time into the weights — by training the behaviour in rather than eliciting it per request — is worth a large one-time investment. At low traffic or during exploration, the reverse holds: test-time compute needs no training run, ships immediately, and can be dialled per request class, which makes it the right first move for anything you might change your mind about. Test-time compute also has a distinctive property: it can be applied *selectively*. You do not have to pay it uniformly. Hard requests get more, easy ones get less. Nothing in the training-side regimes offers that granularity, and it substantially changes the effective economics. ## Where each regime actually binds None of the three is purely FLOP-limited: - Pretraining increasingly binds on the supply of high-quality tokens rather than on accelerators. - RL binds on **verifiable tasks and reward design**. Building a large set of problems whose success can be judged automatically, without exploitable shortcuts, is the hard part; reward hacking is the standard failure. Adding rollout compute to a badly specified reward makes the model better at gaming it. - Test-time compute binds on latency tolerance and on returns that flatten: past some depth of deliberation, extra thinking stops converting into accuracy, and on some tasks it actively hurts by talking the model out of a correct first answer. ## Be honest about the uncertainty The relative returns across the three regimes are not settled. RL post-training at scale is young enough that public evidence is thin and mostly vendor-reported. Test-time scaling curves are strong on verifiable domains — competition maths, code — and much weaker on open-ended judgement work where there is nothing to check against. Anyone offering you a clean allocation formula is overselling. What you can defend is the method: diagnose the failure class, cost the fix against traffic volume, prefer the cheapest regime that addresses the actual defect, and measure. ## What an interviewer wants to hear Not a ranking. They want to see you refuse to answer in the abstract, ask what is failing, distinguish capital from operating cost, note that test-time compute is the only one you can apply selectively per request, name the non-FLOP bottleneck in each regime, and admit where the evidence runs out.