Co powoduje skoki opóźnienia pierwszego tokenu po przełączeniu modeli przez lokalną usługę AI?

Opóźnienie pierwszego tokena zwykle gwałtownie rośnie po przełączeniu modelu, ponieważ nowo wybrany model musi odbudować stan rezydentny, zanim będzie mógł przetworzyć prompt.

Domowy serwer AI może szybko odpowiadać przy użyciu jednego rozgrzanego modelu, przełączyć się na model wizyjny lub programistyczny, a następnie zatrzymać się przed wygenerowaniem pierwszego tokena. Opóźnienie może obejmować odczyt wag, dekwantyzację, transfer urządzenia, kompilację jąder, przechwytywanie grafu CUDA, alokację pamięci podręcznej i wstępne przetwarzanie promptu. To, który etap dominuje, zależy od pamięci masowej, dostępnej pamięci akceleratora, zasad działania środowiska uruchomieniowego oraz od tego, czy poprzedni model został całkowicie usunięty z pamięci.

Zimne ładowanie wag to pierwsza grupa przyczyn

Jeśli kolejnego modelu nie ma w pamięci RAM ani VRAM, serwer musi odczytać jeden lub więcej fragmentów checkpointu, zweryfikować je lub zmapować, utworzyć tensory i przesłać użyteczne wagi do urządzenia wykonawczego. Większy plik lub wolniejsza ścieżka NAS wydłuża przerwę przed rozpoczęciem inferencji.

Pomiary opóźnienia zimnego startu LLM pokazują, że uruchamianie może dominować nad TTFT, gdy stan modelu jest zimny. Ten objaw pojawia się jako intensywne odczyty z pamięci masowej i czas pracy modułu ładującego model, zanim zostaną uruchomione jakiekolwiek jądra wstępnego przetwarzania promptu. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Jeśli przełączanie między dwoma modelami, które nadal pozostają w pamięci, powoduje taki sam skok, ładowanie wag nie jest pełnym wyjaśnieniem. Rozstrzygającą obserwacją jest to, czy liczba odczytanych bajtów i stan modeli rezydentnych zmieniają się przy wolnym żądaniu.

Inicjalizacja środowiska uruchomieniowego tworzy drugą zimną ścieżkę

Załadowany model nadal może być operacyjnie zimny. Środowisko uruchomieniowe może inicjalizować kontekst urządzenia, wybierać jądra, kompilować kształty, przechwytywać grafy, alokować bloki KV albo tworzyć pamięci podręczne tokenizera i szablonów promptów przy pierwszym żądaniu po aktywacji.

Analiza inżynieryjna dotycząca strumieniowania modeli i rozgrzewania rozdziela strumieniowanie z pamięci masowej od inicjalizacji i rozgrzewania. Charakterystyczny przebieg tego etapu obejmuje niewielką aktywność wejścia-wyjścia checkpointu, po której następują kompilacja, alokacja lub aktywność akceleratora przed przetwarzaniem promptu. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Kształt modelu, backend kwantyzacji, limit kontekstu, profile partii i stan sterownika określają, które artefakty można ponownie wykorzystać. Szybki powrót do poprzedniego modelu może być szybki, jeśli pamięci podręczne przetrwały, natomiast eksmisja spowodowana presją na pamięć ponownie uczyni tę samą ścieżkę zimną.

Kolejkowanie i wstępne przetwarzanie mogą przypominać opóźnienie ładowania modelu

Żądanie przełączenia może czekać na zakończenie pracy modelu, odzyskanie pamięci, inne żądanie użytkownika lub długi prompt. Po przyjęciu żądania wstępne przetwarzanie obejmuje każdy token wejściowy przed dekodowaniem, więc dłuższa historia zwiększa TTFT bez zmiany czasu ładowania modelu. Tę granicę należy mierzyć osobno w realistycznych warunkach działania.

Architektura obsługi stronicowanej pamięci podręcznej KV wyjaśnia, jak aktywne sekwencje zużywają stronicowane bloki KV oraz jak przyjmowanie zależy od dostępnej pojemności pamięci podręcznej. Przełączenie, które zmienia rezerwacje pamięci podręcznej, może zatem zmienić czas oczekiwania w kolejce niezależnie od rozmiaru checkpointu.

Granica diagnostyczna pojawia się wtedy, gdy ciepły, rezydentny model ma stabilną inicjalizację, a skok opóźnienia podąża za długością promptu lub współbieżnością. W takim przypadku przełączanie modeli jest tylko korelacją; bezpośrednią przyczyną jest wstępne przetwarzanie lub planowanie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Podziel TTFT na ładowanie, rozgrzewanie, kolejkę i wstępne przetwarzanie

Odtwarzaj stałe prompty, rejestrując eksmisję modelu, liczbę bajtów checkpointu, przepustowość pamięci masowej, transfer z hosta do urządzenia, tworzenie kontekstu urządzenia, kompilację jąder, przechwytywanie grafu, alokację KV, czas oczekiwania w kolejce, czas wstępnego przetwarzania i pierwszy krok dekodowania na jednym monotonicznym zegarze. Praktyczne konsekwencje są widoczne, gdy kilka źródeł konkuruje o ograniczony kontekst.

Porównaj ślad z routingiem modeli według pamięci, a następnie osobno przetestuj zimne przełączenie, natychmiastowy powrót, routing dwóch modeli rezydentnych, krótki prompt i długi prompt. Zachowaj te same ustawienia próbkowania, klienta i współbieżności, aby zmieniać tylko zamierzony stan. Ta zależność powinna pozostać jawna w końcowym interfejsie.

Przypisz skok do najwcześniejszego etapu, który się wydłuża. Utrzymuj wagi w pamięci, gdy dominuje ładowanie, zachowuj zgodne artefakty, gdy dominuje inicjalizacja, oraz zmień zasady przyjmowania lub kontekstu, gdy o TTFT decydują kolejka lub wstępne przetwarzanie, a nie samo przełączenie.