Monitorowanie inferencji LLM w środowisku produkcyjnym (2026): Prometheus i Grafana dla vLLM, TGI oraz llama.cpp

Inferencja LLM wygląda jak „kolejny API" – dopóki nie pojawią się skoki opóźnień, kolejki nie zaczną się zalegać, a Twoje karty GPU nie będą zużywać 95% pamięci bez wyraźnego wyjaśnienia.

Monitoring staje się kluczowy w momencie, gdy przejdziemy poza konfigurację pojedynczego węzła lub zaczniemy optymalizować przepustowość. W tym punkcie tradycyjne metryki API przestają wystarczać. Potrzebujesz widoczności na tokeny, zachowanie kolejkowania (batching), czas oczekiwania w kolejce oraz presję na buforze KV – prawdziwe wąskie gardła nowoczesnych systemów LLM.

Ten artykuł jest częścią mojego szerszego poradnika dotyczącego obserwowalności i monitoringu, gdzie omawiam fundamenty monitoringu i obserwowalności, architekturę Prometheus oraz najlepsze praktyki produkcyjne. Tutaj skupimy się konkretnie na monitoringu obciążeń inferencji LLM.

(Jeśli decydujesz się na infrastrukturę, zobacz mój przewodnik po hostingu LLM w 2026 roku. Jeśli chcesz zgłębić mechanikę kolejkowania, limity VRAM oraz kompromisy między przepustowością a opóźnieniem, sprawdź przewodnik po inżynierii wydajności LLM.)

W przeciwieństwie do typowych usług REST, serwowanie LLM kształtują tokeny, ciągła kolejkowanie (continuous batching), wykorzystanie bufora KV, nasycenie GPU/CPU oraz dynamika kolejkowania. Dwa żądania o identycznym rozmiarze obciążenia mogą mieć radykalnie inne opóźnienia w zależności od max_new_tokens, równoległości (concurrency) oraz ponownego wykorzystania bufora (cache reuse).

Ten przewodnik to praktyczny, nastawiony na produkcję przewodnik po budowaniu monitoringu inferencji LLM z Prometheus i Grafana:

• Co mierzyć (opóźnienia p95/p99, tokeny/sek, czas oczekiwania w kolejce, wykorzystanie bufora, wskaźnik błędów)
• Jak pobierać /metrics z popularnych serwerów (vLLM, Hugging Face TGI, llama.cpp)
• Przykłady PromQL dla percentyli, nasycenia i przepustowości
• Wzorce wdrażania z Docker Compose i Kubernetes
• Rozwiązywanie problemów, które pojawiają się tylko pod prawdziwym obciążeniem

Przykłady są celowo neutralne względem dostawcy. Niezależnie od tego, czy później dodasz śledzenie OpenTelemetry, skalowanie automatyczne lub siatkę usług (service mesh), ten sam model metryk będzie obowiązywał.

Dlaczego monitoring inferencji LLM powinien wyglądać inaczej

Tradycyjny monitoring API (RPS, opóźnienie p95, wskaźnik błędów) jest konieczny, ale niewystarczający. Serwowanie LLM dodaje dodatkowe wymiary:

1) Opóźnienie ma dwa znaczenia

• Opóźnienie E2E: czas od otrzymania żądania do zwrócenia ostatniego tokena.
• Opóźnienie między tokenami (inter-token latency): czas na jeden token podczas dekodowania (krytyczne dla UX strumieniowego).

Niektóre serwery eksponują oba wartości. Na przykład TGI eksponuje czas trwania żądania i średni czas na token jako histogramy.

2) Przepustowość jest mierzona w tokenach, nie w żądaniach

„Szybka" usługa zwracająca 5 tokenów nie jest porównywalna z tą, która zwraca 500 tokenów. Twoje „RPS" powinno często być „tokenami/sek".

3) Kolejka jest produktem

Jeśli używasz ciągłego kolejkowania (continuous batching), głębokość kolejki jest tym, co sprzedajesz. Obserwowanie czasu oczekiwania w kolejce i rozmiaru kolejki mówi Ci, czy spełniasz oczekiwania użytkowników.

