Övervakning av LLM-inferens i produktion (2026): Prometheus & Grafana för vLLM, TGI och llama.cpp

LLM-inferens ser ut som “en API till” – fram till dess att latens toppar, köer backar upp och dina GPU:er sitter på 95 % minnesanvändning utan någon uppenbar förklaring.

Övervakning blir livsviktigt så fort du går utöver en konfiguration med en enda nod eller börjar optimera för genomströmning. Vid det laget räcker traditionella API-mätvärden inte längre. Du behöver insyn i token, beteende vid batchning, kötid och tryck på KV-cache – de verkliga flaskhalsarna i moderna LLM-system.

Den här artikeln är en del av min bredare guide för observabilitet och övervakning, där jag täcker grundläggande skillnader mellan övervakning och observabilitet, Prometheus-arkitektur och bästa praxis i produktion. Här kommer vi att fokusera specifikt på övervakning av LLM-inferensarbetsbelastningar.

(Om du bestämmer dig för infrastruktur, se min guide till LLM-hyrring 2026. Om du vill göra en djupdykning i batchmekanik, VRAM-gränser och avvägningar mellan genomströmning och latens, se guiden för LLM-prestandaingenjörering.)

Till skillnad från typiska REST-tjänster formas LLM-tillhandahållande av token, kontinuerlig batchning, utnyttjande av KV-cache, mättnad av GPU/CPU och ködynamik. Två begäran med identisk storlek på nyttolast kan ha radikalt olika latens beroende på max_new_tokens, konkurrens och återanvändning av cache.

Den här guiden är en praktisk, produktionsinriktad genomgång för att bygga övervakning av LLM-inferens med Prometheus och Grafana:

• Vad som ska mätas (latens p95/p99, token/sekund, kötid, cacheutnyttjande, felhastighet)
• Hur man skrapar /metrics från vanliga servrar (vLLM, Hugging Face TGI, llama.cpp)
• PromQL-exempel för percentiler, mättnad och genomströmning
• Implementeringsmönster med Docker Compose och Kubernetes
• Felsökning av problem som bara uppstår under verklig belastning

Exemplen är medvetet leverantörsneutrala. Oavsett om du senare lägger till OpenTelemetry-spårning, automatisk skalning eller en tjänstmesh, gäller samma mätvärdesmodell.

Varför du bör övervaka LLM-inferens annorlunda

Traditionell API-övervakning (RPS, latens p95, felhastighet) är nödvändig men inte tillräcklig. LLM-tillhandahållande lägger till ytterligare dimensioner:

1) Latens har två betydelser

• Latens från ände till ände (E2E): tiden från att begäran mottogs till att den sista token returnerades.
• Latens per token: tiden per token under avkodning (kritiskt för strömande användarupplevelse).

Vissa servrar exponerar båda. Till exempel exponerar TGI begäranstid och medel tid per token som histogram.

2) Genomströmning mäts i token, inte begäran

En “snabb” tjänst som returnerar 5 token är inte jämförbar med en som returnerar 500 token. Din “RPS” bör ofta vara “token/sekund”.

3) Köen är produkten

Om du kör kontinuerlig batchning är ködjupet det du säljer. Att hålla koll på kötid och köstorlek berättar om du lever upp till användarnas förväntningar.

4) Cache-trängsel är en förebud för driftstopp

Uttömning (eller fragmentering) av KV-cache visar sig ofta som plötsliga latensspikar och tidsöverskridanden. vLLM exponerar KV-cache-användning som en mätare.

Mätvärdeschecklista för övervakning av LLM-inferens

Använd detta som din nordstjärna. Du behöver inte allt från dag ett – men du kommer vilja ha de flesta delarna till slut.

Gyllene signaler (LLM-variant)

