kvcached: KV-Cache als virtueller Speicher auf geteilten GPUs

Welche Speicherlücke kvcached adressiert

Wer heute mehrere Modelle auf einer GPU betreibt, teilt den Speicher statisch auf. Jede Instanz bekommt beim Start ein festes Kontingent, und dieses Kontingent bleibt reserviert, auch wenn das Modell gerade nichts tut. Das README beschreibt genau dieses Verhalten als Ausgangsproblem: die heute übliche, starre Speicherpartitionierung. Die Folge sind zwei Verluste gleichzeitig. Die eine Instanz sitzt auf ungenutztem Speicher, während die andere Anfragen ablehnt, obwohl physisch Platz vorhanden wäre. kvcached setzt dort an, wo der KV-Cache liegt, also bei dem Teil des Speichers, der mit der Last wächst und schrumpft. Die Zielgruppe sind entsprechend nicht einzelne Anwender, sondern Betreiber von Serving-Infrastruktur: Multi-LLM-Setups, serverlose Deployments und zusammengesetzte Systeme, in denen mehrere Modelle nacheinander oder parallel auf derselben Hardware laufen. Das Projekt nennt als konkretes Beispiel die Online-Offline-Coserve, also das gleichzeitige Bedienen von Latenz-kritischem und Batch-Verkehr.

Virtueller Adressraum statt fester Reservierung

Der Mechanismus ist im README als Abstraktion von virtuellem Speicher beschrieben, wie sie Betriebssysteme verwenden. Die Serving-Engine reserviert zunächst nur virtuellen Adressraum für den KV-Cache. Physischer GPU-Speicher wird erst dann zugeordnet, wenn der Cache tatsächlich belegt wird. Zwischen logischem KV und physischem Speicher sitzt eine Laufzeit-Zuordnung, die diese Verbindung herstellt und wieder löst. Daraus folgt die Eigenschaft, die das Projekt elastisch nennt: Speicher wird nach Bedarf angefordert und bei nachlassender Last zurückgegeben, statt bis zum Prozessende blockiert zu bleiben. Für die Prefix-Wiederverwendung gibt es zwei Wege, die das Repository getrennt aufführt: automatic prefix caching (APC) für vLLM und RadixCache für SGLang. Beide sollen laut den Release-Hinweisen von April 2026 mit der elastischen Speicherverwaltung zusammenspielen, was nicht trivial ist, weil ein Prefix-Cache Einträge über Anfragen hinweg halten muss, während das zugrunde liegende Speicherkontingent schrumpfen kann. Wie die beiden Mechanismen im Detail koexistieren, geht aus dem vorliegenden Material nicht hervor.

Einbindung in vLLM und SGLang

kvcached ist kein eigenständiger Server, sondern eine Bibliothek, die in die Engine eingehängt wird. Das README nennt SGLang ab v0.4.9 (getestet bis v0.5.15) und vLLM ab v0.8.4 (getestet bis v0.24.0). Die Versionsangaben sind hier der praktisch wichtigste Teil der Dokumentation, weil der KV-Layout-Code in beiden Engines sich zwischen Releases ändert. Für die Speicherbegrenzung verweist das Projekt auf ein CLI, mit dem sich Obergrenzen durchsetzen lassen; die genauen Flags und Konfigurationsschlüssel stehen im vorliegenden Auszug nicht. Für Prefix-Caching existiert ein eigenes Beispielverzeichnis unter examples/09_prefix_caching, das als Einstiegspunkt für die Konfiguration dient. Wer die Integration plant, sollte mit diesem Verzeichnis beginnen und nicht mit dem Haupt-README, weil dort die einzige konkrete Konfigurationsreferenz für den Prefix-Fall liegt. Ein Frontend-Router gehört ebenfalls zum Funktionsumfang: er leitet Anfragen an das passende Modell weiter und versetzt Modelle in einen Schlafzustand, wenn keine Anfragen eintreffen. Damit ist kvcached nicht nur eine Speicherbibliothek, sondern bringt eine eigene Routing-Komponente mit, die neben einem vorhandenen Gateway betrieben oder an dessen Stelle gesetzt werden muss.

Modellabdeckung und ihre Bruchstellen

Die Unterstützungstabelle nennt für beide Engines MHA, GQA, MLA, sliding window und hybrid als Attention-Typen. Als Beispielmodelle erscheinen DeepSeek-V3, Qwen3-8B, GPT-OSS-20B, Qwen3.5-9B sowie Gemma-4-E2B-it und Gemma-4-12B-it. Das ist eine breite, aber keine vollständige Liste. Das Projekt verweist für Ergebnisse pro Modell und KV-Layout auf Issue #425. Diese Verlagerung ist ein ehrlicher Hinweis darauf, dass die Unterstützung nicht uniform ist: derselbe Attention-Typ kann je nach Engine unterschiedliche Ergebnisse liefern, und Pipeline-Parallelität kam erst im März 2026 hinzu. Wer ein Modell außerhalb der genannten Reihe betreibt, hat keine Zusage. Die zweite Bruchstelle ist die Engine-Version. Eine Umgebung, die vLLM unterhalb von v0.8.4 oder SGLang unterhalb von v0.4.9 fährt, ist ausgeschlossen, und ein Upgrade der Engine kann die Integration brechen, weil die getestete Obergrenze jeweils explizit benannt wird. Das ist ein wiederkehrender Wartungsaufwand, kein einmaliger Integrationsschritt.

