KV-Cache: der stille Kostentreiber selbst-gehosteter KI

Wer selbst-gehostete KI betreibt, schaut zuerst auf die GPU. Verständlich, denn die Karten kosten am meisten. Doch der eigentliche Engpass sitzt oft woanders: im KV-Cache. Dieser Speicher wächst mit jeder Anfrage, frisst GPU-RAM und entscheidet darüber, wie viele Nutzer Sie parallel bedienen können, bevor das System einbricht.

Mit der Welle agentischer Arbeitslasten und langer Kontextfenster ist der KV-Cache vom Randthema zum zentralen Kostentreiber geworden. Red Hat und IBM haben am 20. Oktober 2026 llm-d 1.0 vorgestellt – einen offenen Inferenz-Stack, dessen Kernversprechen ausgerechnet die intelligente Verwaltung genau dieses Caches ist. Grund genug, einmal genau hinzusehen.

Was der KV-Cache wirklich ist

Ein Sprachmodell liest Text Token für Token. Für jedes Token berechnet es sogenannte Key- und Value-Vektoren in jeder Schicht des Netzes. Damit das Modell beim nächsten Token nicht den gesamten bisherigen Text neu durchrechnen muss, speichert es diese Vektoren zwischen. Das ist der KV-Cache: das Kurzzeitgedächtnis der laufenden Antwort.

Der Haken liegt in der Größe. Der Cache wächst linear mit der Kontextlänge und multipliziert sich mit der Zahl gleichzeitiger Anfragen. Ein einziger Chat mit 100.000 Token Kontext belegt je nach Modell schnell mehrere Gigabyte. Bedienen Sie zwanzig solcher Sitzungen parallel, ist eine teure Karte voll – nicht durch die Modellgewichte, sondern durch Zwischenergebnisse.

Genau hier kippt die Rechnung vieler Pilotprojekte. Im Labor mit einer Handvoll Testanfragen läuft alles rund. In der Produktion mit hundert Abteilungen und langen Dokumenten stapeln sich die Caches, der GPU-Speicher ist voll, und das System weist Anfragen ab oder wird quälend langsam.

Warum das Thema gerade jetzt eskaliert

Zwei Entwicklungen treffen zusammen. Erstens die langen Kontextfenster: Modelle mit einer Million Token sind 2026 keine Seltenheit mehr. Metas Muse Spark Open etwa reicht an diese Marke. Je mehr Kontext Sie nutzen, desto größer der Cache.

Zweitens die agentischen Arbeitsabläufe. Ein Agent, der Werkzeuge aufruft, Zwischenschritte plant und mehrfach nachschlägt, hält seinen Kontext über viele Runden offen. Statt einer kurzen Frage-Antwort-Episode entstehen lange, verzweigte Sitzungen. Der Cache bleibt entsprechend lange belegt.

Analysten schätzen inzwischen, dass die Inferenz – also der laufende Betrieb, nicht das Training – den Großteil der KI-Budgets verschlingt. Wer die Caches im Griff hat, senkt direkt die Zahl der benötigten Karten. Das ist kein akademisches Detail, sondern eine Position auf der Rechnung.

Offloading: den Cache auslagern statt wegwerfen

Der naheliegende Reflex lautet: ältere Caches verwerfen, wenn der Speicher knapp wird. Das funktioniert, kostet aber Rechenzeit, sobald dieselbe Sitzung weiterläuft – dann muss das Modell den verworfenen Teil neu aufbauen. Offloading geht einen anderen Weg. Es schiebt selten genutzte Cache-Segmente aus dem teuren GPU-Speicher in den günstigeren CPU-Arbeitsspeicher oder auf schnelle NVMe-SSDs.

Firmen wie Tensormesh und NVIDIA mit seinem Dynamo-Stack treiben diesen Ansatz voran. Der Gedanke: GPU-HBM ist knapp und teuer, CPU-RAM und Flash sind reichlich und billig. Liegt ein Cache-Segment gerade nicht im aktiven Rechenpfad, hat es im Hochpreis-Speicher nichts verloren. Braucht die Sitzung es wieder, holt der Stack es rechtzeitig zurück.

