Chinchilla Scaling Laws › The Chinchilla Scaling Equations
Language AI HandbookAll chapters 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 says that when increases by a factor of 10, increases by a factor of . If , they scale together linearly. If , grows more slowly than . The scaling exponent 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 is approximately equal to , where is parameter count and is training tokens. This means that if we increase and by some factors, compute increases by the product of those factors. Any claim about how and should grow with must be consistent with this multiplicative relationship. This constraint will force the scaling exponents and 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:
where:
- : the optimal number of model parameters for a given compute budget
- : the optimal number of training tokens for a given compute budget
- : the total compute budget (in FLOPs)
- , : scaling exponents that determine how parameters and data should grow with compute
- The constraint follows from (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 and . The proportionality symbol () 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 and the optimal token count increases by .
The constraint that is important because it comes from basic arithmetic rather than experiments. Since compute is approximately proportional to the product of parameters and tokens (), and since and , we have . For this equation to hold, we need . This constraint means that the exponents and 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 , 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 and , 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 ). With Kaplan scaling (unequal exponents), the same 100x compute increase would suggest increasing model size by about 50x () but dataset size by only about 2x (). The difference matters: Kaplan scaling funnels most additional resources into model capacity, while Chinchilla scaling distributes resources evenly between capacity and training data.


Fitting the parametric loss model to experimental data yielded:
where:
- : the exponent governing how loss decreases with model size (from the term)
- : the exponent governing how loss decreases with training data (from the 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 were much larger than , it would mean that increasing model size reduces loss much faster than increasing data, and we should favor parameters. If were much larger, we should favor data. But with and , 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:
where:
- : the optimal number of training tokens
- : the optimal number of model parameters
- The ratio of 20 emerges from the balanced scaling exponents ()
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.