4) Presja na buforze jest zwiastunem awarii

Wyczerpanie (lub fragmentacja) bufora KV często objawia się nagłymi skokami opóźnienia i przekroczeniami czasu oczekiwania (timeouts). vLLM eksponuje wykorzystanie bufora KV jako wskaźnik (gauge).

Kontrolna lista metryk do monitoringu inferencji LLM

Użyj tego jako kompasu. Nie musisz mieć wszystkiego od dnia pierwszego – ale ostatecznie będziesz chciał większość z nich.

Złote sygnały (w wersji LLM)

• Ruch: żądania/sek, tokeny/sek
• Błędy: wskaźnik błędów, timeouty, OOM (Out of Memory), 429 (limitowanie)
• Opóźnienia: czas trwania żądania p50/p95/p99; opóźnienie prefill vs decode; opóźnienie między tokenami
• Nasycenie: wykorzystanie GPU, zużycie pamięci, wykorzystanie bufora KV, rozmiar kolejki

Jeśli potrzebujesz niskopoziomowej widoczności zużycia pamięci GPU, temperatury i wykorzystania poza Prometheus (do debugowania lub w konfiguracjach pojedynczego węzła), zobacz mój przewodnik po aplikacjach do monitoringu GPU w Linux / Ubuntu.

Dla szerszego spojrzenia na obserwowalność LLM poza metrykami – w tym śledzenie (tracing), strukturalne logi, testy syntetyczne, profilowanie GPU i projektowanie SLO – zobacz mój wyczerpujący przewodnik o obserwowalności dla systemów LLM.

Przydatne wymiary (etykiety)

Zachowaj niską kardynalność etykiet. Dobre etykiety:

• model, endpoint, method (prefill/decode), status (success/error), instance

Unikaj etykiet takich jak:

• surowe prompt, surowe user_id, identyfikatory żądań – te wybuchają liczbą serii.

Eksponowanie metryk: wbudowane punkty końcowe /metrics (vLLM, TGI, llama.cpp)

Najłatwiejsza droga to: użyj metryk, które serwer już eksponuje.

vLLM: punkty końcowe /metrics zgodne z Prometheus

vLLM eksponuje punkt końcowy /metrics zgodny z Prometheus (poprzez jego logger metryk Prometheus) i publikuje metryki serwera/żądania z prefiksem vllm:, w tym wskaźniki (gauge) jak żądania w toku i wykorzystanie bufora KV.

Dla konfiguracji kontenerów, serwowania zgodnego z OpenAI i strojenia czasu wykonania zorientowanego na przepustowość, zobacz Szybki start z vLLM: wydajne serwowanie LLM.

Przykładowe metryki, które zazwyczaj zobaczysz:

• vllm:num_requests_running
• vllm:num_requests_waiting
• vllm:kv_cache_usage_perc

Hugging Face TGI: /metrics z kolejką i histogramami żądań

TGI eksponuje wiele metryk klasy produkcyjnej na /metrics, w tym rozmiar kolejki, czas trwania żądania, czas oczekiwania w kolejce i średni czas na token.

Warte uwagi:

• tgi_queue_size (gauge)
• tgi_request_duration (histogram, opóźnienie e2e)
• tgi_request_queue_duration (histogram)
• tgi_request_mean_time_per_token_duration (histogram)

Konfiguracja operacyjna – Docker, GPU, flagi uruchamiania i awarie, które objawiają się pustymi lub mylącymi pobraniami – jest omawiana w TGI - Text Generation Inference - Instalacja, Konfiguracja, Rozwiązywanie problemów.

Serwer llama.cpp: włącz punkt końcowy metryk

Serwer llama.cpp obsługuje punkt końcowy metryk zgodny z Prometheus, który musi być włączony za pomocą flagi (np. --metrics).

Dla ścieżek instalacji, kluczowych flag czasu wykonania i użycia serwera zgodnego z OpenAI, zobacz Szybki start z llama.cpp z CLI i Serwerem.

