vLLM 0.33.0 ohne CUDA 12.9: Was der Wegfall der cu129-Images für den Eigenbetrieb heißt
Am 2. November hat vLLM die Version 0.33.0 veröffentlicht, 927 Commits von 389 Mitwirkenden, 122 davon neu. Für Betreiber gemischter Hallen wiegt ein Punkt der Release-Notes mehr als jede Tempo-Meldung: Die Release-Räder und -Images sind CUDA-13.0-only, die CUDA-12.9-Räder und die -cu129-Image-Tags erscheinen nicht mehr (#62575). Ende September war cu129 noch ein Überbrückungs-Tag neben dem CUDA-13-Standardbau, wie wir im Beitrag zu vLLM 0.30 und llama.cpp 0.5 beschrieben haben. Diese Überbrückung ist jetzt weg. Wann Tag, Image und Release-Notes von 0.33.0 erschienen, haben wir im Beitrag vLLM v0.33.0 und llama.cpp b12033 nachgemessen. Hier geht es um etwas anderes: was der Wegfall von cu129 für Treiber und Betrieb bedeutet.
Was heißt cu129? Ein cu129-Image ist ein vLLM-Containerbild, das gegen CUDA 12.9 gebaut ist; nach NVIDIAs Tabelle genügt dafür ein Treiber ab R525. Ab vLLM 0.33.0 veröffentlicht das Projekt nur noch CUDA-13.0-Artefakte, und CUDA 13.x verlangt laut NVIDIA mindestens Treiber R580. Wer bisher mit einem Treiber zwischen 525 und 579 gefahren ist, muss ihn vor dem Update des Images wechseln.
Was mit cu129 verschwindet
Der Pull Request #62575 wurde am 20. Oktober gemerged. Er entfernt aus der Release-Pipeline die Räder und Images für CUDA 12.9, inklusive der Ubuntu-24.04-Variante. Weitere Punkte aus den Release-Notes: PyTorch 2.14.0 mit torchvision 0.29.0 und Triton 3.8.0 (#52183), ein mit libtorch ABI-stabiles CUDA-Rad, und ROCm 10.0 als Standard-ROCm-Image, ROCm 7.2 bleibt als -rocm72 (#58761). Jedes Release-Image gibt es außerdem unter dem kürzeren Namen vllm/vllm, etwa vllm/vllm:v0.33.0.
Welcher Treiber reicht
Die Frage lässt sich in einer Minute beantworten: nvidia-smi zeigt die Treiberversion. Die NVIDIA-Doku zur Minor-Version-Kompatibilität nennt in ihrer Tabelle für CUDA 13.x einen Treiber ab 580, für CUDA 12.x einen ab 525. Treiber 525 bis 579 bedienen also CUDA-12-Images, aber keine CUDA-13-Anwendungen. Ein Ubuntu-24.04-Host mit dem Paket nvidia-driver-550 konnte die cu129-Images starten. Ab 0.33.0 braucht er einen neueren Treiber oder die Forward-Compatibility-Pakete. Diese beschreibt NVIDIA in der Forward-Compatibility-Doku für Data-Center-GPUs, ausgewählte Server-Ready-RTX-Modelle und Jetson. Ob sie auf Karten wie der RTX 5090 funktionieren, haben wir nicht ausprobiert.
Was sich im Release sonst ändert
Die Release-Notes führen unter „Breaking changes“ auf:
- Medusa und der MLP-Spekulator sind entfernt (#61701). EAGLE, MTP und die DFlash-/DSpark-Drafter bleiben laut PR-Beschreibung erhalten.
- Der alte Ray-Compiled-Graph-Executor ist entfernt,
RayExecutorV2ist der einzige Ray-Executor (#61712). - Der NIXL-Connector braucht NIXL 1.5 oder neuer (#61032). Wie sich ein älteres NIXL beim Start verhält, haben wir nicht geprüft.
- Anfragen, die während einer Generierungspause eintreffen, bekommen HTTP 503.
--mamba-cache-mode, LM Format Enforcer und--ir-op-prioritysind als veraltet markiert.
Im Rust-Frontend (vllm-rs) schlugen lange Unterhaltungen mit HTTP 500 fehl, obwohl der Prompt weit unter der Kontextlänge lag. Ursache war ein fest verdrahtetes MiniJinja-Budget von 500.000 Instruktionen je Rendervorgang. Laut Beschreibung des Pull Requests (er verweist auf den Fehlerbericht #62598) scheiterte eine GLM-5.3-Agentensitzung mit 1.730 Nachrichten und 21.000 Tokens, etwa 2 Prozent des Eine-Million-Kontexts (#62374). Seit 0.33.0 rendert der Server sein eigenes Template ohne Budget, wie das Python-Frontend. Das Budget gilt nur noch für Templates aus der Anfrage, die jetzt --trust-request-chat-template brauchen, und lässt sich über VLLM_CHAT_TEMPLATE_FUEL ändern. Wer vllm-rs testweise fährt, probiert vor einem Produktivtausch beide Pfade mit langen Sitzungen aus.
Zur Geschwindigkeit nennen die Notes Zahlen aus den Pull Requests, die wir nicht nachgemessen haben. DFlash und DSpark reservieren keine Entwurfsplätze mehr im Token-Budget; im Benchmark des PR steigt der Durchsatz für DeepSeek-V4.1-Flash mit DSpark auf einer GB300 bei --max-num-batched-tokens 512 von 1373 auf 3390 Ausgabe-Tokens pro Sekunde (#59468). Der verlustbehaftete FLy-Verifizierer ist optional und kommt laut Notes auf das 1,04- bis 1,31-Fache beim Decodieren (MI355X und B300, #53987). Laut Release-Notes neu standardmäßig an sind Lookahead-Blockhashes, damit EAGLE- und MTP-Treffer im Präfix-Cache den letzten Block behalten (#61589). Zum Cache selbst haben wir zwei vLLM-Sicherheitshinweise zum Präfix-Cache eingeordnet.
Als neue Modelle führen die Notes unter anderem Reflection Beam-1.0 (501B MoE, 23B aktiv) mit DFlash2-Drafter (#62074), Yandex AliceAI-Foundation-80B-A3B, NVIDIA Alpamayo 2 Super und Recursive Flint (40B MoE, 2,5B aktiv) mit BF16- und NVFP4-GGUF-Checkpoints (#62938). Gemessen haben wir keines davon.
Unsere Lane
Die Tabelle zeigt den Stand der Produktiv-Lane auf .180.3 (4× RTX 5090, EPYC 8024P). Es sind Werte aus unseren Messprotokollen, keine neue Messung für diesen Beitrag.
| Was | Wert | Quelle und Datum | Reicht für 0.33.0? |
|---|---|---|---|
| NVIDIA-Treiber | 615.71.09 | .180.3, Messprotokoll vom 4.11.2026 | ja, über R580 |
| vLLM im Container | 0.32.0 plus unser NVFP4-Port | Notiz vom 18.10.2026 | Rebuild nötig |
| CUDA-Runtime im Image | 13.0.88 (cudart) | Inspect eines älteren Lane-Images vom 14.9.2026, für 0.32 nicht neu geprüft | ja, CUDA 13.0 |
| Arbeitsspeicher | 6 × 16 GB DDR5-4800 | .180.3, Messprotokoll vom 4.11.2026 | nicht relevant |
Die cu129-Änderung trifft diese Lane deshalb nicht: Treiber und Image-Basis liegen schon bei CUDA 13. Offen ist der Rebuild. Das Image enthält unseren Port des NVFP4-KV-Caches aus einem noch offenen Pull Request (#54846), beschrieben im Beitrag zu Flash-Next auf vLLM 0.32. Ob das Image weitere Patches trägt, belegt dieser Beitrag nicht. Das P2P-gepatchte NVIDIA-Kernelmodul setzt ein Kernel-Update still zurück, danach zeigt nvidia-smi topo -p2p r wieder GNS. Ob und wann wir auf 0.33.0 gehen, ist nicht entschieden.
Was Betreiber jetzt tun
nvidia-smiauf jedem vLLM-Host: Treiber unter 580 heißt Treiberwechsel im Update-Fenster, dann erst das Image ziehen.- Wer eigene Distributions- oder Hersteller-Images statt der vLLM-Räder nutzt, prüft deren CUDA-Basis. Sie ist nicht automatisch 13.0.
- Wer Medusa-Drafter, den alten Ray-Executor oder ein älteres NIXL im Einsatz hat, liest vorher die Liste oben.
- Einen ersten Überblick zu Speculative Decoding gibt KI-Inferenz beschleunigen. Weitere Texte zur Hardware stehen im Hub lokale KI-Hardware. Wer eine eigene Inferenz-Umgebung plant, findet unser Angebot unter Corporate LLM.
Muss ich wegen vLLM 0.33.0 meinen NVIDIA-Treiber tauschen?+
Nur wenn er unter R580 liegt. Laut NVIDIA-Doku zur Minor-Version-Kompatibilität (abgerufen am 5. November 2026) laufen CUDA-13.x-Anwendungen ab Treiber 580. Die cu129-Images liefen mit Treibern ab 525, sie gibt es ab 0.33.0 nicht mehr. Ein Host mit Treiber 550, wie ihn Ubuntu 24.04 in den Paketquellen führt, braucht für das neue Image einen Treiberwechsel.
Warum steht auf der Release-Seite v0.33.0rc3 statt v0.33.0?+
Die GitHub-Veröffentlichung vom 2. November 2026 trägt den Namen v0.33.0, hängt aber am Tag v0.33.0rc3. Der Tag v0.33.0 existiert ebenfalls und zeigt auf denselben Commit 4ba787e (geprüft am 5. November 2026 per git ls-remote). Auch das Docker-Hub-Image vllm/vllm:v0.33.0 gibt es, zuletzt gepusht am 2. November.
Zieht eure Produktiv-Lane auf 0.33.0 nach?+
Entschieden ist das nicht. Der Treiber 615.71.09 auf .180.3 liegt über der Untergrenze. Offen sind der Rebuild unseres Images mit dem eigenen Patch (NVFP4-KV-Cache-Port) und das P2P-gepatchte Kernelmodul, das ein Kernel-Update still zurücksetzt.
senn-tech