Advanced

Scaling laws III: inference-aware & over-training

When deployment demand matters, training and architecture choices can reduce recurring serving cost; Qwen3.8-27B’s GQA and 3:1 hybrid layout have measurable cache consequences, while their historical rationale is unpublished.

Updated

01 · Concept

Concept

Training-compute optimality asks how to get the lowest loss out of a fixed pretraining budget. A deployed model has a much longer life than that question imagines. Training happens once. Inference happens for every prompt and every generated token, on every replica, for as long as the checkpoint is served. If demand is large, the recurring bill dwarfs the one-time one, and the optimization target has to include both.

The standard framing writes lifetime cost as

Clife=Ctrain(N,D)+RCinfer(N,L),C_{life}=C_{train}(N,D)+R\,C_{infer}(N,L),

with RR the expected inference volume and LL capturing prompt and output lengths. Sardana and collaborators modified Chinchilla-style analysis along exactly these lines, trained models at high token-to-parameter ratios to validate the behaviour, and reported that sufficiently large inference demand shifts the preferred solution toward smaller models trained on more data. Their crossover point is conditional on their costs, fits, and workload assumptions — but the direction is structural, not incidental.

That is the version of inference-aware scaling everyone quotes, and it treats NN as the only lever: pick fewer parameters, feed more tokens, accept a bigger training bill in exchange for a cheaper forward pass forever. Lesson 5.5 walked through that arithmetic. It is real, and it is half the story.

The half that gets skipped is that CinferC_{infer} is not a function of parameter count alone. At a fixed 27 billion parameters you can build architectures whose serving costs differ by more than an order of magnitude, because a served request pays for three things: reading the weights, computing the layers, and holding the per-request state. Only the first scales cleanly with NN. The third — the KV cache — depends entirely on decisions about heads and layer types, and it is where Qwen3.8-27B makes its position obvious.

Lesson 7.2 owns the KV-cache arithmetic for this model, so this lesson uses its result instead of re-deriving a second budget. The relevant counterfactual holds the head dimension and layer count fixed but replaces four KV heads with 24 and replaces 16 caching attention layers with 64. GQA reduces the KV-head count by a factor of six; the 3

hybrid layout reduces the number of growing-cache layers by a factor of four. Their structural factors multiply to 24. The exact byte totals, dtype assumptions, and DeltaNet-state accounting remain in lesson 7.2.

The same distinction applies to the rest of the design. Only 16 layers maintain a cache that grows with sequence length, and the released weights are bf16. Quantized size, usable context, throughput, and total accelerator fit depend on the exact runtime and memory budget; architecture alone does not establish a workstation target or the team’s intent.

Honesty about what is and is not known matters here as much as anywhere in this track. The architectural facts above are verifiable from the model card and config. The reasoning attributed to them is inference from the design, not a published rationale — there is no technical report for this model, and the team never stated their serving assumptions, token budget, or cost model. What you can say with confidence is that the shipped architecture reduces growing per-sequence state relative to the stated counterfactual. Interpreting that effect as a team objective is plausible but remains inference.

The usual caveats still bind. Forecasts of RR are frequently wrong in both directions, so report sensitivity across demand scenarios rather than a single point estimate. Matching validation loss does not guarantee matching latency-sensitive quality, factuality, multilingual behaviour, or post-training responsiveness. Data availability constrains the over-training lever: extra unique high-quality tokens may simply not exist, and repeating data changes the effective objective and raises memorization risk. Update cadence matters too — a checkpoint replaced next month accumulates far less lifetime inference than one served for years.

The durable principle is to optimize the system’s lifetime rather than a single run. Chinchilla asks how to spend a pretraining budget. Inference-aware scaling asks what should exist after training, given how often it will be used — and the answer is expressed in tokens, in parameters, and, most consequentially, in the shape of the layers themselves.

02 · Analogy

Analogy

A delivery company can buy a large van that reaches target capacity after a short setup, or spend longer tuning a smaller electric van that makes each future route cheaper. If it will make ten deliveries, setup dominates. If it will make a billion, operating cost dominates. Inference-aware scaling adds the lifetime route count to a decision that training-only scaling treats as a one-time race.

03 · Teach it back

Teach it back

Explain inference-aware scaling, then analyze the serving consequences of Qwen3.8-27B’s grouped-query attention and 3:1 hybrid layout without attributing an unpublished training rationale.

Minimum: 80 characters and 15 words. Your writing stays only in this browser.

Waiting for your explanation.

Compare with a model answer

Training compute is paid once; inference compute is paid per served token, so high lifetime demand can shift the optimum toward models that are cheaper per request. Training a smaller model for more tokens is one lever. Architecture at fixed parameter count is another: Qwen3.8-27B has 24 query heads but only 4 KV heads, and only 16 of 64 layers maintain a growing KV cache. Relative to an all-MHA, all-attention counterfactual, these facts provide factors of six and four in the cache dimensions, or 24 combined. Lesson 7.2 owns the byte derivation. The architecture and its consequences are documented; the team’s serving assumptions and design rationale are not.

04 · Check your understanding

Check your understanding

01Which two published architectural facts produce the 24-fold KV-cache factor derived in lesson 7.2?
Answer and explanation

Four KV heads instead of 24 give a factor of 6, and 16 caching layers instead of 64 give a factor of 4; 6 × 4 = 24 — GQA changes the KV-head count and the hybrid layout changes the number of layers with a growing cache. Lesson 7.2 derives their byte consequences; the model card does not state a design target.

02Lesson 5.5 defined over-training relative to a Chinchilla point. Why is that not a criticism of a model trained far past it?
Answer and explanation

The Chinchilla optimum minimizes loss for a fixed training budget only, and says nothing about lifetime serving cost — Extra tokens past the training-compute optimum purchase a permanently smaller model at a target quality; that is a different objective, not a mistake.

03What new variable changes the inference-aware optimum most directly?
Answer and explanation

Expected lifetime inference demand — Recurring per-token costs matter more as the number of served tokens or requests grows.

Complete the teach-back and answer the quiz correctly to finish this lesson.

◎ · Evidence marker

Sources

  1. Nikhil Sardana, Jacob Portes, Sasha Doubov, and Jonathan Frankle (2024). Beyond Chinchilla-Optimal: Accounting for Inference in Language Model Scaling Laws.
  2. Qwen Team (2026). Qwen3.8-27B Model Card.
  3. Joshua Ainslie et al. (2023). GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints.