Choosing Batch Size

Batch size is not only “how much fits in GPU memory.” It changes how noisy each update is, how fast you finish an epoch, and how the model generalizes. What usually matters is the effective batch size — how many examples influence one optimizer step.

Intuition

Term Plain-English idea
Micro-batch Examples processed in one forward/backward pass on one GPU
Gradient accumulation How many micro-batches you combine before one weight update
Effective batch micro-batch × accumulation × number of GPUs

Example: micro-batch 2, accumulate 16, 4 GPUs → effective batch 128. You still fit only 2 examples at a time on each GPU, but each update “sees” 128 examples.

How it works

How people choose a batch size

  1. Start from what memory allows for the micro-batch.
  2. Use gradient accumulation to reach a sensible effective batch if one micro-batch is tiny.
  3. Watch the loss: noisy and never settling usually means “effective batch too small or learning rate too high.”
  4. If training is oddly flat despite a healthy learning rate, you may be taking too few optimizer steps (effective batch too large for the data size).

Trade-offs

Direction What tends to happen
Smaller effective batch Noisier gradients, more jitter, more steps per epoch
Larger effective batch Smoother gradients, fewer updates, risk of under-training if the dataset is small
Raise batch a lot Often need a carefully retuned learning rate (not a random guess)

Let the loss curves judge

Practical recommendation

What goes wrong

One-line summary

Care about effective batch size (micro-batch × accumulation × GPUs): large enough for stable updates, small enough that you still take enough learning steps.

Key terms