Jeśli uruchamiasz llama.cpp za pośrednictwem proxy, pobieraj metryki bezpośrednio z serwera, jeśli to możliwe (aby uniknąć ukrywania rzeczywistego zachowania inferencji przez opóźnienia na poziomie proxy).

Konfiguracja Prometheus: pobieranie z serwerów inferencji

Ten przykład zakłada:

• vLLM na http://vllm:8000/metrics
• TGI na http://tgi:8080/metrics
• llama.cpp na http://llama:8080/metrics
• interwał pobierania (scrape interval) dostosowany dla szybkiego zwrotu informacji

prometheus.yml

global:
  scrape_interval: 5s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "vllm"
    metrics_path: /metrics
    static_configs:
      - targets: ["vllm:8000"]

  - job_name: "tgi"
    metrics_path: /metrics
    static_configs:
      - targets: ["tgi:8080"]

  - job_name: "llama_cpp"
    metrics_path: /metrics
    static_configs:
      - targets: ["llama:8080"]

Jeśli jesteś nowy w Prometheus lub chcesz głębszego wyjaśnienia konfiguracji pobierania, eksporterów, relabelingu i reguł alertów, zobacz mój kompletny przewodnik po konfiguracji monitoringu Prometheus.

Wskazówka: dodaj „etykietę usługi"

Jeśli uruchamiasz wiele modeli/replik, dodaj relabeling, aby dołączyć stabilną etykietę service dla pulpitów.

relabel_configs:
  - target_label: service
    replacement: "llm-inference"

Przykłady PromQL do skopiowania/wklejenia

Częstotliwość żądań (RPS)

sum(rate(tgi_request_count[5m]))

Dla vLLM użyj jego liczników żądań (nazwy mogą się różnić w zależności od wersji), ale wzorzec jest ten sam: sum(rate(<counter>[5m])).

Wskaźnik błędów (%)

Jeśli masz liczniki *_success, oblicz stosunek niepowodzeń:

1 - (
  sum(rate(tgi_request_success[5m]))
  /
  sum(rate(tgi_request_count[5m]))
)

Opóźnienie p95 dla metryk histogramu (Prometheus)

Histogramy Prometheus to zliczone przedziały; użyj histogram_quantile() nad rate() przedziałów. Prometheus dokumentuje ten model oraz kompromisy między histogramem a podsumowaniem (summary).

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_duration_bucket[5m]))
)

Czas w kolejce p99

histogram_quantile(
  0.99,
  sum by (le) (rate(tgi_request_queue_duration_bucket[5m]))
)

Średni czas na token (opóźnienie między tokenami)

histogram_quantile(
  0.95,
  sum by (le) (rate(tgi_request_mean_time_per_token_duration_bucket[5m]))
)

Opóźnienie między tokenami jest często ograniczane przez wąskie gardła dekodowania i przepustowość pamięci – tematy omówione szczegółowo w przewodniku po optymalizacji wydajności LLM.

Głębokość kolejki (natychmiastowa)

max(tgi_queue_size)

Wykorzystanie bufora KV vLLM (natychmiastowe)

max(vllm:kv_cache_usage_perc)

Pulpity Grafana: panele, które faktycznie pomagają w dyżurach

Grafana może wizualizować histogramy na wiele sposobów (percentyle, mapy ciepła, rozkład przedziałów). Grafana Labs posiada szczegółowy przewodnik po wizualizacji histogramów Prometheus.

Minimalny układ pulpitu o wysokim sygnale:

Wiersz 1 — Doświadczenie użytkownika

1. Opóźnienie żądania p95 (seria czasowa)
2. Opóźnienie między tokenami p95 (seria czasowa)
3. Wskaźnik błędów (seria czasowa + statystyka)

Wiersz 2 — Pojemność i nasycenie

4. Rozmiar kolejki (seria czasowa)
5. Żądania w toku vs czekające (stosowane)
6. Wykorzystanie bufora KV % (wskaźnik)

Wiersz 3 — Przepustowość

7. Żądania/sek
8. Wygenerowane tokeny/żądanie (p50/p95)

Jeśli masz strumieniowanie, dodaj panel dla „opóźnienia pierwszego tokena" (TTFT), jeśli jest dostępne.

