vllm prometheus observability llmops gpu ttft

Wskaźniki inferencji vLLM: od TTFT i TPOT do bufora KV i Goodput

Przewodnik produkcyjny dotyczący metryk vLLM Prometheus – wskaźniki skuteczności, percentyle opóźnień, stosunek I/O tokenów, przerwy w działaniu, wcześniejsze uzupełnianie danych w partiach, DPD oraz akceptacja dekodowania spekulatywnego.

Wydawca: REACTAPP.TOPDodane na tej stronie 26 wrz 202613 min czytania2973 słów

Źródła: A Deep Dive into vLLM Inference Metrics

Dostarczanie dużych modeli językowych nie stanowi takiego samego problemu z punktu widzenia obserwowalności jak dostarczanie bezstanowych mikrosług. Odsetek wykorzystania CPU oraz średni czas oczekiwania na żądanie to słabe wskaźniki, gdy zachowanie modeli jest determinowane przez mechanizmy takie jak uwaga skupiona, ciągłe grupowanie zapytań oraz pojemność pamięci HBM. Skupienie w środowisku produkcyjnym przesunęło się od surowej przerobowości tokenów w kierunku goodput – czyli pomyślnego ukończenia zadań w ramach ścisłych celów operacyjnych.

To przewodnik omawia podstawowe wskaźniki silnika vLLM, które powinny znaleźć się na panelach Grafana: liczniki niezawodności, histogramy opóźnień, aspekty ekonomiczne tokenów, dynamikę pamięci KV-cache, presję ze strony planeru oraz wybory topologiczne, które pojawiają się tylko wtedy, gdy dane telemetryczne są poprawnie odczytywane.

Streszczone statystyki i stan systemu

Silniki LLM często zawodzą w sposób niewidoczny – z degradowanymi wynikami generowania i ukrytymi przerwami – zamiast wyświetlać jasne błędy HTTP. Dlatego też ocena stanu systemu wymaga semantycznych powodów zakończenia, a nie tylko kodów stanu.

Wskaźnik skuteczności i rozkład powodów zakończenia

Wskaźnik skuteczności to liczba udanych zakończeń w stosunku do wszystkich przetworzonych żądań w określonym oknie czasowym. W vLLM oznacza to sprawdzenie, w jaki sposób zakończył się cykl generowania, a nie tylko liczenie kodów 200 OK. Zdrowe systemy zazwyczaj osiągają wskaźnik skuteczności na poziomie co najmniej ~99,5%; ciągłe spadki poniżej ~98% wskazują na krytyczną sytuację.

Licznik ten to vllm:request_success_total, oznaczony przez finished_reason:

Stop – naturalne zakończenie lub skonfigurowana fraza zatrzymująca. Traktuje się to jako prawdziwy sukces.
Length – skrócenie z powodu maksymalnej długości kontekstu lub liczby generacji.
Abort – rozłączenie ze strony klienta lub wewnętrzne przerwanie.

Częste zakończenia procesu z powodu chronicznego przekroczenia length oznaczają zazwyczaj, że model męczy się przy wykonywaniu zadania lub że limity max_model_len / generacji są zbyt restrykcyjne dla danego stylu promptu. Typowym sposobem formułowania w PromQL jest porównanie częstości zakończeń z powodu przerwania z częstością wszystkich zakończeń w oknie czasowym pięciu minut.

Przepustowość vs. konwergencja sukcesów

Narysuj wykres całkowitej przepustowości żądań obok liczby pomyślnie zakończonych zadań. Przy prawidłowym obciążeniu krzywe powinny iść w parze. Zwiększająca się różnica oznacza, że karty GPU tracą cykle na zadania, które nigdy nie kończą się pomyślnie – z powodu timeoutów (przerwań) lub przekroczenia limitu długości tekstu. Podczas testów obciążeniowych duże różnice wskazują na pogorszenie wydajności lub generacje, które nie kończą się i dążą do osiągnięcia limitu długości.

Zbieranie śmieci w Pythonie i pamięć procesu

Znaczna część kluczowych operacji odbywa się w językach CUDA/C++, ale zarządzanie nimi nadal odbywa się w Pythonie. Śledź liczbę operacji zbierania śmieci razem z zużyciem pamięci procesu (RSS).

