LLM-Abduktion in der Produktion überwachen (2026): Prometheus & Grafana für vLLM, TGI, llama.cpp

LLM-Abduktion sieht so aus, als sei „nur eine weitere API“ — bis Latenzspitzen auftreten, Warteschlangen sich aufbauen und Ihre GPUs bei 95 % Speicherbelegung stehen bleiben, ohne offensichtliche Erklärung.

Überwachung wird zur Mission kritisch, sobald Sie über eine Einzelknoten-Setup hinausgehen oder durchschnittliche Durchsatzoptimierungen anstreben. Zu diesem Zeitpunkt sind traditionelle API-Metriken nicht ausreichend. Sie benötigen Einblicke in Token, Batchverhalten, Warteschlangenzeiten und KV-Cache-Druck — die echten Engpässe moderner LLM-Systeme.

Dieser Artikel ist Teil meiner umfassenden Überwachungs- und Monitoring-Leitfaden, in dem ich Grundlagen von Monitoring vs. Observability, Prometheus-Architektur und Produktionsbest Practices abdecken. Hier konzentrieren wir uns speziell auf das Monitoring von LLM-Abduktions-Arbeitslasten.

(Wenn Sie sich für die Infrastruktur entscheiden, sehen Sie meinen Leitfaden zu LLM-Hosting im Jahr 2026. Wenn Sie eine tiefgehende Analyse der Batch-Mechanik, VRAM-Grenzen und Durchsatz vs. Latenz-Handelsabkommen wünschen, sehen Sie den LLM-Performance-Engineering-Leitfaden.)

Im Gegensatz zu typischen REST-Diensten ist das LLM-Abduktions-Server durch Token, stetige Batchverarbeitung, KV-Cache-Nutzung, GPU/CPU-Sättigung und Warteschlangendynamik geprägt. Zwei Anfragen mit identischen Nutzlastgrößen können je nach max_new_tokens, Konkurrenz und Cache-Wiederherstellung radikal unterschiedliche Latenzzeiten aufweisen.

Dieser Leitfaden ist ein praktischer, produktionsorientierter Durchlauf zur Erstellung von LLM-Abduktions-Monitoring mit Prometheus und Grafana:

• Was gemessen werden sollte (p95/p99 Latenz, Token/sec, Warteschlangendauer, Cache-Nutzung, Fehlerquote)
• Wie Sie /metrics von gängigen Servern (vLLM, Hugging Face TGI, llama.cpp) abfragen
• PromQL-Beispiele für Perzentile, Sättigung und Durchsatz
• Bereitstellungsmuster mit Docker Compose und Kubernetes
• Fehlersuche bei Problemen, die erst unter echter Last auftreten

Die Beispiele sind bewusst herstellerneutral. Ob Sie später OpenTelemetry-Trace, Skalierung oder ein Service Mesh hinzufügen, gilt der gleiche Metrikmodell.

Warum Sie LLM-Abduktion anders überwachen sollten

Traditionelles API-Monitoring (RPS, p95 Latenz, Fehlerquote) ist notwendig, aber nicht ausreichend. LLM-Server fügen zusätzliche Achsen hinzu:

1) Latenz hat zwei Bedeutungen

• E2E-Latenz: Zeit von Anfrage erhalten → letzter Token zurückgegeben.
• Inter-Token-Latenz: Zeit pro Token während der Dekodierung (wichtig für Streaming UX).

Einige Server geben beide aus. Zum Beispiel gibt TGI die Anforderungsdauer und die durchschnittliche Zeit pro Token als Histogramme aus.

2) Durchsatz ist in Token, nicht in Anfragen

Ein „schneller“ Dienst, der 5 Token zurückgibt, ist nicht mit einem vergleichbar, der 500 Token zurückgibt. Ihre „RPS“ sollte oft „Token/sec“ sein.

3) Die Warteschlange ist das Produkt