Wo der Ansatz an seine Grenzen stößt

Elastische Speicherverwaltung hat einen Preis, der in der Beschreibung nicht auftaucht: Zuordnung und Freigabe von physischem Speicher zur Laufzeit sind selbst Arbeit. Bei einem einzelnen Modell mit stetiger, hoher Last ist der Speicher ohnehin durchgehend belegt, und die Virtualisierung bringt dann nichts außer einem zusätzlichen Indirektionsschritt zwischen Engine und Speicher. Der Ansatz zahlt sich in dem Moment aus, in dem Last schwankt oder mehrere Modelle sich einen Pool teilen. Ein zweiter Punkt: die Elastizität hilft nur bei Speicher, nicht bei Rechenleistung. Zwei Modelle, die sich eine GPU teilen, konkurrieren weiterhin um SM-Zeit, und kvcached ändert daran nichts. Das README spricht von besserer Speicherauslastung, nicht von besserem Durchsatz. Wer aus dem Projekt eine Latenzverbesserung ableitet, liest mehr hinein, als dort steht. Drittens ist der Schlafmodus des Frontend-Routers eine Zustandsmaschine, die ein Modell in einen Ruhezustand versetzt und wieder aufweckt. Für Anwendungen mit harten Zeitbudgets pro Anfrage ist ein Kaltstart nach dem Aufwecken ein Risiko, das vor dem Einsatz gemessen werden muss, nicht nachher.

Abgrenzung zu statischer Partitionierung

Die naheliegende Alternative ist die Aufteilung, die kvcached ersetzt: jede Modellinstanz bekommt beim Start einen festen Anteil des GPU-Speichers über die üblichen Engine-Parameter für den KV-Cache. Dieses Verfahren ist vorhersagbar. Der Speicherbedarf steht vor dem ersten Request fest, die Planung ist trivial, und es gibt keine Laufzeitkomponente, die ausfallen kann. Der Unterschied liegt nicht in der Bequemlichkeit, sondern im Verhalten unter schwankender Last: statische Partitionierung verschwendet Speicher in ruhigen Phasen und lehnt Anfragen in Spitzen ab, obwohl die Karte noch Reserven hätte. kvcached tauscht diese Vorhersagbarkeit gegen Auslastung. Ein zweiter Vergleichspunkt ist das Zeitmultiplexen, also das Umschalten zwischen Modellen auf derselben Karte durch Entladen und Nachladen der Gewichte. Das spart Speicher radikaler, kostet aber bei jedem Wechsel das Neuladen, während kvcached die Modelle geladen lässt und nur den Cache-Bedarf anpasst. Für häufige Wechsel bei kleinen Modellen ist Umschalten die einfachere Lösung; für seltene Wechsel bei großen Modellen spricht mehr für den Ansatz von kvcached.

Wartung, Lizenz und Betriebsaufwand

Die Release-Historie zeigt drei Veröffentlichungen zwischen Januar und April 2026: v0.1.3, v0.1.4 und v0.1.5, dazu ein Repository-Stand von August 2026. Das ist ein junges Projekt mit kurzen Zyklen. Für Betreiber bedeutet das, dass die Versionsmatrix aus Engine-Version, kvcached-Version und Modell-KV-Layout bei jedem Upgrade neu geprüft werden muss. Ein Upgrade von vLLM ohne passendes kvcached-Release ist der wahrscheinlichste Fehlerfall im Betrieb. Die Lizenz ist Apache-2.0, was die kommerzielle Nutzung und Modifikation erlaubt und eine Weitergabe der Lizenz- und Urheberrechtshinweise verlangt. Wer kvcached in ein eigenes Produkt einbettet, sollte die Patentklausel und die Bedingungen für Änderungen am Quellcode selbst prüfen; das ist keine Rechtsberatung, sondern nur der Hinweis, dass die Datei LICENSE im Repository die maßgebliche Quelle ist. Ein Hinweis auf eine externe Produktionsnutzung existiert: Red Hat stellt mit Sardeenz ein Projekt vor, das kvcached für dynamisches Multi-Modell-Serving mit Kubernetes und OpenShift nutzt. Das ist ein Datenpunkt zur Tragfähigkeit, ersetzt aber keine eigene Prüfung der eigenen Modell-Engine-Kombination.

Redaktionelles Fazit

Sinnvoll ist kvcached für Teams, die mehrere Modelle oder schwankende Last auf einer einzelnen GPU betreiben und dafür vLLM ab v0.8.4 oder SGLang ab v0.4.9 einsetzen. Wer eine feste, gut ausgelastete Einzelmodell-Instanz mit statischer Speicherplanung fährt, gewinnt nichts und importiert nur zusätzliche Fehlerquellen. Vor dem Rollout ist Issue #425 zu prüfen, weil dort die Ergebnisse pro Modell und Engine zusammenlaufen; stimmt das dort dokumentierte KV-Layout nicht mit dem eigenen Modell überein, ist die Integration nicht abgeschlossen.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. ovg-project/kvcached on GitHub
4. README
5. Releases