Ein gestarteter vLLM-Server belegt, dass der Prozess läuft, das Modell geladen ist und der HTTP-Endpunkt antwortet. Mehr belegt dieser Test nicht. Ein Starttest reicht für die Produktionsfreigabe nie aus, weil kritische Fehler erst unter realistischer Parallelität und mit langen Kontexten auftreten. Die Freigabe braucht deshalb vorab festgelegte Grenzen für p99-Latenz, Fehlerrate, Ausgabequalität und erreichbare API-Pfade.
Projektinterne Release-Tests decken allgemeine Fehler ab, kennen aber weder deine GPU-Konfiguration noch die Prompt-Verteilung des produktiven Systems. Ein fairer A/B-Vergleich hält Hardware, Modellrevision, Lastprofil und Serverparameter konstant. Nur die vLLM-Version ändert sich. So lässt sich eine gemessene Abweichung dem Upgrade zuordnen.
Warum beweist ein gestarteter vLLM-Server kein erfolgreiches Upgrade?
Ein Prozessstart prüft weder Continuous Batching noch das Speicherverhalten unter Parallelität. Regressionen bei langen Kontexten, strukturierten Ausgaben und Tool-Aufrufen erscheinen oft erst während belasteter Testläufe. Deshalb entscheidet eine vorab verabschiedete Go/No-Go-Matrix über das Upgrade; der Health Check bleibt ein Verfügbarkeitstest.
| Gate | Messwerte | Go-Kriterium | Abbruchkriterium |
|---|---|---|---|
| Performance | TTFT, ITL, TPOT, Durchsatz | Die Abweichung zur Baseline bleibt innerhalb der freigegebenen Toleranz | p95 oder p99 verletzt das Service-Level-Ziel |
| Zuverlässigkeit | Fehler, Timeouts, Abbrüche, Neustarts | Die Fehlerrate bleibt innerhalb der definierten Toleranz | Der Server startet unter Last neu |
| Qualität | Referenzausgaben, JSON, Tool-Aufrufe | Alle verpflichtenden Testfälle bestehen | Ein vorgeschriebenes Schema oder ein Tool-Aufruf schlägt fehl |
| Zugriffsschutz | API-Pfade, Netzwerkzugriff, Entwicklungsfunktionen | Nur freigegebene Clients erreichen die vorgesehenen Endpunkte | Ein nicht autorisierter Zugriff erreicht einen geschützten Endpunkt |
Die Grenzwerte werden erst vergleichbar, wenn beide Versionen auf derselben technischen Baseline laufen.
Eine reproduzierbare Baseline erstellen
Zwei Messreihen lassen sich nur vergleichen, wenn das Manifest jede veränderliche Komponente festhält. Dazu gehören die vLLM-Version, die Modellrevision, der Tokenizer und die Quantisierungsmethode. Der Container-Image-Digest, die GPU- und CPU-Modelle, die Treiberversion sowie die CUDA-Version ergänzen die Laufzeitdaten. Ein Image-Tag wie latest reicht nicht, weil sein Inhalt zwischen zwei Läufen wechseln kann.
- Die Serverkonfiguration enthält
max_num_seqs,max_num_batched_tokensundmax_model_len - Das Manifest erfasst die GPU-Speichergrenze, Prefix Caching sowie Tensor- und Pipeline-Parallelität
- Das Rollback-Artefakt bündelt den Image-Digest, die Kubernetes-Manifeste oder Helm-Values, die Modellrevision und die Umgebungsvariablen
Ein separater Installationslauf im vorgesehenen Basis-Image deckt Paket-, ABI- und Treiberkonflikte auf, bevor der Lasttest beginnt. Das unveränderte Rollback-Artefakt bleibt während des gesamten Upgrades verfügbar. Hardware-Auswahl, Quantisierung und Rollback-Runbooks behandelt auch das Training LLM Self-Hosting and Deployment.
Nach der technischen Fixierung bildet das Lastprofil die Verteilung der produktiven Anfragen nach.
Realistische Lastprofile statt Demo-Prompts verwenden
Gateway- oder Inference-Logs liefern die Verteilungen von Prompt-Länge, Ausgabelänge, Anfragerate und Parallelität. Das Exportskript entfernt personenbezogene und vertrauliche Inhalte vor der Übernahme in den Testdatensatz. Mittelwerte reichen nicht aus, weil wenige lange Prompts den KV-Cache und die Warteschlange anders belasten als viele kurze Chat-Anfragen.
Interaktive Chats, Long-Context-Anfragen, Batch-Jobs sowie Tool- und Agentenaufrufe benötigen getrennte Profile, sobald unterschiedliche Service-Level-Ziele gelten. Beide vLLM-Versionen erhalten denselben Datensatz, denselben Request-Zeitplan und dieselbe Aufwärmphase. Identische Zufalls-Seeds reduzieren Abweichungen, garantieren bei paralleler GPU-Ausführung jedoch keine bytegleichen Ausgaben.
Auf dieser Lastbasis zeigen Latenz- und Durchsatzmetriken, ob der Upgrade-Kandidat die vereinbarten Grenzen einhält.
Die fünf wichtigsten Upgrade-Metriken messen
vllm bench serve misst Latenzen und Durchsatz gegen einen laufenden Server. Frei wählbare Perzentile erlauben den Vergleich von p50, p95 und p99 innerhalb derselben Messreihe. Der Ergebnisdatensatz hält auch die angebotene Last und die Zahl erfolgreicher Requests fest.
- Time to First Token (TTFT) misst die Zeit vom Request-Beginn bis zum ersten Token und umfasst Queueing sowie Prefill
- Time per Output Token (TPOT) und Inter-Token Latency (ITL) zeigen die mittlere Generierungszeit und Ausreißer zwischen aufeinanderfolgenden Tokens
- Request- und Token-Durchsatz vergleichen erfolgreiche Requests und ausgegebene Tokens pro Sekunde unter anhaltender Last
- End-to-End-Latenz erfasst die vollständige Antwortzeit bei p50, p95 und p99
- Zuverlässigkeit umfasst Fehler, Timeouts, Abbrüche, unvollständige Antworten und Server-Neustarts
Ein Durchsatzwert ohne zugehörige Fehlerrate ist unvollständig, weil abgewiesene Requests das Ergebnis künstlich verbessern können. Cache- und Queue-Metriken erklären anschließend, wodurch sich die gemessenen Perzentile verändern.
KV-Cache, Prefix Caching und Queues auswerten
Der Prometheus-kompatible Endpunkt /metrics liefert unter anderem laufende und wartende Requests, die KV-Cache-Auslastung sowie Latenzhistogramme. Ein hoher Cache-Füllstand ist allein kein Fehler. Steigen gleichzeitig Queue-Tiefe, p99-Latenz und Timeouts, begrenzt der verfügbare Speicher den getesteten Workload.
Prefix-Cache-Treffer sind nur aussagekräftig, wenn Requests wiederverwendbare System-Prompts oder Dokumentpräfixe enthalten. Kalte und aufgewärmte Läufe gehören deshalb in getrennte Messreihen. Da sich Namen und Labels einzelner Metriken zwischen Releases ändern können, wird das Dashboard gegen das tatsächlich getestete Container-Image validiert.
Zeigt die Telemetrie einen Engpass, kann eine kontrollierte Parameter-Matrix dessen Ursache von einem Versionsunterschied trennen.
Parameter-Sweeps mit wiederholten Lastläufen ausführen
Eine Sweep-Matrix variiert max_num_seqs, max_num_batched_tokens, Anfragerate und Parallelität. vllm bench serve führt jede Kombination gegen den jeweiligen Server aus. Ein CI-Skript versieht die Ergebnisse mit Versionsnummer, Konfigurations-Hash und Zeitstempel.
Hardware, Modellartefakte, Benchmark-Daten und alle nicht untersuchten Parameter bleiben konstant. Jede Kombination erhält dieselbe Zahl an Wiederholungen nach einer festgelegten Aufwärmphase. Ein Server-Neustart wird nicht als Ausreißer verworfen, sondern als Zuverlässigkeitsfehler gewertet.
Unter den Konfigurationen, die alle Latenz- und Fehlergrenzen einhalten, entscheidet der wiederholt gemessene Durchsatz. Die Ausgabequalität bleibt ein separates Gate.
Modellqualität und Tool-Aufrufe separat prüfen
Performance-Messungen erkennen keine semantischen Regressionen. Ein versionierter Evaluationssatz vergleicht repräsentative Antworten, strukturierte Ausgaben, Stop-Bedingungen und Streaming-Ereignisse. Tool-Tests prüfen den Funktionsnamen, die Argumente und die Übereinstimmung mit dem vorgegebenen JSON-Schema.
Zulässige Abweichungen und Abbruchkriterien stehen vor der Auswertung fest. Ungültiges JSON, zusätzliche Tokens nach einer Stop-Sequenz oder ein falscher Tool-Name führen unabhängig von der Latenz zum No-Go. Nutzt der Kandidat einen anderen Ausführungspfad oder neue Modellfunktionen, ergänzt ein modellspezifischer Test den allgemeinen Referenzsatz.
Nach den fachlichen Tests erfasst ein Endpunktinventar die Zugriffskontrolle des Servers.
API-Schlüssel, Endpunkte und Netzwerkzugriff prüfen
Die Option --api-key authentisiert Anfragen an die OpenAI-kompatible API, ersetzt aber keine vorgelagerte Zugriffskontrolle für jede Route des Servers. Ein Reverse Proxy beschränkt den Zugriff auf eine Positivliste. Firewall-Regeln oder Kubernetes NetworkPolicies lassen nur freigegebene Clients zum Dienst durch.
Das Endpunktinventar enthält jeden aktivierten Pfad und den erwarteten HTTP-Status für autorisierte sowie nicht autorisierte Zugriffe. VLLM_SERVER_DEV_MODE=1 bleibt in Produktion deaktiviert, weil dieser Modus zusätzliche Verwaltungsfunktionen freischalten kann. Ein Test aus einem nicht freigegebenen Netzwerksegment verifiziert, dass die Anfrage bereits vor dem vLLM-Server scheitert.
Die Prüfung deckt Infrastruktur- und Endpunktrisiken ab. Das Training LLM Security: Detecting and Defending Against Injections behandelt ergänzend Prompt Injection und Angriffe auf der Anwendungsebene.
Besteht der Kandidat diese Zugriffstests, übernimmt ein begrenzter Canary erstmals produktive Anfragen.
Canary-Rollout mit festen Rollback-Kriterien steuern
Der Canary erhält einen begrenzten Anteil des produktiven Traffics. Eine stabile Routing-Regel hält zusammengehörige Requests auf derselben Version, damit wechselnde Zuordnungen weder Cache-Verhalten noch Antwortvergleiche verfälschen. Das vLLM-Monitoring vergleicht TTFT, Inter-Token Latency, Fehlerraten, Queueing und Cache-Auslastung zwischen Baseline und Kandidat.
Jede Rollout-Stufe besitzt eine vorher definierte Beobachtungsdauer und eine Mindestzahl auswertbarer Requests. Der Traffic-Anteil steigt erst, wenn beide Bedingungen erfüllt sind. Eine Verletzung der festgelegten Latenz-, Zuverlässigkeits-, Qualitäts- oder Sicherheitsgrenze startet den Rollback auf das unveränderte Deployment-Artefakt.
Modellbereitstellung, Monitoring und Rollback werden im Themenbereich MLOps & Model Deployment vertieft.
Benchmark- und Canary-Daten ergeben gemeinsam den Datensatz für die endgültige Freigabe.
Go/No-Go-Checkliste für das Produktions-Upgrade
- Die p95- und p99-Latenzen liegen innerhalb der vorab freigegebenen Grenzwerte
- Der Request- und Token-Durchsatz bleibt innerhalb der definierten Toleranz
- Fehler, Timeouts und Abbrüche überschreiten keinen festgelegten Grenzwert
- Modellqualität, strukturierte Ausgaben und Tool-Aufrufe bestehen ihre Testfälle
- API-Pfade, Netzwerkzugriffe und Entwicklungsfunktionen entsprechen dem Endpunktinventar
- Prometheus-Metriken, Canary-Steuerung und automatisierter Rollback sind aktiv
- Die Entscheidung dokumentiert die Konfiguration, Messdaten, Artefakte und bekannten Ausnahmen
Das vLLM Training: Deploy Open-Source LLMs behandelt vLLM Serve, Continuous Batching, GPU-Speicher, KV-Cache, Multi-GPU-Inferenz sowie die Messung von TTFT, Inter-Token Latency und Tokens pro Sekunde.
Der vollständige Freigabedatensatz zeigt, welches Gate bestanden wurde und welches Messergebnis einen Rollback auslöst.
Fazit: Die Freigabe beginnt vor dem Upgrade
Eine vLLM-Produktionsfreigabe ist prüfbar, wenn Versionsartefakte, Workload-Profile, Perzentile, Qualitätstests und Zugriffskontrollen gemeinsam dokumentiert sind. Lege für den nächsten Upgrade-Kandidaten vor der Installation die Baseline, jedes Gate und alle Abbruchkriterien schriftlich fest.