Częste wykonywanie operacji GC wprowadza fluktuacje w czasie między tokenami. Stabilnie rosnące wartości RSS wskazują na wycieki pamięci w mechanizmach powiązań i ostatecznie prowadzą do uruchomienia mechanizmu eliminacji przeciążenia pamięci. Procesy mogą wydawać się „w porządku” pod względem zużycia CPU, niezależnie od tego, czy są nieużywane, czy obciążone; to właśnie w niezarządzanych zasobach pamięci pojawia się cicha śmierć systemu.

Ilościowe określanie opóźnienia i doświadczenia użytkownika

Opóźnienie w procesach generatywnych ma długi ogon rozkładu. Średnie wartości ukrywają prawdziwe problemy; konieczne są wskaźniki P50/P90/P99 oraz inne podobne.

Opóźnienie żądania od początku do końca

Czas od przybycia żądania do otrzymania ostatniego tokena i jego zamknięcia. vLLM udostępnia wartość vllm:e2e_request_latency_seconds w formie histogramu. Do obliczania kwantyli używana jest funkcja histogram_quantile() z interpolacją liniową wewnątrz poszczególnych grup danych. Nagłe skoki wartości P99 często oznaczają, że mechanizm przetwarzania partii nie potrafi prawidłowo uporządkować kolejności przybywania żądań – czas na sprawdzenie konfiguracji planerów i obciążenia pamięci cache.

Czas od początku do otrzymania pierwszego tokena (TTFT) P99

TTFT to metryka interaktywności. Zalecenia z dziedziny HCI zakładają czas poniżej jednej sekundy, zanim pojawi się frustracja.

Na TTFT duży wpływ ma prefill: odczytanie instrukcji, skupienie uwagi oraz utworzenie początkowego bufora KV. Koszt obliczeń rośnie mniej więcej proporcjonalnie do kwadratu długości sekwencji pomnożonego o szerokość — chodzi tu o obliczenia ograniczone TFLOPami. Przykład skali: prefill z 512 tokenami w modelu o mocy około 70B to kilkadziesiąt TFLOPów.

PromQL dla TTFT P99:

histogram_quantile(0.99, sum(rate(vllm:time_to_first_token_seconds_bucket[5m])) by (le))

W interfejsach czatowych TTFT P99 jest często decydującym ograniczeniem. Ogromne rozmiary pamięci w kartach graficznych średniej klasy (na przykład z serii L40S) mogą sprawić, że TTFT stanie się nie do przyjęcia, bez względu na grupowanie zapytań — co zmusza zespoły do wyboru mniejszych modeli lub chipów o wyższej mocy obliczeniowej (z serii H100).

Czas na jeden token wyjściowy (TPOT) i podział etapów inferencji

Po pierwszym tokenie przejmuje kontrolę operacja decode. TPOT (opóźnienie między tokenami) mierzy szybkość generowania kolejnych tokenów.

Dekodowanie jest zazwyczaj ograniczone przepustowością pamięci: na każdym kroku masy oraz historia KV są ponownie ładowane z HBM do jednostki obliczeniowej przy niskiej intensywności arytmetycznej (~1 FLOP/byte dla gęstych ścieżek niebędących typu MoE).

Korzystne rozłożenie:

E2E ≈ TTFT + (N_output − 1) × TPOT

Wykresy podziału etapów pokazują udział operacji prefill w stosunku do dekodowania:

Długi czas prefill → długie prompty lub niska wydajność w TFLOPS.
Długi czas dekodowania → długie wyniki lub przeciążona przepustowość HBM.

Porównanie TTFT z TPOT przy rosnącym obciążeniu to najszybszy sposób na zidentyfikowanie wąskiego gardła.

Przepustowość tokenów i charakterystyka obciążenia

Opóźnienie bez uwzględnienia objętości nie pozwala na określenie ceny sprzętu.

Przepustowość tokenów i stosunek IO

Rozdziel przepustowość na tokeny na sekundę w promptach oraz tokeny na sekundę podczas generowania. Wyższe, utrzymywane wartości całkowite lepiej amortyzują koszt używania GPU.

Stosunek tokenów wejściowych do wyjściowych (tokeny promptu w stosunku do tokenów generowanych) charakteryzuje pracę silnika:

wysoki (~20:1) — długie dane wejściowe, krótkie wyniki: RAG, streszczanie, klasyfikacja. Duży udział danych wstępnych.
niski — krótkie prompty, długie wyniki generowane: otwarty czat, generowanie kodu. Duży udział procesów dekodowania/HBM.

