vLLM 0.32: strengere CORS-Defaults, neuer KV-Cache und /v1/systemone

Das vLLM-Projekt hat am 18. Oktober 2026 die Version 0.32.0 seines Open-Source-Inferenzservers veröffentlicht. Das Release bündelt laut den Release Notes 814 Commits von 363 Mitwirkenden, darunter 121 neue. Für Betreiber zählen vor allem strengere CORS-Defaults, das Ende von Python 3.10 und geänderte KV-Cache-Voreinstellungen. Neu ist zudem der Endpunkt POST /v1/systemone.

Betroffen sind alle, die vLLM selbst als OpenAI-kompatiblen API-Server betreiben, ob als Docker-Container oder Python-Paket. Wer vLLM nur über einen Cloud-Dienst nutzt, muss nichts tun. Einen Notfall-Patch verlangt das Release nicht, eine aktiv ausgenutzte Lücke nennt das Projekt nicht. Das Update gehört in ein geplantes Wartungsfenster mit vorherigem Test, weil Browser-Clients und ältere Skripte brechen können.

Was ist neu in vLLM 0.32?

• Neuer Endpunkt /v1/systemone: Er beantwortet typisierte Fragen zu einem übergebenen Zustand mit den Fragetypen choice, noul (ja oder nein) und score und liefert je Antwort eine Wahrscheinlichkeit. Laut Dokumentation ist er bei Generierungsmodellen standardmäßig aktiv; nicht unterstützte Modelle antworten mit HTTP 501.
• Generischer Parser hf: Mit --tool-call-parser hf und --reasoning-parser hf liest vLLM das response_template aus dem Checkpoint. Passende Modelle brauchen keinen eigenen Parser mehr.
• KV-Cache mit niedriger Genauigkeit: Der NVFP4-KV-Cache läuft jetzt auch auf den NVIDIA-Generationen SM8x, SM90 und SM12x. Auf AMD ROCm kommt der 4-Bit-Cache ultraquant_4bit hinzu, der laut Projekt etwa die doppelte Dichte von FP8 erreicht.
• Model Runner V2: Die neue Ausführungsschicht ist auf ROCm jetzt Standard.
• Schnellerer Start: vllm download-kernels installiert vorkompilierte FlashInfer-Kernel, vllm preload --preload-autotune hält die Autotune-Tabelle über Neustarts hinweg warm.

Für wen ist das relevant?

Relevant ist das Release für Teams, die vLLM als internen LLM-Endpunkt hinter Chat-Frontend, RAG-System oder Gateway betreiben. Besonders aufmerksam sollten Betreiber mit Browser-Clients sein, die direkt auf die API zugreifen, Nutzer der Responses API mit Reasoning-Streaming und alle mit pip-Installationen unter Python 3.10. Wer GLM-5.x auf GPUs der Generation SM100 betreibt, bekommt automatisch ein anderes KV-Cache-Format. Nicht betroffen sind Nutzer gehosteter APIs und Installationen, die bewusst auf einem älteren, gepinnten Image bleiben.

Breaking Changes beim Update auf 0.32

Die für Selbstbetreiber wichtigsten Punkte aus dem Abschnitt Breaking Changes:

• CORS: Die Standard-Origins wechseln von * auf keine. Browser-Clients brauchen ab sofort --allowed-origins; Server-zu-Server-Aufrufe sind nicht betroffen.
• Python: Mindestversion ist Python 3.11, unterstützt werden 3.11 bis 3.14.
• Abhängigkeiten: Gefordert sind transformers>=5.16.1,<5.20.0 und tokenizers>=0.23.2. PyTorch bleibt laut PyPI-Metadaten bei Version 2.13.0, die Standard-Wheels und das Standard-Image sind auf CUDA 13.0 gebaut.
• max_tokens: Der Wert gilt nur noch als Obergrenze der Ausgabe und wird nicht mehr vom Kontextfenster reserviert. Lange Prompts werden nicht mehr abgelehnt.
• Responses API: Reasoning-Streams nutzen jetzt response.content_part.added/done mit part.type="reasoning_text" statt response.reasoning_part.added/done.
• Entfernte Optionen: Cascade Attention ist weg, --mamba-cache-mode all scheitert an der Validierung, abgekündigte APIs wie AsyncLLM.pause_generation() wurden entfernt.

Neue Defaults und was der KV-Cache bringt

