fix(prose): close up pre-/non- compound prefixes per CMS $7.89 (3 chapters)

Per book-prose.md $10.8, pre- and non- compounds close up unless a
domain convention overrides (multi-, semi-, anti-, before-acronym,
before-number cases stay hyphenated).

Sites:
- vol1/data_selection: non-convex (x2), non-sequential, non-redundant
- vol1/nn_computation: pre-processing/Pre-processing/post-processing/
  Post-processing in fig-cap and fig-alt of fig-usps-inference-pipeline
  (closed up post- alongside pre- for caption-internal consistency)
- vol2/data_storage: pre-processed (x4), pre-allocated, pre-compute,
  pre-decompression, pre-staging (incl. \index{Pre-staging} ->
  \index{Prestaging}), pre-loaded

book/quarto/contents/vol1/data_selection/data_selection.qmd

@@ -1139,7 +1139,7 @@ class QualityMultiplier:
 
 **The Physics of Noise**: Why is one clean sample worth 100 noisy ones?
 
-**The Math**: Classical learning theory (for convex optimization with SGD) tells us that convergence rates depend on label noise. While deep learning operates in a non-convex regime, the qualitative relationship holds broadly.
+**The Math**: Classical learning theory (for convex optimization with SGD) tells us that convergence rates depend on label noise. While deep learning operates in a nonconvex regime, the qualitative relationship holds broadly.
 
 1.  **Clean Data**: Convergence rate is typically $O(1/N)$. Halving the error requires **2$\times$** data.
 2.  **Noisy Data**: Convergence rate drops to $O(1/\sqrt{N})$. Halving the error requires **4$\times$** data.
@@ -1449,7 +1449,7 @@ The optimal training samples do change as the model learns. Early in training, t
 \index{Curriculum Learning!difficulty scorer and pacing function}
 The first dynamic selection technique, **curriculum learning**\index{Dynamic Selection!curriculum learning}[^fn-curriculum-optimization] [@bengio2009curriculum; @soviany2022curriculum], structures the order in which data is presented to the model. Instead of random shuffling, it starts with simpler examples and gradually introduces more complex ones, mirroring how humans learn by mastering basics before advancing to harder material.
 
-[^fn-curriculum-optimization]: **Curriculum Learning**: From Latin *currere* ("to run"), originally meaning "the course to be run" -- a metaphor that maps directly to the technique: training data as a course run in deliberate order, easy stretches first. The key insight is that curriculum learning acts as a continuation method for non-convex optimization: starting with easy examples smooths the loss landscape, helping the optimizer find better local minima. From a systems perspective, the ICR varies *within* a training run -- easy samples have high ICR early but near-zero ICR later -- which is precisely why presenting them first and phasing them out improves total compute efficiency. \index{Curriculum Learning!optimization landscape} \index{Curriculum Learning!etymology}
+[^fn-curriculum-optimization]: **Curriculum Learning**: From Latin *currere* ("to run"), originally meaning "the course to be run" -- a metaphor that maps directly to the technique: training data as a course run in deliberate order, easy stretches first. The key insight is that curriculum learning acts as a continuation method for nonconvex optimization: starting with easy examples smooths the loss landscape, helping the optimizer find better local minima. From a systems perspective, the ICR varies *within* a training run -- easy samples have high ICR early but near-zero ICR later -- which is precisely why presenting them first and phasing them out improves total compute efficiency. \index{Curriculum Learning!optimization landscape} \index{Curriculum Learning!etymology}
 
 The effectiveness of curriculum learning stems from how neural networks respond to gradient signals at different training stages. Easy examples provide clear, consistent gradients that establish strong feature representations early in training, when the loss landscape is highly irregular. Hard examples introduced too early produce noisy gradient signals that slow convergence or cause the model to memorize outliers rather than learn general patterns. By sequencing examples from easy to hard, curriculum learning smooths the optimization trajectory.
 
