Überwachung der LLM-Inferenz im Produktivumfeld (2026): Prometheus und Grafana für vLLM, TGI und llama.cpp

LLM-Inferenz sieht aus wie „nur eine weitere API" – bis die Latenzspitzen auftreten, Warteschlangen sich stauen und Ihre GPUs eine Speichernutzung von 95 % haben, ohne dass eine offensichtliche Erklärung dafür vorhanden ist.

Überwachung wird zum kritischen Erfolgsfaktor, sobald Sie eine Einzellösung verlassen oder mit der Optimierung des Durchsatzes beginnen. Zu diesem Zeitpunkt reichen traditionelle API-Metriken nicht aus. Sie benötigen Einblicke in Tokens, das Batch-Verhalten, die Wartezeit in der Warteschlange und den Druck auf den KV-Cache – die eigentlichen Flaschenhälse moderner LLM-Systeme.

Dieser Artikel ist Teil meines umfassenden Leitfadens zu Observability und Monitoring, in dem ich die Grundlagen von Monitoring vs. Observability, die Prometheus-Architektur und Best Practices für den Produktiveinsatz abdecke. Hier konzentrieren wir uns speziell auf das Monitoring von LLM-Inferenz-Workloads.

(Falls Sie die Infrastruktur wählen müssen, sehen Sie meinen Leitfaden zu LLM-Hosting im Jahr 2026. Wenn Sie einen tiefen Einblick in die Mechanik des Batchings, VRAM-Limits und den Kompromissen zwischen Durchsatz und Latenz wünschen, konsultieren Sie den Leitfaden zur LLM-Performance-Ingenieurwesen.)

Im Gegensatz zu typischen REST-Diensten wird LLM-Serving durch Tokens, Continuous Batching, KV-Cache-Auslastung, GPU/CPU-Sättigung und Warteschlangendynamik geprägt. Zwei Anfragen mit identischer Payload-Größe können je nach max_new_tokens, Concurrenz und Cache-Wiederverwendung radikal unterschiedliche Latenzen aufweisen.

Dieser Leitfaden ist eine praktische, produktionsorientierte Anleitung zur Erstellung von LLM-Inferenz-Monitoring mit Prometheus und Grafana:

• Was gemessen werden sollte (p95/p99-Latenz, Tokens/Sekunde, Warteschlangenlänge, Cache-Auslastung, Fehlerrate)
• Wie /metrics von gängigen Servern gesammelt wird (vLLM, Hugging Face TGI, llama.cpp)
• PromQL-Beispiele für Perzentile, Sättigung und Durchsatz
• Deployment-Muster mit Docker Compose und Kubernetes
• Fehlerbehebung bei Problemen, die nur unter echter Last auftreten

Die Beispiele sind bewusst herstellerneutral. Egal, ob Sie später OpenTelemetry-Tracing, Autoscaling oder ein Service-Mesh hinzufügen – dasselbe Metrikenmodell gilt.

Warum Sie LLM-Inferenz anders überwachen sollten

Traditionelles API-Monitoring (RPS, p95-Latenz, Fehlerrate) ist notwendig, aber nicht ausreichend. LLM-Serving fügt zusätzliche Dimensionen hinzu:

1) Latenz hat zwei Bedeutungen

• End-to-End-Latenz: Zeit vom Erhalt der Anfrage bis zum Zurückgeben des letzten Tokens.
• Inter-Token-Latenz: Zeit pro Token während der Dekodierung (entscheidend für die Streaming-UX).

Einige Server stellen beide bereit. Zum Beispiel stellt TGI die Anfrage-Dauer und die mittlere Zeit pro Token als Histogramme bereit.

2) Durchsatz wird in Tokens, nicht in Anfragen gemessen

Ein „schneller" Dienst, der 5 Tokens zurückgibt, ist nicht mit einem vergleichbar, der 500 Tokens zurückgibt. Ihr „RPS" sollte häufiger „Tokens/Sekunde" sein.