Przykładowe zapytania Grafana

• panel opóźnienia p95: zapytanie histogram_quantile(0.95, …) powyżej
• panel mapy ciepła: wykresuj szybkości przedziałów (*_bucket) jako mapę ciepła (Grafana obsługuje to podejście)

Opcja wdrożenia 1: Docker Compose (szybkie lokalnie + pojedynczy węzeł)

Jeśli decydujesz się między lokalną, self-hosted, czy chmurową architekturą inferencji, zobacz pełne zestawienie w moim poradniku porównawczym hostingu LLM.

Utwórz folder taki jak:

monitoring/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inference.json

docker-compose.yml

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin
    volumes:
      - ./grafana/provisioning:/etc/grafana/provisioning
      - ./grafana/dashboards:/var/lib/grafana/dashboards
    ports:
      - "3000:3000"
    depends_on:
      - prometheus

Jeśli wolisz ręczną instalację Grafana zamiast Docker, zobacz mój przewodnik krok-po-kroku instalacji i używania Grafana na Ubuntu.

Konfiguracja źródła danych Grafana (grafana/provisioning/datasources/datasource.yml)

apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true

Konfiguracja pulpitów (grafana/provisioning/dashboards/dashboards.yml)

apiVersion: 1
providers:
  - name: "LLM"
    folder: "LLM"
    type: file
    disableDeletion: true
    options:
      path: /var/lib/grafana/dashboards

Opcja wdrożenia 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Jeśli używasz kube-prometheus-stack (Prometheus Operator), pobieraj cele poprzez ServiceMonitor.

Dla kompromisów infrastrukturalnych między Kubernetes, Dockerem na pojedynczym węźle i zarządzanymi dostawcami inferencji, zobacz mój przewodnik po hostingu LLM w 2026 roku.

1) Udostępnij swoje wdrożenie inferencji przez Service

apiVersion: v1
kind: Service
metadata:
  name: tgi
  labels:
    app: tgi
spec:
  selector:
    app: tgi
  ports:
    - name: http
      port: 8080
      targetPort: 8080

2) Utwórz ServiceMonitor

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: tgi
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: tgi
  endpoints:
    - port: http
      path: /metrics
      interval: 5s

Powtórz dla usług vLLM i llama.cpp. To skaluje się czysto, gdy dodajesz repliki.

3) Alerty: reguły w stylu SLO (przykład)

Oto dobre alerty startowe:

• Wysokie opóźnienie p95 (tempo spalania)
• Czas w kolejce p99 zbyt wysoki (użytkownicy czekają)
• Wskaźnik błędów > 1%
• Wykorzystanie bufora KV > 90% utrzymujące się (klif pojemności)

Przykładowa reguła (czas trwania żądania p95):

- alert: LLMHighP95Latency
  expr: histogram_quantile(0.95, sum by (le) (rate(tgi_request_duration_bucket[5m]))) > 3
  for: 10m
  labels:
    severity: page
  annotations:
    summary: "TGI p95 latency > 3s (10m)"

Rozwiązywanie problemów: częste awarie Prometheus + Grafana w stosach LLM

1) Cel Prometheus ma status „DOWN"

Objawy

• Interfejs Prometheus → Cele pokazuje DOWN
• „context deadline exceeded" lub połączenie odrzucone

Lista kontrolna

• Czy serwer faktycznie eksponuje /metrics?
• Zły port? Zły schemat (http vs https)?
• Kubernetes: czy Service wybiera pody? Czy etykieta release w ServiceMonitor jest poprawna?

Szybki test

curl -sS http://tgi:8080/metrics | head

2) Możesz pobierać metryki, ale panele są puste

Najczęstsze przyczyny

• Zła nazwa metryki (zmieniona wersja serwera)
• Pulpit oczekuje _bucket, ale masz tylko gauge/counter
• Interwał pobierania Prometheus jest zbyt długi dla krótkich okien (np. [1m] z 30s scrape może być szumny)

Naprawa

• Użyj Grafana Explore do szukania prefiksów metryk (np. tgi_ / vllm:)
• Zwiększ okno zakresu z [1m] → [5m]

