584 Commits von 270 Beitragenden, 76 davon zum ersten Mal dabei. vLLM 0.28.0 ist kein Wartungs-Release. Das Projekt gleicht einer Werkstatt, in der an vielen Stellen gleichzeitig geschraubt wird – an Motor, Getriebe, Fahrwerk und Armaturenbrett. Genau das zeigt der Blick in die Release Notes.
Kimi K3: Optimierungen über den ganzen Stack
Ein Schwerpunkt liegt auf Kimi-K3, einem Modell, das ähnlich wie DeepSeek auf Mixture-of-Experts-Architekturen setzt. Solche Modelle verteilen die Rechenlast auf viele spezialisierte Experten. Das macht sie leistungsfähig, aber auch schwer beherrschbar. Die Optimierungen in vLLM 0.28.0 betreffen alle Schichten. Neu ist Decode Context Parallel (DCP), eine Technik, die das Dekodieren – also das Generieren neuer Tokens – parallel über mehrere Kontexte hinweg aufteilt. Dazu kommen zusammengeführte FlashKDA-Kernel für Dekodierung und Prefill. Prefill bezeichnet das Befüllen des Kontextfensters vor der eigentlichen Generierung. SiTU-Aktivierungen werden für MegaMoE unterstützt. GEMM-RS erweitert die Sequence Parallelism um eine effizientere Matrizenmultiplikation.
Laut Release Notes ergeben diese Arbeiten einen 1,5- bis 3-fachen Speedup auf Kernel-Ebene. Ein adaptives Budget für spekulative Tokens senkt die Time-to-First-Token (TTFT) im DSpark-Modus um rund 60 Prozent. TTFT ist die Zeit, bis das Modell das erste Zeichen einer Antwort liefert. Je kürzer, desto flüssiger wirkt die Anwendung. Optional lässt sich der Shared-Experte sharden. Das macht etwa 17 GiB GPU-Speicher pro Grafikprozessor frei. Außerdem läuft Kimi-K3 jetzt auf AMD-Hardware mit dem neuen Model Runner V2. Die Codebasis löst sich damit zunehmend vom CUDA-only-Image.
DeepSeek V4: Sparse MLA wird produktionstauglich
DeepSeek V4 nutzt Multi-Head Latent Attention (MLA), ein Verfahren, das den Aufmerksamkeitsmechanismus deutlich komprimiert. Die sparse Variante davon funktioniert in dieser Version durchgängig für reguläres Dekodieren, MTP (Multi-Token Prediction) und spekulative Dekodierung mit DSpark. MTP bedeutet, dass das Modell pro Schritt mehrere Tokens vorhersagt und anschließend verifiziert. Das erhöht den Durchsatz.
Hinzu kommen AMD-Quark-Unterstützung für NVFP4 – ein 4-Bit-Format mit spezieller Skalierung – sowie neue Reasoning-Effort-Prompts. Damit lässt sich steuern, wie viel ein Modell „nachdenkt“. Auf der Kernel-Seite wurden die Top-k-Metadaten weiter optimiert und die CUDA-Graph-Regionen für Eager-Mode enger gezogen. Das sind die Bereiche, in denen das Modell ohne Graph-Capture direkt ausgeführt wird. Auch AMD profitiert: DeepSeek V4 läuft jetzt auf den Grafik-Generationen gfx11 und gfx950, jeweils mit angepassten Optimierungen für die dort verfügbaren Sparse-MLA-Pfade.
Model Runner V2: Disaggregation wird ausgebaut
Der Model Runner V2 ist das neue Ausführungs-Backend von vLLM. Er orchestriert die einzelnen Komponenten eines Inferenz-Systems. In 0.28.0 unterstützt er E/P/D-Disaggregation, also die strikte Trennung von Encode-, Prefill- und Decode-Phase. Während des Prefills wird der Kontext einmal vorbereitet. Das eigentliche Generieren übernimmt der Decode-Schritt. Beide Phasen haben unterschiedliche Anforderungen an Rechenzeit und Speicher. Eine Trennung ist daher oft effizienter.
Neu sind außerdem Weight Offloading – das Auslagern von Modellgewichten auf langsamere Speicher, wenn sie gerade nicht gebraucht werden – sowie Multi-Layer-MTP-KV-Cache, Encoder-CUDA-Graphen und Decoder-Token-wise Pooling. Transformerbasierte Pooling-Modelle werden ebenfalls unterstützt. Dazu kommen Aufmerksamkeits-freie Modelle und das Konzept eines thinking_token_budget. Damit lässt sich der Denkaufwand eines Reasoning-Modells explizit begrenzen.
Spekulative Dekodierung: mehrere Wege zum schnelleren Token
Spekulative Dekodierung ist ein Verfahren, bei dem ein kleines, schnelles Entwurfsmodell mehrere Tokens vorschlägt. Das große Modell verifiziert sie anschließend in einem Schwung. vLLM 0.28.0 baut diese Idee konsequent aus. DFlash2 bringt eine lokale Faltung (Convolution) mit, die das Entwurfsmodell zusätzlich verfeinert, sowie einen Candidate Selector, der unter mehreren Vorschlägen auswählt. DSpark erhält eine Confidence-Scheduling-Stufe für die Verifikation. Das asynchrone Scheduling für Draft Models ist nun automatisch aktiviert.
Wer ein produktives System betreibt und bisher klassische autoregressive Generierung nutzte, kann die Tokens pro Sekunde oft verdoppeln, ohne die Modellqualität zu beeinträchtigen. Voraussetzung: Das Draft-Modell passt zur Aufgabe.
Tiered KV Cache Offloading: vom RAM zur SSD
Ein zweiter Schwerpunkt betrifft den KV-Cache. Das ist der Zwischenspeicher, in dem vLLM die Aufmerksamkeits-Zustände vergangener Tokens ablegt. In großen Deployments passt dieser Cache selten komplett in den GPU-Speicher. Die Lösung heißt Offloading: selten benötigte Teile wandern auf die CPU oder – neu in 0.28.0 – auf die Festplatte. Dafür gibt es jetzt Disk-Offloading für den SimpleCPUOffloadConnector, einen Hook für Out-of-Tree-Implementierungen und ein kanonisches CPU-Layout, das unabhängig vom Parallelismus funktioniert.
Ergänzend gibt es Metriken, mit denen sich das Tiering im Betrieb beobachten lässt. Außerdem lassen sich Ergebnisse aus dem Secondary-Tier teilweise laden, wenn nur ein Teil des Kontexts benötigt wird. Praktisch heißt das: Auch lange Konversationen mit hunderttausenden Tokens lassen sich wirtschaftlich bedienen, wenn man SSD-Speicher in Kauf nimmt.
Rust-Frontend, gRPC und neue Defaults
Im API- und Frontend-Bereich gibt es vor allem das Rust-Frontend. Es bringt einen eigenständigen Renderer mit, erlaubt multimodale Bildinferenz über gRPC und unterstützt explizites Routing für Data-Parallel-Ränge. Auch der Lebenszyklus für Reinforcement-Learning-Workflows lässt sich steuern. Die Protobuf-Schemas werden über Buf publiziert, was die Integration in andere Sprachen erleichtert.
Bei den Defaults gibt es drei spürbare Änderungen: max_num_batched_tokens steigt von 8192 auf 16384, also die maximale Anzahl Tokens, die pro Batch verarbeitet werden. Prefix Caching ist nun für Mamba-Modelle standardmäßig aktiv. Der Blackwell-CUDA-Graph-Capture-Bereich wächst auf 1024 Tokens. Wer bestehende Setups betreibt, sollte diese Änderungen berücksichtigen, da sie Speicherverbrauch und Verhalten bei kleinen Batches beeinflussen können.
Breaking Changes, neue Modelle und Lieferung
Mit 0.28.0 wandert bitsandbytes in ein Out-of-Tree-Plugin. Transformers wird auf 5.15.0 aktualisiert. Das veraltete calculate_kv_scales verschwindet, override_attention_dtype wird entfernt. Wer diese Pfade nutzt, muss vor dem Upgrade migrieren. Auf der Modellseite kommen unter anderem Muse Glimmer, Ling 3.0 Flash (mit BF16, MTP und Parser), Dots3 NOTE mit nativer multimodaler Unterstützung sowie Interns2mobius dazu. Qwen3.8 läuft jetzt auf AMD ROCm. Für Qwen3.5 GDN gibt es einen zusammengeführten CUDA-Post-Conv-MTP-Dekodierungskernel.
Geliefert wird vLLM 0.28.0 als Python-Wheel über PyPI und uv, mit eigenem ROCm-Index, sowie als Docker-Image für CUDA 12.9, CUDA 13.0 (Standard), ROCm, CPU und XPU. Hinzu kommen Tarballs und wheels für x86_64, arm64 und macOS.
Was das in der Praxis bedeutet
Für Betreiber großer Serving-Infrastrukturen ist 0.28.0 vor allem wegen der E/P/D-Disaggregation im Model Runner V2 interessant. Prefill- und Decode-Ressourcen lassen sich damit sauberer trennen und skalieren. Für Forschende zählt die breite Unterstützung von Kimi-K3 und DeepSeek V4, einschließlich AMD-ROCm und Intel XPU. Für Entwickler, die eigene Tools oder UIs bauen, wird das Rust-Frontend mit gRPC multimodal zunehmend attraktiv. Wer auf Stabilität setzt, sollte die Breaking Changes prüfen, bevor er upgradet.
Quelle: github.com
