vLLM 0.33 verlangt CUDA 13: der Upgrade-Plan für Treiber, Image und Clients

/01Was am 2. November erschienen ist

Das Projekt vLLM hat Version 0.33.0 veröffentlicht. Der Git-Tag trägt den Zeitstempel 1. November 2026, 09:21 UTC; die Release Notes und das Paket auf PyPI folgten am 2. November. Die Notes zählen 927 Commits von 389 Beitragenden. Der Satz, der für den Betrieb zählt, steht unter den Highlights: „release wheels and images are CUDA 13.0 only“. Die Wheels für CUDA 12.9 und die Images mit den Endungen -cu129 und -cu129-ubuntu2404 werden nicht mehr veröffentlicht (Pull Request #62575).

Am selben 2. November hat das Projekt das Advisory GHSA-qrj2-j723-m6w8 veröffentlicht. Betroffen sind alle Versionen vor 0.33.0, behoben ist der Fehler in 0.33.0. Damit ist die bequeme Trennung der letzten Wochen hinfällig: Version 0.32 war nicht „das Sicherheitsupdate“ und 0.33 „nur der Treiberwechsel“. Auch 0.33.0 ist ein Sicherheitsupdate – und der einzige Weg dorthin führt über CUDA 13.0.

Eine Kleinigkeit kostet beim Nachlesen Zeit: Die ausführlichen Release Notes mit dem Titel „v0.33.0“ hängen bei GitHub am Tag v0.33.0rc3. Die Seite zum Tag v0.33.0 enthält nur eine Titelzeile. Wer Release Notes per Skript einsammelt, sieht für 0.33.0 deshalb einen leeren Eintrag und übersieht die Bruchstellen.

Stand 11. November 2026 gibt es weder ein 0.33.1 noch ein fertiges 0.34.0; veröffentlicht ist nur der Vorabstand v0.34.0rc0 vom 8. November. Bezugsversion dieses Artikels ist 0.33.0. Was Version 0.32 gebracht hat – CORS-Vorgaben, drei Advisories, das Ende von Python 3.10 –, steht in vLLM 0.32: Sicherheitsupdate, CORS und Pickle; hier geht es um den Schritt danach.

/02Wen der CUDA-Bruch trifft und wen nicht

Der Bruch trifft weniger Häuser, als die Überschrift vermuten lässt. Schon in Version 0.32.0 war CUDA 13.0 der Standard: Das Image vllm/vllm-openai:v0.32.0 und das Paket auf PyPI waren dafür gebaut. CUDA 12.9 lief als zweite Schiene daneben – mit eigenen Wheels und den Images v0.32.0-cu129 und v0.32.0-cu129-ubuntu2404. Diese zweite Schiene ist mit 0.33.0 abgeschnitten. Neu ist also nicht CUDA 13.0, neu ist das Ende der Ausweichmöglichkeit.

Zur AMD-Zeile gehört eine Klarstellung, weil sie in Kurzmeldungen oft falsch steht. ROCm 10.0 ist ab 0.33.0 der Standard für Image und Wheels, ROCm 7.2 wird laut Release Notes weiter veröffentlicht, als Image vllm/vllm-openai-rocm:v0.33.0-rocm72 und über einen eigenen Wheel-Index (#58761). Hart gebrochen ist nur CUDA 12.9. Wer auf AMD-Karten ein Tag ohne Versionszusatz zieht, bekommt allerdings beim nächsten Pull stillschweigend ROCm 10.0 – ein weiterer Grund, Image-Tags festzuschreiben.

Eine offene Stelle bleibt. Die Artefakt-Tabelle der Release Notes führt für CUDA nur noch zwei Images auf: den Standard und eine Variante -efa für AWS. Ein Tag -ubuntu2404, das es bei 0.32.0 für CUDA 13.0 gab, nennt sie nicht mehr. Ob es entfallen oder im Standard aufgegangen ist, sagen die Notes nicht. Wer dieses Tag in einer Compose-Datei stehen hat, prüft vor dem Wartungsfenster, ob es sich für 0.33.0 ziehen lässt.

/03Warum Abwarten auf 0.32 keine Option ist

Das Advisory GHSA-qrj2-j723-m6w8 beschreibt einen Fehler beim Laden von Modellen, die Metadaten für Speculative Decoding mitbringen. In der Speculators-Konfiguration eines Repositories steht ein Feld verifier.name_or_path. Bis einschließlich 0.32 folgte vLLM diesem Feld auch dann, wenn es auf ein lokales Verzeichnis des Servers zeigte. Ein präpariertes Repository konnte so laut Advisory die gesamte Identität des ausgelieferten Modells auf ein anderes Verzeichnis umlenken: Geladen wird dann der dort liegende Checkpoint, und der Angreifer erhält über die Schnittstelle unter anderem das Vokabular des fremden Tokenizers. Das Advisory formuliert es so: Der Betreiber liefere „silently … someone else's weights under their own service“ aus.

Die Eckdaten laut GitHub-Advisory des vLLM-Projekts: Einstufung Moderate, CVSS 3.1 mit 5.4 (Vektor AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N), Schwachstellenklassen CWE-22 und CWE-200, keine CVE-Nummer („No known CVE“). Die Bedingung „UI:R“ steht für den Betreiber selbst: Er muss ein nicht vertrauenswürdiges Repository laden, etwa ein öffentliches Modell von Hugging Face. Eine besondere Option muss dafür nicht gesetzt sein, das Advisory schreibt „No opt-in is required“. Als besonders gefährdet nennt es geteilte Modell-Hosts mit mehreren Mandanten.

Für die Planung zählen zwei Befunde. Das Advisory enthält keinen Abschnitt mit Übergangsmaßnahmen; als Abhilfe nennt es nur den Fix aus Pull Request #61587, also Version 0.33.0. Und ein korrigiertes 0.32.x existiert nicht: Im Release-Feed steht für die 0.32-Linie lediglich ein Vorabstand v0.32.1rc0 vom 18. Oktober, zwei Wochen vor dem Advisory. Wer auf 0.32 bleibt, weil der Hosttreiber CUDA 13.0 nicht trägt, betreibt damit eine Version mit bekannter, öffentlich beschriebener Lücke.

Ehrlich: Ein Haus, das zwei oder drei fest ausgewählte Modelle aus einem geprüften lokalen Verzeichnis lädt, ist von diesem Fehler weit weniger bedroht als ein Dienst, der beliebige Hub-Repositories auf Zuruf startet. Bis zum Upgrade hilft – als unsere Einordnung, nicht als Empfehlung des Projekts – eine einfache Regel: nur Modelle starten, deren Konfigurationsdateien jemand gelesen hat, und in der Speculators-Konfiguration kein name_or_path dulden, das auf einen lokalen Pfad zeigt.

Die Release Notes führen unter „Security“ weitere Punkte auf, ohne Advisory-Kennung: Budgets je Anfrage für heruntergeladene und dekodierte Medien-Bytes bei multimodalen Eingaben (#61226), ein aktualisiertes Zertifikatsbündel über certifi>=2026.10.19 (#62868) und höhere Mindestversionen für aiohttp, Pillow, MCP und multidict (#62835). Das sind keine Schlagzeilen, aber vier Bibliotheken, die an der Netzwerkkante des Servers arbeiten.

/04Treiber, CUDA 13 und PyTorch 2.14: die Reihenfolge

Auf einem Server mit NVIDIA-Karten gibt es zwei Ebenen, die oft verwechselt werden. Die CUDA-Bibliotheken stecken im Image oder kommen als Abhängigkeit der PyTorch-Wheels mit. Der Treiber dagegen gehört zum Host und wird vom Container nur mitbenutzt. Entscheidend für den Schritt auf 0.33.0 ist deshalb nicht, welches CUDA-Toolkit auf dem Host installiert ist, sondern welche Treiberversion nvidia-smi meldet.

NVIDIA nennt in den Release Notes des CUDA-Toolkits für die Reihe 13.x einen Treiber ab Version 580 (Treiberzweig R580). Für CUDA 12.9 GA lag die Untergrenze unter Linux bei 575.51.03. Wer das -cu129-Image gewählt hat, weil auf dem Host ein Treiber aus dem Zweig 575 oder älter läuft, braucht also zuerst einen neuen Treiber. Das bedeutet in der Regel: Kernelmodul tauschen, Neustart, alle GPUs für einige Minuten weg. Das ist ein Wartungsfenster, kein Handgriff nebenbei.

In der Praxis: Erst der Treiber, dann vLLM. Ein neuerer Treiber führt ältere CUDA-Laufzeiten weiter aus, der Container mit 0.32 und CUDA 12.9 startet nach dem Treiberwechsel also wieder. So lassen sich die beiden Eingriffe trennen: ein Fenster für den Host, ein zweites für die Inferenzschicht. Geht im ersten etwas schief, ist klar, woran es lag.

Die zweite Ebene ist PyTorch. Version 0.33.0 hebt auf PyTorch 2.14.0, torchvision 0.29.0 und Triton 3.8.0 an (#52183). Die Paketmetadaten auf PyPI schreiben torch==2.14.0 exakt vor und verlangen Python ab 3.11 und unter 3.15. Für Installationen per pip heißt das: nicht in der bestehenden Umgebung aktualisieren, sondern eine neue virtuelle Umgebung anlegen. Eigene Erweiterungen, die gegen eine ältere PyTorch-Version übersetzt wurden, müssen neu gebaut werden. Wer vLLM und ein Trainings- oder Embedding-Werkzeug in derselben Umgebung betreibt, trennt beides spätestens jetzt.

Ein Hinweis für ältere Hardware: Die CUDA-13.0-Release-Notes streichen in mindestens einer Bibliothek (dort belegt für cuFFT) die Generationen Maxwell, Pascal und Volta. Wer noch Karten dieser Generationen betreibt, prüft vor dem Treiberwechsel bei NVIDIA, ob der Zweig 580 die Karte überhaupt noch führt – sonst endet das Wartungsfenster mit einer GPU, die der Treiber nicht mehr erkennt.

/05Der Upgrade-Plan in sechs Schritten

Die folgenden Befehle geben den Stand der Dokumentation wieder und sind von uns nicht getestet. Image-Namen und Installationszeilen stammen aus den Release Notes v0.33.0; Pfade, Containernamen und Ports sind Beispiele. Der Plan geht von Docker aus und nennt die pip-Variante als Alternative.

# Stand der Dokumentation, nicht getestet (vLLM v0.33.0, 11.11.2026)

# 1. Ist-Stand festhalten
nvidia-smi --query-gpu=name,driver_version --format=csv
docker inspect --format '{{.Config.Image}}' vllm      # endet das Tag auf -cu129?
docker inspect --format '{{json .Config.Cmd}}' vllm   # Startparameter sichern

# 2. Treiber: CUDA 13.x verlangt laut NVIDIA Version 580 oder neuer.
#    Liegt driver_version darunter: eigenes Wartungsfenster, Neustart,
#    danach den ALTEN Container wieder starten und prüfen.

# 3. Neues Image neben dem alten bereitlegen (altes Tag nicht löschen)
docker pull vllm/vllm-openai:v0.33.0
#    pip-Variante, in einer NEUEN Umgebung mit Python 3.11 bis 3.14:
#    uv pip install vllm==0.33.0 --torch-backend=auto

# 4. Probelauf auf einem zweiten Port, nur lokal erreichbar
docker run --rm --name vllm-probe --gpus all --ipc=host \
  -p 127.0.0.1:8001:8000 -v /models:/models \
  vllm/vllm-openai:v0.33.0 \
  /models/ihr-modell --served-model-name probe

# 5. Prüfen: Start, Modellliste, eine echte Anfrage aus Ihrer Anwendung
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8001/health
curl -s http://127.0.0.1:8001/v1/models
docker exec vllm-probe python3 -c 'import torch; print(torch.__version__, torch.version.cuda)'

# 6. Umschalten: alten Container stoppen, neuen mit den gesicherten
#    Parametern auf dem Produktivport starten. Rückweg: altes Tag starten.

Zu Schritt 1: Die Ausgabe von nvidia-smi entscheidet, ob Schritt 2 überhaupt nötig ist. Die gesicherten Startparameter sind die Prüfliste für Abschnitt /06 – jeder Schalter, der dort als entfernt oder wirkungslos steht, gehört vor dem Umschalten aus dem Startbefehl.

Zu Schritt 4: Der Probelauf braucht Grafikspeicher. Auf einem Server, dessen Karten das Produktivmodell vollständig belegen, lässt sich das neue Image nicht parallel starten. Dann bleibt nur der Probelauf im Wartungsfenster oder auf einem zweiten System. Ein kleines Modell als Ersatz prüft Treiber und Image, aber nicht das Verhalten Ihres Modells.

Zu Schritt 5: Ein grüner Health-Endpunkt beweist wenig. Aussagekräftig ist eine Anfrage, wie sie Ihre Anwendung wirklich stellt: mit dem echten Systemprompt, mit strukturierter Ausgabe, mit Function Calling, falls Sie es nutzen. Die Release Notes dieser Version sind lang; was sie für Ihr Modell an Standardwerten ändern, zeigt nur der Vergleich zweier Antworten.

Zu Schritt 6: Der Rückweg auf 0.32 ist technisch einfach, solange das alte Image lokal liegt. Er führt aber zurück in die Version mit dem offenen Advisory. Er ist eine Notlösung für Stunden, nicht für Wochen.

/06Was sich im Verhalten ändert: HTTP 503 und entfernte Funktionen

Der CUDA-Wechsel fällt beim Start auf. Die folgenden Änderungen fallen erst im Betrieb auf, und manche nur unter Last. Die Tabelle fasst zusammen, was die Release Notes unter „Breaking Changes“, „Deprecated“ und „API changes“ nennen.

Für die meisten Häuser ist die erste Zeile die wichtigste. vLLM kann die Generierung anhalten, etwa während Gewichte ausgetauscht werden. Anfragen, die in dieser Zeit eintreffen, beantwortet der Server ab 0.33.0 mit dem Status 503. Das ist sauberer als ein hängender Aufruf, verlangt aber, dass jemand hinschaut: Ein Loadbalancer, der einen Knoten nach dem ersten 503 für Minuten aus dem Pool nimmt, macht aus einer kurzen Pause einen Ausfall. Ein Client ohne Wiederholungslogik zeigt dem Anwender eine Fehlermeldung, wo früher eine Wartezeit war. Prüfen Sie beides an Ihrer API-Kante, bevor die neue Version Produktivlast trägt.

Die zweite Zeile betrifft nur, wer Speculative Decoding mit einem der beiden entfernten Verfahren betreibt. Andere Verfahren bleiben; die Notes erwähnen an anderer Stelle weiterhin EAGLE und MTP. Ein Startbefehl, der noch Medusa oder den MLP-Speculator verlangt, muss vor dem Upgrade umgestellt werden. Wie sich der Server in diesem Fall verhält, haben wir nicht geprüft.

Die übrigen Zeilen sind Aufräumarbeit, aber von der Sorte, die beim Start abbricht oder stillschweigend nichts mehr tut. Ein Schalter ohne Wirkung ist tückischer als ein entfernter: Der Server startet, die erwartete Einstellung greift nicht, und niemand bemerkt es. Die gesicherten Startparameter aus Schritt 1 gegen diese Tabelle zu halten, dauert zehn Minuten.

/07Was v0.34 und v0.35 ankündigen

Die Release Notes von 0.33.0 kündigen zwei weitere Einschnitte mit Versionsnummer an. Der Schalter --ir-op-priority entfällt mit v0.34.0 (#63371). Das Backend LM Format Enforcer für strukturierte Ausgaben wird in v0.34.0 nur noch auf ausdrücklichen Wunsch geladen und mit v0.35.0 entfernt (#63423).

Der zweite Punkt verdient Aufmerksamkeit. Wer Antworten im JSON-Format erzwingt und dafür LM Format Enforcer als Backend eingetragen hat – im Startbefehl oder je Anfrage –, bekommt mit 0.34 ein anderes Verhalten und mit 0.35 kein solches Backend mehr. Die Alternativen und ihre Unterschiede beschreibt Structured Output erzwingen. Ob Ihr System betroffen ist, zeigt eine Suche in Startskripten und Anwendungscode:

# Stand der Dokumentation, nicht getestet
grep -rnE 'lm-format-enforcer|lmformatenforcer|ir-op-priority|mamba-cache-mode' \
  /etc/systemd/system /opt/compose /srv/app 2>/dev/null

Zum Zeitplan gibt es nur ein Indiz. Die letzten drei Versionen sind laut PyPI am 5. Oktober (0.31.0), am 18. Oktober (0.32.0) und am 2. November (0.33.0) erschienen, also im Abstand von rund zwei Wochen. Der Vorabstand v0.34.0rc0 liegt seit dem 8. November vor. Hält der Takt, erscheint 0.34.0 noch im November; ein Datum nennt das Projekt nicht. Für die Planung heißt das: Die Umstellung des Structured-Output-Backends gehört in dasselbe Arbeitspaket wie das Upgrade auf 0.33.0, nicht in ein späteres.

/08Grenzen dieses Plans

Dieser Artikel stützt sich auf Release Notes, ein Advisory, die Paketmetadaten und die CUDA-Dokumentation. Einen eigenen Testlauf von 0.33.0 enthält er nicht. Vier Dinge kann er deshalb nicht leisten.

• Keine Leistungsaussage. Ob Ihr Modell unter PyTorch 2.14.0 schneller, gleich schnell oder langsamer antwortet, steht in keiner der Quellen. Belastbare Werte für Durchsatz und Time to First Token liefert nur eine Messung mit Ihrem Prompt-Mix, vor und nach dem Wechsel.
• Keine Aussage zu Ihrem Modell. Die Notes nennen zahlreiche geänderte Standardwerte für einzelne Modellfamilien. Welche davon Ihr Modell betrifft, zeigt der Probelauf, nicht dieser Text.
• Keine verteilten Sonderfälle. Getrenntes Prefill und Decode, Ray-Cluster und Kubernetes-Betrieb mit mehreren Knoten haben eigene Bruchstellen (NIXL, Ray-Executor), die über einen Sechs-Schritte-Plan für einen Einzelserver hinausgehen.
• Kein abgeschottetes Netz. In einer Umgebung ohne Internetzugang müssen Image oder Wheels samt Abhängigkeiten zuerst in die interne Registry gespiegelt werden. Der Wechsel der PyTorch-Version zieht dabei mehrere Gigabyte neue Pakete nach.

Falsch wäre es, aus Zeitdruck gleich auf den Vorabstand v0.34.0rc0 zu springen, um zwei Upgrades zu einem zu machen. Ein Release Candidate ist für Tests gedacht; seine Release-Seite enthält bisher keine zusammenhängenden Notes. Ebenso falsch wäre es, den Treiber im selben Fenster zu tauschen wie Image, Modell und Startparameter. Vier Änderungen auf einmal ergeben bei einem Fehler vier Verdächtige.

Und für manche Häuser ist das ganze Thema keines. Wer seine Sprachmodelle mit Ollama ausliefert, ist weder vom CUDA-Bruch noch vom Advisory betroffen; beides gilt für vLLM. Der Hosttreiber bleibt trotzdem ein Thema, sobald eine zweite Engine dazukommt.

/09Entscheidung: wer sofort aktualisiert und wer ein Fenster plant

Die Entscheidung hängt an zwei Fragen: Laden Sie fremde Repositories, und auf welcher CUDA-Schiene laufen Sie?

• Sie starten Modelle, die Anwender oder Fachabteilungen frei vom Hub wählen, oder Sie betreiben einen Dienst für mehrere Mandanten: Upgrade auf 0.33.0 jetzt. Genau diesen Fall beschreibt das Advisory. Bis dahin keine ungeprüften Repositories laden.
• Sie nutzen das Standard-Image mit CUDA 13.0 und wenige fest ausgewählte Modelle: Upgrade im nächsten regulären Wartungsfenster. Der Eingriff ist klein: Tag anheben, Startparameter gegen Abschnitt /06 prüfen, Clients auf 503 testen.
• Sie hängen an -cu129, weil der Hosttreiber älter ist: zwei Fenster planen, erst Treiber, dann vLLM. Das erste Fenster gehört in diese oder die nächste Woche. Jede Woche auf 0.32 ist eine Woche mit bekannter Lücke.
• Sie betreiben AMD-Karten: kein Zwang zu ROCm 10.0. Tag -rocm72 festschreiben oder den Wechsel bewusst planen; nur nicht dem Standard-Tag überlassen.
• Sie erzwingen strukturierte Ausgaben mit LM Format Enforcer: die Umstellung des Backends jetzt mit erledigen, bevor 0.34.0 sie erzwingt.

Die meisten Mittelständler mit einem einzelnen Inferenzserver landen im zweiten oder dritten Fall. Für sie ist das Upgrade keine Frage des Ob. Das BSI hat im September darauf hingewiesen, wie kurz die Zeit zwischen Veröffentlichung und Ausnutzung geworden ist; die Einordnung steht in BSI-Warnung: Patch-Fenster minus 7 Tage. Ein Advisory mit CVSS 5.4 ist kein Notfall. Ein Inferenzserver, der wegen eines Treibers dauerhaft eine Version zurückhängt, wird aber beim nächsten, schwereren Advisory zum Notfall.

Wer On-Premise-KI betreibt, übernimmt mit der Hardware auch diesen Rhythmus: alle zwei Wochen eine neue Version der Engine, alle paar Monate ein Bruch in den Abhängigkeiten. Das ist kein Argument gegen den eigenen Server. Es ist ein Argument dafür, Model Serving als Betriebsaufgabe mit festen Fenstern zu behandeln und nicht als einmalige Installation.