Epoch, Batch Size and Learning Rate Explained

These three control how a fine-tuning run walks through your data: how many times it sees each example, how many examples it weighs before updating, and how far each update moves. They’re the parameters people reach for when a run disappoints, and usually the wrong place to start.

What does each one mean?

One row each, with the key it maps to in a distil labs configuration file.

Term	What it controls	Config key	Default
Epoch	How many times the model sees each example, one complete pass per epoch	num_train_epochs	4
Batch size	How many examples are processed before a weight update	per_device_train_batch_size	1
Learning rate	How far the optimiser moves the weights per update	learning_rate	5e-5

The learning rate is consumed by AdamW, the decoupled-weight-decay variant of Adam introduced by Loshchilov and Hutter. Two related keys travel with it: learning_rate_scheduler, defaulting to linear, and warmup_ratio at 0.05, which ramps the rate up from zero over the first fraction of training rather than starting at full stride.

How do they interact?

Multiplicatively, not independently. The total number of weight updates is roughly dataset size divided by batch size, times epochs. Raising batch size while holding epochs fixed reduces how many updates the model gets, and often wants a compensating change elsewhere. The Trainer reference documents the gradient-accumulation setting that lets you raise effective batch size without more memory.

Which should you change first?

None of them. Data coverage moves results more than any of these three, and the classic symptom of too many epochs over a narrow set is overfitting. Cut epochs before touching the rest.

If runtime rather than quality is the concern, how long does fine-tuning take breaks down what actually dominates. Adapter capacity is a separate dial: see LoRA rank.