A Field Map and How to Read This Book

Chapter 1 separated model development from request execution. This chapter places the rest of the book around those two processes. It explains what each part is for, which relationships are dependencies rather than reading order, how strongly different kinds of claims are supported, and where a reader can enter the book without first reading every preceding chapter.

The resulting structure is not one pipeline. Some parts describe stages in a model's lifecycle. Others describe runtime components, evidence, physical constraints, or operating conditions. Treating all of them as consecutive steps would hide the relationships this book is meant to explain.

Two processes and several cross-cutting concerns

The model-development process produces and revises a deployable model. It includes data preparation, base-model formation, post-training, evaluation, and release. The request-execution process begins after deployment. It includes serving, model calls, tool use, observations, and user-facing results. Reasoning methods can affect either process: some change training, while others allocate more computation during a model call.

Several concerns apply across both processes. Compute infrastructure limits what can be trained and served. Evaluation supplies evidence about behavior. Safety and governance define permitted behavior and required controls. Economics changes which designs are sustainable. Operations turns those choices into service objectives, incident procedures, and feedback for the next release.

In this chapter, a dependency means that one design needs an artifact or property supplied by another. A feedback relationship means that downstream evidence or cost changes an earlier decision. Neither one specifies the order in which the corresponding chapters must be read.

Where the twelve parts fit

Figure 2.1 shows selected dependencies among Parts I through XII. It is deliberately not a complete system diagram: drawing every evaluation, safety, economic, and operational relationship would make the figure unreadable. The table after the figure states the role of every part directly.

The book's numbering is an editorial sequence; the figure shows dependencies. Part IX, for example, appears below Part I because hardware constrains model training even though the infrastructure chapters come later. Parts VII and VIII are drawn near deployed systems, but evaluation and safety also constrain data, training, and release decisions. Part XII comes last because it combines the earlier material, not because operations begins only after development ends.

Two feedback relationships recur throughout the book. First, expected runtime demand can affect model-development choices. For models that meet the same quality target, a design with higher training cost but lower serving cost may be preferable above some serving volume. That conclusion depends on workload, hardware utilization, input and output lengths, and model lifetime; it is not a universal instruction to train smaller models longer (Sardana et al. 2024). Chapter 1 gives the lifecycle-cost model and its break-even condition.

Second, evaluation and operations influence later releases. A failed task can expose a missing test, an unsafe permission, an inadequate training example, or a serving limit. The appropriate response depends on the cause. Retraining the model will not fix a runtime authorization error, and changing a benchmark will not fix an incomplete product requirement.

How strong is a claim?

Technical writing becomes confusing when definitions, measurements, and hypotheses are presented with the same certainty. This book uses three broad categories.

Scaling laws are an important example of the second category. Kaplan et al. reported approximate power-law relationships between language-model loss and model size, data, and training compute across the regimes they studied (Kaplan et al. 2020). A simple compute-only fit can be written as

$$L(C) \approx L_\infty + A C^{-\alpha}.$$

Here $C$ is the training compute measured over the fitted range; $L(C)$ is the validation cross-entropy loss after training with compute $C$; $L_\infty$ is a fitted lower asymptote; $A>0$ sets the scale of the reducible loss; and $\alpha>0$ is the fitted scaling exponent. The equation summarizes measured behavior under a particular data distribution, architecture family, and training procedure. It does not guarantee the same exponent after those conditions change.

The interactive figure isolates the normalized reducible term $L_{\mathrm{red}}(C)=C^{-\alpha}$, with $A=1$ and $L_\infty=0$, so that the slope is easy to see. $L_{\mathrm{red}}(C)$ is normalized reducible loss; the other symbols retain the definitions above. This is a shape illustration, not a forecast for a real training run.

Scope and complementary references

This book is for readers who want to understand how model, systems, product, and operating decisions affect one another. It develops enough mechanism to make those dependencies precise, but it is not a substitute for a full course on implementing a language model or programming an accelerator cluster. A reader new to Transformers should read Chapter 7 and Chapter 8 before the serving, reasoning, and orchestration parts.

Several references go deeper on narrower tasks.

The focus here is the connection between those specialties. A serving workload can change model economics. An evaluation protocol can change what post-training rewards. A permission boundary can rule out an otherwise capable agent design. Hardware capacity, energy supply, and cost can narrow the set of models a team can operate. These are influences with explicit conditions, not single causes that determine an entire system.

How to use the chapters

The chapters do not follow one rigid heading template. They do, however, return to the same questions:

1. What problem or constraint motivates this component?
2. How does the mechanism work, and what assumptions does it make?
3. Which evidence supports it, and which claims remain uncertain?
4. What does it cost in capability, efficiency, or operational complexity?
5. Which earlier choices constrain it, and which later choices does it affect?

A What's contested callout identifies an unresolved interpretation or design choice. A Constraint arrow callout identifies a dependency that crosses chapter boundaries. Neither callout replaces evidence in the surrounding text.

Capability, efficiency, and trust are three evaluation questions, not a fixed budget that every technique divides. Capability asks whether the system can complete the intended task. Efficiency asks which resources and latency that result requires. Trust asks what evidence, controls, and recovery mechanisms justify relying on the result. An intervention may improve more than one dimension, harm one, or leave it unchanged.

Choose a reading route

When entering in the middle, keep four questions visible: which process or cross-cutting concern is involved, what it depends on, what evidence supports the claim, and what downstream choice or upstream feedback it can change. Those questions are more useful than memorizing a single linear stack.

Further reading