3) Die Warteschlange ist das Produkt

Wenn Sie Continuous Batching betreiben, ist die Tiefe der Warteschlange das, was Sie verkaufen. Die Beobachtung der Warteschlangen-Dauer und der Warteschlangen-Größe zeigt Ihnen, ob Sie die Erwartungen der Nutzer erfüllen.

4) Cache-Druck ist ein Vorläufer von Ausfällen

Die Erschöpfung (oder Fragmentierung) des KV-Caches zeigt sich oft als plötzliche Latenzspitzen und Timeouts. vLLM stellt die KV-Cache-Nutzung als Gauge bereit.

Metriken-Checkliste für das LLM-Inferenz-Monitoring

Nutzen Sie dies als Ihren Nordstern. Sie brauchen nicht alles am ersten Tag – aber Sie werden die meisten davon irgendwann wollen.

Goldene Signale (LLM-farblich)

• Verkehr: Anfragen/Sekunde, Tokens/Sekunde
• Fehler: Fehlerrate, Timeouts, OOMs (Out of Memory), 429s (Rate Limiting)
• Latenz: p50/p95/p99 Anfrage-Dauer; Prefill vs. Decode-Latenz; Inter-Token-Latenz
• Sättigung: GPU-Auslastung, Speichernutzung, KV-Cache-Nutzung, Warteschlangen-Größe

Wenn Sie eine tiefe Sicht auf die GPU-Speichernutzung, Temperatur und Auslastung außerhalb von Prometheus benötigen (zur Fehleranalyse oder für Einzellösungen), sehen Sie meinen Leitfaden zu GPU-Monitoring-Anwendungen in Linux / Ubuntu.

Für einen breiteren Blick auf die Observability von LLM-Systemen über Metriken hinaus – einschließlich Tracing, strukturierten Logs, synthetischen Tests, GPU-Profiling und SLO-Design – sehen Sie meinen ausführlichen Leitfaden zu Observability für LLM-Systeme.

Nützliche Dimensionen (Labels)

Halten Sie die Label-Kardinalität niedrig. Gute Labels:

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

Vermeiden Sie Labels wie:

• rohe prompt, rohe user_id, Anfrage-IDs – diese explodieren die Serienanzahl.

Metriken bereitstellen: integrierte /metrics-Endpunkte (vLLM, TGI, llama.cpp)

Der einfachste Weg ist: nutzen Sie die Metriken, die der Server bereits bereitstellt.

vLLM: Prometheus-kompatibler /metrics-Endpunkt

vLLM stellt einen Prometheus-kompatiblen /metrics-Endpunkt (über seinen Prometheus-Metriken-Logger) bereit und veröffentlicht Server- und Anfrage-Metriken mit dem Präfix vllm:, einschließlich Gauges wie laufende Anfragen und KV-Cache-Nutzung.

Für die Container-Einrichtung, OpenAI-kompatibles Serving und durchsatzorientierte Laufzeitoptimierung sehen Sie vLLM Quickstart: Hochleistungs-LLM-Serving.

Beispielhafte Metriken, die Sie typischerweise sehen werden:

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

Hugging Face TGI: /metrics mit Warteschlange und Anfrage-Histogrammen

TGI stellt viele produktionsreife Metriken unter /metrics bereit, einschließlich Warteschlangen-Größe, Anfrage-Dauer, Warteschlangen-Dauer und der mittleren Zeit pro Token.

Bemerkenswerte Metriken:

• tgi_queue_size (Gauge)
• tgi_request_duration (Histogramm, E2E-Latenz)
• tgi_request_queue_duration (Histogramm)
• tgi_request_mean_time_per_token_duration (Histogramm)

Die operative Einrichtung – Docker, GPUs, Startflags und die Fehler, die als leere oder irreführende Scrapes erscheinen – wird in TGI - Text Generation Inference - Installieren, Konfigurieren, Fehler beheben behandelt.