• Trafik: begäran/sekund, token/sekund
• Fel: felhastighet, tidsöverskridanden, OOM (Out of Memory), 429 (hastighetsbegränsning)
• Latens: begäranstid p50/p95/p99; latens vid förbehandling (prefill) kontra avkodning; latens per token
• Mättnad: GPU-utnyttjande, minnesanvändning, KV-cache-användning, köstorlek

Om du behöver lågnivåinsyn i GPU-minnesanvändning, temperatur och utnyttjande utanför Prometheus (för felsökning eller konfigurationer med en enda nod), se min guide till GPU-övervakningsapplikationer i Linux / Ubuntu.

För en bredare bild av LLM-observabilitet bortom mätvärden – inklusive spårning, strukturerade loggar, syntetisk testning, GPU-profiler och design av SLO – se min djupgående guide om observabilitet för LLM-system.

Användbara dimensioner (etiketter)

Håll etikett-kardinaliteten låg. Bra etiketter:

• model, endpoint, method (prefill/decode), status (lyckad/fel), instance

Undvik etiketter som:

• rå prompt, rå user_id, begäran-ID:n – dessa exploderar seriesträkningen.

Exponering av mätvärden: inbyggda /metrics-ändpunkter (vLLM, TGI, llama.cpp)

Den enklaste vägen är: använd de mätvärden som servern redan exponerar.

vLLM: Prometheus-kompatibel /metrics

vLLM exponerar en Prometheus-kompatibel /metrics-ändpunkt (via dess Prometheus-mätvärdesloggare) och publicerar server- och begäranmätvärden med prefixet vllm:, inklusive mätare för pågående begäran och KV-cache-användning.

För behållarkonfiguration, OpenAI-kompatibel tillhandahållande och runtime-justeringar inriktade på genomströmning, se vLLM-hurtstart: högpresterande LLM-tillhandahållande.

Exempel på mätvärden du typiskt kommer att se:

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

Hugging Face TGI: /metrics med kö + begäran-histogram

TGI exponerar många produktionskvalificerade mätvärden på /metrics, inklusive köstorlek, begäranstid, kötid och medel tid per token.

Några noterbart:

• tgi_queue_size (mätare)
• tgi_request_duration (histogram, E2E-latens)
• tgi_request_queue_duration (histogram)
• tgi_request_mean_time_per_token_duration (histogram)

Operativ konfiguration – Docker, GPU, startflaggor och de fel som visar sig som tomma eller vilseledande skrapningar – täcks i TGI – Text Generation Inference – Installera, konfigurera, felsök.

llama.cpp-server: aktivera mätvärdesändpunkt

llama.cpp-servern stöder en Prometheus-kompatibel mätvärdesändpunkt som måste aktiveras med en flagga (t.ex. --metrics).

För installationsvägar, nyckelflaggor för runtime och användning av OpenAI-kompatibel server, se llama.cpp-hurtstart med CLI och server.

Om du kör llama.cpp bakom en proxy, skrapa servern direkt när det är möjligt (för att undvika att proxy-nivåns latens döljer den faktiska inferensbeteendet).

Prometheus-konfiguration: skrapa dina inferensservrar

Detta exempel förutsätter:

• vLLM på http://vllm:8000/metrics
• TGI på http://tgi:8080/metrics
• llama.cpp på http://llama:8080/metrics
• skrapintervall justerat för snabb feedback

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"]

Om du är ny till Prometheus eller vill ha en djupare förklaring av skrapkonfigurationer, exportörer, ometikettering och larmregler, se min fulla guide för att ställa in Prometheus-övervakning.

Pro-tips: lägg till en “service-etikett”

Om du kör flera modeller/replikor, lägg till ometikettering för att inkludera en stabil service-etikett för tavlorna.

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

PromQL-exempel du kan kopiera och klistra in

Begäranhastighet (RPS)

sum(rate(tgi_request_count[5m]))

För vLLM, använd dess begäranräknare (namnen varierar beroende på version), men mönstret är detsamma: sum(rate(<räknare>[5m])).

Felhastighet (%)

Om du har *_success-räknare, beräkna felkvoten:

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

