Die Churn-Steuer 2026 für Serving-Engines: vLLM 0.29, SGLang 0.5.19 und TensorRT-LLM ohne TensorRT

Wer 2026 eine Serving-Engine selbst hostet, betreibt einen Stack, der sich wöchentlich verändert. Allein in den ersten Septembertagen lieferten alle drei großen Engines Releases, die ein Produktions-Deployment brechen können: SGLang 0.5.19 am 5. September, vLLM 0.29.0 und NVIDIAs TensorRT-LLM v1.3.0rc26 am 9. September — Teil einer RC-Linie, die seit Ende Juni etwa alle ein bis zwei Wochen ausliefert ^{1 2 3}.

Das ist keine Klage über Tempo — die Releases stecken voller echter Verbesserungen. Es ist eine Kostenrechnung: Pins, die gepflegt werden müssen, Migrationen, die getestet werden müssen, Regressionen, die sich nie in einem Changelog ankündigen. Dieser Guide verifiziert die drei Releases an ihren Primärquellen, berechnet die Kosten eines schiefgegangenen Upgrades und liefert eine Pinning-Disziplin, die das Tempo überlebt. Die Engine-Auswahl behandelt der vLLM-vs-SGLang-Vergleich.

Die drei Releases im Überblick

vLLM 0.29.0: ein neuer Default-Runner, und der alte läuft auf Timer

vLLM 0.29.0 (9. September 2026) macht Model Runner V2 zum Default für alle Modelle und nennt die Konsequenz im selben Atemzug: Model Runner V1 ist deprecated, die Entfernung für v0.32 anvisiert ².

Der operativ gefährliche Teil, sinngemäß aus den Release Notes: Manche Features sind in MRV2 noch nicht unterstützt, und vLLM fällt still auf MRV1 zurück, sobald sie konfiguriert sind. Namentliche Lücken: Sequence Parallelism, Dual-Batch Overlap, Elastic Expert Parallelism, eigene Logits-Prozessoren, bestimmte Speculative-Decoding-Methoden ². Konfiguration und Modell ändern sich nicht — wohl aber der Codepfad, den dein Traffic nimmt, entschieden beim Start anhand deiner Flags; einziges Symptom eine absinkende Throughput-Zahl. Der Lehrbuchfall für seine Konfiguration statt den Release-Blog.

Eine zweite harte Grenze: Veraltete Architektur-Einträge wurden entfernt, darunter Arctic, Chameleon, Cheers, Fairseq2Llama, FireRedLID, GritLM, HCXVision und MPT. Checkpoints, die noch eine dieser nicht unterstützten Architekturen deklarieren, scheitern mit einer entsprechenden Fehlermeldung. Die Release Notes nennen außerdem die Aliasse RWForCausalLM und StableLMEpochForCausalLM sowie PrithviGeoSpatialMAE (durch Terratorch ersetzt). Sie sprechen von „zehn“, zählen aber elf Namen auf; für eine Migration zählt deshalb die tatsächlich deklarierte Checkpoint-Architektur. Auch der PyAV-Video-Decoder-Backend ging, hin zu OpenCV oder Torchcodec ². FlashInfer-Allreduce ist für TP-CUDA-Gruppen jetzt default an ² — ein „Engine-Upgrade" ist damit eine Wette, dass ein Dutzend Flags noch gleich zusammenspielen. Der MRV1-zu-MRV2-Übergang ist eine Verhaltensänderung im Gewand einer Versionsänderung: Wer Sequence Parallelism oder Dual-Batch Overlap in Produktion nutzt, plant mit v0.32 eine Migration — kein Upgrade.

SGLang 0.5.19: Beam Search kommt, und der Cache-Default ändert sich

SGLang v0.5.19 (5. September 2026) bringt 786 gemergte Pull Requests von 214 Contributorn ¹.

Die Schlagzeile ist Beam Search: beam_width im Request mitgeben, und statt eines Samples bekommst du die n besten Sequenzen ¹. Im selben Satz steht der Vorbehalt: kombinierbar noch nicht mit Speculative Decoding, Prefill/Decode-Disaggregation, DP Attention oder HiCache ¹. Nutzt dein Stack eines davon, ist das Feature für dich nicht verfügbar — „das Release hat Feature X" und „Feature X erreicht mein Deployment" sind verschiedene Aussagen.

