Skip to content
AI.info

Generative AI

Scaling Laws, Data Budgets, and Compute Allocation

Interpret scaling results as empirical planning tools and connect model size, data, compute, and downstream serving cost.

By the end you can

Parameter count is only one coordinate of the training plan

More parameters do not settle the question. The cleanest demonstration is a published scaling prescription that a later experiment reversed.

Cross-entropy loss falls as a power law in model size, dataset size and training compute. That was the finding of Scaling Laws for Neural Language Models in 2020, fitted across trends spanning more than seven orders of magnitude. The prescription that came with it was explicit: “Larger models are significantly more sample-efficient, such that optimally compute-efficient training involves training very large models on a relatively modest amount of data and stopping significantly before convergence.”

Two years later Chinchilla overturned exactly that prescription. A larger model can underperform a smaller model trained on more appropriate data or for more tokens. How well the training goes depends on how model capacity, dataset size, optimization and compute are allocated together.

Note what did not fail in 2020. The power law was real. It was fitted over more than seven orders of magnitude, and it still did not survive a different allocation of the same compute.

That is what a scaling law is: an empirical trend inside a measured regime. It is useful for estimating tradeoffs. It is not a guarantee of product quality, safety, or transfer to a different architecture and data distribution. Kaplan and colleagues named their regime honestly. Readers two years later were the ones who treated it as permanent.

A parameter count without data, compute, objective, and evaluation context is not a capability explanation.

Visual

Four budgets constrain a foundation-model program

A decision that improves one stage can increase cost elsewhere. The link between training and serving has now been priced rather than merely asserted.

Serving cost belongs inside the law. Beyond Chinchilla-Optimal, from Sardana and colleagues in 2023, modified the Chinchilla laws to include inference and trained 47 models to validate the result: “We conduct our analysis both in terms of a compute budget and real-world costs and find that LLM researchers expecting reasonably large inference demand (~1B requests) should train models smaller and longer than Chinchilla-optimal.” In their analysis quality kept improving out to 10,000 tokens per parameter.

The number that moves the optimum is a demand forecast — roughly 1 billion inference requests — not an architecture choice. A team that expects that volume and optimizes the training budget alone will build the wrong model, correctly.

FigureLayers · 4 layers
  1. 01

    Data budget

    Available tokens, quality, rights, languages, and refresh possibilities.

  2. 02

    Training budget

    Accelerator time, energy, optimizer state, retries, and experiment overhead.

  3. 03

    Inference budget

    Latency, memory, throughput, context length, and generated tokens per request.

  4. 04

    Adaptation budget

    Post-training data, evaluation, safety testing, and downstream integration work.

Comparison

Three ways to spend additional compute

Each choice changes the evidence needed for success. Two of the three now have a measured limit rather than a caution.

Repeating data pays, and then stops paying. Scaling Data-Constrained Language Models, from Muennighoff and colleagues in 2023, ran roughly 400 training runs, up to 900 billion training tokens and 9 billion parameters: “We find that with constrained data for a fixed compute budget, training with up to 4 epochs of repeated data yields negligible changes to loss compared to having unique data. However, with more repetition, the value of adding compute eventually decays to zero.” Four epochs is a number to plan against. Past it, the compute is still spent and the loss stops moving.

Inference compute has a measured payoff and a stated precondition. Snell and colleagues allocated test-time compute per prompt according to difficulty and improved efficiency by more than 4x over a best-of-N baseline. That was 2024. The FLOPs-matched comparison is the striking one: “Additionally, in a FLOPs-matched evaluation, we find that on problems where a smaller base model attains somewhat non-trivial success rates, test-time compute can be used to outperform a 14x larger model.” Read the condition as carefully as the 14x. The payoff was measured on problems where the small model already had non-trivial success rates. That is precisely where extra deliberation has something to work with.

FigureComparison · 3 columns

Increase parameters

Expand capacity while keeping architecture broadly similar.

  • May improve loss within a scaling regime
  • Raises memory and serving demands
  • Needs enough training data and updates
  • Can increase fine-tuning and evaluation cost

Train on more tokens

Expose the model to more examples or repeated passes.

  • Can reduce undertraining
  • Data quality and duplication become limiting
  • Raises legal and provenance burden
  • May improve smaller models substantially

Spend more at inference

Generate candidates, deliberate longer, retrieve more, or use verifiers.

  • Targets difficult requests selectively
  • Adds latency and variable cost
  • Needs a stopping policy
  • Does not repair missing evidence automatically

Key idea

Compute-optimal is conditional, not eternal

Compute-optimal studies estimate how model size and token count should scale under specific objectives, architectures, datasets and budgets. Their conclusions can change when the recipe or the deployment goal changes. A product team should use such results as priors for experiments. It should not treat a fitted exponent as a law that overrides current data quality, inference constraints, or task evaluation.

