Beware of the Batch Size: Hyperparameter Bias in Evaluating LoRA
Paper • 2602.09492 • Published
torch CuDNN (overriding the default SDPA)1.5e-04 - 2.5e-043 - 4Moss-Image Fast(rank 16, 0.25MP)0.26 MP ≈ 512 res1e-043Moss-Image Fast(rank 16, 0.25MP)0.26 MP ≈ 512 res1.5e-04 - 2.5e-043 - 4Local Batch Size: 3, LR: 0.0003) → ~0.37s/img (17m 43s)Gradient Accumulation: 3, LR: 0.0001) → ~0.83s/img (36m 17s)Batch Size: 3, LR: 0.0003) → ~0.69s/img (31m 20s)LR / Batch Size / Gradient Accumulation
- Effective Batch Size =
Batch Size × Gradient Accumulation. Gradient accumulation saves VRAM but is slower; a larger Batch Size is faster but uses more VRAM.- LR Scaling: Don't blindly apply the linear rule to LoRA. Validate with loss curves. (My baseline:
Batch 3+LR 0.0003). Note: The vanilla Fizgig benchmark used the defaultLR 0.0001, which is under-scaled for an effective batch of 3. As widely discussed on GitHub and Reddit, increasing the batch size generally requires a higher LR to compensate for fewer update steps.Paper TL;DR:
- Accurate, Large Minibatch SGD (2017): The "Linear Scaling Rule" — if you multiply batch size by k, multiply LR by k. This was designed for full fine-tuning on ImageNet, not LoRA (e.g.,
BS 1, LR 1e-4→BS 4, LR 4e-4).- One weird trick for parallelizing CNNs (2014): The "Square Root Scaling Rule" — if you multiply batch size by k, to keep gradient variance stable, scale LR by k^0.5 instead of k. More conservative when batch gets very large (e.g.,
BS 1, LR 1e-4→BS 4, LR 2e-4).- Beware of the Batch Size (2026): For LoRA specifically, batch size is not just a multiplier for LR — it's a first-order design parameter. Optimal batch depends on dataset size (most sensitive), rank, and model capacity. Vanilla LoRA matches fancy variants when batch is tuned properly.
Base model
krea/Krea-2-Raw