Der Churn steckt im Breaking-Changes-Abschnitt. Der Unified Radix Tree ist jetzt Default-Cache für jede Konfiguration, sein Opt-in-Env-Var deprecated — ein Austausch der Kerndatenstruktur des KV-Caches (Hintergrund: unser KV-Cache-Deep-Dive) als Nebenwirkung eines Minor-Bumps. Weiter: Spark3 heißt jetzt Spark2.5 — in Config, Modellklassen und Tool-Call-Parser; FlashInfer 0.6.18 ist harte Anforderung, ohne Fallback auf zwei Pfaden; ServerArgs resolved sich nicht mehr selbst (resolve_once() aufrufen); Requests auf 32 Stop-Strings à 256 Bytes begrenzt, darüber HTTP 400 ¹. Seit diesem Release ist bereits v0.5.20 (18. September) gelandet: 713 PRs von 237 Contributorn, und seine Breaking Changes beißen härter als die von 0.5.19 — CUDA-12-Wheels und -Images werden eingestellt (0.5.19 ist das letzte CUDA-12-Release; pinne es, falls CUDA 13 noch nicht in Frage kommt), Prefill-Context-Parallelism v1 ist entfernt, und die Persistenz von /v1/responses ist jetzt Opt-in. Diese September-Releases erfordern gezielte Kompatibilitätsprüfungen.

TensorRT-LLM: „ohne TensorRT" — aber nicht dort, wo man es dir erzählt hat

Hier zahlt sich Verifikation aus. Die kursierende Behauptung lautet: „TensorRT-LLM 1.2 entfernt das TensorRT-Backend." Die Primärquellen sagen: falsch bei der Version. Das stabile v1.2.0 (12. März 2026) lieferte weiterhin beide Backends aus ⁴.

Die Entfernung lebt in der v1.3.0-RC-Linie (~1 RC alle 10 Tage seit Juli) ^{5 3}: rc21 (15. Juli) entfernte die Python-Module und Tests des Legacy-Backends; rc22 entfernte die C++-Module (rc23 räumte die Überreste und Docs auf). Aktuell: LLM(backend="tensorrt") löst einen ValueError aus; die CLIs trtllm-build / trtllm-refit / trtllm-prune, die convert_checkpoint.py-Skripte und --backend tensorrt sind weg; PyTorch ist das einzige Ausführungs-Backend — HuggingFace-Checkpoints laden direkt, ohne Engine-Build ^{6 7}. Der Produktname bleibt, während dieses alte Ausführungs-Backend entfernt wird; Migrationsanleitungen und Runbooks müssen die Release-Linie benennen.

Die zweite strukturelle Änderung ist der KV-Cache-Manager V2, die empfohlene Architektur laut Release Notes — neue Modelle defaulten auf V2, bestehende migrieren schrittweise, V1 wird deprecated ⁸. Speicherseitig keine kosmetische Neuschreibung: KVCM2 kodiert verdrängte Seiten in einen fixgroßen, opaken Cold-Page-Blob (Hot/Cold-Tieraufteilung) — eine I/O-Operation pro Cold Page statt pro Hot Pool, optionale Kompression (NVFP4), Hot-zu-Host- und Hot-zu-Disk-Migrationen ⁹ — ein zweites Subsystem, dessen Defaults mitten im Jahr kippten.

Die Zwickmühle für Self-Hoster: Auf v1.2.0 pinnen heißt, ein März-Release zu betreiben, während die RC-Linie zwei Subsystem-Rewrites weiter ist; auf v1.3.0rc28 (23. September) heraufjagen heißt, Release Candidates in Produktion zu fahren — Known-Issues: Startup-Fehler im Disaggregated Serving, TinyLlama-Batch-Isolation-Bug ¹⁰. Self-Hoster müssen das ältere stabile Release gegen Risiken und Korrekturen der RC-Linie abwägen.

Die Churn-Steuer, nachgerechnet