There is a stronger reason than caution. The most-cited fitted coefficients in this literature failed a replication. Besiroglu and colleagues at Epoch AI tried in 2024 to reproduce the third estimation procedure behind Chinchilla, and reported: “We find that the reported estimates are inconsistent with their first two estimation methods, fail at fitting the extracted data, and report implausibly narrow confidence intervals”. The arithmetic of that last point is the memorable part. Intervals that narrow would require over 600,000 experiments. The Chinchilla authors likely ran fewer than 500.

The rederived law, L(N,D) = 1.8172 + 482.01/N^0.3478 + 2085.43/D^0.3658, is consistent with the paper's other two approaches. The headline finding survived; a set of published exponents did not. Anyone planning a budget from a third-party fit is planning from an estimate that carries error the paper may not have printed.

Scaling laws narrow a search space; they do not replace a workload-specific decision.

Case

Seventy billion parameters ahead of two hundred and eighty

Chinchilla is the worked example, and its numbers are worth carrying. A 70-billion-parameter model, trained on four times more data than Gopher at the same compute budget, scored 67.5% on MMLU. That is more than 7% above Gopher and its 280 billion parameters. The result held against GPT-3 (175B), Jurassic-1 (178B) and Megatron-Turing NLG (530B) as well. Hoffmann and colleagues published it in 2022.

The headline is not the finding. The experiment behind it is. Their abstract states the base and the rule in one sentence: “By training over 400 language models ranging from 70 million to over 16 billion parameters on 5 to 500 billion tokens, we find that for compute-optimal training, the model size and the number of training tokens should be scaled equally: for every doubling of model size the number of training tokens should also be doubled.” Four hundred models, three orders of magnitude of parameters, two of tokens. The verdict on the large models of the day was that they were significantly undertrained. Chinchilla's 70B against Gopher's 280B is that rule spent on the other side of the ledger: a quarter of the parameters, four times the data, one compute budget.

The 67.5% deserves the same treatment, because it is an average and not a score. MMLU was introduced in 2020 by Hendrycks and colleagues, and it covers 57 subjects. Their account of how it was built: “We collected 15908 questions in total, which we split into a few-shot development set, a validation set, and a test set. The few-shot development set has 5 questions per subject, the validation set may be used for selecting hyperparameters and is made of 1540 questions, and the test set has 14079 questions.” At least 100 test examples sit under each subject. So 67.5% is an average accuracy over 57 tasks scored on 14,079 test questions, and a margin of more than 7% over Gopher is a margin between two such averages. That is a far more interesting claim than a single number. It is also a far weaker one than a single number sounds.

Figure

The compute-optimal result in one picture: the smallest model on the list, and the two ratios that make its 4× data budget the interesting number.

Analogy

A factory can buy machines, materials, or operating time

A factory with a fixed capital budget can buy more machines, supply more materials, or run selected production lines for longer. Model capacity, training data and inference effort are the three purchases. They are worth costing separately.

The prices do not hold still. Materials get cheaper for the first four passes through the same stock and then buy nothing. Operating time is worth more than 4x its list price when it is spent on the hard orders, and close to nothing on the rest. And the machine you buy depends on how many orders you expect to fill. Model training is a coupled optimization process. The value of each resource changes with architecture and data quality.

Ask how each unit of compute changes the measured system, not merely how large the final model becomes.

Steps

Build a compute-allocation experiment

Compare alternatives under the same decision target. Every anchor above is an experiment someone ran because a plausible argument was not enough: over 400 models for the equal-scaling rule, roughly 400 runs for the repetition threshold, 47 models to price inference into the law. The steps below are the small version of the same discipline.

FigureProcess · 5 steps
  1. 1. Fix the product metric

    Choose a workload-shaped quality and safety target.

  2. 2. Define comparable budgets

    Include training, tuning, evaluation, and serving.

  3. 3. Vary one allocation

    Change model size, tokens, or inference effort while controlling the rest.

  4. 4. Measure the frontier

    Plot quality against cost, latency, and memory rather than one score.

  5. 5. Record the regime

    Document architecture, objective, data mixture, and extrapolation limits.

Scale creates options and obligations

Larger training programs can produce broad capabilities. They also increase data, evaluation, security and serving obligations. And the smaller model wins often enough that it deserves a named case rather than a hedge.

LLaMA is that case. Touvron and colleagues at Meta AI trained 7B–65B models in 2023 on trillions of tokens from publicly available datasets only, and reported: “In particular, LLaMA-13B outperforms GPT-3 (175B) on most benchmarks, and LLaMA-65B is competitive with the best models, Chinchilla-70B and PaLM-540B.” Thirteen billion parameters against 175 billion. The smaller model is also the one you can afford to serve.

Small models can dominate when latency, privacy or specialization matters, and the published record now says they can also dominate on capability at a fraction of the size. The next lesson examines benchmarks and contamination. A scaling claim becomes useful only when the evaluation evidence measures the behavior the product needs — which is why it mattered, above, that 67.5% turned out to be an average over 57 subjects and 14,079 test questions.

Key takeaways