Monitorowanie wdrażania LLM (2026): Prometheus i Grafana dla vLLM, TGI, llama.cpp

Inferencja modeli LLM wygląda jak „po prostu kolejny API” – aż do momentu, gdy pojawiają się spiki opóźnienia, kolejki zaczynają się gromadzić, a GPU siedzą na 95% pamięci bez wyraźnego powodu.

Monitorowanie staje się krytyczne dla operacyjności od momentu, gdy opuszczasz konfigurację jedno-węzłową lub zaczynasz optymalizować przepustowość. W tym momencie tradycyjne metryki API nie są wystarczające. Potrzebujesz wglądu w tokeny, zachowanie grupowania, czas przebywania w kolejce i presję na pamięć (KV cache) – rzeczywiste miejsca, w których występują opóźnienia w systemach LLM.

Ten artykuł jest częścią mojego szerokiego przewodnika po monitorowaniu i obserwowalności, w którym omawiam podstawy monitorowania vs obserwowalności, architekturę Prometheus i najlepsze praktyki w środowisku produkcyjnym. Tutaj skupimy się konkretnie na monitorowaniu zadań inferencji LLM.

(Jeśli decydujesz się na infrastrukturę, zobacz mój przewodnik po hostowaniu LLM w 2026. Jeśli chcesz głębszy wgląd w mechaniki grupowania, limity VRAM i trade-offy między przepustowością a opóźnieniem, zobacz przewodnik po inżynierii wydajności LLM.)

W przeciwieństwie do typowych usług REST, serwowanie LLM jest kształtowane przez tokeny, ciągłe grupowanie, wykorzystanie pamięci (KV cache), nasycenie GPU/CPU i dynamiczne zachowanie kolejki. Dwa żądania z identycznymi rozmiarami ładunku mogą mieć znacznie różne opóźnienia w zależności od max_new_tokens, konkurencyjności i ponownego użycia pamięci.

Ten przewodnik to praktyczna, skupiona na środowisku produkcyjnym instrukcja tworzenia monitorowania inferencji LLM z użyciem Prometheus i Grafana:

• Co mierzyć (p95/p99 opóźnienia, tokeny/sec, czas przebywania w kolejce, wykorzystanie pamięci, stopień błędów)
• Jak zebrać dane z /metrics z typowych serwerów (vLLM, Hugging Face TGI, llama.cpp)
• Przykłady zapytań PromQL do percentyli, nasycenia i przepustowości
• Patterny wdrażania z Docker Compose i Kubernetes
• Rozwiązywanie problemów, które pojawiają się tylko przy rzeczywistym obciążeniu

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

Dlaczego warto monitorować inferencję LLM inaczej

Tradycyjne monitorowanie API (RPS, p95 opóźnienia, stopień błędów) jest konieczne, ale nie wystarczające. Serwowanie LLM dodaje dodatkowe osie:

1) Opóźnienie ma dwa znaczenia

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

Niektóre serwery udostępniają oba. Na przykład TGI udostępnia czas trwania żądania i średni czas na token jako histogramy.

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

Szybki serwer, który zwraca 5 tokenów, nie jest porównywalny z tym, który zwraca 500 tokenów. Twój „RPS” powinien często być „tokeny/sec”.

3) Kolejka to produkt

Jeśli uruchamiasz ciągłe grupowanie, głębokość kolejki to to, co sprzedajesz. Obserwowanie czasu przebywania w kolejce i rozmiaru kolejki mówi Ci, czy spełniasz oczekiwania użytkowników.

4) Presja na pamięć to wstęp do awarii

Wygasanie pamięci (lub fragmentacja) często pojawia się jako nagłe spiki opóźnienia i timeouty. vLLM udostępnia wykorzystanie pamięci (KV cache) jako gage.

Lista metryk do monitorowania inferencji LLM

Użyj jej jako punktu orientacyjnego. Nie potrzebujesz wszystkiego od razu – ale w końcu chcesz większość z tego.

