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: zehn deprecatete Architekturen wurden entfernt — Arctic, Chameleon, Cheers, Fairseq2Llama, FireRedLID, GritLM, HCXVision, MPT — deren Checkpoints scheitern jetzt mit einem klaren Fehler, Model architecture X was supported in vLLM until v0.28.0, and is not supported anymore. Die anderen drei der zehn waren Registry-Aliasse, deren native Implementierungen unangetastet bleiben: RW lädt als Falcon, StableLMEpoch als StableLM, und PrithviGeoSpatialMAE wird von der generischen Terratorch-Architektur abgelöst, die die Prithvi-EO-Checkpoints bereits deklarieren — sie laden weiter. 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 ein Pflicht-Cache-Wechsel mit

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. Ein halbes Jahr Churn in einer einzigen Woche.

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}. Ein Produkt namens TensorRT-LLM ohne TensorRT ist der reinste Ausdruck der Churn-Steuer: Runbook-Name und Software sind auseinandergelaufen.

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 ¹⁰. Die meisten konsumieren TensorRT-LLM über gemanagte Endpunkte; der Self-Hoster zahlt die RC-Steuer direkt.

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 verheizte GPU-Stunden, 240 $ bei 2,50 $/GPU-h — der echte Schaden: Der Spitzenlast-Headroom ist still um ein Fünftel geschrumpft.

Die Absorptionskosten. vLLM liefert monatliche Minors, SGLang etwa vierzehntägig, TensorRT-LLM etwa monatlich einen belastbaren Checkpoint — grob 74 Release-Events pro Jahr, die es zu bewerten gilt. Bei zwei Ingenieurstagen pro ernsthaftem A/B: 148 Ingenieurtage, also 0,67 eines Vollzeit-Ingenieurjahrs (bei 220 Arbeitstagen) allein fürs Absorbieren des Upstream-Churns. Das ist die Churn-Steuer, in der einzigen Einheit, die zählt: der Aufmerksamkeit deines Teams.

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. Upgradiere sofort, wenn ein Release ein Security-Problem behebt (Request-Parsing, Datei-Laden, LoRA-Pfade) oder ein Modell hinzufügt, das du brauchst — die Kosten des Nicht-Upgradens übersteigen die Churn-Steuer per Konstruktion. 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. Drei bis sechs Monate Pin schlagen wöchentliches Gezerre bei allem außer Sicherheit.

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 74-Releases-pro-Jahr-Bewertungslast wird nicht kleiner, weil man sich das wünscht. Cloud-Anbieter verteilen die Absorption auf Tausende Tenants; ein Self-Hoster mit Pinning-Disziplin zahlt sie bewusst, in Fenstern, die er wählt.

Drei breaking Releases in zehn Tagen sind 2026s Normalzustand, nicht die Krise. 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.