Nimm einen bescheidenen Aufbau: ein Endpoint mit 99,9%-SLO. Ein 30-Tage-Monat hat 43.200 Minuten, das Fehlerbudget 0,1% davon: 43,2 Minuten pro Monat — der ganze Spielraum für einen verhexen Upgrade-Versuch.

Ein schiefgegangenes Upgrade. 10 Minuten Erkennung, 15 Minuten Rollback (Image gepinnt — Neustart mit altem Digest), 8 Minuten Warmup mit leerem KV-Cache. Summe: 33 Minuten, also 76,4% des Monatsbudgets. Zwei Vorfälle im Monat: 66 Minuten, 152,8% des Budgets — das SLO ist rechnerisch gerissen (erreichte 99,847%), bevor irgendein fremder Ausfall dazukommt.

Der Fall der stillen Regression. Die 33 Minuten sind der laute Fehler. Der teure ist leise: vLLMs MRV1-Fallback heißt, dass eine Konfiguration mit Dual-Batch Overlap still den Ausführungspfad wechseln kann. 20% weniger Throughput auf 4 GPUs, fünf Tage unbemerkt: 4 GPUs × 120 h × 20% = 96 GPU-Stunden verlorene Durchsatzkapazität, bei 2,50 $/GPU-h rechnerisch 240 $ Kapazitätswert — der echte Schaden: Der Spitzenlast-Headroom ist still um ein Fünftel geschrumpft.

Die Absorptionskosten. Angenommen, ein Team bewertet jährlich 12 vLLM-, 26 SGLang- und 12 TensorRT-LLM-Releases: Das sind 50 Kandidaten. Bei angenommenen zwei Ingenieurtagen pro vollständigem A/B würde das Testen aller Kandidaten 100 Ingenieurtage beanspruchen, also 0,45 eines 220-Tage-Ingenieurjahrs. Das sind Planungsannahmen, keine gemessene Release-Zahl für 2026; Teams können Releases vorab aussortieren.

Was du wirklich pinnen musst

Der naive Pin lautet „Engine-Version + Weights-Hash." Er reicht nicht: Ein Weights-Hash pinnt nichts ohne einen Runtime-Hash. Dasselbe Checkpoint unter vLLM 0.29s MRV2 und 0.28s MRV1 nimmt verschiedene Codepfade; dasselbe Modell unter TensorRT-LLMs KVCM V1 und V2 zeigt anderes Tiering- und Eviction-Verhalten. Die vollständige Pin-Fläche für ein reproduzierbares Deployment:

1. Image-Digest — die unveränderliche sha256:-Referenz, nicht der Tag.
2. Engine-Version — redundant beim Digest, nützlich im Incident-Report.
3. Flags und Config — Env-Vars wie VLLM_ATTENTION_BACKEND ändern das Verhalten je Engine-Version (MRV1-Fallback!); Config allein pinnt nichts.
4. Weights-Hash — Checksumme committen; eine floating Revision mit anderer Quantisierung ist nicht das Artefakt, das du gebenchmarkt hast.
5. Kernel-/Abhängigkeits-Pins — SGLang 0.5.19 verlangt FlashInfer 0.6.18, ohne Fallback ¹.
6. Eval-Baselines — Golden Outputs zum Diffen, damit „gleiche Weights, neue Engine" auf Verhalten getestet wird, nicht nur auf Throughput.

Sechs Artefakte, nicht zwei — jedes Release berührt eine Teilmenge.

Pinne den Digest, nicht den Tag. Tags sind veränderlich: vllm/vllm-openai:v0.29.0 kann neu gepusht werden; latest driften mitten im Deploy. Pinne die unveränderliche Form:

image: vllm/vllm-openai@sha256:<digest>   # what you deploy

Digest einmal abrufen (docker inspect --format '{{index .RepoDigests 0}}' oder crane digest), ins Manifest legen, jede Änderung wie einen Version-Bump behandeln: Changelog, Canary, Rollback-Plan.

Upgraden oder einfrieren? Ein Entscheidungsrahmen