llama.cpp Server: Metriken-Endpunkt aktivieren

Der llama.cpp-Server unterstützt einen Prometheus-kompatiblen Metriken-Endpunkt, der mit einem Flag aktiviert werden muss (z. B. --metrics).

Für Installationspfade, wichtige Laufzeitflags und die Nutzung des OpenAI-kompatiblen Servers sehen Sie llama.cpp Quickstart mit CLI und Server.

Wenn Sie llama.cpp hinter einem Proxy betreiben, scrape Sie den Server immer direkt, wann immer möglich (um zu vermeiden, dass die Proxy-Latenz das tatsächliche Inferenzverhalten verschleiert).

Prometheus-Konfiguration: Scraping Ihrer Inferenz-Server

Dieses Beispiel geht davon aus:

• vLLM unter http://vllm:8000/metrics
• TGI unter http://tgi:8080/metrics
• llama.cpp unter http://llama:8080/metrics
• Intervall für das Scraping für schnelles Feedback optimiert

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

Wenn Sie neu in Prometheus sind oder eine tiefere Erklärung der Scrape-Konfigurationen, Exporter, Relabeling und Alerting-Regeln wünschen, sehen Sie meinen vollständigen Leitfaden zur Prometheus-Monitoring-Einrichtung.

Profi-Tipp: Fügen Sie ein „Service-Label" hinzu

Wenn Sie mehrere Modelle/Replikate betreiben, fügen Sie Relabeling hinzu, um ein stabiles service-Label für Dashboards einzubeziehen.

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

PromQL-Beispiele, die Sie kopieren/einfügen können

Anfragerate (RPS)

sum(rate(tgi_request_count[5m]))

Für vLLM verwenden Sie seine Anfragezähler (die Namen variieren je nach Version), aber das Muster ist dasselbe: sum(rate(<counter>[5m])).

Fehlerrate (%)

Wenn Sie *_success-Zähler haben, berechnen Sie das Fehlersignal:

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

p95-Latenz für Histogramm-Metriken (Prometheus)

Prometheus-Histogramme sind in Buckets unterteilt; verwenden Sie histogram_quantile() über rate() der Buckets. Prometheus dokumentiert dieses Modell und die Kompromisse zwischen Histogramm und Summary.

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

p99 Warteschlangenzeit

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

Mittlere Zeit pro Token (Inter-Token-Latenz)

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

Die Inter-Token-Latenz wird oft durch Decode-Flaschenhälse und Speicherbandbreite begrenzt – Themen, die im Detail im Leitfaden zur LLM-Performance-Optimierung behandelt werden.

Warteschlangen-Tiefe (aktuell)

max(tgi_queue_size)

vLLM KV-Cache-Auslastung (aktuell)

max(vllm:kv_cache_usage_perc)

Grafana-Dashboards: Panels, die beim On-Call wirklich helfen

Grafana kann Histogramme auf verschiedene Weise visualisieren (Perzentile, Heatmaps, Bucket-Verteilungen). Grafana Labs hat einen detaillierten Leitfaden zur Visualisierung von Prometheus-Histogrammen.

Ein minimales, hochsignalreiches Dashboard-Layout:

Reihe 1 — Nutzererfahrung

1. p95 Anfrage-Latenz (Zeitreihe)
2. p95 Inter-Token-Latenz (Zeitreihe)
3. Fehlerrate (Zeitreihe + Stat)

Reihe 2 — Kapazität und Sättigung

4. Warteschlangen-Größe (Zeitreihe)
5. Laufende vs. wartende Anfragen (gestapelt)
6. KV-Cache-Nutzung % (Gauge)

Reihe 3 — Durchsatz

7. Anfragen/Sekunde
8. Generierte Tokens/Anfrage (p50/p95)

Wenn Sie Streaming verwenden, fügen Sie ein Panel für „First Token Latency" (TTFT) hinzu, falls verfügbar.