Nieodpowiednia topologia w stosunku do tego wskaźnika powoduje marnotrawstwo zasobów: użycie RAG w strukturach optymalizowanych pod dekodowanie lub długie rozmowy w systemach ubogich w dane wstępne.

Hmapa długości zapytań (Prompt)

Hmapy długości promptów pokazują, czy ruch składa się z spokojnej, jednomodalnej dystrybucji, czy z mieszanki małych i dużych promptów. Duże odchylenia w długości promptów tłumaczą nagłe wzrosty TTFT, nawet gdy QPS wydaje się niewielki.

Wewnętrzne mechanizmy silnika i dynamika pamięci cache

Zawartość czasu oczekiwania zewnętrznego zależy od stanu pamięci cache KV i planerza.

Wykorzystanie pamięci cache KV na GPU

Śledź, na jakim poziomie jest wypełniony zasób KV. W miarę wzrostu obciążenia ciągłe grupowanie sekwencji powoduje przyjmowanie coraz mniej z nich; po przekroczeniu określonego progu silnik interweniuje.

Wskaźnik trafień w pamięci cache z prefiksami i oszczędności

Caching prefiksów umożliwia ponowne użycie danych KV dla wspólnych prefiksów zapytań (zapytania systemowe, nagłówki RAG). Wskaźnik trafień oraz zaoszczędzone zasoby pokazują, czy projektowanie zapytań i ich kierowanie rzeczywiście wykorzystują te same prefiksy, czy też przypadkowo każde zapytanie jest unikalne.

Stan planeru i efektywność systemu

Obserwuj liczbę bieżących i czekających zadań. Wzrost liczby zadań w stanie oczekiwania przy stałej liczbie bieżących zazwyczaj oznacza ograniczenia związane z zasobem KV lub wartością max_num_seqs, a nie „zajęty CPU”.

Stan planeru i wskaźnik interwencji

Gdy KV nie może przechowywać wektorów następnego tokena, vLLM dokonuje przedwczesnego przejęcia. Wartość vllm:num_preemptions_total jest licznikiem krytycznym: niezerowa liczba takich interwencji wymaga większej ilości pamięci VRAM, więcej kopii modelu lub obniżenia maksymalnej liczby sekwencji max_num_seqs.

Wydajność systemu i czas oczekiwania w kolejce

Wydajność systemu mierzy się stosunkiem szybkości przetwarzania do tempa przychodzenia zapytań. Wartość bliska 1,0 oznacza szybkie obsługiwanie zapytań; wartości poniżej około 0,7 wskazują na to, że kolejka oczekujących rośnie szybciej, niż GPU są w stanie ją opróżniać.

To problem objawia się poprzez wartość vllm:request_queue_time_seconds – czas spędzony w oczekiwaniu przed rozpoczęciem faktycznego obliczania. Dłuższy czas oczekiwania powoduje wzrost całkowitego czasu realizacji zapytania, mimo że nie wygenerowano żadnych tokenów.

Klasyczne rozwiązania HPA oparte na CPU tutaj zawodzą. Podłącz wskaźniki vllm:num_requests_waiting oraz czasu oczekiwania w kolejce za pośrednictwem adaptera Prometheus, aby HPA skalował się w zależności od głębokości kolejki (na przykład gdy w niej jest wiele zapytań w oczekiwaniu), a nie na podstawie iluzorycznych wskaźników CPU.

Infrastruktura, równoważenie obciążeń i zaawansowane topologie

Sygnały oprogramowania muszą odpowiadać rzeczywistości sprzętowej.

Równoważenie obciążeń i wykorzystanie sprzętu

Czas trwania zapytań LLM znacznie się różni – minuty przy długim generowaniu w porównaniu z natychmiastowymi, krótkimi odpowiedziami. Dlatego metoda round-robin powoduje nierównowagę w zespołach obliczeniowych. Lepiej używać rozwiązań równoważących obciążenia, które biorą pod uwagę głębokość przetwarzania w trakcie.

Kontroluj również za pomocą DCGM:

Wykorzystanie GPU – pożądany efekt zwrotu z inwestycji to wysokie wykorzystanie przy niskich kolejkach oczekujących; wysokie wykorzystanie przy długich kolejkach oznacza przeciążenie.
Użyta VRAM – potwierdza, że vLLM zarezerwowało wymaganą ilość pamięci na początku.

Rozwiązywanie konfliktu między prefill a dekodowaniem