Die richtige Haltung ist asymmetrisch: schnell bei Sicherheit und Modell-Support, langsam bei Performance. Priorisiere Sicherheitskorrekturen nach Schweregrad und eigener Exposition sowie benötigten Modell-Support. Teste den Kandidaten und deploye ihn nach einem zum Risiko passenden Zeitplan. Friere bewusst ein, wenn du in Produktion servst und die Notes keines von beidem enthalten: Deine Engine-Wahl fiel mit Benchmarks, die für die gepinnte Version galten; nichts Upstream verbessert deine deployte Realität ohne Neu-Messen auf deiner Hardware — denselben Punkt macht der vLLM-vs-SGLang-Guide bei der Auswahl. Wähle den Prüfzyklus nach Support- und Sicherheitsanforderungen.

A/B-Teste eine Runtime mit denselben Weights — die Kernkompetenz dieses Tempos, MRV2 als durchgerechnetes Beispiel:

1. Kandidaten auf derselben Node-Klasse, demselben Weights-Digest, denselben Flags hochfahren.
2. Aufgezeichneten Traffic oder ein fixes Benchmark-Skript mit gepinnten Seeds abspielen — die Release Notes wurden auf den Traces anderer validiert.
3. Latenzverteilung (p50/p99), Throughput bei realer Concurrency und Output-Äquivalenz diffen — eine Scheduler- oder Sampling-Änderung kann Generationen verändern, ohne dass irgendwo ein Fehler steht.
4. Prüfe, welcher Runner lief: bei vLLM 0.29.0 in den Logs bestätigen, ob MRV1 still zugeschlagen hat ². Falls ja, hat dein A/B den alten Runner gemessen — und sagt nichts über den Pfad nach v0.32.

Promote nur bei bestandenem Gesamtbild, halte den alten Digest warm für sofortiges Rollback, und plane die 33 Minuten Recovery ins Fenster ein.

Die kritische Sicht

Release-Blog-Benchmarks sind handverlesene Kernel, nicht dein End-to-End. vLLMs Notes zitieren Kernel-Speedups (6,6–7,6× beim Mamba-Metadata-Kernel, 12,9–25,2% auf einem GEMM-Pfad); SGLang bis zu 1,52× Decode-Throughput für einen konkreten AMD-Kernel auf konkreter Hardware ^{2 1}. Ehrlich in ihrer Scope-Angabe — aber Einzelkernel-Messungen auf herstellernaher Hardware, während deine Rechnung End-to-End-Tokens pro Sekunde auf deiner Flotte ist. Der einzige Benchmark, der zählt, ist deiner.

„Nimm default vLLM" ist jetzt eine bewegte Zielgröße. „vLLM" im Sinne dessen, was deine Flags tun, änderte sich am 9. September — MRV2 als Default samt Feature-Fallback-Regeln — und ändert sich erneut bis v0.32, wenn MRV1 entfernt wird. Jeder Guide ist eine Aussage über ein Versionsfenster.

Release-Kadenz als Strategie, ehrlich gelesen. Der Engine-Krieg nützt Nutzern in der Aggregatsrechnung: Features erreichen alle in Wochen statt Quartalen. Aber Aggregatsnutzen und Einzelkosten sind verschiedene Bücher. Den Nutzen einzustreichen erfordert, die Upgrades zu absorbieren — und die beispielhafte Warteschlange von 50 Kandidaten pro Jahr braucht dennoch Triage. Cloud-Anbieter verteilen die Absorption auf Tausende Tenants; ein Self-Hoster mit Pinning-Disziplin zahlt sie bewusst, in Fenstern, die er wählt.

Diese drei September-Releases zeigen, warum versionsspezifische Kompatibilitätsprüfungen nötig sind. Die Krise ist, diesen Stack zu betreiben, als gelte noch das Tempo von 2024: ungepinnte Images, „Engine-Version + Weights", als würde das irgendetwas pinnen, Benchmarking als einmalige Handlung. Der überlebende Stack pinnt den Digest, inventarisiert seine sechs Artefakte und behandelt jedes Upgrade als A/B mit Rollback-Pfad. Die Engine wählst du mit dem Architektur-Vergleich; wer über llama.cpp/Ollama kam, zahlt hier die Steuer fürs Verlassen von ollama serve. Und vor dem GPU-Budget: Self-Hosting-Mathematik rechnen.