Chapter 1 · Frame and baseline

Keep it fed: loaders and async copies

A fast training step needs an equally deliberate supply chain from storage to pinned memory to the device.

65–90 min4 key conceptsReviewed 26 Aug 2026
01 · Production proposition

Training repeatedly OOMs and misses its nightly completion window.

This chapter moves from separate wait from compute to verify sustained overlap. We will make the idea concrete in a small code example before placing it back inside a production system with 24 GB device and nightly completion.

Decision

Use a profiler timeline after warm-up. Healthy training shows copies prepared ahead of compute rather than wide blank gaps before every step.

Evidence

Verify the behavior illustrated in fed_loader.py, then measure decision utility, slice reliability, and system latency.

Failure consequence

Unsynchronized timing reports impossible speedups while retained tensors keep computation graphs alive and leak memory. An unsafe release must degrade to a named baseline or the last known-good version.

02 · Guided chapter

Build the idea one layer at a time.

An expensive GPU that waits for the next batch is a very fast machine doing nothing.

The input pipeline spans storage reads, decoding, augmentation, collation, host memory, and the host-to-device copy. If any stage is slower than the training step, gaps appear between GPU kernels. More data-loader workers help only when CPU preparation is the bottleneck; they can hurt when they contend for storage or duplicate large process state.

Pinned host memory enables DMA transfers, and a non-blocking copy lets the host enqueue work without waiting. Real overlap also requires the copy and compute to use compatible CUDA streams and enough queued work. Measure batch wait time and device utilization before changing worker count, prefetch depth, or batch size.

Keep in view
  • HBM bandwidth
  • arithmetic intensity
  • pinned memory
  • FP16/BF16
WORKED PATH

Follow the reasoning before touching the code.

  1. 01

    Separate wait from compute

    Time how long iteration spends obtaining a batch, copying it, and running forward/backward. A single end-to-end throughput number cannot identify starvation.

  2. 02

    Tune one stage

    Increase workers until preparation no longer dominates, then test pinned memory and non-blocking copies. Watch RAM, file handles, and storage throughput.

  3. 03

    Verify sustained overlap

    Use a profiler timeline after warm-up. Healthy training shows copies prepared ahead of compute rather than wide blank gaps before every step.

pythonfed_loader.py
import torch
from torch.utils.data import DataLoader, TensorDataset

features = torch.randn(4096, 32)
targets = torch.randint(0, 2, (4096,))
dataset = TensorDataset(features, targets)
loader = DataLoader(dataset, batch_size=256, num_workers=2,
                    pin_memory=True, persistent_workers=True)
for host_x, host_y in loader:
    device_x = host_x.to('cuda', non_blocking=True)
    device_y = host_y.to('cuda', non_blocking=True)
    assert device_x.shape[0] == device_y.shape[0]

Prepare batches in pinned host memory and enqueue asynchronous device copies.

READ THE EXAMPLE

What to notice

  • `non_blocking=True` permits an asynchronous copy because the loader produced pinned tensors; it does not by itself prove copy/compute overlap.
  • `persistent_workers=True` avoids recreating worker processes each epoch but keeps their memory allocated between epochs.
YOUR TURN Pause and predict before revealing the answer.

GPU utilization is low, but increasing loader workers from 4 to 16 makes throughput worse. What should you inspect next?

Need a hint?

Workers share resources outside the GPU.

Check your reasoning

Inspect storage latency and bandwidth, CPU saturation, augmentation cost, worker memory, and batch wait time. The workers may be competing for the same disk or oversubscribing CPU cores.

Bring forward

Lessons 1 in this course.

03 · Formal treatment

Connect the chapter to the course’s quantitative spine.

A fast training step needs an equally deliberate supply chain from storage to pinned memory to the device. The roofline bound below is the shared course-level lens that helps quantify the surrounding system. Name each symbol, check its units or shape, and use only values that were available at the production cutoff.

Formal treatment
attainable FLOP/s≤min⁡ ⁣(Ppeak,I⋅Bmem)\text{attainable FLOP/s} \le \min\!\left(P_{\mathrm{peak}}, I \cdot B_{\mathrm{mem}}\right)

Roofline bound

Symbol, shape or unit contract
SymbolMeaning / shape / unit
P_peakpeak compute
Iarithmetic intensity
B_memmemory bandwidth
Open derivation and numerical substitution

Start from the production quantity being optimized, substitute the observed values with their declared units, then isolate the model-controlled term. Preserve shape annotations at each step so broadcasting or aggregation cannot silently change the result.

  1. Write the named inputs: P_peak, I, B_mem.
  2. Substitute one small, hand-checkable batch before vectorizing.
  3. Calculate an independent reference value and compare within a declared tolerance.
# equation → code contract
inputs = validate_shapes_and_units(batch)
value = compute_c12(inputs)
assert is_finite(value)
04 · Deterministic lab

Change one assumption and make the tradeoff visible.

Use the worked chapter as your prediction, then change one input in the lab and explain why the output moves. The lab runs predefined TypeScript and never executes learner code, so the focus stays on the concept rather than setup.

Estimate

GPU memory ledger

Change microbatch size and calculate a simplified training-memory budget.

samples
Primary8.6 GB
Secondary36.0%
DiagnosisFits

Assumption: 3.2 GB weights+grads+optimizer, 0.34 GB activations per sample, 24 GB device, 10% reserve.

Open nonvisual data table
ItemComputed stateInterpretation
block 11.09 GB activationsresident
block 22.18 GB activationsresident
block 33.26 GB activationsresident
block 44.35 GB activationsresident
block 55.44 GB activationsresident
05 · Production implications

Trace the complete operating path.

Carry the chapter’s central idea into the system: A fast training step needs an equally deliberate supply chain from storage to pinned memory to the device. The path below shows where that reasoning needs an artifact, a test, an owner, or a fallback.

  1. 01

    Turn “Separate wait from compute” into a written invariant and a failing test.

  2. 02

    Promote fed_loader.py from illustration to a versioned implementation with representative fixtures.

  3. 03

    Use “Verify sustained overlap” as the release checkpoint: Use a profiler timeline after warm-up. Healthy training shows copies prepared ahead of compute rather than wide blank gaps before every step.

  4. 04

    Serve or materialize behind explicit 24 GB device and nightly completion.

  5. 05

    Join telemetry to mature outcomes and retain a rollback path.

Observability

Join service health, input quality, prediction distributions, slice behavior, and mature outcomes by exact version.

Cost

Measure storage, preprocessing, compute, queueing, and human review under a representative arrival pattern.

Failure modes

Unsynchronized timing reports impossible speedups while retained tensors keep computation graphs alive and leak memory. Add a detector, owner, mitigation, and stop condition for this class of failure.

Alternatives

Compare a rule, a simpler statistical baseline, and a different system boundary before adding model complexity.

06 · Check understanding

Explain the contract, not just the vocabulary.

Browser-graded checkpointPass ≥ 80%
01Why does FP16 often need loss scaling?
02Does gradient accumulation always equal one large batch?
03Why can Python timing understate GPU work?
07 · Apply in production

Single-GPU optimization plan

Profile and optimize a correctness-locked trainer without sacrificing model quality.

  • Profiler diagnosis
  • Mixed precision parity
  • Memory plan
  • Throughput/cost report
Open assignment and rubric
08 · Sources & next depth

Read primary material with a purpose.

09 · Production resolution

Return to the opening failure.

Record hardware/software, shapes, precision, seeds, throughput method, peak memory, and cost per sample.

For this lesson, the release evidence is the worked code example, a hand-checked formal result, deterministic simulation output, a ≥80% checkpoint, the production rubric, and a named fallback. The course resolves when the system can produce a profiled, mixed-precision, memory-budgeted training loop.