Dlaczego opóźnienie pierwszego tokena lokalnego LLM-a wzrasta po bezczynności serwera?

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 Does Local LLM First-Token Latency Rise After the Server Sits Idle? - Zima Store Online

Opóźnienie pierwszego tokenu często rośnie po bezczynności, ponieważ kolejne żądanie musi odtworzyć stan modelu, pamięci, akceleratora i zasilania, z którego korzystają żądania obsługiwane przy rozgrzanym systemie.

Domowy serwer AI może szybko odpowiadać na powtarzające się prompty, a następnie działać wolno, gdy pierwsze żądanie nadejdzie następnego ranka. Model może nadal znajdować się na dysku, ale jego strony, przydział pamięci GPU, jądra i kontekst wykonywania mogą nie być już rozgrzane. Szybkość pamięci masowej, presja na pamięć, eksmisja zasobów przez środowisko uruchomieniowe, zarządzanie zasilaniem urządzeń i długość promptu określają, jak duże opóźnienie powróci.

Bezczynność usuwa kilka różnych rodzajów rozgrzanego stanu

Rozgrzane żądanie może ponownie wykorzystać wagi znajdujące się już w pamięci RAM lub VRAM, strony systemu plików zachowane przez system operacyjny, zainicjalizowane biblioteki akceleratora, skompilowane jądra, pule pamięci i aktywny proces roboczy modelu. Czyszczenie po okresie bezczynności może usunąć tylko jedną warstwę albo całkowicie zakończyć proces.

Wielowarstwowe ładowanie punktów kontrolnych skraca uruchamianie modeli bezserwerowych, utrzymując punkty kontrolne blisko akceleratorów, ładując je przez wiele warstw pamięci masowej i planując żądania tam, gdzie stan modelu jest już lokalnie dostępny. Jego konstrukcja pokazuje, że zimne opóźnienie jest łańcuchem transferów i etapów inicjalizacji, a nie pojedynczą wartością odczytu z dysku.

Obserwowane opóźnienie zależy od tego, która warstwa ostygła. Proces, który pozostał aktywny, może potrzebować jedynie zwiększenia częstotliwości zegara urządzenia, podczas gdy eksmitowany model musi odczytać wagi, przydzielić pamięć urządzenia, odbudować struktury środowiska uruchomieniowego, a następnie przetworzyć prompt przed wygenerowaniem tokenu.

Ładowanie modelu i faza prefill kumulują się, zanim pojawi się jakikolwiek token

Czas do pierwszego tokenu obejmuje oczekiwanie w kolejce, dostępność wag, inicjalizację środowiska uruchomieniowego, tokenizację i fazę prefill dla całego wejścia. Szybkość dekodowania nie może ukryć tych etapów, ponieważ żaden token wyjściowy nie istnieje, dopóki faza prefill nie utworzy pierwszego stanu dekodowania.

Ponowne wykorzystanie pamięci GPU zachowuje parametry w nieużywanej pamięci GPU i stosuje planowanie uwzględniające lokalność, aby ograniczyć powtarzające się transfery. Raportowane skrócenie czasu zimnego startu pokazuje, dlaczego zachowanie częściowej rezydencji może mieć znaczenie, nawet gdy usługa nie może utrzymywać w pełni załadowanego każdego modelu.

Długi prompt systemowy może więc nadal działać wolno po rozgrzaniu wag, podczas gdy krótki prompt może zatrzymać się na zimnym ładowaniu modelu. Oddzielenie czasu ładowania, inicjalizacji, fazy prefill i pierwszego dekodowania zapobiega temu, aby jedna uśredniona wartość TTFT ukrywała rzeczywisty zimny komponent.

Oszczędzanie energii jest zwykle mniejszą, ale mierzalną warstwą

Procesory, procesory GPU, urządzenia NVMe i łącza PCIe mogą podczas bezczynności przechodzić w stany niższego poboru mocy. Pierwszy impuls musi zwiększyć częstotliwość zegara i przywrócić aktywne ścieżki, co dodaje krótkie narastanie opóźnienia przed rozpoczęciem stabilnych obliczeń; agresywne usypianie hosta może dodać znacznie więcej, wstrzymując usługi lub dyski.

Nakładanie na siebie etapów zimnego startu łączy ładowanie modelu, komunikację i obliczenia podczas zimnych startów brzegowych modeli LLM. Praca pokazuje, że ukrycie jednego etapu uruchamiania wymaga koordynacji z pozostałymi, szczególnie gdy wagi i obliczenia są rozproszone między urządzeniami o ograniczonych zasobach.

Błędem jest przypisywanie każdej wolnej pierwszej odpowiedzi stanowi zasilania. Jeśli opóźnienie mierzy się w wielu sekundach, zwykle dominuje eksmisja modelu, odczyty z pamięci masowej, uruchamianie kontenera lub faza prefill promptu, a nie przejście zegara trwające milisekundy. Diagnozuj oś czasu zamiast domyślnie wyłączać wszystkie mechanizmy oszczędzania energii.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Oddziel zimny start od kosztu zimnego promptu

Wyślij jeden stały, krótki prompt po 0, 1, 10, 60 i 480 minutach bezczynności. Dla każdego przedziału zarejestruj czas życia procesu, rezydencję modelu, użycie pamięci RAM i VRAM, liczbę odczytanych bajtów, częstotliwości zegara urządzeń, czas oczekiwania w kolejce, tokenizację, fazę prefill, pierwsze dekodowanie i całkowity TTFT.

Porównaj warstwę pamięci masowej z pamięcią masową dla zimnego startu modelu, a następnie powtórz test, przypinając proces roboczy, rozgrzewając tylko pamięć podręczną systemu plików, utrzymując rozgrzaną wyłącznie pamięć RAM hosta i zmieniając długość promptu. Każdy test powinien modyfikować jedną warstwę stanu, zamiast łączyć wszystkie optymalizacje.

Traktuj serwer jako rozgrzany tylko wtedy, gdy powtarzające się okresy bezczynności zachowują wymagany TTFT bez zagładzania innych usług. Jeśli przypięcie modelu powoduje presję na pamięć lub blokuje zadania o wyższym priorytecie, zaakceptuj ograniczony zimny start i ujawnij ten fakt zamiast ukrywać kompromis.