vLLM v0.32.0 ist am 18. Oktober 2026 erschienen: Das vLLM-Projekt veröffentlichte auf GitHub eine Version mit 814 Commits von 363 Beitragenden, 121 davon zum ersten Mal dabei. Für Teams, die Open-Weight-Modelle auf eigener Hardware betreiben, zählen weniger die neuen Modelle als zwei andere Punkte: Der KV-Cache mit niedriger Präzision läuft jetzt auch auf älteren GPUs, und mehrere vertraute Standardwerte wurden geändert, sodass ein Upgrade ohne Lektüre der Hinweise eine laufende Installation brechen kann.
Ein neuer Endpunkt für Urteile statt für Generierung
Der neue Endpunkt POST /v1/systemone ist standardmäßig aktiv und beantwortet strukturierte Urteilsfragen zu einem gegebenen Zustand: welche Option zu wählen ist, ob eine Aussage zutrifft und wie ein Ergebnis zu bewerten ist. Bisher holten sich Teams solche Antworten per Format-Prompt aus dem Modell und werteten sie selbst aus; die Serving-Schicht behandelt sie nun als eigene Schnittstelle. Ein generischer hf-Parser liest zudem die im Checkpoint mitgelieferte response_template, sodass Modelle mit eigener Vorlage keine maßgeschneiderten Parser für Tool-Aufrufe und Reasoning mehr brauchen. Das nimmt der Anbindung neuer Modelle ihren umständlichsten Teil.
Die KV-Cache-Rechnung: halber Speicher, bezahlt mit Latenz bis zum ersten Token
Speicher ist die erste Wand, an die lange Kontexte und hohe Parallelität stoßen, und der größte Teil dieser Version floss genau dorthin. Der NVFP4-KV-Cache läuft nun auf SM8x, SM12x und SM90, sodass auch ältere Karten mit niedriger Präzision Speicher freigeben. GLM-5.x nutzt auf SM100 standardmäßig einen FP8-KV-Cache: Der KV-Speicher pro Karte halbiert sich, der Durchsatz steigt um 2,3 bis 5,5 Prozent, während die Zeit bis zum ersten Token um 7 bis 11 Prozent zunimmt; auf SM90 hebt fp8_ds_mla den Ausgabedurchsatz von GLM-5.3-Flash um bis zu 31 Prozent. Der Tausch ist klar benannt: Speicher kommt zurück, Nutzer warten etwas länger auf das erste Token. Optimierung auf dieser Ebene ist ein roter Faden des Jahres, wie auch die vLLM-Optimierung, mit der Kimi K3 auf AMD-Hardware eine B300 schlug, zeigt.
Neue Modelle, Durchsatz bei kurzen Anfragen und Sicherheitsfixes
Neu unterstützt werden Googles multimodales Embedding-Modell EmbeddingGemma 2, MiniCPM-V 4.7 und NVIDIAs Streaming-Spracherkennung Nemotron 3.5 ASR. Auf der Serving-Seite gehen Anfragen an mehrere API-Prozesse nun an den am wenigsten ausgelasteten Prozess; im Benchmark des Projekts brachte das 43 bis 85 Prozent mehr Anfragen pro Sekunde bei kurzen Anfragen, allerdings unter der extrem kurzen Last von 32 Eingabe- und 1 Ausgabe-Token, sodass Produktionsverkehr diesen Wert nicht erwarten sollte. Außerdem behebt die Version drei erfasste Schwachstellen zu Chat-Template-Ressourcenerschöpfung, einem Tokenizer-Parameter und Peer-to-Peer-Kommunikation, schränkt Cross-Origin-Zugriffe standardmäßig ein statt alle Herkunftsorte zu erlauben und begrenzt nicht vertrauenswürdige Bilder auf Rasterformate.
Vor dem Upgrade diese drei Bruchstellen prüfen
Die inkompatiblen Änderungen beißen eher zu als die neuen Funktionen nützen. Python 3.10 wird nicht mehr unterstützt, Installationen darauf scheitern am Upgrade selbst. Der strengere Cross-Origin-Standardwert trennt Browser-Frontends, die die Inferenz-API direkt aufrufen, bis erlaubte Herkunftsorte ausdrücklich konfiguriert sind. Cascade Attention wurde entfernt, und der unterstützte transformers-Bereich verengt sich auf 5.16.1 bis 5.20.0. Für den Produktivbetrieb ist die sichere Reihenfolge: zuerst diese drei Punkte in einer Testumgebung prüfen und dann messen, ob die neuen KV-Cache-Standardwerte unter der eigenen Last überhaupt helfen, denn der Preis bei der Latenz bis zum ersten Token zeigt sich nur unter der eigenen Anfrageverteilung in voller Größe.