Kluczowe sygnały (w stylu LLM)

• Ruch: żądań/sec, tokenów/sec
• Błędy: stopień błędów, timeouty, OOM, 429 (ograniczenie przepustowości)
• Opóźnienie: p50/p95/p99 czas trwania żądania; opóźnienie prefill vs dekodowania; opóźnienie między tokenami
• Nasycenie: wykorzystanie GPU, użycie pamięci, wykorzystanie pamięci (KV cache), rozmiar kolejki

Jeśli potrzebujesz szczegółowego wglądu w użycie pamięci GPU, temperaturę i wykorzystanie poza Prometheus (dla debugowania lub konfiguracji jednowęzłowych), zobacz mój przewodnik po aplikacjach monitorowania GPU w Linux / Ubuntu.

Dla szerszego wglądu w obserwowalność LLM poza metrykami – w tym śledzenie, strukturalne logi, testy syntetyczne, profilowanie GPU i projektowanie SLO – zobacz moją szczegółową instrukcję dotyczącą obserwowalności systemów LLM.

Przydatne wymiary (etykiety)

Zachowaj niską liczbę etykiet. Dobrze sprawdzane etykiety:

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

Unikaj etykiet takich jak:

• surowe prompt, surowe user_id, identyfikatory żądań – te powodują eksplodowanie liczby serii.

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

Najprostsza droga to: użyj metryk, które serwer już udostępnia.

vLLM: kompatybilne z Prometheus /metrics

vLLM udostępnia kompatybilne z Prometheus /metrics (poprzez jego logger metryk Prometheus) i publikuje metryki serwera/żądania z prefiksem vllm:, w tym gage takie jak działające żądania i wykorzystanie pamięci (KV cache).

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 kolejka + histogramy żądań

TGI udostępnia wiele metryk produkcyjnych na /metrics, w tym rozmiar kolejki, czas trwania żądania, czas przebywania w kolejce i średni czas na token.

Wyróżnione:

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

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

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

Jeśli uruchamiasz llama.cpp za proxy, skanuj serwer bezpośrednio, kiedy to tylko możliwe (aby uniknąć ukrywania rzeczywistego zachowania inferencji przez opóźnienie na poziomie proxy).

Konfiguracja Prometheus: skanowanie 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
• skanowanie z interwałem dostosowanym do szybkiego zwrotnego sprzętu

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łębsze wyjaśnienie konfiguracji skanowania, eksporterów, ponownej etykietowania i reguł alertów, zobacz mój pełny przewodnik po konfiguracji monitorowania z Prometheus.

Porada: dodaj etykietę „service”

Jeśli uruchamiasz wiele modeli/replic, dodaj ponowne etykietowanie, aby uwzględnić stabilną etykietę service dla paneli.

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

Przykłady zapytań PromQL, które możesz skopiować i wkleić

Prędkość żądań (RPS)

sum(rate(tgi_request_count[5m]))

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

Stopień błędów (%)

Jeśli masz liczniki *_success, oblicz współczynnik błędów:

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

p95 opóźnienia dla metryk histogramowych (Prometheus)

Histogramy w Prometheus są zliczane w kubkach; użyj histogram_quantile() z rate() kubków. Prometheus dokumentuje ten model i różnice między histogramami a podsumowaniami.

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

p99 czas przebywania w kolejce

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 ograniczenia dekodowania i przepustowość pamięci – tematy omawiane szczegółowo w przewodniku po optymalizacji wydajności LLM.

Głębokość kolejki (natychmiastowa)

max(tgi_queue_size)

Wykorzystanie pamięci (KV cache) vLLM (natychmiastowa)

max(vllm:kv_cache_usage_perc)

Paneli Grafana: panele, które naprawdę pomagają w obsłudze awarii

