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

LLM-inferens ser ut som “bara en annan API” – tills latens stiger, köer upp, och dina GPU:er sitter på 95% minne utan tydlig förklaring.

Övervakning blir kritiskt viktigt direkt när du går utomför en enskild nod eller börjar optimera för genomströmning. På det stadiet är traditionella API-mått inte tillräckliga. Du behöver insikt i token, batchbeteende, kötid och KV-cache-tryck – de verkliga fläckarna i moderna LLM-system.

Den här artikeln är en del av min bredare övervaknings- och insiktsguide, där jag täcker grunderna i övervakning vs insikt, Prometheus-arkitektur och produktions bästa praxis. Här kommer vi fokusera specifikt på att övervaka LLM-inferensarbetsbelastningar.

(Om du väljer infrastruktur, se min guide till LLM-värd i 2026. Om du vill ha en djupdykning i batchmekanik, VRAM-gränser och genomströmning vs latens kompromisser, se LLM-prestandaingenjörsguide.)

Olika från typiska REST-tjänster är LLM-servering formad av token, kontinuerlig batchning, KV-cacheanvändning, GPU/CPU-sättning och ködynamik. Två förfrågningar med identiska payloads storlekar kan ha radikalt olika latens beroende på max_new_tokens, konkurrens och cacheåteranvändning.

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

• Vad du ska mäta (p95/p99-latens, token/sec, kötid, cacheanvändning, felkvot)
• Hur du skrapar /metrics från vanliga servrar (vLLM, Hugging Face TGI, llama.cpp)
• PromQL-exempel för percentiler, mättnad och genomströmning
• Distributionsmönster med Docker Compose och Kubernetes
• Felsökning av problem som bara dyker upp vid riktig belastning

Exemplen är avsiktligt oberoende av leverantör. Oavsett om du senare lägger till OpenTelemetry-spårning, autoskalning eller ett tjänstnät, gäller samma måttsmodell.

Varför du bör övervaka LLM-inferens på ett annat sätt

Traditionell API-övervakning (RPS, p95-latens, felkvot) är nödvändig men inte tillräcklig. LLM-servering lägger till ytterligare axlar:

1) Latens har två betydelser

• E2E-latens: tid från förfrågan mottagen → sista token returnerad.
• Inter-token-latens: tid per token under decode (viktigt för streaming UX).

Vissa servrar exponerar båda. Till exempel exponerar TGI förfrågningstid och medel tid per token som histogram.

2) Genomströmning är i token, inte förfrågningar

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/sec”.

3) Köen är produkten

Om du kör kontinuerlig batchning är ködjupet det du säljer. Att följa kötid och köstorlek berättar om du uppfyller användarförväntningar.

4) Cache-tryck är en förkunnare till avbrott

KV-cache-uttömning (eller fragmentering) visar ofta upp som plötsliga latensstigningar och tidsgränsöverskridanden. vLLM exponerar KV-cacheanvändning som en gauge.

Måttchecklista för LLM-inferensövervakning

Använd detta som din norra stjärna. Du behöver inte allt från början – men du kommer vilja ha de flesta av dem till slut.

Gyllene signaler (LLM-utformade)

• Trafik: förfrågningar/sec, token/sec
• Fel: felkvot, tidsgränsöverskridanden, OOMs, 429s (begränsning av hastighet)
• Latens: p50/p95/p99 förfrågningstid; förberedelse vs decode-latens; inter-token-latens
• Mättnad: GPU-användning, minnesanvändning, KV-cacheanvändning, köstorlek

Om du behöver lägre nivå insikt i GPU-minnesanvändning, temperatur och användning utanför Prometheus (för felsökning eller enskilda noder), se min guide till GPU-övervakningsprogram i Linux / Ubuntu.

För en bredare vy av LLM-insikt utöver mått – inklusive spårning, strukturerade loggar, syntetisk testning, GPU-profilering och SLO-design – se min detaljerade guide till insikt för LLM-system.

Nytta dimensioner (etiketter)

Håll etikettens kardinalitet låg. Bra etiketter:

• model, endpoint, method (förberedelse/decode), status (lyckad/fel), instance

Undvik etiketter som:

• rå prompt, rå user_id, förfrågning id – dessa sprider serieantal.

Exponering av mått: inbyggda /metrics-slutpunkter (vLLM, TGI, llama.cpp)

Den enklasta vägen är: använd måtten som servern redan exponerar.

vLLM: Prometheus-kompatibel /metrics