@@ -2654,7 +2654,7 @@ The techniques in this chapter are not mutually exclusive; in practice, the most
 
 The preceding decision framework answers the *what* of data selection: which samples to prune, when to select dynamically, and how to synthesize new data. Understanding these algorithmic choices is essential, but algorithms alone do not translate into faster training. A perfectly designed coreset algorithm that takes 10 hours to select samples for a two-hour training run yields no practical benefit. Similarly, a curriculum learning strategy that requires scanning the entire dataset to determine difficulty rankings may idle GPUs while CPUs compute scores. The *how* of implementation matters as much as the *what* of algorithm choice. Concretely, a 2$\times$ improvement in the Information-Compute Ratio (ICR) is mathematically equivalent to doubling the hardware's peak throughput ($R_{\text{peak}}$) for that training run.
 
-The gap between algorithmic elegance and practical value raises several systems challenges: preventing selection overhead from negating theoretical gains, handling non-sequential I/O patterns that confuse prefetching logic, and coordinating selection decisions across distributed workers without introducing synchronization bottlenecks. The engineering patterns that follow bridge the gap between data selection theory and production reality.
+The gap between algorithmic elegance and practical value raises several systems challenges: preventing selection overhead from negating theoretical gains, handling nonsequential I/O patterns that confuse prefetching logic, and coordinating selection decisions across distributed workers without introducing synchronization bottlenecks. The engineering patterns that follow bridge the gap between data selection theory and production reality.
 
 ## Selection Engineering {#sec-data-selection-selection-engineering-a4eb}
 
@@ -3575,7 +3575,7 @@ Data selection does not exist in isolation. A coreset-trained model will eventua
 
 Model compression (@sec-model-compression) reduces the size of the trained model through pruning, quantization, and distillation. The training dataset directly affects how compressible the resulting model becomes. Models trained on smaller, higher-quality datasets are often *more* compressible than those trained on larger, noisier ones.
 
-The mechanism relates to how models encode information. A model trained on repetitive data learns redundant features that pruning later removes. The training compute required to learn those features was wasted, only to be discarded during compression. By contrast, a model trained on diverse, informative samples learns compact, non-redundant representations from the start, making subsequent compression more effective. Empirical evidence supports this relationship: in experiments on ImageNet, models trained on fifty percent coresets selected by EL2N compress to four-bit precision with two percent less accuracy loss than models trained on the full dataset, because the curated training produced cleaner weight distributions that quantize more gracefully.
+The mechanism relates to how models encode information. A model trained on repetitive data learns redundant features that pruning later removes. The training compute required to learn those features was wasted, only to be discarded during compression. By contrast, a model trained on diverse, informative samples learns compact, nonredundant representations from the start, making subsequent compression more effective. Empirical evidence supports this relationship: in experiments on ImageNet, models trained on fifty percent coresets selected by EL2N compress to four-bit precision with two percent less accuracy loss than models trained on the full dataset, because the curated training produced cleaner weight distributions that quantize more gracefully.
 
 Data selection and model compression are therefore *complementary*. The techniques in this chapter can reduce both training cost *and* post-training compression effort. When planning an efficiency pipeline, apply data selection first; the resulting model will be easier to compress.
 

book/quarto/contents/vol1/nn_computation/nn_computation.qmd

@@ -4701,7 +4701,7 @@ The engineering team faced a critical decision regarding confidence thresholds\i
 
 Following a single piece of mail through the USPS recognition system illustrates how the concepts in this chapter integrate into a complete solution. The journey from physical mail to sorted letter demonstrates the interplay between traditional computing, neural network inference, and physical machinery. Trace the data flow in @fig-usps-inference-pipeline to see this hybrid architecture in action, with the neural network operating as one component within a broader pipeline of conventional preprocessing and post-processing stages.
 