Latens p95 för histogram-mätvärden (Prometheus)

Prometheus-histogram är uppdelade i burkar; använd histogram_quantile() över rate() på burkarna. Prometheus dokumenterar denna modell och avvägningarna mellan histogram och sammanfattningar.

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

Kötid p99

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

Medel tid per token (latens per token)

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

Latens per token begränsas ofta av flaskhalsar i avkodning och minnesbandbredd – ämnen som behandlas i detalj i guiden för LLM-prestandaoptimering.

Ködjup (ögonblickligt)

max(tgi_queue_size)

vLLM KV-cache-utnyttjande (ögonblickligt)

max(vllm:kv_cache_usage_perc)

Grafana-tavlor: paneler som faktiskt hjälper under vakttid

Grafana kan visualisera histogram på flera sätt (percentiler, värmebilder, fördelning av burkar). Grafana Labs har en detaljerad guide för visualisering av Prometheus-histogram.

En minimal layout för en tavel med hög signal:

Rad 1 – Användarupplevelse

1. Latens för begäran p95 (tidsserie)
2. Latens per token p95 (tidsserie)
3. Felhastighet (tidsserie + stat)

Rad 2 – Kapacitet och mättnad

4. Köstorlek (tidsserie)
5. Pågående kontra väntande begäran (stackad)
6. KV-cache-användning % (mätare)

Rad 3 – Genomströmning

7. Begäran/sekund
8. Genererade token/begäran (p50/p95)

Om du har strömning, lägg till en panel för “latens för första token” (TTFT) när det finns tillgängligt.

Exempel på Grafana-frågor

• Panel för latens p95: frågan histogram_quantile(0.95, …) ovan
• Panel för värmebild: grafiska burkhastigheterna (*_bucket) som en värmebild (Grafana stöder detta tillvägagångssätt)

Implementeringsalternativ 1: Docker Compose (snabb lokal + en enda nod)

Om du bestämmer dig mellan lokal, självhärbärgad eller molnbaserad inferensarkitektur, se den fulla genomgången i min guide för jämförelse av LLM-hyrring.

Skapa en mapp som:

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

Om du föredrar en manuell installation av Grafana istället för Docker, se min steg-för-steg-guide om att installera och använda Grafana på Ubuntu.

Grafana-datasource-provisionering (grafana/provisioning/datasources/datasource.yml)

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

Provisionering av tavel (grafana/provisioning/dashboards/dashboards.yml)

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

Implementeringsalternativ 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Om du använder kube-prometheus-stack (Prometheus Operator), skrapa mål via ServiceMonitor.

För infrastruktursavvägningar mellan Kubernetes, Docker med en enda nod och hanterade inferensleverantörer, se min guide för LLM-hyrring 2026.

1) Exponera din inferensdeployment med en Service

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

2) Skapa en 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

Upprepa för vLLM- och llama.cpp-tjänster. Detta skalar rent när du lägger till replikor.

3) Larm: SLO-liknande regler (exempel)

Här är bra startlarm:

• Hög latens p95 (brännhastighet)
• Kötid p99 för hög (användare väntar)
• Felhastighet > 1 %
• KV-cache-användning > 90 % ihållande (kapacitetsklippa)

Exempelregel (begäranstid 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-latens > 3s (10m)"

Felsökning: vanliga Prometheus- och Grafana-fel i LLM-stackar

1) Prometheus-målet är “DOWN”

Symtom

• Prometheus-gränssnitt → Mål visar DOWN
• “context deadline exceeded” eller anslutning nekades

Kontrolllista

• Exponerar servern faktiskt /metrics?
• Fel port? Fel schema (http kontra https)?
• Kubernetes: väljer tjänsten poddar? Är ServiceMonitor-etiketten release korrekt?

Snabbtest

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

2) Du kan skrapa mätvärden, men panelerna är tomma

Mest vanliga orsaker