Długie operacje obliczeniowe typu prefill w ramach mieszanej partii mogą zmonopolizować rdzenie tensorowe i spowodować zatrzymanie wszystkich trwających procesów dekodowania – co skutkuje gwałtownymi wzrostami TPOT i przerywanymi strumieniami danych.

Dominują tu dwie metody łagodzenia problemów: prefill w formie fragmentów oraz oddzielne prefill i dekodowanie.

Prefill w formie fragmentów

Rozbija się duże zapytania na stałe fragmenty (na przykład po 512 tokenów) i mieszka te fragmenty z krokami dekodowania innych zapytań. Czas TTFT dla początkujących wzrasta nieznacznie, natomiast wartość TPOT u pozostałych pozostaje stała. Efekty mierzalne to gładsze histogramy ITL, umiarkowany koszt P50 w postaci TTFT oraz większe zyski pod względem stabilności strumienia przy P99.

Oddzielne prefill i dekodowanie (DPD)

W większych skali poszczególne fazy są wykonywane na różnych urządzeniach: prefill na GPU o dużej mocy obliczeniowej TFLOPS, dekodowanie na GPU z dużą ilością pamięci HBM, przy czym dane KV są przesyłane przez sieć po wykonaniu prefill. Należy obserwować czasy transferu i ilość przesłanych bajtów, np. vllm:nixl_xfer_time_seconds_sum oraz vllm:nixl_bytes_transferred_sum. DPD jest korzystne tylko wtedy, gdy czas transferu jest krótszy od zakłóceń, które eliminuje; o tym decyduje jakość technologii RDMA/NCCL.

Matematyka spekulatywnego dekodowania

Spekulatywne dekodowanie przyspiesza procesy związane z ograniczeniami pamięci poprzez użycie małego modelu wstępnego, który proponuje tokeny, oraz modelu docelowego, który weryfikuje wiele z nich za jednym przejściem. Weryfikacja kilku tokenów wymaga zazwyczaj około jednego kroku obliczeniowego, co pozwala obejść ograniczenia HBM, jeśli wersje wstępne są dobre.

Kluczowym wskaźnikiem jest wskaźnik akceptacji wersji wstępnych (vllm:spec_decode_draft_acceptance_rate). Liczba akceptowanych tokenów na krok podlega sekwencji geometrycznej w zależności od prawdopodobieństwa akceptacji α. Jeśli α spadnie poniżej około 0,5, koszty związane z wersjami wstępnymi mogą przewyższyć oszczędności i spowolnić system.

Należy oceniać wersje wstępne przy temperaturze produkcji. Testy z podejściem chciwym (T=0) mogą pokazać wartość α≈0,8, podczas gdy w warunkach kreatywnych przy T=1,0 ta sama para wartości spada do około α≈0,4 – co zamienia optymalizację w regresję.

Architektura telemetrii wieloprocesowej Prometheus

Serwer vLLM kompatybilny z OpenAI wykorzystuje wieloprocesorowość. Proste klienty Prometheus nie działają poprawnie na różnych procesach (z powodu GIL i podzielonej pamięci).

Rozwiązaniem jest użycie prometheus_client.multiprocess w połączeniu z PROMETHEUS_MULTIPROC_DIR: każdy proces dodaje zmiany do plików mapowanych na pamięć; narzędzia zbierające dane korzystają z MultiProcessCollector, który łączy wyniki OpenMetrics. Złożone zapytania PromQL (histogram_quantile, rate) pozostają w Prometheus, a nie na ścieżce przetwarzania danych — dzięki temu pomiar opóźnienia nie staje się samym opóźnieniem.

Wszystkie te wskaźniki — powody sukcesu lub niepowodzenia, kwantyle TTFT/TPOT/E2E, struktura operacji z tokenami, zajętość pamięci KV, przerwy w działaniu, czas oczekiwania w kolejce oraz statystyki specyficzne dla topologii — tworzą zamknięty obieg od celów SLO użytkownika do specyfiki pracy GPU. To właśnie ten obieg przekształca vLLM z serwera demonstracyjnego w funkcjonalną platformę do przetwarzania danych.

