Continuous Batching

Continuous Batching to sposób obsługi generowania, w którym skład batcha można zmieniać między kolejnymi iteracjami modelu. Zakończone żądanie opuszcza grupę, a oczekujące może zająć zwolnione miejsce, podczas gdy inne sekwencje nadal rosną. Nie trzeba czekać na zakończenie całej grupy. W pracy Orca, §3, „Iteration-level scheduling” scheduler odzyskuje kontrolę po jednej iteracji i ponownie wybiera żądania.

To szczególnie przydatne w Decode: jedna osoba potrzebuje krótkiej odpowiedzi, inna kilkuset tokenów. Samo zebranie kilku żądań przed uruchomieniem modelu nie zapewnia możliwości zmiany składu już działającego batcha. Nowe żądanie wymaga też Prefill; obsługa tego etapu razem z generowaniem zależy od implementacji silnika.

Czy C musi czekać na A?

Własny eksperyment: dostępne są dwa miejsca. A i B są gotowe w chwili 0 i potrzebują odpowiednio sześciu oraz dwóch rund. C staje się gotowe w chwili 1, potrzebuje dwóch rund. W obu wariantach wykonujemy te same obliczenia, ale w stałej grupie miejsce po B nie przyjmuje C aż do końca A.

Przy Continuous Batching C rusza w chwili 2 i kończy w 4; przy stałej grupie rusza w 6 i kończy w 8. Przełącz B na sześć rund: w tym przypadku wcześniejsze zwolnienie miejsca znika i obie strategie dają ten sam harmonogram.

Rundy mają tu umowną, jednakową długość. Prefill i transfery są poza eksperymentem; „gotowe” oznacza gotowość do pokazywanych rund. Na GPU czas iteracji zależy od jej pracy, więc liczba zajętych miejsc nie jest procentem wykorzystania urządzenia.

Możliwość dołączenia żądania nie gwarantuje natychmiastowego startu: obowiązują limity pamięci i polityka schedulera (Orca, §4.2). PagedAttention ułatwia gospodarowanie pamięcią, ale samo nie ustala kolejności obsługi.

Wykorzystuję treści generowane przez AI jako część mojego codziennego procesu nauki.