Der KV-Cache hält Zwischenergebnisse verarbeiteter Tokens im GPU-Speicher. Je kleiner ein Eintrag, desto mehr parallele Anfragen oder längere Kontexte passen auf eine Karte. Für GLM-5.x setzt vLLM 0.32 auf SM100-GPUs bei --kv-cache-dtype auto jetzt standardmäßig einen FP8-KV-Cache. Laut Release Notes halbiert das den KV-Speicher pro Rank; im Benchmark des zugehörigen Pull Requests stieg der Durchsatz um 2,3 bis 5,5 Prozent, die Zeit bis zum ersten Token (TTFT) wurde dabei um 7 bis 11 Prozent länger. Bei latenzkritischen Anwendungen lohnt eine eigene Messung, bei Bedarf lässt sich der Datentyp explizit setzen.

Weitere neue Defaults: Die Shared-Memory-Tensor-Arena für multimodale Tensoren ist eingeschaltet, und mit --api-server-count größer 1 geht jede Verbindung an den am wenigsten ausgelasteten Worker.

Sicherheitskorrekturen im Überblick

Das Release führt drei GHSA-Kennungen auf: Ressourcenerschöpfung über Chat-Templates (jetzt mit Timeout über VLLM_CHAT_TEMPLATE_RENDER_TIMEOUT), einen Off-by-one-Fehler bei max_token_id im Tokenizer und die Erschöpfung von ZMQ-Sockets im P2P-Betrieb, begrenzt über VLLM_P2P_MAX_PEERS (Standard 128). Zum Redaktionsschluss waren zwei dieser Kennungen in der GitHub-Advisory-Datenbank noch nicht öffentlich abrufbar; die dritte verweist dort auf einen anderen, bereits mit 0.26.0 behobenen Eintrag. Schweregrade sind daher nicht unabhängig bestätigt. Zusätzlich akzeptiert vLLM nicht vertrauenswürdige Bilder nur noch in Rasterformaten und lehnt JSON-Schemata mit mehr als 64 Ebenen ab.

Was Admins jetzt tun sollten

• Inventar prüfen: Laufende vLLM-Version und Image-Tag auf allen Hosts erfassen, etwa per docker ps oder pip show vllm, dazu die Python-Version.
• Image-Tag pinnen: Statt latest gezielt vllm/vllm-openai:v0.32.0 verwenden. Laut Docker Hub liegt es seit dem 18. Oktober 2026 für amd64 (rund 9,2 GB) und arm64 vor, für ältere Treiber gibt es v0.32.0-cu129.
• Treiber abgleichen: Das Standard-Image nutzt CUDA 13.0, das laut Doku einen Treiber ab R580 voraussetzt. Für ausgewählte Rechenzentrums-GPUs gibt es VLLM_ENABLE_CUDA_COMPATIBILITY=1.
• CORS festlegen: Für Browser-Clients --allowed-origins mit den konkreten Domains setzen, nicht pauschal wieder *.
• Startparameter durchsehen: Entfernte Optionen wie --mamba-cache-mode all aus Compose-Dateien und Units streichen.
• Erst testen, dann umstellen: Das neue Image auf einem Testhost starten, /v1/chat/completions, Streaming und Tool Calls prüfen, Latenz und Speicher vergleichen.
• Rückweg sichern: Das bisherige Image-Tag lokal behalten, um schnell zurückzurollen.

Einordnung

vLLM erscheint derzeit etwa alle zwei Wochen in einer neuen Minor-Version; 0.31.0 kam am 5. Oktober 2026. Für kleine Installationen ist 0.32 vor allem ein Release mit geändertem Standardverhalten. Die strengere CORS-Vorgabe ist aus Sicherheitssicht sinnvoll, kann aber unvorbereitet Weboberflächen lahmlegen. Unabhängige Fachberichte lagen zum Redaktionsschluss nicht vor; die Angaben stützen sich auf die Release Notes, PyPI, Docker Hub und die offizielle Dokumentation.

Passende Anleitungen auf S-EDV

• Offene LLMs mit vLLM per Docker selbst hosten
• Qwen3 lokal mit Ollama und vLLM betreiben, inklusive Thinking Mode

Quellen

• GitHub: vLLM v0.32.0 Release Notes
• PyPI: vllm 0.32.0
• Docker Hub: vllm/vllm-openai Tags
• vLLM-Dokumentation: Using Docker
• vLLM-Dokumentation: Structured Decisions (/v1/systemone)