Jak ciągłe grupowanie żądań wpływa na sprawiedliwość na domowym serwerze AI?
Batchowanie ciągłe poprawia wykorzystanie zasobów poprzez uzupełnianie aktywnych partii, ale sprawiedliwość zależy od tego, jak użytkownicy w czasie otrzymują dostęp, obsługę tokenów i pamięć.
Domowy serwer AI może obsługiwać kilka rozmów jednocześnie, bez czekania, aż każda sekwencja zakończy się w tym samym momencie. Ukończone żądania opuszczają partię, nowe do niej dołączają, a aktywni użytkownicy współdzielą kolejne iteracje wnioskowania. Zwiększa to przepustowość, jednak żądania nie są równoważne: jeden użytkownik może wysłać krótkie polecenie, inny długi dokument, a jeszcze inny agenta generującego setki tokenów. Sprawiedliwy harmonogram musi określić, jaka jednostka pracy się liczy, jak nowe żądania są przyjmowane oraz jak priorytety współdziałają z nieprzewidywalną długością generowanych wyników.
Batchowanie ciągłe zmienia jednostkę planowania ze stałej partii na iteracje
Batchowanie statyczne utrzymuje jedną grupę do momentu ukończenia wszystkich żądań, marnując zasoby, gdy krótkie żądania kończą się wcześniej. Batchowanie ciągłe może uzupełniać wolne miejsca pomiędzy iteracjami generowania.
Orca wprowadziła planowanie na poziomie iteracji, dzięki któremu żądania mogą dołączać do partii i ją opuszczać wraz ze zmianą stanu ich sekwencji.
Poprawia to wykorzystanie zasobów, ale oznacza również, że użytkownicy wielokrotnie rywalizują o miejsce w następnej iteracji, zamiast otrzymać jeden niepodzielny slot żądania.
Kolejność przyjmowania określa, kto zaczyna gromadzić obsługę
Żądanie znajdujące się poza aktywną partią nie otrzymuje żadnego postępu modelu. Harmonogram może przyjmować żądania według czasu nadejścia, szacowanej długości, priorytetu, dostępnych bloków KV lub licznika sprawiedliwości.
vLLM łączy ciągłe przyjmowanie ze stronicowanym zarządzaniem pamięcią podręczną KV, dzięki czemu pamięć może być przydzielana w miarę rozrastania się sekwencji.
Obsługa żądań według kolejności zgłoszeń jest prosta, ale kolejka długich żądań może opóźniać późniejsze krótkie polecenia domowników, nawet jeśli te polecenia zakończyłyby się szybko.
Równe liczenie żądań może zapewniać nierówną obsługę akceleratora
Odpowiedź zawierająca pięć tokenów i odpowiedź zawierająca pięćset tokenów to nadal po jednym żądaniu, jednak zajmują zupełnie różną liczbę iteracji dekodowania. Długość promptu również przekłada się na różną ilość pracy wstępnego przetwarzania.
Virtual Token Counter definiuje sprawiedliwość opartą na tokenach, ponieważ sama liczba żądań nie odzwierciedla obsługi zużytej przez heterogeniczne obciążenia LLM.
Polityka domowa powinna określać, czy sprawiedliwość oznacza równą ilość pracy związanej z tokenami, równy czas oczekiwania, równe szanse na ukończenie czy priorytet dla zadań wrażliwych na opóźnienia.
Żadna pojedyncza miara nie pasuje do każdego obciążenia. Polecenie głosowe i podsumowanie wykonywane w tle nie muszą otrzymywać identycznego traktowania.
Nieznana długość wyniku utrudnia przewidywanie przyszłej obsługi
Harmonogram zna rozmiar promptu w momencie przyjęcia, ale zwykle nie wie dokładnie, ile tokenów wyjściowych wygeneruje model. Jedno żądanie może pozostać aktywne znacznie dłużej, niż oczekiwano.
Badania nad sprawiedliwością wskazują na nieprzewidywalną długość żądań jako szczególne wyzwanie w obsłudze LLM.
Rozliczanie obsługi w miarę faktycznego przetwarzania tokenów pozwala uniknąć całkowitego polegania na niedokładnym oszacowaniu długości, ale nadal może umożliwić długiemu żądaniu zajmowanie pamięci przez wiele iteracji.
Duże etapy wstępnego przetwarzania mogą zakłócać użytkowników, którzy już otrzymują tokeny
Nowy prompt zawierający dokument może zostać przyjęty, gdy kilku użytkowników dekoduje swoje wyniki. Jego wymagające obliczeniowo wstępne przetwarzanie może wydłużyć iterację, na którą muszą czekać aktywne rozmowy.
Sarathi-Serve wykorzystuje planowanie bez zatrzymań, aby dzielić duże etapy wstępnego przetwarzania i ograniczać ich wpływ na opóźnienia dekodowania trwających rozmów.
Harmonogram, który liczy wyłącznie tokeny dekodowania, nadal może być niesprawiedliwy, jeśli jeden użytkownik wielokrotnie wprowadza duże etapy wstępnego przetwarzania opóźniające strumieniowanie wyników wszystkich pozostałych.
Sprawiedliwe rozliczanie powinno więc obejmować zarówno przetwarzanie danych wejściowych, jak i generowanie tokenów.
Presja na pamięć może powodować problemy ze sprawiedliwością, zanim obliczenia osiągną pełne obciążenie
Każda aktywna rozmowa potrzebuje pamięci podręcznej KV, a dłuższe konteksty zajmują więcej bloków. Użytkownik dysponujący jednym dużym kontekstem może zmniejszyć liczbę innych żądań mieszczących się w aktywnej partii.
Analiza obsługi wielu użytkowników w ZimaSpace łączy współbieżność domową ze współdzieloną pamięcią modelu i decyzjami harmonogramu.
Wstrzymanie lub przeniesienie żądania może przywrócić dostępną pojemność, ale przerwany użytkownik może później zapłacić za ponowne obliczenia, ponowne wczytanie pamięci podręcznej lub dłuższy czas ukończenia.
Przyjmowanie do pamięci i planowanie obliczeń powinny zatem stosować tę samą politykę sprawiedliwości, zamiast działać jako niezależne ograniczenia.
Priorytety wymagają starzenia, limitów i pomiarów widocznych dla użytkowników
Sterowanie głosowe, narzędzia ułatwień dostępu i krótki interaktywny czat mogą zasługiwać na wyższy priorytet niż generowanie embeddingów lub nocne podsumowania. Czyste planowanie priorytetowe może jednak doprowadzić do zagłodzenia zadań o niskim priorytecie.
Llumnix wykorzystuje dynamiczne planowanie, aby dostosowywać rozmieszczenie żądań i decyzje dotyczące zasobów do zmieniających się warunków obsługi.
Dodaj mechanizm starzenia, limity na użytkownika, maksymalną długość kontekstu lub wyniku oraz zarezerwowany udział zasobów dla zadań w tle, aby preferowane zadania reagowały szybko, nie blokując bezterminowo całej reszty.
Mierz czas oczekiwania w kolejce, czas do pierwszego tokena, odstęp między tokenami, czas ukończenia, liczbę obsłużonych tokenów oraz wstrzymania według użytkownika lub klasy obciążenia. Batchowanie ciągłe jest sprawiedliwe tylko wtedy, gdy obserwowany rozkład odpowiada polityce domowej, a nie jedynie wtedy, gdy całkowita liczba tokenów na sekundę jest wysoka.
Polecane produkty
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania
Jakie funkcje umożliwiają utworzenie domowej granicy zaufania AI wokół wrażliwych plików?
Domowa granica zaufania dla AI łączy szyfrowanie danych w spoczynku, uprawnienia zgodne z zasadą najmniejszych przywilejów, sandboxing w czasie działania oraz zakresowe pobieranie danych...
Co powoduje, że prywatne wyniki wyszukiwania faworyzują często edytowane pliki?
Często edytowane pliki zyskują przewagę w rankingu, gdy każda aktualizacja dodaje sygnały świeżości, fragmentów, wersji lub interakcji bez normalizacji względem źródła.
Co powoduje, że modele obecności w inteligentnym domu mylą gości z mieszkańcami?
Goście mogą wyglądać jak domownicy, gdy system obserwuje wzorce aktywności gospodarstwa domowego, ale nie ma stabilnego sygnału tożsamości osoby, która je generuje.
