6.1.2 · D5Scaling & Efficient Architectures

Question bank — Compute-data-parameter tradeoffs

1,911 words9 min readBack to topic

Before you start, recall the pieces in play (build them fresh so no symbol is unearned):

  • = number of parameters (how big the model is — count of tunable weights).
  • = number of training tokens (how much text it reads).
  • = total training compute in FLOPs (floating-point operations, the raw "work" done), tied together by .

The figure below shows why balance matters: each penalty term is a curve, and the total loss has a single valley.

Figure — Compute-data-parameter tradeoffs

And here is the tradeoff itself — along the fixed-budget line , loss dips to a minimum at one split:

Figure — Compute-data-parameter tradeoffs

True or false — justify

Every statement below is either true or false. The reveal gives the reason, which is the whole point.

TF1. "At a fixed compute budget, doubling the model size always lowers final loss."
False. Fixed means doubling halves ; past the optimum the data-starvation term grows faster than shrinks, so loss goes up.
TF2. "The irreducible loss can be driven to zero with enough compute."
False. is the entropy of the language itself — inherent unpredictability that no model or data amount can remove; only the and terms vanish as .
TF3. "Chinchilla and GPT-3 differ because Chinchilla used far more total compute."
False. Chinchilla used roughly the same compute as GPT-3 but re-split it (smaller , larger tokens) — a better allocation, not more budget. See Chinchilla vs GPT-3.
TF4. "The exponents and in , must sum to 1."
True. Because , we need , forcing ; the derived , indeed sum to 1.
TF5. "Since and , data should grow slightly faster than model size as compute increases."
True. (barely), so tokens outpace parameters marginally — but both grow near , which is the real headline: scale them together.
TF6. "The factor 6 in counts fused multiply-adds."
False. It counts FLOPs (2 forward + 4 backward per parameter per token). In fused multiply-adds it would be 3, since 1 FMA = 2 FLOPs. See FLOP accounting in Transformers.
TF7. "If Chinchilla-optimal is best, you should never train past 20 tokens/parameter."
False. That optimizes training loss per FLOP. If inference dominates lifetime cost, deliberately over-training a smaller model (more tokens/param) is better — see Inference cost vs training cost.
TF8. "A model with lower training loss will always have lower loss at deployment scale."
False (as a blanket claim). Training-optimal minimizes loss for the training budget; a model chosen for cheap inference trades a little training loss for far lower serving cost.
TF9. "The scaling law is a proven theorem."
False. The constants and exponents are an empirical fit to observed runs — remarkably robust, but not derived from first principles, and it can break outside the fitted range.
TF10. "Because , adding data gives diminishing returns."
True. Loss falls like with , so each doubling of helps less than the last — the curve flattens.

Spot the error

Each line contains a flawed argument. The reveal names the flaw.

SE1. "GPT-3 had 175B params and 300B tokens, so 300B > 175B means it had plenty of data."
The comparison is tokens-per-parameter, not raw totals: , about 12× short of the ~20 target. Absolute sizes are meaningless without the ratio.
SE2. " is exact, so I can predict wall-clock training time to the minute."
is a leading-order estimate ignoring attention (scales with sequence length), embeddings, and hardware utilization. It's a planning tool, not a stopwatch. See FLOP accounting in Transformers.
SE3. "To find the optimal , I maximize and set the derivative to zero."
We minimize loss, not maximize it — lower loss is better. The zero-derivative condition finds the bottom of the loss curve, not a peak.
SE4. "I substituted then optimized over both and freely."
Once you substitute the constraint, is no longer free — it's determined by . You optimize over the single remaining variable . Optimizing both again double-counts the budget.
SE5. "Raw scaling-law fits sometimes report , so ."
Those tiny numbers are the slope of loss vs. in a differently-parameterized fit — a different quantity. The allocation exponent is , not itself.
SE6. "A tiny model on infinite data reaches zero loss because ."
Only the data term vanishes; the parameter term stays large for small , plus irreducible . Capacity, not data, becomes the bottleneck.
SE7. "Overfitting means the model memorized, so more parameters always overfit more."
At fixed compute, more parameters means less data per parameter — the failure mode is under-training / data-starvation, not classic memorization. Capacity and data must be balanced. See Overfitting and capacity.
SE8. "Since bigger models win benchmarks, scaling is the priority; data is secondary."
Benchmark leaders often had huge budgets, conflating more compute with more parameters. At equal compute, balanced scaling beats a giant, data-starved model.

Why questions

WQ1. Why does substituting the constraint before differentiating make the problem easier?
It converts a two-variable constrained minimization into a one-variable unconstrained one, so a single derivative-equals-zero condition suffices.
WQ2. Why is the minimum of the loss curve found where its slope (derivative) is zero?
A smooth curve turns from falling to rising at its lowest point, and exactly there its instantaneous slope is zero — that's what "bottom of the valley" means.
WQ3. Why does the backward pass cost roughly twice the forward pass ( vs )?
Backprop must compute gradients with respect to both the weights and the activations of each layer, roughly doubling the multiply-add work of the single forward pass.
WQ4. Why must model and data scale at nearly equal rates ()?
The loss-law exponents and are close, so and are both near ; neither penalty term dominates, so and each grow near . See Neural Scaling Laws.
WQ5. Why does the "20 tokens per parameter" rule flip when inference dominates?
20:1 minimizes training cost for a target loss. If the model serves billions of queries, a smaller model (cheaper per query) trained on more tokens amortizes better over its lifetime.
WQ6. Why can't you improve loss just by lowering the learning rate at fixed ?
The learning-rate schedule affects how well you reach the loss the data-and-size allow, not the floor itself. It's a separate lever. See Learning rate schedules.
WQ7. Why does the constraint act as a sanity check on any fitted allocation?
Because compute is literally proportional to ; any fit claiming would violate the definition and signals an error.
WQ8. Why is over-training a small model called "wasteful for training but smart for deployment"?
For a fixed training budget you'd reach lower loss by enlarging ; but deployment cost scales with per query, so the small over-trained model wins once inference volume is large.

Edge cases

Boundary and degenerate scenarios the reader must not be surprised by.

EC1. What happens to as with held finite?
The parameter term , so loss floors at — data-limited. Adding parameters beyond this buys nothing.
EC2. What happens as with held finite?
The data term , leaving — capacity-limited. The model saturates; extra data is wasted.
EC3. If (essentially no model), what does the law predict?
, so loss blows up — a model with no capacity can't fit anything, consistent with intuition.
EC4. Both and together — what's the loss?
It approaches , the irreducible entropy floor. That's the best any system can ever do; you can't beat the language's own randomness.
EC5. At zero compute (), what does force?
At least one of or is zero — no trained model exists, so the law only describes runs with genuine positive budget.
EC6. If your data is finite (you run out of unique tokens), does more compute still help via bigger ?
Only up to a point — repeating data yields diminishing gains and eventual overfitting; the balanced-scaling recipe assumes fresh tokens are available. See Overfitting and capacity.
EC7. Two runs share the same tokens/param ratio but different absolute sizes — same loss?
No. The ratio fixes the split, but larger absolute and (more total compute) still push both penalty terms lower, giving lower loss.
EC8. What if attention FLOPs are large (very long sequences)? Does still hold?
It underestimates, because attention cost grows with sequence length and isn't captured by the per-parameter count. Use as a floor and measure real FLOPs for long-context models.
Recall One-line survival summary

Fixed budget question ::: Split so tokens/param 20 (training-optimal); shift smaller-and-longer if inference dominates. The single most-missed trap ::: At fixed compute, bigger means smaller — "bigger is better" is false past the optimum.