Refined the PDF layout for chapter 16 (conclusion.qmd) (#1829)

Author: hzeljko

book/quarto/contents/vol1/conclusion/conclusion.qmd

@@ -174,7 +174,7 @@ class MobileNetJourneyMath:
 | **Serving (@sec-model-serving)**              | Respecting the Latency Budget  | **$\text{P99} < 50$ ms** constraint; optimizing preprocessing (resize/normalize) to avoid CPU bottlenecks                                                                                                                                                                                      |
 | **Operations (@sec-ml-operations)**           | Managing System Entropy        | **Drift Monitoring**: Detecting accuracy decay across heterogeneous device populations and lighting conditions                                                                                                                                                                                 |
 
-: **The Lighthouse Journey (MobileNetV2)**: Tracing one model through the entire systems stack reveals how decisions in one domain (for example, architecture) propagate constraints and opportunities to every other domain (for example, hardware acceleration and monitoring). {#tbl-lighthouse-journey-mobilenet}
+: **The Lighthouse Journey (MobileNetV2)**: Tracing one model through the entire systems stack reveals how decisions in one domain (for example, architecture) propagate constraints and opportunities to every other domain (for example, hardware acceleration and monitoring). {#tbl-lighthouse-journey-mobilenet tbl-colwidths="[17,20,61]"}
 
 The table reveals a pattern: every row's decisions constrain the next row's options. Architecture choices (depthwise separable convolutions) enabled compression choices (INT8 quantization), which in turn enabled acceleration choices (mobile NPU deployment). Constraint propagation governs every ML system, but the MobileNetV2 journey is one instance of a deeper structure. The question is which quantitative invariants transcend specific models and technologies. The answer lies in thirteen principles, each grounded in physics, information theory, or statistics, that recur across every Lighthouse model and every deployment context.
 
@@ -257,7 +257,7 @@ class EnergyMovementMath:
 | \ref{pri-latency-budget}        | Latency Budget Invariant    | IV: Deploy     | $T_{\text{p99}}(x) \le L_{\text{budget}}$                                                                                              | Throughput is optimized within the latency envelope, never at its expense      |
 | \ref{pri-bias-feedback}         | Bias Feedback Invariant     | IV: Deploy     | $\Delta_{\text{err},g}(n) \approx \Delta_{\text{err},g}(0) \cdot \alpha_{\text{fb}}^n$, $\alpha_{\text{fb}} > 1$                       | Errors against subgroups compound across cycles when outputs reshape inputs    |
 
-: **The Thirteen Quantitative Invariants of ML Systems Engineering**: Each invariant was introduced in the Part where its governing constraint first becomes visible. Together, they form the complete analytical framework for reasoning about ML system design, optimization, and deployment. The meta-principle that unifies them all is the conservation of complexity: complexity cannot be destroyed, only moved between data, algorithm, and machine. {#tbl-thirteen-principles tbl-colwidths="[3,18,14,30,35]"}
+: **The Thirteen Quantitative Invariants of ML Systems Engineering**: Each invariant was introduced in the Part where its governing constraint first becomes visible. Together, they form the complete analytical framework for reasoning about ML system design, optimization, and deployment. The meta-principle that unifies them all is the conservation of complexity: complexity cannot be destroyed, only moved between data, algorithm, and machine. {#tbl-thirteen-principles tbl-colwidths="[3,18,12,30,37]"}
 
 The thirteen invariants are not independent axioms. They form an integrated framework unified by a single meta-principle: the conservation of complexity[^fn-conservation-complexity]\index{Conservation of Complexity!meta-principle}. Complexity in an ML system *cannot* be destroyed; it can only be moved between data, algorithm, and machine. Every invariant in @tbl-thirteen-principles quantifies a specific consequence of where complexity currently resides. The sections that follow trace how each Part's invariants connect to the Lighthouse models and to each other.
 
@@ -738,6 +738,12 @@ Foundational choices (what data to curate, which computational primitives to rel
 
 Training systems (@sec-model-training) demonstrated the iron law in action: data parallelism reduces the compute term by distributing work across GPUs, mixed precision halves the data movement term by using FP16 instead of FP32, and gradient checkpointing trades recomputation for memory capacity, each technique pulling a different lever of the same three-term equation. Model compression (@sec-model-compression) navigated the Pareto frontier directly: MobileNetV2's INT8 quantization and DLRM's embedding pruning each traded one metric for another, while the arithmetic intensity law diagnosed which trade-off would yield the greatest return for a given hardware target.
 
+::: {.column-margin}
+![](images/svg/vol1_conclusion_margin_003.svg){width="100%" fig-alt="Margin illustration showing Mean latency versus P99 latency."}
+
+*Mean latency hides the tail; P99 governs user experience.*
+:::
+
 Building and optimizing a model, however, is only half the engineering challenge. The other half begins the moment the model leaves the training cluster and enters production, where a new set of invariants governs behavior and where the optimizations that worked on the bench must survive the unpredictability of real-world traffic.
 
 ```{python}
@@ -783,12 +789,6 @@ class TailLatencyRatio:
 
 The transition from *training* to *inference* inverts optimization objectives: where training maximizes throughput over days, inference optimizes latency per request in milliseconds. The latency budget invariant makes P99 the governing constraint, and tracking tail latencies reveals that mean latency tells little about user experience when the 99th-percentile request can be `{python} TailLatencyRatio.conclusion_tail_ratio_str`$\times$ the mean latency. MLOps (@sec-ml-operations) orchestrates the full system lifecycle, transforming the statistical drift invariant and the training-serving skew law from abstract equations into monitoring alerts and automated retraining triggers.
 
-::: {.column-margin}
-![](images/svg/vol1_conclusion_margin_003.svg){width="100%" fig-alt="Margin illustration showing Mean latency versus P99 latency."}
-
-*Mean latency hides the tail; P99 governs user experience.*
-:::
-
 Beyond technical performance, @sec-responsible-engineering broadened the framework to include societal impact. The verification invariant demands monitoring for fairness violations alongside performance: tracking prediction distributions across demographic groups, detecting bias amplification over time (Principle \ref{pri-bias-feedback}), and alerting on unexplained accuracy disparities. The statistical drift invariant applies equally to demographic subgroup performance, where accuracy may degrade for underrepresented populations even as aggregate metrics remain stable. Responsible AI is therefore an integral dimension of systems engineering, a first-class design constraint governed by the same invariants that govern performance.
 
 The three domains demonstrate that the thirteen invariants are not theoretical constructs but working tools. The question now is *where* these tools will be tested next, as ML systems expand into new deployment contexts, confront new failure modes, and pursue increasingly ambitious goals.
@@ -904,16 +904,19 @@ The compound AI systems framework aligns naturally with the systems engineering
 
 :::
 
-That era demands concrete engineering advances. Achieving exascale sustained throughput $(\geq 10^{18} \text{ FLOP/s})$ and beyond requires entirely new approaches to power delivery, cooling, interconnects, and software coordination, not merely faster chips. The analytical tools developed in this volume, applied to those challenges, are what equip engineers to navigate the regime ahead.
-
-Whether or not AGI emerges in its fullest form, the systems principles established throughout this book will remain essential. The principles do not expire; they evolve. Their most immediate evolution is the transition from a single machine to the fleet-scale infrastructure that frontier AI already demands, a transition that brings with it both engineering opportunity and engineering responsibility.
-
 ::: {.column-margin}
+```{=latex}
+\vspace{-15mm}
+```
 ![](images/svg/vol1_conclusion_fleet_mtbf_ladder.svg){width="100%" fig-alt="Margin ladder showing one GPU with about 5.7 years mean time to failure versus a 1024 GPU pool with about 48.8 hours mean time between failures."}
 
 *Fleet scale turns rare component failures into routine system events.*
 :::
 
+That era demands concrete engineering advances. Achieving exascale sustained throughput $(\geq 10^{18} \text{ FLOP/s})$ and beyond requires entirely new approaches to power delivery, cooling, interconnects, and software coordination, not merely faster chips. The analytical tools developed in this volume, applied to those challenges, are what equip engineers to navigate the regime ahead.
+
+Whether or not AGI emerges in its fullest form, the systems principles established throughout this book will remain essential. The principles do not expire; they evolve. Their most immediate evolution is the transition from a single machine to the fleet-scale infrastructure that frontier AI already demands, a transition that brings with it both engineering opportunity and engineering responsibility.
+
 ## Journey Forward {#sec--journey-forward-6453}
 
 Every frontier explored in the previous section (diverse deployment contexts, robust systems, societal applications, and the path to AGI through compound AI systems) rests on a common foundation: the engineering skills this book has developed. Managing the stochastic nature of data through the data as code invariant (Principle \ref{pri-data-as-code}) and the statistical drift invariant, while enforcing deterministic reliability through the iron law (Principle \ref{pri-iron-law}), silicon contract (Principle \ref{pri-silicon-contract}), and latency budget, requires bridging the gap between Software 1.0's explicit logic and Software 2.0's learned behaviors. That bridge is the engineering rigor required to make probabilistic systems dependable.
@@ -1089,9 +1092,8 @@ In 1990, Hennessy and Patterson gave computer architecture a shared analytical l
 
 *The future of intelligence is not a destiny we will merely witness. It is a system we must engineer.*
 
-\vspace{5mm}
-
 ```{=latex}
+\vspace{5mm}
 \begingroup
 \raggedleft
 ```