Wenn Sie kontinuierliche Batchverarbeitung durchführen, ist die Warteschlangentiefe das, was Sie verkaufen. Die Beobachtung von Warteschlangendauer und Warteschlangengröße zeigt Ihnen, ob Sie die Erwartungen der Benutzer erfüllen.

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

KV-Cache-Verbrauch (oder Fragmentierung) zeigt sich oft als plötzliche Latenzspitzen und Timeout. vLLM gibt KV-Cache-Nutzung als Gauge aus.

Metrik-Checkliste für LLM-Abduktions-Monitoring

Verwenden Sie dies als Ihr Nordstern. Sie benötigen nicht alles am ersten Tag — aber Sie werden am Ende die meisten davon benötigen.

Goldene Signale (LLM-geprägt)

• Verkehr: Anfragen/sec, Token/sec
• Fehler: Fehlerquote, Timeout, OOMs, 429s (Rate-Limiting)
• Latenz: p50/p95/p99 Anforderungsdauer; Vorbereitung vs. Dekodierung Latenz; Inter-Token Latenz
• Sättigung: GPU-Nutzung, Speichernutzung, KV-Cache-Nutzung, Warteschlangengröße

Wenn Sie eine tiefgehende Einblick in die GPU-Speichernutzung, Temperatur und Nutzungsgrad außerhalb von Prometheus benötigen (für Debugging oder Einzelknoten-Setup), sehen Sie meinen Leitfaden zu GPU-Monitoring-Anwendungen in Linux / Ubuntu.

Für einen umfassenderen Blick auf LLM-Observability über Metriken hinaus — einschließlich Nachverfolgung, strukturierte Protokolle, synthetische Tests, GPU-Profilierung und SLO-Entwurf — sehen Sie meinen umfassenden Leitfaden zu Observability für LLM-Systeme.

Nützliche Dimensionen (Labels)

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

• model, endpoint, method (vorbereiten/decode), status (Erfolg/Fehler), instance

Vermeiden Sie Labels wie:

• Roh prompt, Roh user_id, Anfrage-IDs — diese vergrößern die Serie-Anzahl.

Metriken offenlegen: eingebaute /metrics Endpunkte (vLLM, TGI, llama.cpp)

Der einfachste Weg ist: verwenden Sie die Metriken, die der Server bereits offenlegt.

vLLM: Prometheus-kompatibler /metrics

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

Beispiele für Metriken, die Sie typischerweise sehen:

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

Hugging Face TGI: /metrics mit Warteschlange + Anfragen-Histogrammen

TGI legt viele produktionsreife Metriken auf /metrics offen, einschließlich Warteschlangengröße, Anfragedauer, Warteschlangendauer und durchschnittliche Zeit pro Token.

Hervorzuheben sind:

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

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).

Wenn Sie llama.cpp hinter einem Proxy laufen lassen, scannen Sie den Server direkt, wann immer möglich (um Proxy-Ebene-Latenz zu vermeiden, die das tatsächliche Inferenzverhalten versteckt).

Prometheus-Konfiguration: Scannen Ihrer Abduktions-Server

Dieses Beispiel setzt voraus:

• vLLM bei http://vllm:8000/metrics
• TGI bei http://tgi:8080/metrics
• llama.cpp bei http://llama:8080/metrics
• Scrape-Intervall für schnelle Rückmeldung 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 bei Prometheus sind oder eine tiefgehende Erklärung zu Scrape-Konfigurationen, Exportern, Neuanordnungen und Alarmregeln benötigen, sehen Sie meinen vollständigen Prometheus-Monitoring-Setup-Leitfaden.

Pro-Tipp: Fügen Sie eine „Service-Label“ hinzu

Wenn Sie mehrere Modelle/Replikate laufen lassen, fügen Sie Neuanordnungen hinzu, um ein stabiles service-Label für Dashboards zu erhalten.

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

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

Anfrage-Rate (RPS)

sum(rate(tgi_request_count[5m]))

Für vLLM verwenden Sie seine Anfrage-Counter (die Namen variieren je nach Version), aber der Muster ist der gleiche: sum(rate(<counter>[5m])).

