What Are Train-to-Test (T²) Scaling Laws?

Train-to-Test, or T², scaling laws are a research framework for choosing a language model's size, training duration, and number of test-time samples under a shared compute budget. The central result is not that small models always beat large ones. It is that a model intended to generate many candidate answers may be cheaper overall when it is smaller and trained on more tokens than a training-only scaling rule would recommend.

The term comes from the 2026 preprint “Test-Time Scaling Makes Overtraining Compute-Optimal”. Its findings are empirical and task-dependent, so they should be treated as evidence for a design trade-off rather than a universal production recipe.

The gap between training and deployment

Pretraining scaling laws ask how to allocate a fixed training budget between parameter count and training data. The influential Chinchilla study, for example, found that model size and training tokens should grow together in its compute-optimal training setup.

Deployment introduces a second cost. Some systems generate several independent solutions and use a test, verifier, reward model, or other selection method to find a successful one. Larger models make every extra sample more expensive. A training plan that minimizes pretraining loss alone may therefore be a poor choice for a high-volume, repeated-sampling workload.

What T² optimizes

The T² framework models performance as a function of three linked variables:

• N: model size.
• D: the number of pretraining tokens.
• k: the number of samples generated at test time.

It then searches for a combination that fits an end-to-end budget containing both training and inference compute. Increasing N may improve each sample but also raises the cost of training and every deployment attempt. Increasing D spends more compute before deployment. Increasing k spends more compute per task in exchange for more chances to obtain a correct answer.

Why pass@k matters

pass@k measures the probability that at least one of k generated candidates passes an evaluation. It is common in coding tasks because candidates can be run against tests. If independent samples each have success probability p, the idealized probability of at least one success is 1 - (1 - p)k.

Real samples are not perfectly independent, and pass@k is not the same as user-visible accuracy. A system still needs a reliable way to identify the successful candidate. If no verifier exists, generating ten answers may simply create ten plausible outputs without revealing which one is right.

What the paper found

Across eight downstream tasks, the researchers found that accounting for repeated-sampling cost shifted the predicted optimum toward smaller models trained on substantially more data than standard pretraining-only guidance. They trained models in the predicted overtrained region and reported stronger performance than the pretraining-only allocation at comparable modeled budgets. The trend also remained after their post-training stage.

Those results support a conditional conclusion: when the workload benefits from repeated samples and model inference cost matters, extra pretraining for a smaller model can be compute-efficient. They do not show that any small model will outperform a frontier model, that every task benefits from sampling, or that the same optimum transfers unchanged to a different architecture, dataset, sequence length, hardware stack, or serving volume.

Where the idea is most relevant

• Code generation: compile or run tests against multiple candidates.
• Mathematics: verify a final value or proof step with a trusted checker.
• Planning and search: score several paths against explicit constraints.
• Agents: compare candidate tool plans when the environment returns objective success signals.

It is less directly useful for a conversational answer with no dependable verifier. More samples can improve diversity, but a model or human judge adds cost and can choose incorrectly.

Practical implications for model builders

1. Estimate expected lifetime traffic, input and output lengths, latency targets, and sampling count.
2. Define a task-level metric and the verifier used to select a result.
3. Benchmark several model sizes and training checkpoints on representative data.
4. Measure total cost per accepted solution, not only training loss or price per token.
5. Include post-training, serving hardware, batching, cache behavior, and failure retries.
6. Stress-test the fitted scaling law outside the samples used to estimate it before making a large training decision.

Prefix or KV caching can reduce repeated processing of shared prompt context, but it does not make the generated continuation free and does not remove the need to validate candidates.

Practical implications for application teams

Most companies will not pretrain a model, but they can apply the same accounting discipline. Compare a single call to a stronger model with several calls to a smaller one. Record accuracy, selector errors, latency at the median and tail, and total cost per successful task.

A routing system may be better than one fixed strategy: use a compact model for routine cases, retry only when verification fails, and escalate ambiguous work to a stronger model or human. TipsMake's comparison of the best large language models describes other selection criteria, while these compact local coding models illustrate why model size and deployment constraints matter.

Key limitations

• T² is a scaling-law forecast fitted to particular experiments, not a guarantee for every model family.
• High-quality training data can be limited, duplicated, or expensive to curate.
• Repeated sampling raises latency and operational complexity.
• Pass@k can overstate practical value when the selector is weak.
• Safety, calibration, privacy, and worst-case errors are not captured by one accuracy curve.

The useful lesson is to optimize the system that will actually run. Training compute, inference volume, verification, latency, and error cost belong in the same deployment decision.