Wprowadzenie
Critical Batch Size (Krytyczny Rozmiar Batcha) to taki rozmiar batcha, powyżej którego dalsze zwiększanie liczby przykładów przetwarzanych jednocześnie przestaje znacząco poprawiać jakość treningu lub nawet go pogarsza.
Dlaczego istnieje Critical Batch Size?
W małych batchach gradient jest bardzo zaszumiony (duża wariancja) – to pomaga modelowi uczyć się lepiej (efekt „noise helps”). Przy bardzo dużych batchach szum znika, ale model zaczyna się zachowywać jak w trybie full-batch (deterministycznym), co często prowadzi do gorszej generalizacji.
Kluczowe obserwacje
- Istnieje pewien próg (Critical Batch Size), przy którym stosunek sygnału do szumu gradientu jest optymalny
- Powyżej tego progu trzeba proporcjonalnie zwiększać learning rate (Linear Scaling Rule)
- Po przekroczeniu Critical Batch Size korzyści ze skalowania maleją dramatycznie
- Dla wielu architektur Critical Batch Size leży w zakresie 1k–32k przykładów
Przykłady z literatury
- Microsoft (2017–2018) – trenowali ResNet-50 na batch size 32k–64k
- DeepMind (Chinchilla era) – badania nad compute-optimal training
- OpenAI / Megatron – eksperymenty z batch size rzędu setek tysięcy
Praktyczne implikacje
- Nie ma sensu trenować z batch size znacznie powyżej Critical Batch Size bez specjalnych technik
- Przy bardzo dużych batchach warto stosować Layer-wise Adaptive Rate Scaling (LARS) lub AdaFactor
- Gradient Accumulation pozwala symulować duży batch size przy mniejszym zużyciu pamięci
Aktualny stan (2026)
W erze modeli na setki miliardów parametrów Critical Batch Size stał się bardzo ważnym parametrem przy planowaniu treningu. Najnowsze badania pokazują, że optymalny batch size zależy od architektury, rozmiaru modelu i ilości danych. Wiele laboratoriów stosuje teraz dynamiczne dostosowywanie batch size w trakcie treningu.
Powiązane pojęcia
Large Batch Training • Linear Scaling Rule • Noise Scale • Compute Optimal Scaling • Gradient Accumulation • LARS • Chinchilla Scaling Laws
Dodano: 17 maja 2026