Grafana może wizualizować histogramy na wiele sposobów (percentyle, heatmapy, rozkłady kubków). Grafana Labs ma szczegółowy przewodnik po wizualizacji histogramów w Prometheus.

Przykładowy układ paneli o wysokiej wartości:

Wiersz 1 — doświadczenie użytkownika

1. p95 opóźnienia żądania (szereg czasowy)
2. p95 opóźnienia między tokenami (szereg czasowy)
3. Stopień błędów (szereg czasowy + stat)

Wiersz 2 — pojemność i nasycenie

4. Rozmiar kolejki (szereg czasowy)
5. Działające vs. oczekujące żądania (stosowane)
6. Wykorzystanie pamięci (KV cache) % (gauge)

Wiersz 3 — przepustowość

7. Żądań/sec
8. Wygenerowane tokeny/żądanie (p50/p95)

Jeśli masz strumienie, dodaj panel dla „czasu pierwszego tokena” (TTFT), kiedy jest dostępny.

Przykładowe zapytania Grafana

• Panel p95 opóźnienia: powyższe zapytanie histogram_quantile(0.95, …)
• Panel heatmapy: wykresuj stawki kubków (*_bucket) jako heatmapę (Grafana obsługuje ten podejście)

Opcja wdrażania 1: Docker Compose (szybki lokalny + jednowęzłowy)

Jeśli decydujesz się między lokalną, samodzielnie zarządzaną a chmurową architekturą inferencji, zobacz pełną analizę w moim przewodniku po hostowaniu LLM w 2026.

Utwórz folder takie 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ęczne instalowanie Grafana zamiast Docker, zobacz moją krok po kroku instrukcję dotyczącą instalacji i użycia 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 paneli Grafana (grafana/provisioning/dashboards/dashboards.yml)

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

Opcja wdrażania 2: Kubernetes (Operator Prometheus + ServiceMonitor)

Jeśli korzystasz z kube-prometheus-stack (Operator Prometheus), skanuj cele za pomocą ServiceMonitor.

Dla trade-offów infrastruktury między Kubernetes, jednowęzłowym Dockerem a zarządzanymi dostawcami inferencji, zobacz mój przewodnik po hostowaniu LLM w 2026.

1) Wyświetl swoje wdrożenie inferencji za pomocą 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 to dla usług vLLM i llama.cpp. To skaluje się czysto, gdy dodajesz repliki.

3) Alerty: reguły typu SLO (przykład)

Oto dobre początkowe alerty:

• Wysokie opóźnienia p95 (burn rate)
• Zbyt wysoki czas przebywania w kolejce p99 (czekający użytkownicy)
• Stopień błędów > 1%
• Wykorzystanie pamięci (KV cache) > 90% utrzymywane (skok pojemności)

Przykład reguły (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: "Opóźnienie TGI p95 > 3s (10m)"

Rozwiązywanie problemów: typowe awarie w stosach LLM z Prometheus + Grafana

1) Cel Prometheus jest „DOWN”

Symptomy

• Interfejs użytkownika Prometheus → Cele pokazuje „DOWN”
• „context deadline exceeded” lub połączenie odmówione

Lista kontrolna

• Czy serwer faktycznie udostępnia /metrics?
• Zły port? Zły schemat (http vs https)?
• Kubernetes: czy Service wybiera pakiety? Czy etykieta ServiceMonitor release jest poprawna?

Szybki test

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

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

Najczęstsze przyczyny

• Zły nazwa metryki (wersja serwera zmieniła się)
• Panel oczekuje _bucket, ale masz tylko gage/counter
• Zbyt długie okno skanowania Prometheus dla krótkich okien (np. [1m] z 30s skanowaniem może być szumowe)

Poprawka

• Użyj Grafana Explore, aby wyszukać prefiksy metryk (np. tgi_ / vllm:)
• Zwiększ okno zakresu z [1m] → [5m]

3) Percentyle histogramów wyglądają „równo” lub są złe