Fehlerquote (%)

Wenn Sie *_success-Counter haben, berechnen Sie den Fehlersatz:

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

p95 Latenz für Histogrammetriken (Prometheus)

Prometheus-Histogramme sind in Buckets gegliedert; verwenden Sie histogram_quantile() über rate() der Buckets. Prometheus dokumentiert dieses Modell und den Histogramm vs. Zusammenfassung Tradeoff.

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

p99 Warteschlangenzeiten

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

Durchschnittliche Zeit pro Token (Inter-Token-Latenz)

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

Inter-Token-Latenz ist oft durch Dekodierungsengpässe und Speicherbandbreite eingeschränkt – Themen, die im Detail in LLM-Performance-Optimierungsleitfaden behandelt werden.

Warteschlangentiefe (instant)

max(tgi_queue_size)

vLLM KV-Cache-Nutzung (instant)

max(vllm:kv_cache_usage_perc)

Grafana-Dashboards: Panels, die tatsächlich On-Call-Teams helfen

Grafana kann Histogramme auf mehrere Weise visualisieren (Perzentile, Wärmekarten, Bucket-Verteilungen). Grafana Labs hat einen detaillierten Leitfaden zur Prometheus-Histogramm-Visualisierung.

Ein minimales, hohen Signal-Dashboard-Layout:

Zeile 1 — Nutzererfahrung

1. p95 Anfragedauer (Zeitreihe)
2. p95 Inter-Token-Latenz (Zeitreihe)
3. Fehlerquote (Zeitreihe + Statistik)

Zeile 2 — Kapazität und Sättigung

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

Zeile 3 — Durchsatz

7. Anfragen/sec
8. Erzeugte Token/Anfrage (p50/p95)

Wenn Sie Streaming haben, fügen Sie ein Panel für „erster Token Latenz“ (TTFT) hinzu, wenn verfügbar.

Beispiel Grafana-Abfragen

• p95 Latenzpanel: die oben genannte histogram_quantile(0.95, …)-Abfrage
• Wärmekartenpanel: grafische Darstellung der Bucket-Raten (*_bucket) als Wärmekarte (Grafana unterstützt diesen Ansatz)

Bereitstellungsoption 1: Docker Compose (schnelle lokale + Einzelknoten)

Wenn Sie zwischen lokalen, selbstgehosteten und Cloud-basierten Inferenzarchitekturen entscheiden, sehen Sie die vollständige Analyse in meinem LLM-Hosting-Vergleichsleitfaden.

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 anstelle von Docker bevorzugen, sehen Sie meinen Schritt-für-Schritt-Leitfaden zu Grafana-Installation und -Verwendung unter Ubuntu.

Grafana-Datenquellen-Bereitstellung (grafana/provisioning/datasources/datasource.yml)

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

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

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

Bereitstellungsoption 2: Kubernetes (Prometheus Operator + ServiceMonitor)

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

Für Infrastruktur-Handelsabkommen zwischen Kubernetes, Einzelknoten-Docker und verwalteten Inferenzanbietern, siehen Sie meinen LLM-Hosting im Jahr 2026 Leitfaden.

1) Exponieren Sie Ihre Inferenzbereitstellung mit einem Service

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

2) Erstellen Sie eine 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) Alarmierung: SLO-stilige Regeln (Beispiel)

Hier sind gute Starter-Alarms:

• Hohe p95 Latenz (Verbrauchsgeschwindigkeit)
• Warteschlangenzeiten p99 zu hoch (Benutzer warten)
• Fehlerquote > 1%
• KV-Cache-Nutzung > 90% (Kapazitätsabfall)

Beispielregel (p95 Anforderungsdauer):

- 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 + Grafana-Fehler in LLM-Stacks

1) Prometheus-Ziel ist „DOWN“

Symptome

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

Checkliste

• Wird der Server tatsächlich /metrics aus?
• Falscher Port? Falsches Schema (http vs. https)?
• Kubernetes: Wählt der Service Pods aus? Ist das ServiceMonitor-Label release korrekt?

