Czym jest ciągłe grupowanie i kiedy ma znaczenie w przypadku domowego serwera AI?
Ciągłe grupowanie planuje aktywne sekwencje podczas każdej iteracji dekodowania, umożliwiając dołączanie nowych żądań i opuszczanie grupy przez ukończone żądania bez oczekiwania na stałą partię.
Rodzina może w ciągu kilku sekund wysłać do jednego lokalnego modelu żądanie głosowe, pytanie dotyczące dokumentu i polecenie programistyczne. Ich prompty i długości wyników różnią się, więc stała partia marnuje wolne miejsca, podczas gdy krótsze odpowiedzi czekają na najdłuższą. Ciągłe grupowanie stale tworzy wokół modelu nowy zestaw użytecznych zadań, ale ma znaczenie tylko wtedy, gdy żądania nakładają się w czasie, a serwer dysponuje wystarczającą pamięcią i zapasem mocy obliczeniowej oraz możliwości planowania.
Planowanie na poziomie iteracji to kluczowa idea
Dekodowanie autoregresywne przesuwa każdą aktywną sekwencję o mniej więcej jeden token podczas każdej iteracji modelu. Ciągły harmonogram wybiera sekwencje gotowe do wykonania w następnej iteracji, przyjmuje nowe żądania, gdy pojawia się wolna przepustowość, i natychmiast usuwa sekwencje po ich ukończeniu.
Artykuł Orca wprowadził planowanie na poziomie iteracji, zamiast planowania na poziomie całych żądań. Grupowanie selektywne łączy następnie zgodne operacje, pozostawiając zadania zależne od konkretnego żądania oddzielnie. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.
Nie jest to to samo co strumieniowe przesyłanie tokenów użytkownikowi. Strumieniowanie zmienia moment dostarczania wyniku, natomiast ciągłe grupowanie zmienia sposób, w jaki kilka żądań współdzieli wewnętrzne wykonywanie modelu. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja podejmie dalsze działania.
Różni się od grupowania statycznego i grupowania w oknie napływu
Grupowanie statyczne blokuje razem stałą grupę i często dopełnia krótsze sekwencje aż do zakończenia najdłuższej. Grupowanie w oknie napływu lub grupowanie dynamiczne przez chwilę czeka na zebranie żądań, ale nadal może wykonywać powstałą grupę jako jedną całość. Ciągłe grupowanie ponownie ocenia skład grupy podczas każdej iteracji.
Artykuł vLLM łączy planowanie na poziomie iteracji z stronicowanym zarządzaniem pamięcią podręczną KV, dzięki czemu zmieniające się zestawy sekwencji nie wymagają sztywnych, ciągłych rezerwacji. Planowanie i zarządzanie pamięcią uzupełniają się, ale nie są wzajemnie wymiennymi funkcjami. Tę granicę należy mierzyć oddzielnie w realistycznych warunkach pracy.
Większa liczba aktywnych sekwencji pozwala rozłożyć odczyty wag i może poprawić przepustowość, jednak każde żądanie konkuruje o pamięć KV i moc obliczeniową. Większa aktywna partia nie zawsze zapewnia lepsze opóźnienia ani sprawiedliwość. Praktyczne skutki pojawiają się, gdy kilka źródeł konkuruje o ograniczony kontekst.
To współbieżność, a nie sam rozmiar modelu, tworzy korzyść
Pojedynczy użytkownik interaktywny może odczuć niewielką poprawę, ponieważ nie ma drugiego żądania, które mogłoby wykorzystać niewykorzystaną przepustowość. Korzyści pojawiają się przy nakładających się żądaniach użytkowników domowych, gałęziach agentów, podsumowaniach działających w tle lub kilku aplikacjach współdzielących jeden załadowany model.
Sarathi-Serve analizuje, jak zakłócenia fazy prefill mogą pogarszać opóźnienia dekodowania, i wykorzystuje porcjowane operacje prefill, aby zwiększyć przewidywalność mieszanego planowania. Wynik pokazuje, że polityka przyjmowania żądań ma znaczenie obok samej funkcji ciągłego grupowania. Ta zależność powinna pozostać wyraźnie widoczna w końcowym interfejsie.
Granica awarii pojawia się przy presji na pamięć lub agresywnym przyjmowaniu żądań, które zwiększa czas generowania tokena wyjściowego i opóźnienia ogona. Gdy pamięć podręczna KV się zapełni, wywłaszczanie, wymiana lub ponowne obliczenia mogą wyeliminować zyski z przepustowości i destabilizować obsługę interaktywną.
Ustal, czy współbieżne zapotrzebowanie uzasadnia jego zastosowanie
Odtwórz jedno, dwa, cztery i osiem nakładających się żądań o realistycznych długościach promptów i wyników. Zapisz przepustowość, czas do pierwszego tokena, czas generowania tokena wyjściowego, czas ukończenia p95, wykorzystanie pamięci KV, przypadki wywłaszczenia oraz sprawiedliwość dla poszczególnych klas żądań.
Porównaj działanie z lukami w ciągłym grupowaniu. Powtórz test przy wyłączonym ciągłym grupowaniu lub z użyciem bazowej konfiguracji ze stałymi partiami, zachowując bez zmian model, kwantyzację, limity kontekstu i sprzęt. Wynik należy zatem sprawdzić względem pierwotnych danych.
Stosuj ciągłe grupowanie, gdy nakładanie się żądań zapewnia istotny wzrost przepustowości lub pojemności bez przekraczania interaktywnych opóźnień ogona. Jeśli żądania rzadko się nakładają, przed dodaniem złożoności harmonogramu nadaj priorytet utrzymaniu modelu w pamięci i opóźnieniu uruchamiania. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Czym jest dryf osadzeń i kiedy prywatny indeks wyszukiwania wymaga przebudowy?
Odkoduj dryf modelu, przetwarzania wstępnego, korpusu i zapytań; odróżnij monitorowanie od niezgodności oraz zdecyduj, kiedy prywatny indeks wymaga przebudowy.
Czym jest zgodność tokenizera i dlaczego może zakłócić przełączanie modeli?
Odkryj tożsamość słownictwa, znaczenie tokenów specjalnych, szablony czatu, buforowane tokeny, adaptery i kontrole zgodności przy lokalnym przełączaniu modeli.
Czym jest rezydencja modelu i kiedy lokalna usługa AI powinna przechowywać wagi w pamięci?
Poznaj rezydencję wag, poziomy pamięci podręcznej, zimne uruchomienia, eksmisję, multipleksowanie, presję pamięci oraz dowiedz się, kiedy domowa usługa AI powinna pozostać aktywna.
