Dlaczego odpowiedzi lokalnych modeli LLM stają się krótsze przy równoczesnym obciążeniu?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Do Local LLM Responses Become Shorter Under Concurrent Load? - Zima Store Online

Lokalne odpowiedzi LLM stają się krótsze pod obciążeniem, gdy warstwa obsługująca żądania wymienia budżet generowania na współbieżność za pomocą limitów, terminów, wywłaszczania lub nieudanych żądań.

Model nie decyduje sam z siebie, by odpowiadać zwięźlej tylko dlatego, że pojawił się inny użytkownik. Przy stałym promptcie i stanie próbkowania współbieżność powinna wpływać głównie na kolejkę i czas generowania tokenów. Krótsze odpowiedzi wskazują, że środowisko uruchomieniowe, brama, klient lub menedżer pamięci zmieniły efektywny warunek zatrzymania, anulowały pracę albo zwróciły częściowy strumień po przekroczeniu progu obciążenia.

Współbieżność zwiększa zużycie pamięci KV i aktywuje limity obsługi

Każda aktywna sekwencja zajmuje bloki pamięci podręcznej KV, które powiększają się wraz z zachowywanym kontekstem i wygenerowanymi tokenami. Gdy kilka żądań korzysta z tego samego akceleratora, środowisko uruchomieniowe może obniżyć maksymalną długość wyjścia, odrzucić przyjęcie żądania, wywłaszczyć sekwencję lub przenieść bloki, aby zmieścić partię w dostępnej pamięci.

Projekt obsługi oparty na stronicowanej alokacji pamięci podręcznej KV wykorzystuje stronicowane bloki KV, aby ograniczyć fragmentację i umożliwić większą współbieżność. Mechanizm ten zwiększa pojemność, ale pokazuje również, że każda aktywna sekwencja zużywa coraz większy przydział pamięci aż do zakończenia lub eksmisji.

Brama może narzucać osobny budżet tokenów dla żądania lub globalny budżet tokenów. Jeśli budżet ten wynika z dostępnej przepustowości, priorytetu lub długości kolejki, identyczne prompty otrzymują różną maksymalną długość wyjścia, mimo że wagi modelu i parametry próbkowania wydają się niezmienione.

Terminy i wywłaszczanie mogą zwrócić poprawnie wyglądającą częściową odpowiedź

Systemy interaktywne często wymuszają terminy, limity czasu bezczynności strumienia lub anulowanie przez klienta. Wolniejsze dostarczanie kolejnych tokenów pod obciążeniem powoduje wcześniejsze osiągnięcie tych limitów w odpowiedzi semantycznej, a niektóre interfejsy API zwracają już wysłane tokeny zamiast wyraźnego błędu.

Metoda dzielenia wstępnego przetwarzania na fragmenty rozbija przetwarzanie promptu na mniejsze części, aby zapobiec blokowaniu dekodowania przez długie etapy wstępne. Praca ta pokazuje, jak zmiany harmonogramowania wpływają na czas do pierwszego tokena i opóźnienie między tokenami przy mieszanym obciążeniu żądaniami. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Wywłaszczanie może zachować żądanie do późniejszego wznowienia, uruchomić je ponownie albo przerwać, zależnie od silnika. Jeśli klient rozłączy się podczas przerwy, serwer może zarejestrować anulowanie, podczas gdy interfejs wyświetli gramatyczny, lecz niepełny prefiks jako ukończoną odpowiedź.

Samo próbkowanie nie powinno niezawodnie korelować z obciążeniem

Stochastyczne dekodowanie w naturalny sposób generuje odpowiedzi o różnej długości, gdy temperatura i ziarno losowe są inne. Ta zmienność może współwystępować z obciążeniem w małych próbach, ale współbieżność nie ma bezpośredniego sygnału semantycznego, chyba że współdzielony stan, adaptacyjna polityka lub błąd oprogramowania zmienia ścieżkę dekodowania.

Badania nad harmonogramowaniem uwzględniającym SLO modelują routing i harmonogramowanie przy jednoczesnej ochronie celów dotyczących czasu między tokenami. Rozdzielenie przepustowości, TTFT i terminów dekodowania pokazuje, dlaczego politykę pojemności należy mierzyć niezależnie od jakości wyjścia modelu. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim zostanie zastosowana automatyzacja.

Punktem granicznym awarii jest obwinianie harmonogramu przed sprawdzeniem metadanych zatrzymania. Tokeny końca sekwencji, jawne limity długości, anulowania przez klienta, terminy serwera, błędy OOM i rozłączenia transportowe to różne przyczyny. Tylko powtarzalne, kontrolowane zmiany długości z odpowiadającymi im przyczynami zatrzymania potwierdzają mechanizm zależny od obciążenia.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Porównaj długość i przyczynę zatrzymania przy stałych poziomach współbieżności

Powtarzaj stałe prompty i ziarna przy jednym, dwóch, czterech i ośmiu równoczesnych żądaniach. Rejestruj żądaną maksymalną liczbę tokenów, rzeczywistą liczbę tokenów wyjściowych, przyczynę zakończenia, czas oczekiwania w kolejce, TTFT, opóźnienie między tokenami, termin zegarowy, rozłączenie klienta, liczbę wywłaszczeń, liczbę bajtów KV, wolną pamięć VRAM i błąd serwera.

Powiąż zachowanie pamięci z limitami równoczesnego obciążenia, a następnie powtórz test bez limitów czasu bramy i ze stałym limitem przyjmowania żądań. Zachowaj prompty, szablony, próbkowanie i kod klienta, aby jedyną zamierzoną zmianą była współbieżność. Tę granicę należy mierzyć osobno w realistycznych warunkach pracy.

Traktuj krótsze wyjście jako błąd obsługi, gdy wskaźnik ukończenia lub zakres semantyczny spada przed osiągnięciem reklamowanego budżetu. Jeśli rośnie tylko opóźnienie, a przyczyny zakończenia nadal wskazują EOS, zbierz więcej prób z ustalonym ziarnem; jeśli dominują przekroczenia czasu lub limity, jawnie ujawnij te polityki i odpowiednio je skonfiguruj.