Histogramy w Prometheus wymagają poprawnego agregowania:

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

Prometheus dokumentuje model kubków i obliczanie percentyli po stronie serwera.
Przewodnik wizualizacji histogramów Grafana zawiera praktyczne wzorce paneli.

4) Eksplozja liczby serii (spiky użycie pamięci przez Prometheus)

Symptomy

• Użycie pamięci przez Prometheus rośnie
• Błędy „too many series”

Typowa przyczyna

• Dodano prompt, user_id lub identyfikatory żądań jako etykiety w eksporterze własnym.

Poprawka

• Usuń etykiety o dużej liczbie serii
• Przeagreguj do etykiet o niskiej liczbie serii (model, endpoint, status)
• Rozważ użycie logów/śledzenia do debugowania żądań zamiast etykiet

5) „Mamy metryki, ale nie mamy pojęcia, dlaczego jest powolne”

Metryki są konieczne, ale czasem potrzebujesz korelacji:

• Dodaj strukturalne logi z metadane żądania (model, liczba tokenów, TTFT)
• Dodaj śledzenie (OpenTelemetry) wokół bramy + serwera inferencji
• Użyj przykładów (jeśli są obsługiwane), aby przejść od spiku opóźnienia do śledzenia

Dobry workflow: spik w panelu Grafana → kliknij w Explore → wąskie w model/instancję → sprawdź logi/śledzenie dla tego okresu.

To następuje klasyczny model metryk -> logi -> śledzenie opisany w przewodniku po architekturze monitorowania i obserwowalności.

6) Szczególne przypadki metryk vLLM / wieloprocesowych

Jeśli stos inferencji działa w wielu procesach, może być konieczna konfiguracja Prometheus dla wielu procesów (zależy od tego, jak proces udostępnia metryki). Dokumentacja vLLM podkreśla udostępnianie metryk przez /metrics dla wykrywania przez Prometheus; sprawdź tryb metryk serwera przy wdrażaniu.

Praktyczny zestaw paneli i alertów dla dnia 1

Jeśli chcesz wdrożenie o cienkim ustawieniu, które nadal działa w środowisku produkcyjnym, zacznij od:

Paneli dashboardu

1. p95 opóźnienia żądania
2. p95 średniego czasu na token
3. rozmiar kolejki
4. p95 czasu przebywania w kolejce
5. stopień błędów
6. wykorzystanie pamięci (KV cache) %

Alerty

• opóźnienie żądania p95 > X przez 10m
• czas przebywania w kolejce p99 > Y przez 10m
• stopień błędów > 1% przez 5m
• wykorzystanie pamięci (KV cache) > 90% przez 15m
• cel Prometheus offline (zawsze)

Powiązane przewodniki po obserwowalności

• Przewodnik po obserwowalności: Prometheus, Grafana & monitorowaniu w środowisku produkcyjnym
• Monitorowanie z Prometheus: konfiguracja & najlepsze praktyki
• Instalacja i użycie Grafana na Ubuntu: kompletny przewodnik

Powiązane przewodniki po infrastrukturze LLM

• Hostowanie LLM w 2026: lokalne, samodzielnie zarządzane i chmurowe porównanie
• Wydajność LLM w 2026: testy wydajnościowe i optymalizacja

Uwagi końcowe

Prometheus + Grafana daje Ci „zawsze włączony” wgląd w stan inferencji. Po uzyskaniu podstaw, kolejne duże wygrane zwykle pochodzą z:

• SLO dla modelu / dzierżawcy
• kształtowanie żądań (maksymalna liczba tokenów, ograniczenia współbieżności)
• skalowanie automatyczne związane z czasem przebywania w kolejce i przestrzenią (headroom) pamięci (KV cache)

Dla szerokiego wyjaśnienia monitorowania vs obserwowalności, podstaw Prometheus i wzorców w środowisku produkcyjnym, zobacz mój pełny przewodnik po obserwowalności.