Chinchilla Scaling Laws › The Chinchilla Scaling Equations

Michael BrenndoerferOctober 22, 20257 min read
Language AI HandbookAll chapters
Part 23 of 67Scaling Laws
Chapter 164Chinchilla Scaling Laws › The Chinchilla Scaling Equations
Reading section 3 of 12 · The Chinchilla Scaling Equations · 7 minSection 3 of 12 · 7 min

Book contents

Section 3 of 12 · 7 min read

Chinchilla Scaling Laws › The Chinchilla Scaling EquationsOne section · Sections in this chapter3 / 12 ↓
Reading tools Definitions & inline links

Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.

Article links

Make inline references clickable

All three experimental approaches yielded consistent conclusions about optimal scaling. The Chinchilla team derived that for compute-optimal training, both model size and dataset size should scale as power laws of the compute budget. This convergence across three independent methods is the strongest form of empirical evidence: not only did the team find a result, they found it three times, using three different experimental designs, and it came out the same each time.

The mathematical form of these relationships is a power law, the same functional family that the Kaplan paper found. Such relationships also appear throughout physics and economics, as well as biology, when quantities scale with each other. A power law relationship y∝xay \propto x^a says that when xx increases by a factor of 10, yy increases by a factor of 10a10^a. If a=1a = 1, they scale together linearly. If a<1a < 1, yy grows more slowly than xx. The scaling exponent aa therefore encodes the efficiency of converting one resource into another, and finding that exponent precisely is the core empirical contribution of the Chinchilla paper.

Before seeing the equations, notice an important structural constraint: compute CC is approximately equal to 6×N×D6 \times N \times D, where NN is parameter count and DD is training tokens. This means that if we increase NN and DD by some factors, compute increases by the product of those factors. Any claim about how NoptN_{opt} and DoptD_{opt} should grow with CC must be consistent with this multiplicative relationship. This constraint will force the scaling exponents aa and bb to satisfy a specific relationship, which we will work out below.

The Chinchilla team derived that for compute-optimal training, both model size and dataset size should scale as power laws of the compute budget:

Nopt∝CaN_{opt} \propto C^a Dopt∝CbD_{opt} \propto C^b

where:

  • NoptN_{opt}: the optimal number of model parameters for a given compute budget
  • DoptD_{opt}: the optimal number of training tokens for a given compute budget
  • CC: the total compute budget (in FLOPs)
  • aa, bb: scaling exponents that determine how parameters and data should grow with compute
  • The constraint a+b≈1a + b \approx 1 follows from C∝N×DC \propto N \times D (compute scales with the product of parameters and tokens)

These power law relationships mean that as your compute budget grows by some factor, both the optimal model size and dataset size grow by predictable amounts determined by the exponents aa and bb. The proportionality symbol (∝\propto) indicates that while we don't specify the exact constants, the scaling relationship holds. If you increase compute by a factor of 100, the optimal parameter count increases by 100a100^a and the optimal token count increases by 100b100^b.

The constraint that a+b≈1a + b \approx 1 is important because it comes from basic arithmetic rather than experiments. Since compute is approximately proportional to the product of parameters and tokens (C∝N×DC \propto N \times D), and since Nopt∝CaN_{opt} \propto C^a and Dopt∝CbD_{opt} \propto C^b, we have C∝Nopt×Dopt∝Ca×Cb=Ca+bC \propto N_{opt} \times D_{opt} \propto C^a \times C^b = C^{a+b}. For this equation to hold, we need a+b=1a + b = 1. This constraint means that the exponents aa and bb cannot be chosen independently. They must sum to one, representing different ways of dividing the same computational pie.

The Equal Scaling Exponents

The central finding was that a≈b≈0.5a \approx b \approx 0.5, meaning model size and dataset size should grow at roughly the same rate with compute. This stands in stark contrast to the Kaplan scaling laws, which suggested a≈0.73a \approx 0.73 and b≈0.27b \approx 0.27, implying model size should grow much faster than dataset size.

Consider what this means in practice. With Chinchilla scaling (equal exponents around 0.5), if you increase your compute budget by a factor of 100, you should increase both your model size and your dataset size by a factor of 10 (since 1000.5=10100^{0.5} = 10). With Kaplan scaling (unequal exponents), the same 100x compute increase would suggest increasing model size by about 50x (1000.73≈50100^{0.73} \approx 50) but dataset size by only about 2x (1000.27≈2100^{0.27} \approx 2). The difference matters: Kaplan scaling funnels most additional resources into model capacity, while Chinchilla scaling distributes resources evenly between capacity and training data.

Out[6]:
Visualization
Pie or bar chart showing Chinchilla compute allocation split evenly between model parameters and training tokens.
Chinchilla scaling allocates compute growth evenly between parameters and data (a ≈ b ≈ 0.5).
Pie or bar chart showing Kaplan compute allocation heavily weighted toward model parameters over training tokens.
Kaplan scaling heavily favors parameters over data (a ≈ 0.73, b ≈ 0.27).

Fitting the parametric loss model to experimental data yielded:

α≈0.34,β≈0.28\alpha \approx 0.34, \quad \beta \approx 0.28

where:

  • α\alpha: the exponent governing how loss decreases with model size (from the A/NαA/N^\alpha term)
  • β\beta: the exponent governing how loss decreases with training data (from the B/DβB/D^\beta term)

These exponents determine how quickly each source of error decreases as we add parameters or data. The relatively similar values explain why balanced scaling is optimal: neither parameters nor data provide much faster diminishing returns compared to the other. If α\alpha were much larger than β\beta, it would mean that increasing model size reduces loss much faster than increasing data, and we should favor parameters. If β\beta were much larger, we should favor data. But with α≈0.34\alpha \approx 0.34 and β≈0.28\beta \approx 0.28, both resources contribute roughly equally to loss reduction per unit of compute invested, so we should invest roughly equally in both.

Optimal Tokens Per Parameter

The most practical finding from Chinchilla is the optimal ratio of training tokens to model parameters. The analysis suggests:

DoptNopt≈20\frac{D_{opt}}{N_{opt}} \approx 20

where:

  • DoptD_{opt}: the optimal number of training tokens
  • NoptN_{opt}: the optimal number of model parameters
  • The ratio of 20 emerges from the balanced scaling exponents (a≈b≈0.5a \approx b \approx 0.5)

This means a compute-optimal model should be trained on approximately 20 tokens per parameter. A 1 billion parameter model should see roughly 20 billion tokens, a 10 billion parameter model should see 200 billion tokens, and so on.

This ratio provides a practical guideline: before training any model, you can estimate whether your training corpus is appropriately sized. Multiply your planned parameter count by 20, and that's roughly how many tokens you need for compute-optimal training. If you have fewer tokens available, you're training a model too large for your data. If you have many more tokens, you might benefit from a larger model.

This ratio is remarkably consistent across scales. The team found that deviating significantly from this ratio leads to compute inefficiency: either the model is too small to fully utilize the available training signal, or too large to be trained adequately given the data budget. The intuition is that each parameter represents a "slot" for storing learned knowledge, and 20 tokens provides enough gradient signal to fill that slot effectively. Too few tokens means the slot remains partially empty; too many tokens means the model cannot store all the patterns it could learn.