Wprowadzenie
<strong>Critical Batch Size</strong> (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
- <strong>Microsoft (2017–2018)</strong> – trenowali ResNet-50 na batch size 32k–64k
- <strong>DeepMind (Chinchilla era)</strong> – badania nad compute-optimal training
- <strong>OpenAI / Megatron</strong> – 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
Dodano: 17 maja 2026