vLLM exponerar en Prometheus-kompatibel /metrics-slutpunkt (via dess Prometheus måttsloggningsmodul) och publicerar server/förfrågan mått med prefixet vllm:, inklusive gauges som körande förfrågningar och KV-cacheanvändning.

Exempel på mått du vanligtvis ser:

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

Hugging Face TGI: /metrics med kö + förfrågan histogram

TGI exponerar många produktionsnivå mått på /metrics, inklusive köstorlek, förfrågningstid, kötid och medel tid per token.

Notabla:

• tgi_queue_size (gauge)
• tgi_request_duration (histogram, e2e-latens)
• tgi_request_queue_duration (histogram)
• tgi_request_mean_time_per_token_duration (histogram)

llama.cpp server: aktivera måttsslutpunkt

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

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

Prometheus-konfiguration: skrapa dina inferensservrar

Detta exempel antar:

• vLLM på http://vllm:8000/metrics
• TGI på http://tgi:8080/metrics
• llama.cpp på http://llama:8080/metrics
• skrapinterval anpassat för snabb återkoppling

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, exporterare, ometikettering och varningsregler, se min fullständiga Prometheus-övervakningsguide.

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

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

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

PromQL-exempel du kan kopiera/klippa

Förfrågningstakt (RPS)

sum(rate(tgi_request_count[5m]))

För vLLM, använd dess förfrågningställare (namn varierar beroende på version), men mönstret är samma: sum(rate(<counter>[5m])).

Felkvot (%)

Om du har *_success-tällare, beräkna felkvot:

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

p95-latens för histogrammått (Prometheus)

Prometheus-histogram är bucketade räkningar; använd histogram_quantile() över rate() av bucketarna. Prometheus dokumenterar detta modell och histogram vs sammanfattning kompromisser.

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

p99-kötid

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

Medel tid per token (inter-token-latens)

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

Inter-token-latens är ofta begränsad av decode-fläckar och minnesbandbredd – ämnen som behandlas detaljerat i LLM-prestandaoptimeringsguide.

Ködjup (instant)

max(tgi_queue_size)

vLLM KV-cacheanvändning (instant)

max(vllm:kv_cache_usage_perc)

Grafana-dashboards: paneler som faktiskt hjälper på värd

Grafana kan visualisera histogram på flera sätt (percentiler, heatmap, bucketfördelningar). Grafana Labs har en detaljerad guide till Prometheus-histogramvisualisering.

En minimal, högsignal dashboardlayout:

Rad 1 – Användarupplevelse

1. p95-förfrågan latens (tidsserier)
2. p95-inter-token-latens (tidsserier)
3. Felkvot (tidsserier + stat)

Rad 2 – Kapacitet och mättnad

4. Köstorlek (tidsserier)
5. Körande vs väntande förfrågningar (stapeldiagram)
6. KV-cacheanvändning % (gauge)

Rad 3 – Genomströmning

7. Förfrågningar/sec
8. Genererade token/förfrågan (p50/p95)

Om du har streaming, lägg till en panel för “första token latens” (TTFT) när tillgänglig.

Exempel på Grafana-frågor

• p95-latenspanel: histogram_quantile(0.95, …)-frågan ovan
• heatmappanel: grafiskt visa bucketraten (*_bucket) som en heatmap (Grafana stöder detta tillvägagångssätt)

Distributionsoption 1: Docker Compose (snabb lokal + enskild nod)

Om du väljer mellan lokal, självvärdad eller molnbaserad inferensarkitektur, se den fullständiga analysen i min LLM-värdjämförelseguide.

Skapa en mapp som:

övervakning/
  docker-compose.yml
  prometheus/
    prometheus.yml
  grafana/
    provisioning/
      datasources/datasource.yml
      dashboards/dashboards.yml
    dashboards/
      llm-inferens.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 Grafanainstallation istället för Docker, se min steg-för-steg-guide på installera och använda Grafana på Ubuntu.

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

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

Dashboardprovisionering (grafana/provisioning/dashboards/dashboards.yml)

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

Distributionsoption 2: Kubernetes (Prometheus Operator + ServiceMonitor)

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

För infrastrukturkompromisser mellan Kubernetes, enskild nod Docker och hanterade inferensleverantörer, se min LLM-värd i 2026-guide.

1) Exponera din inferensdistribution 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 detta för vLLM och llama.cpp-tjänster. Det här skalerar renligt när du lägger till repliker.