• Fel mätvärdesnamn (serverversionen ändrades)
• Tavlan förväntar sig _bucket men du har bara en mätare/räknare
• Prometheus-skrapintervall för långt för korta fönster (t.ex. [1m] med 30s-skrap kan vara brusigt)

Fix

• Använd Grafana Explore för att söka efter mätvärdesprefix (t.ex. tgi_ / vllm:)
• Öka områdesfönstret från [1m] → [5m]

3) Histogrampercentiler ser “platta” eller felaktiga ut

Prometheus-histogram kräver korrekt aggregering:

• använd rate(metric_bucket[5m])
• sedan sum by (le) (och valfritt andra stabila etiketter)
• sedan histogram_quantile()

Prometheus dokumenterar burkmodellen och serverbaserad percentilberäkning. Grafanas guide för visualisering av histogram inkluderar praktiska panelmönster.

4) Kardinalitetsexplosion (Prometheus-minnesökningar)

Symtom

• Prometheus-minnesanvändning klättrar
• Felmeddelanden om “för många serier”

Typisk rotorsak

• Du lade till prompt, user_id eller begäran-ID:n som etiketter i en anpassad exportör.

Fix

• Ta bort etiketter med hög kardinalitet
• Aggregera förhandsaggregerat till etiketter med låg kardinalitet (modell, ändpunkt, status)
• Överväg att använda loggar/spår för felsökning per begäran istället för etiketter

5) “Vi har mätvärden, men ingen aning om varför det är långsamt”

Mätvärden är nödvändiga, men ibland behöver du korrelation:

• Lägg till strukturerade loggar med begäranmetadata (modell, tokental, TTFT)
• Lägg till spårning (OpenTelemetry) runt din gateway + inferensserver
• Använd exemplar (när det stöds) för att hoppa från en latensspik till ett spår

Ett bra arbetsflöde: Grafana-tavla spikar -> klicka in i Explore -> begränsa efter instans/modell -> kolla loggar/spår för den perioden.

Detta följer den klassiska modellen mätvärden -> loggar -> spår som beskrivs i guiden för observabilitet och övervakningsarkitektur.

6) vLLM / flervärlds mätvärdeskuriosa

Om din tillhandahållande-stack kör i flera processer kan du behöva Prometheus-konfiguration för multiprocess (beroende på hur processen exponerar mätvärden). vLLM-dokumentationen betonar exponering av mätvärden via /metrics för Prometheus-polling; kolla serverns mätvärdesläge vid implementering.

En praktisk “dag-1”-tavel och larmsättning

Om du vill ha en smidig konfiguration som ändå fungerar i produktion, börja med:

Tavelpaneler

1. Latens för begäran p95
2. Medel tid per token p95
3. Köstorlek
4. Kötid p95
5. Felhastighet
6. KV-cache-användning %

Larm

• Latens för begäran p95 > X i 10 minuter
• Kötid p99 > Y i 10 minuter
• Felhastighet > 1 % i 5 minuter
• KV-cache-användning > 90 % i 15 minuter
• Prometheus-mål nere (alltid)

Relaterade guider för observabilitet

• Observabilitetsguide: Prometheus, Grafana och produktionsövervakning
• Prometheus-övervakning: installation och bästa praxis
• Installera och använd Grafana på Ubuntu: komplett guide

Relaterade guider för LLM-infrastruktur

• LLM-hyrring 2026: lokal, självhärbärgad och moln jämfört
• LLM-prestanda 2026: prestandamätningar och optimering

Avslutande anteckningar

Prometheus + Grafana ger dig en “alltid-aktiv” vy över inferenshälsa. När du har grunderna kommer nästa stora vinster oftast från:

• SLO per modell / hyresgäst
• Formgivning av begäran (max token, konkurrenslimit)
• Automatisk skalning kopplad till kötid och KV-cache-reserv

För en bredare förklaring av övervakning kontra observabilitet, Prometheus-grunder och produktionsmönster, se min kompletta observabilitetsguide.