Schnelltest

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

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

Häufigste Ursachen

• Falscher Metrikname (Serverversion geändert)
• Dashboard erwartet _bucket aber Sie haben nur einen Gauge/Counter
• Prometheus-Scrape-Intervall zu lang für kurze Fenster (z. B. [1m] mit 30s Scrape kann störend sein)

Fix

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

3) Histogram-Perzentile sehen „flach“ oder falsch aus

Prometheus-Histogramme benötigen 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 Panelmuster.

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

Symptome

• Prometheus-Speichernutzung steigt
• „zu viele Series“-Fehler

Typische Ursache

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

Fix

• Entfernen Sie Labels mit hoher Kardinalität
• Aggregieren Sie in Labels mit niedriger Kardinalität (Modell, Endpunkt, Status)
• Überlegen Sie, ob Sie Logs/Traces für Debugging pro Anfrage verwenden, anstatt Labels

5) „Wir haben Metriken, aber keine Ahnung, warum es langsam ist“

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

• Fügen Sie strukturierte Logs mit Anfragemetadaten hinzu (Modell, Tokenzahlen, TTFT)
• Fügen Sie Nachverfolgung (OpenTelemetry) um Ihre Gateway- und Inferenzserver hinzu
• Verwenden Sie Exemplare (wenn unterstützt), um von einem Latenzspitze zu einem Trace zu springen

Ein gutes Workflow: Grafana-Dashboard-Spitze → auf Explore klicken → einengen auf Instanz/Modell → prüfen Sie Logs/Traces für diesen Zeitraum.

Dies folgt dem klassischen Modell der Metriken → Logs → Traces, wie in Observability und Monitoring-Architektur-Leitfaden.

6) vLLM / Multi-Prozess-Metrik-Eigenschaften

Wenn Ihre Servierstapel in mehreren Prozessen läuft, benötigen Sie möglicherweise eine Prometheus-Multi-Prozess-Konfiguration (abhängig davon, wie der Prozess Metriken ausgibt). Die vLLM-Dokumentation betont, Metriken über /metrics für Prometheus-Abfragen zu offenlegen; prüfen Sie den Server-Modus für Metriken, wenn Sie deployen.

Praktische „Tag-1“-Dashboard- und Alarm-Gruppe

Wenn Sie eine schlankere Einrichtung benötigen, die dennoch in der Produktion funktioniert, starten Sie mit:

Dashboard-panels

1. p95 Anforderungslatenz
2. p95 durchschnittliche Zeit pro Token
3. Warteschlangengröße
4. p95 Warteschlangendauer
5. Fehlerquote
6. KV-Cache-Nutzung %

Alarme

• p95 Anforderungslatenz > X für 10m
• p99 Warteschlangendauer > Y für 10m
• Fehlerquote > 1 % für 5m
• KV-Cache-Nutzung > 90 % für 15m
• Prometheus-Ziel abgeschaltet (immer)

Verwandte Observability-Leitfäden

• Observability-Leitfaden: Prometheus, Grafana & Produktions-Monitoring
• Prometheus-Monitoring: Einrichtung & Best Practices
• Installieren und Verwenden von Grafana unter Ubuntu: Vollständiger Leitfaden

Verwandte LLM-Infrastruktur-Leitfäden

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

Schlussnotizen

Prometheus + Grafana geben Ihnen den „immer-ein“-Blick auf die Gesundheit der Inferenz. Nachdem Sie die Grundlagen haben, folgen die nächsten großen Gewinne oft von:

• SLOs pro Modell / Mieter
• Anfrageformung (max Tokens, Konkurrenzgrenzen)
• Skalierung, die an Warteschlangenzeiten und KV-Cache-Reserve gekoppelt ist

Für eine umfassende Erklärung von Monitoring vs. Observability, Prometheus-Grundlagen und Produktionsmuster, siehe meinen vollständigen Observability-Leitfaden.