3) Percentyle histogramu wyglądają „płasko" lub są błędne

Histogramy Prometheus wymagają poprawnej agregacji:

• użyj rate(metric_bucket[5m])
• następnie sum by (le) (i opcjonalnie inne stabilne etykiety)
• następnie histogram_quantile()

Prometheus dokumentuje model przedziałów i obliczanie kwantyle po stronie serwera. Przewodnik wizualizacji histogramów Grafana zawiera praktyczne wzorce paneli.

4) Wybuch kardynalności (skoki pamięci Prometheus)

Objawy

• Zużycie pamięci RAM Prometheus rośnie
• Błędy „too many series"

Typowa przyczyna źródłowa

• Dodałeś prompt, user_id lub identyfikatory żądań jako etykiety w niestandardowym eksporterze.

Naprawa

• Usuń etykiety o wysokiej kardynalności
• Zsumuj do etykiet o niskiej kardynalności (model, endpoint, status)
• Rozważ użycie logów/śladów (traces) do debugowania per-żądanie zamiast etykiet

5) „Mamy metryki, ale nie wiemy, dlaczego jest wolno"

Metryki są konieczne, ale czasem potrzebna jest korelacja:

• Dodaj strukturalne logi z metadanymi żądania (model, liczba tokenów, TTFT)
• Dodaj śledzenie (tracing) (OpenTelemetry) wokół bramki + serwera inferencji
• Użyj przykładów (exemplars), gdy są obsługiwane, aby przejść od skoku opóźnienia do śladu

Dobry przepływ pracy: skok na pulpicie Grafana -> kliknij do Explore -> zawęż po instancji/modelu -> sprawdź logi/ślad dla tego okresu.

To podąża za klasycznym modelem metryki -> logi -> ślady opisanym w przewodniku po architekturze obserwowalności i monitoringu.

6) Dziwactwa metryk vLLM / wieloprocesowych

Jeśli Twój stos serwowania działa w wielu procesach, możesz potrzebować konfiguracji wieloprocesowej Prometheus (zależy to od tego, jak proces eksponuje metryki). Dokumentacja vLLM podkreśla eksponowanie metryk poprzez /metrics do pobierania przez Prometheus; sprawdź tryb metryk serwera podczas wdrażania.

Praktyczny zestaw pulpitów i alertów na „dzień pierwszy"

Jeśli chcesz zwinną konfigurację, która nadal działa w produkcji, zacznij od:

Panele pulpitu

1. Opóźnienie żądania p95
2. Średni czas na token p95
3. Rozmiar kolejki
4. Czas w kolejce p95
5. Wskaźnik błędów
6. Wykorzystanie bufora KV %

Alerty

• Opóźnienie żądania p95 > X przez 10m
• Czas w kolejce p99 > Y przez 10m
• Wskaźnik błędów > 1% przez 5m
• Wykorzystanie bufora KV > 90% przez 15m
• Cel Prometheus down (zawsze)

Powiązane przewodniki po obserwowalności

• Przewodnik po obserwowalności: Prometheus, Grafana & Monitoring w produkcji
• Monitoring Prometheus: Konfiguracja i najlepsze praktyki
• Instalacja i użycie Grafana na Ubuntu: kompletny przewodnik

Powiązane przewodniki po infrastrukturze LLM

• Hosting LLM w 2026: Lokalne, Self-Hosted & Chmura Porównane
• Wydajność LLM w 2026: Testy i Optymalizacja

Zakończenie

Prometheus + Grafana daje Ci widok „zawsze włączony" zdrowia inferencji. Gdy masz podstawy, kolejne duże zyski zazwyczaj pochodzą z:

• SLO dla każdego modelu / najemcy
• kształtowania żądań (max tokeny, limity równoległości)
• skalowania automatycznego powiązanego z czasem w kolejce i zapasem bufora KV

Dla szerszego wyjaśnienia monitoringu vs obserwowalności, fundamentów Prometheus i wzorców produkcyjnych, zobacz mój kompletny przewodnik po obserwowalności.