Beispiel Grafana-Abfragen

• p95-Latenz-Panel: die histogram_quantile(0.95, …)-Abfrage oben
• Heatmap-Panel: grafische Darstellung der Bucket-Raten (*_bucket) als Heatmap (Grafana unterstützt diesen Ansatz)

Deployment-Option 1: Docker Compose (schnell lokal + Einzellösung)

Wenn Sie zwischen lokaler, selbstgehosteter oder cloud-basierter Inferenz-Architektur entscheiden, sehen Sie die vollständige Aufschlüsselung in meinem Leitfaden zum Vergleich von LLM-Hosting.

Erstellen Sie einen Ordner wie:

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

Wenn Sie eine manuelle Grafana-Installation statt Docker bevorzugen, sehen Sie meinen Schritt-für-Schritt-Leitfaden zum Installieren und Verwenden von Grafana auf Ubuntu.

Grafana-Datasource-Provisioning (grafana/provisioning/datasources/datasource.yml)

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

Dashboard-Provisioning (grafana/provisioning/dashboards/dashboards.yml)

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

Deployment-Option 2: Kubernetes (Prometheus Operator + ServiceMonitor)

Wenn Sie kube-prometheus-stack (Prometheus Operator) verwenden, scrape Sie Ziele über ServiceMonitor.

Für Infrastrukturauswahlen zwischen Kubernetes, Docker-Einzelknoten und verwalteten Inferenz-Anbietern sehen Sie meinen Leitfaden zu LLM-Hosting im Jahr 2026.

1) Stellen Sie Ihre Inferenz-Deployment mit einem Service bereit

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

2) Erstellen Sie einen 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

Wiederholen Sie dies für vLLM- und llama.cpp-Dienste. Dies skaliert sauber, wenn Sie Replikate hinzufügen.

3) Alerting: SLO-ähnliche Regeln (Beispiel)

Hier sind gute Start-Alerts:

• Hohe p95-Latenz (Burn Rate)
• Warteschlangenzeit p99 zu hoch (Nutzer warten)
• Fehlerrate > 1%
• KV-Cache-Nutzung > 90% nachhaltig (Kapazitätsabfall)

Beispielregel (p95 Anfrage-Dauer):

- 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 Latenz > 3s (10m)"

Fehlerbehebung: Häufige Prometheus- und Grafana-Fehler in LLM-Stacks

1) Prometheus-Ziel ist „DOWN"

Symptome

• Prometheus UI → Ziele zeigt DOWN
• „context deadline exceeded" oder Verbindung abgelehnt

Checkliste

• Stellt der Server tatsächlich /metrics bereit?
• Falscher Port? Falsches Schema (http vs. https)?
• Kubernetes: Selektiert der Service die Pods? Ist das ServiceMonitor-Label release korrekt?

Schnelltest

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

2) Sie können Metriken scrapen, aber die Panels sind leer

Häufigste Ursachen

• Falscher Metrikenname (Server-Version geändert)
• Dashboard erwartet _bucket, aber Sie haben nur ein Gauge/Counter
• Prometheus-Scrape-Intervall zu lang für kurze Fenster (z. B. [1m] mit 30s-Scrape kann verrauscht sein)

Behebung

• Verwenden Sie Grafana Explore, um nach Metriken-Präfixen zu suchen (z. B. tgi_ / vllm:)
• Erhöhen Sie das Fenster von [1m] → [5m]

3) Histogramm-Perzentile sehen „flach" oder falsch aus

Prometheus-Histogramme erfordern korrekte Aggregation:

• verwenden Sie rate(metric_bucket[5m])
• dann sum by (le) (und optional andere stabile Labels)
• dann histogram_quantile()

Prometheus dokumentiert das Bucket-Modell und die serverseitige Quantilberechnung.
Grafanas Histogramm-Visualisierungsleitfaden enthält praktische Panel-Muster.