-::: {#fig-usps-inference-pipeline fig-env="figure" fig-pos="htb" fig-cap="**USPS Inference Pipeline**: The mail sorting pipeline combines traditional pre-processing (blue) with neural network inference (green) and traditional post-processing (purple). Raw envelope images undergo preprocessing, including thresholding, segmentation, and normalization, before the neural network classifies individual digits. Post-processing applies confidence thresholds and formats sorting instructions for the physical sorting machinery." fig-alt="Six-box linear pipeline: Raw Data and Pre-processing in a blue pre-processing section, Neural Network in a green deep-learning section, then Raw Output, Post-processing, and Final Output in a purple post-processing section."}
+::: {#fig-usps-inference-pipeline fig-env="figure" fig-pos="htb" fig-cap="**USPS Inference Pipeline**: The mail sorting pipeline combines traditional preprocessing (blue) with neural network inference (green) and traditional postprocessing (purple). Raw envelope images undergo preprocessing, including thresholding, segmentation, and normalization, before the neural network classifies individual digits. Postprocessing applies confidence thresholds and formats sorting instructions for the physical sorting machinery." fig-alt="Six-box linear pipeline: Raw Data and Preprocessing in a blue preprocessing section, Neural Network in a green deep-learning section, then Raw Output, Postprocessing, and Final Output in a purple postprocessing section."}
 
 ```{.tikz}
 \begin{tikzpicture}[font=\small\usefont{T1}{phv}{m}{n}, >=stealth]

book/quarto/contents/vol2/data_storage/data_storage.qmd

@@ -422,7 +422,7 @@ Understanding *how* data is accessed across storage tiers is essential for choos
 
 The gap labeled "The I/O Wall" in @fig-access-patterns-vol2 widens as request sizes shrink: at 4 KB, sequential reads outperform random reads by 10$\times$. This is *why* datasets stored as millions of small files (the "small file problem") perform catastrophically on ML workloads, even on high-bandwidth storage [@shvachko2010hadoop]. The solution, as we will see in the parallel file system and object storage tiers, is to aggregate small samples into large sequential shards.
 
-The practical consequence for our running example is stark. The 1.5 trillion tokens of training data, stored as compressed text, produce roughly 3 TB of sequential reads per epoch. If each token were stored as an individual file (as naive data collection might produce), the metadata overhead alone would throttle throughput to a fraction of what the storage hardware can deliver. Instead, the data must be pre-processed into large shards, typically 256 MB to 4 GB each, so that each read operation amortizes the fixed overhead of file open, seek, and close across millions of tokens. This preprocessing step transforms the access pattern from random [@zaharia2012resilient] (one file per sample) to sequential (one contiguous read per shard), moving the workload from the red line to the blue line in @fig-access-patterns-vol2.
+The practical consequence for our running example is stark. The 1.5 trillion tokens of training data, stored as compressed text, produce roughly 3 TB of sequential reads per epoch. If each token were stored as an individual file (as naive data collection might produce), the metadata overhead alone would throttle throughput to a fraction of what the storage hardware can deliver. Instead, the data must be preprocessed into large shards, typically 256 MB to 4 GB each, so that each read operation amortizes the fixed overhead of file open, seek, and close across millions of tokens. This preprocessing step transforms the access pattern from random [@zaharia2012resilient] (one file per sample) to sequential (one contiguous read per shard), moving the workload from the red line to the blue line in @fig-access-patterns-vol2.
 
 With these inversions established, we can trace the storage hierarchy that ML systems use to bridge the gap between accelerator appetite and storage capacity.
 
@@ -485,7 +485,7 @@ This is over 2,400$\times$ higher than the text workload and requires a high-per
 
 :::
 
-The bandwidth cliff between tiers also has implications for the data format at each level. At the HBM tier, data must be in the format the accelerator can directly compute on: float16 tensors, packed token IDs, or pre-processed feature vectors. At the NVMe tier, data can be in a more compact format (compressed JPEG, tokenized text with dictionary encoding) because the CPU has time to decode it while the accelerator processes the previous batch. At the object storage tier, maximum compression is desirable to minimize both storage cost and transfer time, even if decompression adds CPU overhead. The format transition from compressed storage to compute-ready tensors is part of the pipeline's "value-added" work, transforming raw bytes into the representation that the accelerator needs. This transformation happens in host DRAM, which is *why* host DRAM serves as the critical staging area for the pipeline.
+The bandwidth cliff between tiers also has implications for the data format at each level. At the HBM tier, data must be in the format the accelerator can directly compute on: float16 tensors, packed token IDs, or preprocessed feature vectors. At the NVMe tier, data can be in a more compact format (compressed JPEG, tokenized text with dictionary encoding) because the CPU has time to decode it while the accelerator processes the previous batch. At the object storage tier, maximum compression is desirable to minimize both storage cost and transfer time, even if decompression adds CPU overhead. The format transition from compressed storage to compute-ready tensors is part of the pipeline's "value-added" work, transforming raw bytes into the representation that the accelerator needs. This transformation happens in host DRAM, which is *why* host DRAM serves as the critical staging area for the pipeline.
 
 The format challenge intensifies for multi-modal training, which combines text, images, audio, and video in a single model. Each modality has a dramatically different data profile: a text token is 4 bytes, a high-resolution image is 150 KB, and a short video clip is 10 MB. They also have different compression characteristics and require different augmentation pipelines. A multi-modal training job must manage multiple parallel data streams, each with its own bandwidth profile and prefetch requirements. The storage hierarchy must be provisioned for the *sum* of all modalities' bandwidth demands, not the dominant one alone. For a training job combining 3 TB of text with 50 TB of images and 200 TB of video, the video modality overwhelmingly dominates both storage capacity and I/O bandwidth requirements, even though the text modality may contribute more to model quality. This asymmetry between storage cost and training value is a recurring challenge in multi-modal system design.
 
@@ -514,7 +514,7 @@ The razor-thin margin is a defining feature of large model training. Consider th
 
 Even with aggressive partitioning, the total memory footprint consumes between 85 percent and 98 percent of the available HBM. This leaves less than 15 percent of the GPU's fastest memory, just a few gigabytes, to serve as a buffer for the incoming data pipeline. Any delay in fetching the next batch from host memory risks starving the accelerator, forcing it to sit idle while the most expensive resource in the system produces heat instead of gradients.
 
-The batch lifecycle within HBM illustrates how transient storage at this tier truly is. When a new training batch arrives from host DRAM via PCIe, it is placed in a pre-allocated input buffer in HBM. The forward pass reads the input data, reads the model weights (which persist across batches), and writes activations to HBM. The backward pass reads the activations, computes gradients, and writes gradient updates. The optimizer step reads gradients and model weights, computes updated weights, and writes them back. After the optimizer step, the input batch and activations are no longer needed and their HBM regions are freed for the next batch. The entire lifecycle of an input batch in HBM, from arrival to deallocation, spans a single training step: typically 100 to 500 ms. Model weights and optimizer state, by contrast, persist in HBM for the entire training run, occupying a fixed allocation that *cannot* be reclaimed for batch data.
+The batch lifecycle within HBM illustrates how transient storage at this tier truly is. When a new training batch arrives from host DRAM via PCIe, it is placed in a preallocated input buffer in HBM. The forward pass reads the input data, reads the model weights (which persist across batches), and writes activations to HBM. The backward pass reads the activations, computes gradients, and writes gradient updates. The optimizer step reads gradients and model weights, computes updated weights, and writes them back. After the optimizer step, the input batch and activations are no longer needed and their HBM regions are freed for the next batch. The entire lifecycle of an input batch in HBM, from arrival to deallocation, spans a single training step: typically 100 to 500 ms. Model weights and optimizer state, by contrast, persist in HBM for the entire training run, occupying a fixed allocation that *cannot* be reclaimed for batch data.
 
 From the data pipeline's perspective, Tier 0 is not a storage tier to be managed but a constraint to be satisfied. The pipeline's purpose is to ensure that the batch the accelerator needs *next* is already resident in HBM before the current batch's computation completes. If it arrives late, the accelerator stalls. If it arrives early, it consumes HBM that could hold activations. The tension between "just in time" and "just too late" defines the pipeline's buffer management strategy, which we quantify in @sec-storage-pipeline-equation.
 
@@ -761,7 +761,7 @@ The severity of this problem in practice is illustrated by a well-known producti
 
 ::: {.callout-warning title="The Metadata Meltdown"}
 
-A well-known large-scale training cluster experienced a catastrophic slowdown when migrating from a pre-processed sequential dataset to raw images stored as individual files. The parallel file system, provisioned with 500 TB of data bandwidth, delivered less than 1 percent of its rated throughput. The metadata servers, designed for scientific workloads with thousands of large files, could not sustain the millions of `stat()` and `open()` calls per second that the ML data loaders generated. The fix required converting the entire 200-million-image dataset into 50,000 large tar files (4 GB each), reducing metadata operations by four orders of magnitude. The lesson: **at scale, metadata operations, not data bandwidth, are the first bottleneck to hit.**
+A well-known large-scale training cluster experienced a catastrophic slowdown when migrating from a preprocessed sequential dataset to raw images stored as individual files. The parallel file system, provisioned with 500 TB of data bandwidth, delivered less than 1 percent of its rated throughput. The metadata servers, designed for scientific workloads with thousands of large files, could not sustain the millions of `stat()` and `open()` calls per second that the ML data loaders generated. The fix required converting the entire 200-million-image dataset into 50,000 large tar files (4 GB each), reducing metadata operations by four orders of magnitude. The lesson: **at scale, metadata operations, not data bandwidth, are the first bottleneck to hit.**
 
 :::
 
@@ -874,7 +874,7 @@ Object storage provides strong read-after-write consistency, which means that on
 
 The immense scale of ML datasets makes them vulnerable to **silent data corruption**\index{Silent Data Corruption}: subtle bit flips in the storage medium or during network transfer that can introduce training artifacts nearly impossible to diagnose. Object storage services provide per-object checksums (typically MD5 or the more performant CRC32C) that verify integrity on every read. Parallel file systems typically rely on underlying RAID or erasure coding for physical integrity but do not provide end-to-end checksums visible to the application. Best practice for large-scale ML pipelines is to compute and store a checksum for each data shard during preprocessing and verify it when the shard is first loaded by a training worker. The verification overhead is negligible (a modern CPU computes CRC32C at over 20 GB/s) compared to the cost of training on corrupted data. For model checkpoints, integrity verification is even more critical: a single bit flip in a weight or optimizer state can corrupt the model, causing training to diverge silently after recovery. Frameworks like PyTorch and DeepSpeed include checkpoint integrity verification as a default behavior.
 
-Storage security is a first-class concern in production ML infrastructure. Training datasets often contain sensitive information (personally identifiable data, proprietary text, licensed images) that requires access control. Object storage provides fine-grained security policies through IAM roles, per-bucket policies, and integrated encryption for data at rest and in transit. Parallel file systems provide POSIX permissions and ACLs but often lack the audit logging that compliance requires. For organizations subject to data protection regulations such as the General Data Protection Regulation (GDPR) and CCPA, the storage architecture must ensure that data access is logged, that deletion requests can be honored (a task complicated by immutable pre-processed shards), and that model checkpoints do not inadvertently memorize protected information. The intersection of storage security and ML privacy is examined further in @sec-security-privacy.
+Storage security is a first-class concern in production ML infrastructure. Training datasets often contain sensitive information (personally identifiable data, proprietary text, licensed images) that requires access control. Object storage provides fine-grained security policies through IAM roles, per-bucket policies, and integrated encryption for data at rest and in transit. Parallel file systems provide POSIX permissions and ACLs but often lack the audit logging that compliance requires. For organizations subject to data protection regulations such as the General Data Protection Regulation (GDPR) and CCPA, the storage architecture must ensure that data access is logged, that deletion requests can be honored (a task complicated by immutable preprocessed shards), and that model checkpoints do not inadvertently memorize protected information. The intersection of storage security and ML privacy is examined further in @sec-security-privacy.
 
 This consistency guarantee makes object storage suitable for both training data source (the original dataset) and long-term checkpoint retention (the archival copy after local NVMe staging). Vector databases, a specialized storage primitive for approximate nearest-neighbor search in embedding spaces, are covered in @sec-inference-scale, where they serve the retrieval-augmented generation pipeline.
 
@@ -1220,7 +1220,7 @@ The pipeline equation also reveals a scaling challenge that worsens with cluster
 
 ::: {.callout-war-story title="The Invisible Tax"}
 
-A major cloud provider invested heavily in a 4,096-GPU cluster for a flagship large language model (LLM) training service. Despite top-tier hardware, the team struggled to exceed 68 percent Model FLOPS Utilization (MFU), far below their target of 85 percent. Profiling revealed the GPUs were frequently idle, but network and storage I/O metrics looked healthy. The root cause was insidious: the default data loader behavior issued a `stat()` system call for each file before opening it, a defensive check inherited from a database-era storage library. Across thousands of workers, this generated millions of metadata requests per minute, overwhelming the parallel file system's metadata server. The GPUs were stalling on file-open operations, a delay invisible to standard I/O bandwidth counters. The fix was to pre-compute a file manifest at job start and have loaders read it once, eliminating the per-file `stat()` calls. MFU immediately rose to 83 percent, recovering an estimated \$2.4 million per month in wasted compute.
+A major cloud provider invested heavily in a 4,096-GPU cluster for a flagship large language model (LLM) training service. Despite top-tier hardware, the team struggled to exceed 68 percent Model FLOPS Utilization (MFU), far below their target of 85 percent. Profiling revealed the GPUs were frequently idle, but network and storage I/O metrics looked healthy. The root cause was insidious: the default data loader behavior issued a `stat()` system call for each file before opening it, a defensive check inherited from a database-era storage library. Across thousands of workers, this generated millions of metadata requests per minute, overwhelming the parallel file system's metadata server. The GPUs were stalling on file-open operations, a delay invisible to standard I/O bandwidth counters. The fix was to precompute a file manifest at job start and have loaders read it once, eliminating the per-file `stat()` calls. MFU immediately rose to 83 percent, recovering an estimated \$2.4 million per month in wasted compute.
 
 :::
 
@@ -1404,7 +1404,7 @@ The GDS design principle also extends to checkpoint writes. In the traditional p
 
 ### The complete data path {#sec-storage-complete-path}
 
-Combining GDS with the multi-tier hierarchy, we can now trace the complete data path for our running example. At the beginning of the training job, the 3 TB dataset is staged from object storage to each node's local NVMe during a setup phase. The data loader workers read compressed shards from NVMe, decompress them on the CPU, apply augmentations, and assemble batches in pinned host DRAM. With GDS enabled, the raw (pre-decompression) data can flow directly from NVMe to GPU memory for formats that the GPU can decode natively (such as NVIDIA nvJPEG for image data). For text data that is already tokenized, GDS can load the token IDs directly into GPU memory without CPU involvement.
+Combining GDS with the multi-tier hierarchy, we can now trace the complete data path for our running example. At the beginning of the training job, the 3 TB dataset is staged from object storage to each node's local NVMe during a setup phase. The data loader workers read compressed shards from NVMe, decompress them on the CPU, apply augmentations, and assemble batches in pinned host DRAM. With GDS enabled, the raw (predecompression) data can flow directly from NVMe to GPU memory for formats that the GPU can decode natively (such as NVIDIA nvJPEG for image data). For text data that is already tokenized, GDS can load the token IDs directly into GPU memory without CPU involvement.
 
 During training, the pipeline operates in steady state. The CPU data loader workers continuously read from local NVMe, filling a prefetch queue in host DRAM. The GPU pulls batches from this queue via PCIe DMA. The compute phase (forward pass, backward pass, optimizer step) consumes the batch and updates the model weights in HBM. Every 10 minutes, the training framework initiates a checkpoint: model weights and optimizer state are written from GPU HBM to local NVMe (either through host DRAM or via GDS), and a background thread asynchronously copies the local checkpoint to the parallel file system.
 
@@ -1533,7 +1533,7 @@ The economic benefit of automated tiering compounds over time. An organization r
 
 The mechanics of staging data between tiers deserve careful attention because they often become the bottleneck that delays job start time. Three common patterns address different tradeoffs between start time and steady-state performance.
 
-The **pre-staging**\index{Pre-staging} pattern copies the entire dataset from object storage to local NVMe before the first training iteration begins. This approach provides the best steady-state performance (all reads are local) but the worst job start time. Staging a 10 TB dataset across 256 nodes, where each node copies its assigned shards at 500 MB/s from the parallel file system, takes roughly 80 seconds per node. If the parallel file system bandwidth is shared across all 256 nodes staging simultaneously, the effective per-node bandwidth drops and staging can take several minutes. For time-critical training jobs, this startup delay is acceptable; for interactive development or hyperparameter sweeps that run many short jobs, it is prohibitive.
+The **prestaging**\index{Prestaging} pattern copies the entire dataset from object storage to local NVMe before the first training iteration begins. This approach provides the best steady-state performance (all reads are local) but the worst job start time. Staging a 10 TB dataset across 256 nodes, where each node copies its assigned shards at 500 MB/s from the parallel file system, takes roughly 80 seconds per node. If the parallel file system bandwidth is shared across all 256 nodes staging simultaneously, the effective per-node bandwidth drops and staging can take several minutes. For time-critical training jobs, this startup delay is acceptable; for interactive development or hyperparameter sweeps that run many short jobs, it is prohibitive.
 
 The **on-demand staging**\index{On-demand Staging} pattern copies shards to local NVMe only when they are first accessed by the data loader. The first epoch incurs the full cost of network reads, but subsequent epochs read from local NVMe cache. This pattern eliminates the startup delay at the cost of slower first-epoch performance. It is well-suited to multi-epoch training, where the amortized cost of the first-epoch staging becomes negligible over many epochs.
 
@@ -1557,7 +1557,7 @@ The storage requirements for inference differ fundamentally from training. Train
 
 The most critical metric for inference storage is **model loading latency**\index{Model Loading!latency}, often called cold-start time: the duration required to load a model from storage into the accelerator's HBM. For our 175B parameter language model, the weights alone occupy 350 GB in FP16 format. Loading this sequentially from a single high-performance NVMe drive at 14 GB/s takes 25 seconds, an unacceptable delay for a user-facing application. Loading from a shared PFS at a per-node rate of 4 GB/s takes nearly 88 seconds. From object storage at 1 GB/s, the delay approaches six minutes.
 
-To reduce cold-start time, the model is sharded and loaded in parallel. If the 350 GB model is striped across 8 NVMe drives, each loading a 43.75 GB shard at 3.5 GB/s, the total load time drops to 12.5 seconds. When using tensor parallelism across 8 GPUs, each GPU loads only its 43.75 GB shard, which can be accomplished in under 4 seconds by reading from host DRAM. For the most latency-sensitive applications, organizations maintain **warm replicas**\index{Warm Replicas}: one or more copies of the model weights kept pre-loaded in host DRAM, ready to be transferred to HBM in under two seconds. This trades DRAM capacity for near-instantaneous cold-start times.
+To reduce cold-start time, the model is sharded and loaded in parallel. If the 350 GB model is striped across 8 NVMe drives, each loading a 43.75 GB shard at 3.5 GB/s, the total load time drops to 12.5 seconds. When using tensor parallelism across 8 GPUs, each GPU loads only its 43.75 GB shard, which can be accomplished in under 4 seconds by reading from host DRAM. For the most latency-sensitive applications, organizations maintain **warm replicas**\index{Warm Replicas}: one or more copies of the model weights kept preloaded in host DRAM, ready to be transferred to HBM in under two seconds. This trades DRAM capacity for near-instantaneous cold-start times.
 
 During autoregressive generation, the **KV cache**\index{KV Cache} grows with sequence length and can consume significant HBM. For long sequences (128K tokens or more), KV cache offloading to host DRAM or NVMe extends the effective context window at the cost of increased latency per generated token, as the data must be moved back into HBM for computation. This interaction between storage and inference performance is covered in depth in @sec-inference-scale.