Co powoduje awarie serwowania LLM i jak je naprawić?
Tłumaczenie automatyczne
Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.
Awarie serwowania LLM często wynikają z niedoboru pamięci, większej liczby równoległych zadań, niż usługa może obsłużyć, lub ponownych prób, które powtarzają kosztowne żądania. Zanim zmienisz środowisko wykonawcze, ustal, który zasób lub etap zawodzi. Poprawne załadowanie modelu nie dowodzi, że poradzi sobie z planowanym ruchem.
Powiąż objaw z danymi
| Objaw | Dane do sprawdzenia w pierwszej kolejności | Zmiana do przetestowania |
|---|---|---|
| Błąd braku pamięci GPU | Wagi, przydział KV, aktywacje, długości żądań | Mniejsza aktywna partia, krótsze limity lub obsługiwana kwantyzacja |
| Opóźnienie rośnie bez błędów | Wykorzystanie KV, wywłaszczenia, oczekujące żądania | Mniej żądań dopuszczanych równocześnie lub większa wydajność potwierdzona pomiarami |
| Wolny pierwszy token | Kolejka, tokenizacja, wstępne przetwarzanie promptu, czasy sieciowe | Naprawić wolny etap; przetestować wstępne przetwarzanie w blokach, jeśli fazy sobie przeszkadzają |
| Obciążenie rośnie po przekroczeniu limitów czasu | Liczba ponownych prób i nadal wykonywana praca | Ograniczone ponowne próby i anulowanie porzuconej pracy |
Pamięć na wagi i pamięć na KV to oddzielne zasoby. Model 70B w FP16 potrzebuje około 140 GB na same wartości wag. Przy konwencjonalnej organizacji pamięci podręcznej dla pełnego mechanizmu uwagi jedna sekwencja Llama 3.1 70B o długości 128K tokenów dodaje 40 GiB danych KV w FP16, bez narzutu środowiska wykonawczego. Żadna z tych liczb sama w sobie nie opisuje całkowitego zapotrzebowania na pamięć.
Sprawdź wywłaszczenia, zanim powiększysz kolejkę
Gdy brakuje miejsca na KV, silnik serwowania może wywłaszczać żądania. vLLM V1 zwykle ponownie wykonuje obliczenia dla wywłaszczonej pracy, co zwiększa opóźnienie, nawet jeśli API ostatecznie zwróci poprawną odpowiedź. Powiąż liczbę wywłaszczeń z długościami promptów, aktywnymi sekwencjami i wykorzystaniem KV.
Ogranicz dopuszczaną pracę lub zmień testowany przydział pamięci. Zwiększenie wykorzystania pamięci GPU wymaga potwierdzenia, że pozostałe przydziały nadal się mieszczą. Przeniesienie danych KV nadających się do ponownego użycia do CPU lub na dysk także wymaga transferów; nie gwarantuje, że zbyt duże aktywne żądanie zmieści się w pamięci.
Ogranicz ponowne próby
Ponawiaj operacje po przejściowych błędach w ramach terminu i budżetu ponownych prób. Stosuj rosnące odstępy z losową zmiennością i przypisz ponowne próby jednej warstwie, aby próby bramy i klienta nie mnożyły się. Wytyczne SRE Google wyjaśniają, jak ponowne próby mogą pogłębiać przeciążenie.
Przekazuj anulowanie, gdy wywołujący rezygnuje, sprawdź, czy generowanie się zatrzymuje, i przetestuj to zachowanie pod obciążeniem. Większa pojemność kolejki opóźnia odrzucenie, ale nie zwiększa zdolności przetwarzania.
Przeczytaj sekcję tryby awarii serwowania LLM w przewodniku, aby poznać powiązane pojęcia dotyczące pamięci i planowania.