Planowanie mocy GPU dla modelu, który twój zespół serwuje sam

Co ogranicza pojedynczą replikę

Pamięć GPU mieści wagi modelu i KV cache, który rośnie z długością kontekstu i liczbą równocześnie przetwarzanych sekwencji. Po załadowaniu wag to KV cache wyznacza, ile zapytań replika może przetwarzać w jednej partii, a to wyznacza przepustowość. Artykuł o PagedAttention, na którym opiera się vLLM, pokazał, że marnowana pamięć KV cache ograniczała wielkość partii, a zarządzanie nią stronami podniosło przepustowość przy tym samym opóźnieniu.

W vLLM parametr gpu_memory_utilization określa, ile pamięci zajmuje instancja, według obecnej dokumentacji domyślnie 0,92, a max_model_len i max_num_seqs ograniczają kontekst i równoległość. Gdy KV cache się kończy, vLLM wywłaszcza zapytania i przelicza je ponownie, co według dokumentacji może pogorszyć opóźnienie. Skwantyzowane wagi albo mniejszy typ danych KV cache zwalniają pamięć na więcej równoczesnych zapytań, kosztem jakości, który trzeba przetestować.

Opisz obciążenie, zanim zaczniesz testy

Test na syntetycznych promptach o stałej długości odpowiada na pytanie, którego nikt nie zadał. Przed pomiarem zapisz:

• Liczbę przybyć na sekundę według godziny i dnia tygodnia, z najbardziej obciążonymi pięcioma minutami zamiast średniej godzinowej
• Rozkład tokenów wejściowych i wyjściowych na zapytanie, bo kilka długich zapytań zajmuje dużą część KV cache
• Cele opóźnień dla każdej funkcji, na przykład p95 czasu do pierwszego tokenu i czasu na token wyjściowy
• Która praca jest interaktywna, a która może poczekać, na przykład nocne przetwarzanie dokumentów

Przetestuj jedną replikę przy docelowym opóźnieniu

Benchmark serwowania w vLLM potrafi odtworzyć własny zbiór twoich promptów w wybranym tempie zapytań, z regulowaną nierównomiernością i opcjonalnym limitem równoległości, oraz raportować goodput, czyli zapytania, które spełniły ustalone przez ciebie cele dla pierwszego tokenu, czasu na token i czasu całkowitego. Zwiększaj tempo, aż goodput spadnie poniżej potrzebnego odsetka. To tempo jest pojemnością repliki dla tego obciążenia. Benchmark przepustowości offline odpowiada na inne pytanie, o maksymalną liczbę tokenów na sekundę bez celu opóźnienia, i przydaje się do planowania zadań wsadowych.

W trakcie testu obserwuj metryki samego serwera, ale traktuj je jako wskazówki. Rosnący czas w kolejce przy prawie pełnym KV cache sugeruje presję na pamięć, a spowolnienie generowania przy wolnym cache sugeruje moc obliczeniową, choć oba zjawiska mogą występować razem, a ustawienia schedulera wpływają na każde z nich. Zanim wskażesz ograniczenie, sprawdź liczbę wywłaszczeń, wykorzystanie mocy obliczeniowej i przepustowości pamięci GPU oraz liczbę działających zapytań, a potem powtórz test z kontrolowanymi zmianami równoległości i długości kontekstu, żeby zobaczyć, która z nich zmienia wynik.

Od jednej repliki do floty: przykład obliczeń

Wszystkie liczby są hipotetyczne. Wewnętrzny asystent w dni robocze rano osiąga szczyt 18 zapytań na sekundę, a w nocy i w weekendy spada do 2. Na prawdziwych promptach jedna replika na jednym GPU utrzymuje 99 procent goodputu do 5 zapytań na sekundę. Przy 6 czas w kolejce obniża goodput do 93 procent.

1. 1

   Repliki na szczyt

   18 podzielone przez 5 daje 3,6, więc szczyt uniosą 4 repliki.

2. 2

   Zapas na awarie

   Jedna replika więcej pokrywa awarię węzła lub wdrożenie kroczące, razem 5.

3. 3

   Spokojne godziny

   Przy 2 zapytaniach na sekundę wystarczy 1 replika plus 1 zapasowa.

4. 4

   Porównaj harmonogramy

   Pięć replik całą dobę zużywa około 3650 godzin GPU miesięcznie. Pięć przez 12 godzin w 22 dni robocze i 2 w pozostałych godzinach to około 2250, czyli mniej więcej o 38 procent mniej.

Harmonogram działa tylko wtedy, gdy repliki są gotowe przed porannym wzrostem ruchu. Ładowanie modelu nie trwa chwili, więc skaluj w górę według rozkładu, zamiast czekać, aż urosną kolejki. vLLM opisuje sposoby skrócenia kolejnych uruchomień, na przykład ponowne użycie cache kompilacji. Nocne zadania wsadowe mogą wtedy działać na zapasowej replice zamiast na osobnej flocie.

Zdecyduj, co przejmie ruch ponad plan

Żaden plan nie obejmie każdego skoku. Wybierz z góry jedną z trzech opcji. Ograniczona kolejka utrzymuje przewidywalne opóźnienie i wcześnie odrzuca nadmiar. Model hostowany jako przelew podtrzymuje odpowiedzi, o ile przeszedł te same testy jakości, a wasze zasady dotyczące danych na to pozwalają. Odkładanie mniej pilnej pracy wyprowadza zadania wsadowe poza szczyt. Każdy wybór ma swój koszt, a ustalenie go przed startem chroni przed odruchem kupowania GPU na skok, który zdarza się dwa razy w roku.