vLLM 0.26.0 macht aus dem KV-Cache eine explizite Betriebsarchitektur. Das am 25. Juli veröffentlichte Release erweitert Offloading und sekundäre Storage-Tiers bis hin zu einem Object Store mit Workload Identity. Für Teams, die lange Kontexte oder viele parallele Sessions bedienen, ist das mehr als Release-Notiz: Cache-Daten, Latenz und Zugriffsrechte müssen künftig gemeinsam geplant werden.
Die offiziellen Release Notes nennen 411 Commits. Auffällig ist nicht nur die Zahl, sondern die Richtung: vLLM baut die Ebene unter dem Modell weiter zu einem steuerbaren Speicher- und Observability-System aus.
Was sich im Cache-Pfad konkret ändert
KV-Offloading war bisher leicht als Notlösung zu lesen: GPU-Speicher wird knapp, also werden Blöcke ausgelagert. Version 0.26.0 macht diesen Pfad deutlich systematischer:
- Object-Store-Tier mit Workload Identity: Ein sekundärer Storage-Tier kann über Workload Identity angebunden werden. Damit muss ein Serving-Deployment für den Zugriff nicht zwangsläufig langlebige Storage-Credentials mitführen.
- Tier-eigene Events und Metriken: vLLM ergänzt Offloading-Metriken, getrennte Read-/Write-Gauges für den CPU-Cache sowie synchrone und asynchrone Histogramme für Tiering-Lookups.
- DP-replica-aware Tiering: Das Tiering kennt Data-Parallel-Replikate. Das ist relevant, sobald ein Cache nicht mehr als lokaler Nebeneffekt eines einzelnen Workers behandelt wird.
- Heterogene KV-Gruppen: Mit
blocks_per_chunklässt sich das Chunking für unterschiedliche KV-Cache-Gruppen konfigurieren.
Die operative Konsequenz: Ein Miss im GPU-Cache ist nicht mehr einfach ein Performance-Detail. Er kann einen CPU- oder Object-Store-Pfad auslösen, dessen Latenz, Berechtigungen und Egress-Kosten Teil des SLOs werden. Workload Identity ist dabei ein wichtiger Hinweis auf die Zielumgebung: mehrmandantenfähige, cloud-native Serving-Stacks statt einzelner GPU-Hosts mit lokalem Cache.
Auch hybride Modelle erhalten präzisere Kontrolle
vLLM erlaubt jetzt, das Attention-Backend pro KV-Cache-Gruppe zu wählen; Sliding-Window-Support wird als explizite Backend-Fähigkeit modelliert. Das klingt intern, trifft aber eine reale Lücke: Hybride Architekturen kombinieren unterschiedliche Attention- und Cache-Anforderungen. Ein globaler Backend-Schalter war dafür zu grob.
Daneben nennt das Release partielle Prefix-Cache-Hits und selektive Retention für hybride Caches. In Verbindung mit den neuen Metriken wird Cache-Politik damit messbarer: Nicht nur „Trefferquote“, sondern welche Blöcke wiederverwendet, gehalten oder ausgelagert werden.
Was Betreiber jetzt testen sollten
- Baseline erfassen: Vor dem Upgrade TTFT, TPOT, GPU-Speicher, CPU-Cache-Read/Write und Cache-Hit-Rate pro Workload festhalten.
- Identity-Pfad isoliert prüfen: Für Object Storage minimal privilegierte Workload Identity verwenden; fehlende Rechte und abgelaufene Tokens müssen im Canary klar fehlschlagen.
- Tail-Latenz messen: Nicht nur den Median vergleichen. Cache-Misses über einen entfernten Tier sind ein p95-/p99-Thema.
- Backend-Matrix klein halten: Bei hybriden Modellen Attention-Backend und Cache-Gruppen zunächst in einer reproduzierbaren Konfiguration testen, bevor Autotuning oder Quantisierung dazukommen.
Einordnung
vLLM 0.26.0 enthält auch neue Modellpfade, DeepSeek-V4-Optimierungen und Security-Fixes. Der strategisch interessanteste Teil ist jedoch das Cache-Tiering: Inference-Serving wird zunehmend ein Datenpfad-Problem. Wer lange Kontexte wirtschaftlich anbieten will, braucht nicht nur schnellere GPUs, sondern nachvollziehbare Speicherhierarchien, saubere Identitäten und Telemetrie, die den Umweg sichtbar macht.
Quelle: vLLM v0.26.0 Release Notes, veröffentlicht am 25. Juli 2026.
Schreibe einen Kommentar