4) Kardinalitäts-Explosion (Prometheus-Speicherspitzen)

Symptome

• Prometheus-RAM-Nutzung steigt an
• „too many series"-Fehler

Typische Ursache

• Sie haben prompt, user_id oder Anfrage-IDs als Labels in einem benutzerdefinierten Exporter hinzugefügt.

Behebung

• Entfernen Sie Labels mit hoher Kardinalität
• Aggregieren Sie vorab zu Labels mit niedriger Kardinalität (Modell, Endpunkt, Status)
• Erwägen Sie die Verwendung von Logs/Traces zur Fehleranalyse pro Anfrage statt Labels

5) „Wir haben Metriken, wissen aber nicht, warum es langsam ist"

Metriken sind notwendig, aber manchmal benötigen Sie Korrelation:

• Fügen Sie strukturierte Logs mit Anfrage-Metadaten hinzu (Modell, Token-Anzahl, TTFT)
• Fügen Sie Tracing (OpenTelemetry) um Ihr Gateway + Inferenz-Server hinzu
• Verwenden Sie Exemplare (wenn unterstützt), um von einer Latenzspitze zu einem Trace zu springen

Ein guter Workflow: Grafana-Dashboard-Spitze -> in Explore klicken -> nach Instanz/Modell eingrenzen -> Logs/Traces für diesen Zeitraum prüfen.

Dies folgt dem klassischen Modell Metriken -> Logs -> Traces, das im Leitfaden zur Observability- und Monitoring-Architektur beschrieben wird.

6) vLLM / Mehrprozess-Metrik-Eigenheiten

Wenn Ihr Serving-Stack in mehreren Prozessen läuft, benötigen Sie möglicherweise die Prometheus-Mehrfachprozess-Konfiguration (abhängig davon, wie der Prozess Metriken bereitstellt). Die vLLM-Dokumente betonen das Bereitstellen von Metriken über /metrics für Prometheus-Polling; überprüfen Sie den Metriken-Modus des Servers beim Deployment.

Ein praktischer „Tag-1"-Dashboard- und Alert-Satz

Wenn Sie eine schlanke Einrichtung wünschen, die dennoch im Produktiveinsatz funktioniert, beginnen Sie mit:

Dashboard-Panels

1. p95 Anfrage-Latenz
2. p95 mittlere Zeit pro Token
3. Warteschlangen-Größe
4. p95 Warteschlangen-Dauer
5. Fehlerrate
6. KV-Cache-Nutzung %

Alerts

• p95 Anfrage-Latenz > X für 10m
• p99 Warteschlangen-Dauer > Y für 10m
• Fehlerrate > 1% für 5m
• KV-Cache-Nutzung > 90% für 15m
• Prometheus-Ziel down (immer)

Verwandte Observability-Leitfäden

• Observability-Leitfaden: Prometheus, Grafana & Produktions-Monitoring
• Prometheus-Monitoring: Einrichtung & Best Practices
• Grafana auf Ubuntu installieren und verwenden: Kompletter Leitfaden

Verwandte LLM-Infrastruktur-Leitfäden

• LLM-Hosting im Jahr 2026: Lokal, Selbstgehostet & Cloud im Vergleich
• LLM-Performance im Jahr 2026: Benchmarks & Optimierung

Abschließende Anmerkungen

Prometheus + Grafana bietet Ihnen die „immer aktive" Sicht auf die Inferenz-Gesundheit. Sobald Sie die Grundlagen haben, stammen die nächsten großen Gewinne in der Regel aus:

• SLOs pro Modell / Tenant
• Request-Shaping (maximale Tokens, Concurrency-Limits)
• Autoscaling, gebunden an Warteschlangenzeit und KV-Cache-Reserven

Für eine umfassendere Erklärung von Monitoring vs. Observability, Prometheus-Grundlagen und Produktionsmustern, sehen Sie meinen vollständigen Observability-Leitfaden.