DL0079 Scaling Laws Size vs Data

How do scaling laws relate model size to training data requirements?

Answer

Neural scaling laws say that test loss falls as a power law in both parameter count N and training tokens D, plus an irreducible floor, so the two are not independent knobs: a fixed compute budget C \approx 6ND forces a trade between them. Kaplan et al. (2020) fit the loss surface and concluded that most extra compute should go into parameters, which is why GPT-3 used 175B parameters on only about 300B tokens (roughly 1.7 tokens per parameter). Hoffmann et al. (2022, “Chinchilla”) re-ran the sweep with properly decayed learning-rate schedules over more than 400 runs and found the compute-optimal frontier scales both quantities at roughly the same rate, N_{opt} \propto C^{0.5} and D_{opt} \propto C^{0.5}, giving the well-known heuristic of about 20 tokens per parameter. Under that law a 70B model trained on 1.4T tokens beat a 280B model trained on 300B tokens at equal compute. The practical answer to the interview question is therefore: data requirements grow roughly linearly with model size along the compute-optimal frontier, and any deviation from that ratio should be justified by a constraint the loss law does not model, such as a finite corpus or the cost of serving.

(1) Joint Power Law: loss decomposes into an entropy floor plus one shrinking term per resource, L = E + AN^{-\alpha} + BD^{-\beta}, so starving either resource leaves its term dominant and no amount of the other resource can fix it.
(2) Compute Couples The Two: with C \approx 6ND FLOPs (2 for the forward pass and 4 for the backward pass per parameter per token), choosing N fixes D, which is why the question is always “what split”, never “how big”.
(3) IsoFLOP Minima Define The Frontier: sweeping N at fixed C traces a shallow U-shaped curve; the locus of minima across budgets is the compute-optimal frontier, and its slope in log-log space is the exponent you actually care about.
(4) Kaplan Versus Chinchilla: the earlier exponents (N_{opt} \propto C^{0.73}) came from a fixed-length cosine schedule truncated early and from parameter counts that excluded embeddings, both of which penalize the long-token runs and bias the fit toward oversized models.
(5) Optimal Does Not Mean Correct: the law optimizes training loss per training FLOP; it says nothing about inference cost, so serving-heavy models are deliberately overtrained far past 20 tokens per parameter.

The empirical procedure behind these numbers is worth stating precisely, because interviewers probe it. You pick a grid of compute budgets, and for each budget you train several models of different widths and depths, always to the token count that exhausts exactly that budget, with the learning rate decayed to its minimum at the end of each run. Plotting final loss against N for one budget yields an IsoFLOP curve whose minimum is flat enough that a factor of two in parameter count often costs under 1% in loss, which is exactly the slack engineers exploit when memory or latency constraints bite.

Four U-shaped IsoFLOP curves of loss versus parameter count on a log x-axis for compute budgets of 1e19, 1e20, 1e21 and 1e22 FLOPs, with minima marked and joined by a dashed frontier line moving right and down

Figure 1: Illustrative IsoFLOP curves from L = E + AN^{-0.34} + BD^{-0.34} with C = 6ND. Each budget’s minimum sits at D/N \approx 20, moving from 0.29B parameters / 5.8B tokens at 10^{19} FLOPs to 9.1B parameters / 183B tokens at 10^{22} FLOPs, and the basins are shallow near the optimum.

Mathematical Formulation:
L(N,D) = E + A N^{-\alpha} + B D^{-\beta}
C \approx 6ND
N_{opt} \propto C^{a}
D_{opt} \propto C^{b}
a = \frac{\beta}{\alpha + \beta}
b = \frac{\alpha}{\alpha + \beta}
D_{opt} / N_{opt} \approx 20

Where:

  • L(N,D) is expected test loss in nats per token, and E is the irreducible term: the entropy of the data plus whatever the architecture can never represent, so no scaling drives loss to zero.
  • N is the number of trainable parameters (embeddings included, which is where the Kaplan fit differed) and D is the number of training tokens.
  • A, B are fitted scale constants and \alpha, \beta are the power-law exponents; Chinchilla’s fit put both near 0.3, meaning the two resources have comparable marginal value.
  • C is training compute in FLOPs; the factor 6 comes from roughly 2 FLOPs per parameter per token forward and 4 backward, and it ignores attention’s quadratic term, which is minor while d_{model} dominates sequence length.
  • a, b are the frontier exponents obtained by minimizing L subject to the compute constraint; a + b = 1 always holds, so if parameters take a larger share of compute growth, tokens must take a smaller one.
  • The ratio D_{opt}/N_{opt} is constant only when \alpha = \beta; the “20 tokens per parameter” rule is that special case, and it drifts slowly with budget under asymmetric fits.
Log-log plot of compute-optimal parameter count and token count versus training compute from 1e19 to 1e25 FLOPs, with Chinchilla curves scaling as C to the 0.5 for both quantities and Kaplan curves scaling as C to the 0.73 for parameters and C to the 0.27 for tokens, diverging by more than an order of magnitude at high compute

Figure 2: Illustrative comparison of the two prescriptions, normalized to agree at 10^{19} FLOPs. Because the exponents differ (0.5 versus 0.73), the gap compounds: at 10^{24} FLOPs one recipe asks for 91B parameters on 1.8T tokens and the other for 1.3T parameters on 130B tokens, about a 14\times disagreement in both directions.

Modern frontier practice has moved past the compute-optimal point on purpose. If a model will serve billions of tokens, total lifetime FLOPs are dominated by inference, and a smaller model trained on far more data is cheaper end to end even though its training run is nominally suboptimal. Meta’s Llama 3 8B was trained on roughly 15T tokens, near 1,875 tokens per parameter, almost two orders of magnitude past the Chinchilla ratio, and the authors report the loss was still improving log-linearly at that point. The scaling law is still doing the work here; the objective being minimized has simply changed from training loss per training FLOP to quality per unit of deployment cost.

RegimeTokens Per ParameterWhat It OptimizesWhen It Is The Right Call
Kaplan-style (parameter-heavy)About 1 to 2Loss under a truncated schedule and an embedding-free parameter countEssentially never today; understand it to explain why GPT-3 looked the way it did
Chinchilla-optimalAbout 20Best loss for a fixed training budgetResearch runs, ablations, and any model whose main cost is the training job
Deliberately overtrained150 to 2,000 or moreQuality per unit of training plus inference costHigh-traffic serving, on-device targets, fixed memory or latency budgets
Data-constrainedSet by the corpus, not by computeLoss given a finite unique-token pool with repeated epochsSpecialist domains (code, medical, low-resource languages) where fresh tokens run out

Login to view more content


Log in to track your progress

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *