From one update to repeated training
In Lesson four, we used one delivery example to change one parameter once. A real shop has many deliveries. How does that one visible calculation become a repeatable training process, and what does a report of twenty epochs actually tell us?
This is Module one, Lesson five: Batches, epochs, and the repeated learning loop. By the end, you should be able to count batches in a simple pass, describe the stages of a training loop, explain what a checkpoint must preserve, and compare training workloads more carefully than by epoch count alone.
We'll expand our example in three steps: group deliveries into batches, repeat passes through the data, and account for state and resource costs.
Group examples into batches
Instead of using a single delivery, the shop can select a group of examples. That group is a batch. The model uses its current parameters to predict for the examples, measures their losses, combines relevant change information, and lets an optimizer make an update under its rule.
Batch size is the number of examples processed together under the chosen implementation. If a batch holds one hundred deliveries, it can give information about those one hundred rather than one row alone. The exact calculation can vary by objective and optimizer; batch does not mean that every example produces a separate completed update.
Count a simple non-overlapping arrangement
Imagine one thousand training deliveries, divided into non-overlapping groups of one hundred. There are ten batches. If the procedure updates after each batch, that simple arrangement gives ten update opportunities across the thousand examples.
Define a pass through the data
An epoch usually means one pass through the training dataset. With our simple thousand-delivery set and ten non-overlapping batches, processing those ten batches makes one epoch. Twenty epochs means twenty passes under that arrangement, potentially with a changed parameter state each time.
The order may be shuffled between passes. Some examples may be sampled differently. In streaming or distributed training, a clean full pass can be harder to define. When a team reports an epoch count, ask what dataset, sampling and pass definition it used.
Compare actual workloads
Twenty epochs over one thousand short delivery rows and twenty epochs over millions of long text sequences are not comparable amounts of work. Model size, sequence lengths, numerical precision, hardware and procedure also affect compute. Epoch count describes a relationship to data under a definition; it is not a universal unit of time, energy or progress.
Follow the training loop
The repeated loop has an order. Select examples. Compute predictions with the current parameters. Calculate loss against the targets. Compute change information, such as gradients. Use an optimizer to update the parameters. Record measurements, then repeat.
Evaluate on separate cases
At intervals, the team can evaluate on separate data that is not driving those updates. This matters because a falling training loss can coexist with weaker performance on new cases. We will define those data roles in Lesson seven.
Record and preserve the work
Monitoring records what happened: losses, evaluation results, step counts and sometimes system measurements. A checkpoint saves state so the work can be inspected, resumed or used later. It is more than a celebratory mark on a chart.
Save the state needed to resume
The model's learned parameters, often called weights, are central. But resuming the exact training process may also require optimizer state, progress counters, configuration, data order and transformation details. Some optimizers accumulate information from earlier updates. Saving weights without that additional state can make the next update different from the one an uninterrupted run would have made.
For inference, saved model weights and the necessary input-processing setup may be enough for some uses. For reproducible training, the bar is higher. The software environment, random choices, versions, data and preparation steps can influence the result.
Preserve the meaning of inputs
Suppose the shop restores only the learned distance parameter but forgets that vehicle categories were encoded in a changed order. The arithmetic may run while the inputs mean something different. A useful checkpoint and record preserve the meanings needed to interpret and continue the model, not just a file that loads.
Look beyond falling training loss
Repeating the loop can lower loss on the training examples. That is not a guarantee that quotes improve for new deliveries. After many passes, a model may start fitting accidental details or noisy labels from its dataset. Its training loss can continue to fall while performance on relevant unseen deliveries gets worse.
This is why teams monitor independent validation results as training progresses. A run can stop or change direction when those results cease improving. The appropriate response depends on the data and model; epoch count by itself is not a quality target.
Account for batching resources
Batching also changes the system workload. Grouping numerical operations can help hardware work efficiently. Yet larger batches require memory and may change update behavior. Across machines, moving information and coordinating updates can add communication cost. A batch choice therefore affects both learning and compute.
Calculate a hypothetical timing component
Use a hypothetical timing budget. There are ten batches in each epoch, and a batch takes two seconds of computation. At twenty epochs, ten times twenty gives two hundred batch calculations. At two seconds each, ideal batch-computation time is four hundred seconds, or six minutes and forty seconds.
Include overhead, recovery and opportunity cost
That is one component of the schedule, not the full run. Data loading, evaluation, checkpoint writes, orchestration and failures add time. If a run must be repeated because a data definition was wrong, hardware, electricity and engineering effort were still spent. The rerun also delays another experiment or task that the same people and hardware could have completed: that is an opportunity cost. The cost of development includes unsuccessful experiments and recovery, not just the final successful training job.
Check your understanding
Two teams each report twenty epochs. Can we conclude they used the same compute?
No. Compare dataset sizes, model sizes, batch definitions, sequence lengths, precision, hardware and training procedures. Even the meaning of a pass may differ. We need a matched workload before the epoch counts say much about resource use.
In our simple example, how many one-hundred-example batches make one pass through one thousand deliveries?
Ten, if the batches are non-overlapping and cover the thousand examples once. That answer depends on the arrangement we specified.
Connect the distinctions
A batch groups examples for a calculation; an epoch usually marks a pass through the training data; a loop predicts, measures loss, calculates change information and updates parameters repeatedly. Monitoring and checkpoints make that work interpretable and recoverable.
Continue to generalization
The resource bill depends on the actual workload, and more passes need evidence of improvement beyond training examples. In Lesson six, we'll name that central goal: generalization to relevant new cases. We'll also examine how a model can fit its training data too closely or fail to capture the relationship at all.