Step versus epoch in a training run: define the relationship.

**Steps and epochs** are two units that measure progress through training, and they answer different questions. A step is one optimizer update. The model sees an effective batch of examples, computes the loss, runs backprop, and the optimizer adjusts weights once. That whole cycle counts as one step. An epoch is one full pass through the training dataset. Every example has been shown to the model exactly once. The two are tied by the effective batch size. The effective batch is how many examples contribute to a single optimizer update. It equals the micro-batch per device, times the number of gradient accumulation steps, times the number of GPUs working in parallel. Divide the dataset size by the effective batch size and round up to get steps per epoch. Multiply by the number of epochs to get the total step count. Trainers let you cap a run by total steps or by epochs, and they stop on whichever bound triggers first.

**A step** is one optimizer update over one effective batch. **An epoch** is one full pass through the dataset. They convert through the effective batch size: $$\text{steps\_per\_epoch} = \lceil \text{num\_examples} / \text{effective\_batch\_size} \rceil$$ The effective batch is `micro_batch_per_device * grad_accum_steps * num_gpus`. So if you train on 12,800 examples for 3 epochs at effective batch 32, that is 3 times 400, which is 1,200 steps total. The distinction matters because step counts are not portable across cluster shapes. The same micro-batch and the same step count produce different amounts of learning when the GPU count or accumulation depth changes, because each step now covers more or fewer examples. Quoting only steps without naming the effective batch is ambiguous. Trainer configs typically accept both `max_steps` and `num_train_epochs` as run caps. Whichever bound triggers first ends the run. Pick `max_steps` for token-budget control, pick `num_train_epochs` for dataset-pass control.