6.1.2 · D4Scaling & Efficient Architectures

Exercises — Compute-data-parameter tradeoffs

1,900 words9 min readBack to topic

Quick reference (everything you need, no other page required):

Figure — Compute-data-parameter tradeoffs

The picture above is the whole story: a fixed budget is a curve (a hyperbola, because is constant) in the plane. Every point on that curve is a legal "spend" of the same compute. The red dot is the compute-optimal split. Move away from it in either direction and loss goes up.


Level 1 — Recognition

Recall Solution 1.1

What they got right: the forward pass really is FLOPs per token (one multiply + one add per weight = 2 FLOPs). What they missed: training also runs a backward pass to compute gradients, costing about FLOPs per token (gradients w.r.t. weights and activations, roughly twice the forward cost). Correct constant: FLOPs per parameter per token, so . Their counts inference-style forward-only compute, not training.

Recall Solution 1.2

False. is the irreducible loss — the entropy of language itself. The two shrinking terms and both vanish as and , but has no or in it, so no amount of compute touches it. It is the floor every model asymptotes toward.


Level 2 — Application

Recall Solution 2.1

Why start from the ratio? It fixes the shape of the split so we have one unknown. Set . So parameters, and tokens. Check: ✓.

Recall Solution 2.2

Ratio: tokens/param. FLOPs: FLOPs. Verdict: Chinchilla-optimal is ~20 tokens/param; this run uses 200, i.e. 10× more data than "training-optimal." So the model is heavily over-trained (small model, lots of data). This is not "wrong" — it is exactly the deployment-optimal choice when you plan to serve the model a lot.


Level 3 — Analysis

Recall Solution 3.1

From :

  • Run A: . Ratio .
  • Run B: . Ratio . Optimal ratio is ~20. Run A (2.8) is too big/data-starved; Run B (44) is too small/over-fed. Both miss, but A is ~7× below optimum and B is ~2× above it — Run B is closer, so at equal compute Run B should reach the lower loss. (The true optimum is near ; see Example 2 in the parent.)
Recall Solution 3.2

Why: the constraint says . If and , then For this to be proportional to (which the constraint demands), we need . It is a conservation statement: the two growth rates must exactly split the compute exponent between them. Numeric: ✓. This is why "both grow at roughly equal rates " — the budget forces them to share the exponent.


Level 4 — Synthesis

Recall Solution 4.1

Step 1 — differentiate. What: take . Why: the minimum of a smooth curve of loss vs. has zero slope. ( is constant so its derivative is 0; the second term uses so its derivative brings down .) Step 2 — set to zero and separate. Why: find where slope . Step 3 — collect powers of . Divide both sides by : Step 4 — isolate . Raise both sides to power : With : exponent , matching the reported .

Recall Solution 4.2

, so grows by ; , so grows by . Model grows ~2.6×, data grows ~3.1×. Verify: ✓ (since ). Neither dominates — both scale up, consistent with .


Level 5 — Mastery

Recall Solution 5.1

(a) Training: FLOPs. Inference: FLOPs. Ratio (inference / training): . Inference dominates by ~83×. (b) Why smaller ? Inference cost scales with linearly and forever ( every time you serve), while training pays only once. When inference dwarfs training, shrinking saves compute on every future forward pass. To keep loss low with a smaller model you compensate with more data (over-train), which is exactly the LLaMA-style choice. So the training-optimal 20-tokens/param is not the lifetime-optimal split — see Inference cost vs training cost.

Recall Solution 5.2

Compute each term. With : . , so . Thus . : , , so . Design Q: : , , . : , , . Design P wins (): the balanced ratio-20 design beats the huge-but-starved design at (nearly) matched compute. This matches the intuition — Q spent too much on and starved , inflating the term. See Overfitting and capacity.