Zachowaj pisemny przewodnik, który powiązuje każdą kluczową miarę z pierwszą akcją do podjęcia: wzrost liczby przerwań → zmniejsz max_num_seqs lub dodaj VRAM; tylko TTFT P99 → skróć polecenia, zwiększ liczbę TFLOPS lub włącz cache prefiksów; gwałtowny wzrost TPOT przy pełnym wykorzystaniu KV → zmniejsz obciążenie dekodowania lub usunąć zakłócenia z prefillu; załamanie się wartości α → dostosuj ustawienia draft/temperature. Do każdej zmiany wydajności dołącz wykres goodput przed i po zmianie na tym samym wykresie, aby wydatki na sprzęt były powiązane z osiągnięciem celów SLO, a nie tylko z liczbą tokenów/s. Sprawdzaj ponownie panele sterujące wskaźnikiem IO-ratio za każdym razem, gdy zmienia się skład produktów — wprowadzanie funkcji RAG i treści długich przesuwa wąskie gardła pomiędzy prefill a dekodowaniem z dnia na dzień, a wczorajsze progi autoscalingu stają się dziś cichymi kolejkami oczekiwania. Wreszcie traktuj katalogi metryk wieloprocesorowych jako część cyklu życia poda: puste lub z błędami uprawnień ścieżki PROMETHEUS_MULTIPROC_DIR wyglądają jak „zdrowe” wyniki z zerami, podczas gdy użytkownicy już odczuwają

awarii.

Podczas wdrażania nowego punktu kontrolnego modelu należy zamrozić profil obciążenia (mieszanka długości promptu, mieszanka długości wyniku, współbiegłość) i porównać te same panele PromQL przed zwiększeniem ruchu. Punkt kontrolny, który radzi sobie dobrze pod względem średniej liczby tokenów na sekundę, ale przegrywa pod względem TTFT P99 lub wskaźnika prewencji, nie nadaje się do wdrożenia w interaktywnych API.

Gdy wdrażasz nowy punkt kontrolny modelu, zamroź profil obciążenia (mieszanka długości promptów, mieszanka długości wyników, współbiegłość) i porównaj te same panele PromQL przed przekierowaniem ruchu. Punkt kontrolny, który radzi sobie dobrze pod względem średniej liczby tokenów na sekundę, ale przegrywa pod względem TTFT P99 lub wskaźnika prewencji, nie nadaje się do wdrożenia w interaktywnych API.

Gdy wdrażasz nowy punkt kontrolny modelu, zamroź profil obciążenia (mieszanka długości promptów, mieszanka długości wyników, współbieżność) i porównaj te same panele PromQL przed przekierowaniem ruchu. Punkt kontrolny, który radzi sobie dobrze pod względem średniej liczby tokenów na sekundę, ale przegrywa pod względem TTFT P99 lub wskaźnika prewencji, nie nadaje się do wdrożenia w interaktywnych API.

Literatura pokrewna

Optymalizacja wykonywania modeli LLM: wypełnianie z góry, dekodowanie i enterprise LLMOps — Wąskie gardła związane z wypełnianiem z góry i dekodowaniem, ciągłe grupowanie danych, FlashAttention, kwantyzacja, PagedAttention, dekodowanie spekulatywne, wypełnianie z góry w fragmentach oraz serwisowanie rozproszone.
LLMOps dla małych modeli językowych: frameworki serwisowe i procedury produkcyjne — Dlaczego małe modele językowe przewyższają inne pod względem kosztów i prywatności, jak porównują się vLLM, SGLang, TGI, llama.cpp, Ollama, WebLLM, ONNX i TensorRT-LLM, oraz jak kwantyzować je, oceniać i zarządzać nimi w środowisku produkcyjnym.

Ciągłe grupowanie zadań i przedwczesne uzupełnianie danych w formie fragmentów w vLLM i SGLang — Statyczne grupowanie zadań LLM marnuje zasoby GPU na wypełnianie dodatkowymi danymi. Planowanie na poziomie iteracji oraz przedwczesne uzupełnianie danych w formie fragmentów zapewniają płynny przepływ dekodowania, nawet gdy nowe polecenia są jeszcze przetwarzane.

Co nie może zobaczyć LiteLLM: monitorowanie obsługi GPU pod bramką — LiteLLM śledzi żądania oraz zużycie zasobów. Czekanie w kolejce, różnice między przedwczesnym uzupełnianiem a dekodowaniem, restarty kontenerów oraz obciążenie hosta wymagają narzędzi takich jak Prometheus, metryki vLLM, cAdvisor oraz ślady działania systemu.

← Wszystkie artykuły Wyślij brief