Der Gewinn ist handfest. Sie bedienen längere Kontexte und größere Stapel, ohne neue Karten zu kaufen. Der Preis ist eine sorgfältige Steuerung: Das Zurückholen über den PCIe-Bus darf die Antwort nicht ausbremsen. Deshalb entscheidet die Qualität der Vorhersage, welches Segment wann gebraucht wird, über Erfolg oder Frust.

Kompression: den Cache kleiner rechnen

Ein zweiter Hebel setzt an der Datenmenge selbst an. Standardmäßig liegen die Key- und Value-Vektoren in 16 Bit vor. Rechnet man sie in FP8 oder INT8 um, halbiert sich der Speicherbedarf – und damit verdoppelt sich grob die Zahl der Sitzungen, die auf eine Karte passen.

Die Genauigkeit leidet dabei weniger, als viele befürchten. Keys und Values sind robuster gegenüber niedriger Präzision als die Modellgewichte. Trotzdem gilt: Messen statt glauben. Prüfen Sie an Ihren eigenen Aufgaben, ob die Antwortqualität stabil bleibt, bevor Sie die Kompression produktiv schalten.

Kompression und Offloading schließen sich nicht aus. Im Gegenteil: Ein komprimierter Cache lässt sich schneller auslagern und zurückholen, weil weniger Daten über den Bus wandern. Die beiden Techniken verstärken sich gegenseitig.

Prefix-Caching: Gemeinsames nur einmal rechnen

Viele Anwendungen schicken denselben Textanfang immer wieder los. Ein System-Prompt mit Rollenbeschreibung, eine Formatvorlage, eine Firmenrichtlinie – dieser Block ist bei jeder Anfrage identisch. Ohne Zwischenspeicher rechnet das Modell ihn jedes Mal neu durch.

Prefix-Caching hält den KV-Cache für solche gemeinsamen Präfixe vor und teilt ihn über viele Anfragen. Die erste Anfrage füllt den Cache, alle folgenden setzen darauf auf. Gerade bei langen, festen System-Prompts oder bei RAG-Anwendungen mit wiederkehrenden Anweisungen spart das spürbar Rechenzeit und senkt die Latenz des ersten Tokens.

In der Praxis bringt dieser Hebel oft den größten Sofortgewinn, weil er keine Qualitätsabwägung erfordert. Sie rechnen schlicht nicht doppelt. vLLM, llm-d und die meisten modernen Inferenz-Server bringen Prefix-Caching bereits mit – es muss nur bewusst genutzt und auf die eigenen Prompts zugeschnitten werden.

Was das für Ihre Architektur bedeutet

Die drei Hebel gehören zusammen gedacht. Prefix-Caching reduziert, was überhaupt entsteht. Kompression verkleinert, was bleibt. Offloading verteilt den Rest auf die passende Speicherebene. Wer nur an einer Schraube dreht, verschenkt Potenzial.

Praktisch heißt das: Wählen Sie einen Inferenz-Server, der diese Funktionen nativ beherrscht, statt sie selbst nachzurüsten. vLLM hat die Grundlagen mit PagedAttention gelegt; llm-d 1.0 setzt mit verteilter Cache-Verwaltung über mehrere Knoten darauf auf. Beide sind quelloffen und laufen auf eigener Hardware – passend für Unternehmen, die Daten im Haus behalten müssen.

Und messen Sie, bevor Sie skalieren. Beobachten Sie die GPU-Speicherauslastung unter echter Last, nicht im Testlauf. Oft zeigt sich, dass eine vorhandene Karte deutlich mehr Nutzer trägt, sobald der Cache klug verwaltet wird. Die günstigste GPU ist die, die Sie nicht kaufen müssen.

Sie planen eine selbst-gehostete KI, die unter realer Last bezahlbar bleibt – und wollen KV-Cache, Offloading und Inferenz-Architektur von Anfang an richtig aufsetzen? Sprechen Sie mit dem Team von AI-Designers, wir bringen Ihre Modelle wirtschaftlich in Produktion.

Bilder: AI-Designed