3) Varningar: SLO-stilregler (exempel)

Här är goda startervarningar:

• Hög p95-latens (brännkostnad)
• Kötid p99 för hög (användare väntar)
• Felkvot > 1%
• KV-cacheanvändning > 90% hålls (kapacitetsklyfta)

Exempelregel (p95-förfrågningstid):

- 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 + Grafana-fel i LLM-stackar

1) Prometheus mål är “DOWN”

Symtom

• Prometheus UI → Mål visar DOWN
• “context deadline exceeded” eller anslutning nekad

Checklista

• Är servern verkligen exponerad för /metrics?
• Fel port? Fel schema (http vs https)?
• Kubernetes: är Service väljande podar? Är ServiceMonitor-etiketten release korrekt?

Snabb test

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

2) Du kan skrapa mått, men paneler är tomma

Vanligaste orsaker

• Felaktigt måtnamn (serverversion har förändrats)
• Dashboard förväntar sig _bucket men du har bara en gauge/tällare
• Prometheus skrapintervall för långt för korta fönster (t.ex., [1m] med 30s skrap kan vara brusig)

Fixa

• Använd Grafana Explore för att söka måttprefix (t.ex., tgi_ / vllm:)
• Öka fönsterintervallet från [1m] → [5m]

3) Histogrampercentiler ser ut som “platta” eller felaktiga

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 bucketmodellen och serverbaserade kvantilberäkningar.
Grafanas histogramvisualiseringsguide innehåller praktiska panelmönster.

4) Kardinalitetsexplosion (Prometheus-minnesstigning)

Symtom

• Prometheus RAM-användning stiger
• “too many series” fel

Vanlig rotorsak

• Du har läagt till prompt, user_id eller förfrågning id som etiketter i en anpassad exporterare.

Fixa

• Ta bort högkardinalitetetiketter
• Aggregera förut till lågkardinalitetetiketter (modell, endpoint, status)
• Överväg att använda loggar/spårning för perförfrågning felsökning istället för etiketter

5) “Vi har mått, men ingen idé om varför det är långsamt”

Mått är nödvändiga, men ibland behöver du korrelation:

• Lägg till strukturerade loggar med förfrågningmetadata (modell, tokenantal, TTFT)
• Lägg till spårning (OpenTelemetry) runt din gateway + inferensserver
• Använd exemplar (när stödjer) för att hoppa från en latensstigning till en spårning

Ett bra arbetsflöde: Grafana-dashboardspik → klicka in i Explore → begränsa efter instans/modell → kontrollera loggar/spårning för den perioden.

Det följer den klassiska mått -> loggar -> spårningsmodellen som beskrivs i övervaknings- och insiktsarkitekturguide.

6) vLLM / multiprocess måttspecifika egenskaper

Om din serverstack körs i flera processer, kan du behöva Prometheus multiprocesskonfiguration (beroende på hur processen exponerar mått). vLLM-dokumentationen betonar att exponera mått via /metrics för Prometheus-pollning; kontrollera servers måttläge vid distribution.

En praktisk “dag-1” dashboard och varningsuppsättning

Om du vill ha en lätt inställning som ändå fungerar i produktion, börja med:

Dashboardpaneler

1. p95-förfrågning latens
2. p95-medel tid per token
3. köstorlek
4. p95-kötid
5. felkvot
6. KV-cacheanvändning %

Varningar

• p95-förfrågning latens > X för 10m
• p99-kötid > Y för 10m
• felkvot > 1% för 5m
• KV-cacheanvändning > 90% för 15m
• Prometheus-mål ner (alltid)

Relaterade insiktsguides

• Insiktsguide: Prometheus, Grafana & produktionssövning
• Prometheus-övervakning: Konfigurering & bästa praxis
• Installera och använda Grafana på Ubuntu: Komplett guide

Relaterade LLM-infrastrukturguides

• LLM-värd i 2026: Lokalt, självvärd och moln jämförda
• LLM-prestanda i 2026: Benchmarkar & optimering

Avslutande anteckningar

Prometheus + Grafana ger dig den “alltid på” vy av inferenshälsa. När du har grunderna, kommer de stora vinsterna ofta från:

• SLO per modell / klient
• förfrågningsskulptering (max token, konkurrensgränser)
• autoskalning kopplad till kötid och KV-cache-utrymme

För en bredare förklaring av övervakning vs insikt, Prometheus-fundament och produktionsmönster, se min fullständiga insiktsguide.