Kernaussage — betreiben Sie Self-Hosted LLM-Inferenz gegen nutzernahe Service-Level Objectives (SLOs), nicht gegen die durchschnittliche GPU-Auslastung. Eine stark ausgelastete GPU kann bei akzeptabler Warteschlange völlig in Ordnung sein; eine wenig ausgelastete GPU kann Nutzer dennoch hinter langem Prefill oder einem gesättigten KV-Cache warten lassen. Beginnen Sie mit p95 und p99 für Time to First Token (TTFT), Inter-Token-Latenz, Queue-Zeit, End-to-End-Latenz und Fehlerrate – jeweils nach Request-Klasse. Nutzen Sie GPU-Telemetrie anschließend, um eine verletzte Zielvorgabe zu erklären, nicht um Erfolg zu definieren.
Das ist ein Betriebsmuster für Produktion, keine Behauptung, dass ein einzelner Grenzwert für jedes Modell oder jeden Workflow passt. vLLM exportiert Prometheus-Histogramme für TTFT, Inter-Token-Latenz, Queue-Zeit, Prefill, Decode und End-to-End-Latenz sowie Gauges für wartende Requests und KV-Cache-Nutzung. Die vLLM-Dokumentation zu Produktionsmetriken beschreibt diese Signale auf dem Request-Pfad. NVIDIA DCGM ergänzt sie um Gerätegesundheit, Konfiguration, Job-Statistiken und GPU-Metriken. Damit wird eine operative Frage beantwortbar: Welche Phase verletzt die Servicezusage, für welche Requests, und welche Änderung lässt sich sicher testen?
GPU-Auslastung erklärt, aber sie ist kein Nutzervertrag
GPU-Auslastung ist ein abgetastetes Signal auf Geräteebene. Sie sagt nicht, ob ein interaktiver Nutzer schnell das erste Token sah, ob ein langer Prompt die Admission-Kapazität blockierte, ob ein Request im Scheduler wartete oder ob ein Streaming-Response stockte. Ein Durchschnitt verdeckt zudem den Tail: Einer von hundert Requests kann ein p99-Ziel verfehlen, obwohl das Dashboard ruhig wirkt. Eine Servicezusage muss deshalb an der Request-Grenze formuliert und nach Traffic-Klasse sowie Zeitfenster ausgewertet werden.
Das entspricht dem Observability-Modell von vLLM: Request-Metriken sind die SLOs, die SREs verfolgen; Server-Metriken erklären sie. Behalten Sie diese Trennung über Gateway, Inferenzserver, GPU-Exporter und Client hinweg bei. Jeder Request braucht Korrelations-ID, Route/Modellrevision, Prompt-Längenklasse, Output-Limit sowie Tenant- oder Workload-Klasse und Abschlussgrund. Rohe Prompts oder personenbezogene Inhalte gehören nicht in breit zugängliche Betriebsmetriken.
Referenzpfad: Phasen getrennt instrumentieren
Diagramm — Client → API-Gateway → Admission und Queue → Tokenizer/Prefill → Scheduler und KV-Cache-Allokation → Decode/Streaming → Response-Gateway → Client. Parallel: vLLM-Request-Histogramme sowie Queue-/KV-Gauges → Prometheus; DCGM-Signale für GPU, Speicher, Leistung, Temperatur, ECC/Xid und Topologie → Exporter → Prometheus. Eine Trace-ID verbindet den Request-Pfad mit einer begrenzten Trace-Stichprobe. Die Betriebsregel lautet: Bewahren Sie Phasenzeiten, bevor Sie sie zu einer Latenzzahl aggregieren.
Prefill verarbeitet den Eingabekontext und schreibt Attention-Zustand in den KV-Cache; Decode erzeugt Ausgabetokens iterativ und liest diesen Zustand wiederholt. Die Ressourcenprofile unterscheiden sich. Ein langer RAG-Prompt kann TTFT und Cache-Druck erhöhen, ohne dass Streaming nach dem ersten Token langsam wird. Eine Decode-lastige Aufgabe kann akzeptablen TTFT, aber schlechte Inter-Token-Latenz haben. Testen Sie Kapazitätsänderungen, Batching-Parameter und Request-Limits gegen beide Phasen.
Vor dem Tuning ein kleines SLO-Set definieren
Interaktiver TTFT: p95 und p99 von Gateway-Annahme bis zum ersten gestreamten Token, getrennt nach Prompt-Länge und Route. Das misst den wahrgenommenen Start.
Streaming-Kontinuität: p95 und p99 der Inter-Token-Latenz (bzw. Zeit pro Output-Token). Das zeigt Antworten, die schnell beginnen und dann unbrauchbar langsam werden.
Queue-Zeit: p95/p99 der Wartezeit und Tiefe wartender Requests. Damit trennen Sie Admission-Sättigung von Modellausführung.
Completion Time: p95/p99 der End-to-End-Latenz, getrennt nach Input- und Output-Größe. Das bleibt für nicht-streamende Integrationen notwendig.
Zuverlässigkeit: Abschlussgründe, Timeouts, Cancel-Rate und serverseitige Fehlerrate. Definieren Sie Fehler präzise; ein Client-Abbruch ist nicht zwingend ein Serverfehler.
Kapazitätskontext: Concurrency, Verteilung von Prompt- und Generation-Tokens, KV-Cache-Nutzung, Preemption, GPU-Speicher, Energie-/Temperaturzustand und relevante DCGM-Health-Events.
Verwenden Sie Histogramme für Latenzverteilungen, damit Perzentilabfragen die Zielschwelle abbilden. Die Prometheus-Histogramm-Dokumentation erläutert, dass Histogramme Beobachtungen in Buckets halten und die Bucket-Wahl den Fehler im Wertebereich bestimmt. Platzieren Sie Grenzen um SLO-Schwelle und erwarteten Fehlerbereich. Begrenzen Sie Labels: Modellrevision und Route sind sinnvoll; Request-ID, Nutzer-ID und Prompt-Text nicht.
Entscheidungstabelle: Metrik, Symptom, Korrektur
| Signal | Wahrscheinlicher Engpass | Erste Korrektur | Zielkonflikt |
|---|---|---|---|
| p99-TTFT steigt; Inter-Token-Latenz stabil; Queue-Zeit steigt | Admission-Sättigung oder Contention durch langen Prefill | Concurrency-/Admission-Limit testen und Long-Context-Traffic trennen | geringerer Peak-Durchsatz oder separate Route |
| TTFT steigt; Queue stabil; Prefill-Zeit steigt mit Prompt-Länge | Prefill-Kapazität oder übermäßiger Kontext | Kontext begrenzen/retrieval reduzieren; Prefill/Decode-Trennung testen | weniger Kontext oder mehr Infrastrukturkomplexität |
| Inter-Token-Latenz steigt; TTFT akzeptabel; Decode-Zeit steigt | Decode-Kapazität, Batching oder Clock-/Power-Grenze | Output-Limits, Batch-Konfiguration und GPU-Gesundheit testen | weniger Antwortlänge oder Durchsatz |
| Queue-Zeit und KV-Cache-Nutzung nahe Sättigung; Preemptions steigen | KV-Cache-Druck | Kontext/Concurrency reduzieren, Cache-Kapazität ergänzen oder Long Context routen | Kosten, geringere Concurrency oder Routing-Komplexität |
| Latenz und Fehler steigen mit DCGM-Signalen zu Temperatur/ECC/Xid | Geräte-/Hostfehler oder Throttling | Node aus dem Service nehmen; freigegebene Diagnose und Eskalation | temporärer Kapazitätsverlust |
| GPU-Auslastung hoch, Ziele eingehalten | effiziente Last, nicht automatisch ein Problem | Headroom-Test beibehalten und Tails beobachten | zusätzlicher Headroom kostet Kapazität |
Die Sättigungskurve testen, nicht nur den Happy Path
Eine belastbare Kapazitätsentscheidung ist eine Matrix, kein einzelnes Tokens-pro-Sekunde-Ergebnis. Frieren Sie Modellrevision, Tokenizer, Runtime-Flags, Hardwareprofil und Gateway-Policy ein. Erzeugen Sie repräsentative Klassen: kurze interaktive Fragen, RAG-Fragen mit langem Kontext, strukturierte Extraktion und lange Generierung. Variieren Sie je Klasse angebotene Concurrency und Arrival Rate bis zum ersten SLO-Verstoß. Wiederholen Sie das mit Mischtraffic, denn wenige lange Prefill-Requests können kurze interaktive Requests stark beeinflussen. Erfassen Sie bei jedem Punkt p50/p95/p99, Abschlussgründe, Queue-Tiefe, KV-Cache-Nutzung, Preemptions und DCGM-Zustand.
Wiederholen Sie die Matrix nach jeder wesentlichen Änderung: Modell oder Quantisierung, Runtime-Upgrade, GPU-Partitionierung, Kontextlimit, Batching-Policy, Adapter-Set, Gateway-Timeout oder Routing-Policy. Das ist das Latenz- und Ausfallverhalten eines Release. Es ergänzt strukturierte LLM-Ausgaben als API-Vertrag: Zum Servicevertrag gehört nicht nur gültige Syntax. Speichern Sie Testgenerator bzw. Testeingaben, Konfigurationsmanifest und Resultate reproduzierbar.
Mit Error Budget Änderungen steuern
Ein SLO braucht einen Entscheidungsweg. Definieren Sie pro Traffic-Klasse eine monatliche Zielvorgabe: Ein festgelegter Anteil angenommener interaktiver Requests erfüllt TTFT- und Inter-Token-Ziel; eine eigene Zuverlässigkeitsvorgabe deckt serverseitige Fehler ab. Die verbleibenden zulässigen Verfehlungen bilden das Error Budget. Bei einem vorab festgelegten Verbrauch stoppen Sie nicht notwendiges Tuning, untersuchen die regressierte Phase und verlangen Canary plus Sättigungstest vor der Promotion. Zahlenwerte entstehen aus Geschäftstoleranz und gemessenen Verteilungen, nicht aus allgemeinen Blogwerten.
Verteilen Sie Ownership auf die Ebenen: Product legt Nutzerergebnis und Traffic-Klassen fest; Platform verantwortet Runtime und Node-Kapazität; SRE verantwortet Recording Rules, Alerts und Error-Budget-Policy; Security steuert Telemetriezugriff und Prompt-Redaktion; Application Owner verantworten Input-/Output-Grenzen. Das ergänzt Betriebsgrenzen für vernetzte KI-Workflows: Skalieren Sie erst, wenn Servicegrenze, Evidenz und ein sicherer Stopp- oder Rollback-Pfad benannt sind.
Ausfallmodi vorab üben
Durchschnitt maskiert Tail: Mittlere Latenz bleibt stabil, p99-TTFT scheitert für Long Context. Gegenmaßnahme: klassenbezogenes p95/p99 alarmieren und Histogramm-Buckets prüfen.
Blinde Cache-Sättigung: GPU-Dashboard wirkt normal, während KV-Cache, wartende Requests und Preemptions steigen. Gegenmaßnahme: Cache-/Scheduler-Gauges mit Queue-Zeit korrelieren; Kontext und Concurrency begrenzen.
Gateway-Verzögerung fehlt: Nur die Inferenzzeit wird gemessen. Gegenmaßnahme: Ab Gateway-Annahme bis erstem Byte/Token messen und mit Traces verbinden.
Nur Benchmark-Kapazität: Test verwendet kurze fixe Prompts bei einer Concurrency. Gegenmaßnahme: kontrollierte Workload-Matrix mit echten Verteilungen.
Unsicheres Tuning im Incident: Batching, Kontext und Modellflags ändern sich gleichzeitig. Gegenmaßnahme: eine Canary-Änderung, Rollback-Manifest und Error-Budget-Freeze.
GPU-Health-Blindheit: Applikationsmetriken gelten als Hardware-Beweis. Gegenmaßnahme: DCGM-Health, ECC/Xid und Temperatur/Power behalten sowie defekte Nodes kontrolliert aussteuern.
Was dieser Ansatz nicht löst
SLO-Instrumentierung macht ein Modell weder korrekt noch sicher oder rechtlich konform. Sie bestimmt nicht automatisch die passende Hardware, beseitigt Warteschlangen bei endlicher Kapazität oder macht eine schwache Workload-Mischung repräsentativ. Detailliertes Tracing kann Overhead erzeugen; zu viele Labels machen Telemetrie teuer und unzuverlässig. DCGM liefert Gerätesignale, aber keine Aussage über fachliche Nützlichkeit einer Antwort. Behandeln Sie Qualitätsevaluation, Security, Datenverarbeitung und rechtliche Pflichten als eigene Arbeitsstränge. Bei regulatorisch relevanter Verarbeitung oder Bereitstellung ist Rechtsberatung erforderlich; dieses Muster betrifft messbaren Servicebetrieb, keine Rechtsberatung.
Mit einem Service, einer Journey und einem Sättigungstest beginnen
Wählen Sie die wertvollste interaktive Route. Definieren Sie Request-Klassen, Gateway-basiertes TTFT- und Inter-Token-Ziel, Fehlersemantik, Owner und eine kurze Aufbewahrung für nicht-sensitive Telemetrie. Exportieren Sie vLLM- und DCGM-Signale, bauen Sie ein phasenorientiertes Dashboard und führen Sie den kontrollierten Sättigungstest vor dem nächsten Kapazitätskauf durch. Ein Architekturreview kann daraus Route-Policy, Dashboard-Spezifikation, Load-Test-Harness und Rollback-Plan für die reale Workload machen.
