Co powoduje przerwy w wykorzystaniu GPU podczas ciągłego grupowania zadań LLM?

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.

What Causes GPU Utilization Gaps During Continuous LLM Batching? - Zima Store Online

Luki w wykorzystaniu GPU zwykle pojawiają się, gdy scheduler ciągłego batchowania nie może utworzyć zadań gotowych do uruchomienia albo zasilić akceleratora z powodu blokady zależności.

Domowy serwer LLM może raportować wysoką przepustowość, a jednocześnie wykazywać okresowe spadki wykorzystania GPU między iteracjami dekodowania. Ciągłe batchowanie usuwa ukończone sekwencje i dopuszcza nowe, ale nie może utworzyć zadań, gdy napływ żądań jest niewielki, bloki KV są niedostępne, długie fazy prefill blokują dekodowanie lub środowisko uruchomieniowe CPU przygotowuje batche zbyt wolno. Synchronizacja i przenoszenie danych w pamięci mogą powodować luki nawet przy pełnej kolejce żądań.

Podaż żądań i rotacja sekwencji mogą opróżnić batch

Ciągłe batchowanie zastępuje ukończone sekwencje na granicach iteracji. Jeśli napływ żądań jest nierównomierny, wyniki kończą się jednocześnie lub limity przyjmowania zatrzymują żądania poza kolejką zadań gotowych do uruchomienia, liczba aktywnych tokenów może spaść poniżej efektywnego zakresu pracy GPU.

Testy porównawcze ciągłego składu batcha porównują statyczne i ciągłe członkostwo żądań przy różnych długościach wejścia i wyjścia oraz czasach napływu. Charakterystycznym objawem jest niewielka liczba tokenów gotowych do uruchomienia podczas luk w wykorzystaniu, mimo sprawnego akceleratora i braku błędu pamięci.

Naprawdę pusta kolejka nie oznacza wady schedulera. Przed uznaniem każdego okresu bezczynności za utraconą przepustowość porównaj tempo napływu, liczbę przyjętych sekwencji i liczbę tokenów planowanych w każdej iteracji. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Prefill, dekodowanie i alokacja KV tworzą luki w pracy schedulera

Prefill przetwarza wiele tokenów promptu za pomocą jąder intensywnie wykorzystujących obliczenia, podczas gdy dekodowanie przesuwa każdą sekwencję o jeden token i często jest ograniczone przepustowością pamięci. Mieszanie tych faz może opóźniać dekodowanie, a rezerwowanie lub odzyskiwanie bloków KV może wstrzymywać przyjmowanie między iteracjami.

Projekt planowania porcjowanego prefill wykorzystuje porcjowany prefill, aby zapobiec monopolizowaniu iteracji obsługi przez długie prompty. Jego mechanizm wskazuje luki skorelowane z granicami prefill, alokacją KV lub wywłaszczaniem żądań, a nie ze słabym popytem. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja podejmie dalsze działania.

Jeśli luki w pracy GPU zwiększają się wraz z długością promptu, ale nie z długością wyjścia, silniejszą przyczyną jest planowanie prefill. Jeśli odpowiadają presji na pamięć podręczną lub eksmisjom, odpowiada za nie przyjmowanie ograniczane pamięcią, nawet gdy kolejka pozostaje pełna. Tę granicę należy mierzyć osobno w realistycznych warunkach pracy.

Zasilanie z CPU i synchronizacja między urządzeniami mogą zagłodzić jądra

Tokenizacja, próbkowanie, decyzje schedulera, metadane tensorów, kopiowanie z hosta do urządzenia, kolektywy rozproszone i rejestrowanie zdarzeń odbywają się poza głównymi jądrami. Nasycony wątek CPU lub blokująca synchronizacja może pozostawić GPU w oczekiwaniu między poprawnymi skądinąd batchami. Praktyczny skutek pojawia się, gdy wiele źródeł konkuruje o ograniczony kontekst.

Badania nad interferencją między prefill a dekodowaniem rozdzielają zasoby prefill i dekodowania, aby ograniczyć zakłócenia i spełnić docelowe wymagania dotyczące opóźnień. Wynik potwierdza, że jeden wykres wykorzystania łączy zachowanie schedulera, hosta, komunikacji i akceleratora. Ta zależność powinna pozostać jawna w końcowym interfejsie.

Granica awarii to krótki interwał próbkowania, który raportuje normalne granice jąder jako zerowe wykorzystanie. Potwierdź luki za pomocą śladu lub liczników sprzętowych; uśrednianie w panelu może tworzyć pozorne spadki, które nie zmniejszają liczby tokenów na sekundę.

-15% OFF

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

Single board computer zimaboard2

Wyrównaj osie czasu kolejki, schedulera i jąder

Odtwarzaj kontrolowany napływ równomierny i skokowy, rejestrując oczekujące, przyjęte i uruchomione żądania, liczbę tokenów promptu i dekodowania w każdej iteracji, wolne bloki KV, wywłaszczenia, czas pracy schedulera CPU, tokenizację, próbkowanie, kopiowanie, kolektywy, luki między uruchomieniami jąder, taktowanie GPU i przepustowość wyjściową.

Porównaj wzorzec z zachowaniem ciągłego batchowania, a następnie pojedynczo zmieniaj tempo napływu, długość promptu, rozmiar porcjowanego prefill, budżet pamięci podręcznej i przypisanie CPU. Zachowaj model, kwantyzację i docelowe opóźnienie. Wynik należy zatem sprawdzić względem pierwotnych dowodów.

Przed strojeniem sklasyfikuj każdą dolinę jako brak popytu, blokadę przyjmowania, interferencję prefill, presję na pamięć podręczną, zagłodzenie hosta lub synchronizację. Optymalizuj odpowiednią granicę; wymuszenie większego batcha nie naprawi pustej kolejki ani zablokowanego wątku hosta.