Der KV-Cache-Steuер: Warum Inferenzserver vor der Rechnung den Speicher verlieren
Eine VRAM-Budget-Formel für LLM-Serving sowie drei Optimierungsstrategien, die auf Traffic-Muster abgebildet sind, die Speicherfehler auslösen.
Hintergrund
Beim Betrieb von Inferenzdiensten für große Sprachmodelle beobachten Ingenieure ein besonders tückisches Phänomen: Die GPU-Auslastung erreicht selten ihre Obergrenze, doch der Dienst stürzt trotzdem ab, weil der Arbeitsspeicher überläuft. Man möchte meinen, bei fehlender Rechenleistung würden Anfragen schlicht in eine Warteschlange eingereiht. Beim VRAM hingegen handelt es sich um eine harte physikalische Grenze. Ist sie überschritten, verlässt der gesamte Prozess ohne jede Rückkopplung das System. Der Auslöser dafür ist der KV-Cache, ein Faktor, der in Produktionssystemen über lange Zeit ignoriert wurde.
Während der Dekodierung müssen die Key- und Value-Tensoren jeder Transformer-Ebene immer wieder gelesen werden. Für jedes neu erzeugte Token neu zu rechnen, ließe die Rechenkosten exponentiell explodieren. Deswegen persistieren gängige Inferenzframeworks diese Tensoren im VRAM, anstatt sie immer wieder zu berechnen. Sie tauschen Speicher gegen Rechenleistung. Der Preis dafür: Der KV-Cache wächst linear mit der Kontextlänge und der Zahl paralleler Anfragen. Anders als die Modellgewichte lässt sich der KV-Cache nicht in gleicher struktureller Weise komprimieren, wodurch der VRAM zum empfindlichsten Glied jeder Serving-Pipeline wird.
Tiefenanalyse
Die Größenordnung dieses Problems wird aus der VRAM-Budgetformel deutlich. Der gesamte KV-Cache-Speicherbedarf in einem Batch ergibt grob die Größe des Batch geteilt durch die Sequenzlänge, multipliziert mit der Zahl der Modell Ebenen, erneut multipliziert mit der Dimension je Aufmerksamkeitskopf und der Bytebreite des Datentyp. Drei Hebel offenbaren sich direkt: die Batchgröße, die Sequenzlänge und die architektonischen Parameter des Modells. Bei einem Modell mit 70B Parametern, 32 Ebenen und 128 Aufmerksamkeitsköpfen im FP16-Modus belegt jedes zusätzliche Token einer Sequenz mehrere Hundert Kilobyte VRAM. Sobald mehrere Dutzend Anfragen parallel je Zehntausende von Tokens mitführen, übersteigt der KV-Cache-Speicherbedarf rasch die Modellgewichte selbst. Genau darin begründet sich, warum Inferenzserver ausfallen, bevor die Rechenleistung erschöpft ist.
Drei Traffic-Muster lösen Speicherfehler durch völlig unterschiedliche Mechanismen aus. Der erste ist das Langkontext-Modell, wie es bei Dokumentenfragen oder Codebase-Analysen auftritt, wo die Sequenzlänge ins Unendliche wächst. Die Quantierung greift dies direkt auf und komprimiert den KV-Cache von FP16 auf INT8 oder sogar INT4, reduziert den Speicher nahezu proportional und verletzt dabei die Erzeugungsqualität kaum. Der zweite ist das Burst-Parallelitäts-Modell, ausgelöst durch Aktionsverkäufe oder virale Ereignisse, wo sich die Batchgröße instantan erhöht. Statisches Batching hält die Batches entweder winzig und die Durchsatz niedrig oder akzeptiert zu viele Anfragen und stürzt ab. Der Paging-KV-Cache, die PagedAttention-Technik, die Frameworks wie vLLM einsetzen, zerteilt den KV-Cache jeder Sequenz in fix große Seiten, die bedarfsweise zugewiesen und bei Vollendung zurückgeholt werden. Damit verschwindet der für OOM-Vorsorge reservierte Speicherfragmentierung, und die VRAM-Auslastung klettert von unter 50% auf über 90%.
Der dritte Fall ist das gemischte Last-Modell, die echte Produktionsumgebung, wo Langkontext und Burst-Parallelität nebeneinander existieren. Keine einzelne Strategie bewältigt beide zugleich, daher kombinieren Ingenieure Quantierung und Paging mit Speicherrückholung und Anfrageplanung: leerstehende Anfragen werden mit ihrem KV-Cache ausgelagert, die Batchgröße wird prioritätsabhängig dynamisch angepasst, und bei knappen Speicher werden sogar niedrig priorisierte Anfragen proaktiv verworfen. Diese gestaffelte Steuerung hält einen stabilen Durchsatz unter unvorhersehbaren Bedingungen aufrecht.
Branchenwirkung
Die Speicherverwaltung des KV-Cache hat sich vom technischen Detail zu einem Kernfaktor der Wettbewerbsfähigkeit von Inferenzdiensten entwickelt. Für Cloud-Anbieter ermöglicht ein hoher paralleler Durchsatz pro Karte niedrigere Einheitspreise in abrechnungsorientierten Märkten, was direkt die Gewinnspannen bestimmt. Für Anwendungsentwickler erlaubt das Verstehen der KV-Cache-Muster eine präzisere Einschätzung, wie viele parallele Anfragen eine einzelne Karte trägt, und schützt vor unvorhersehbaren Produktionsausfällen. Für die Edge-KI schärft sich dieses Problem beträchtlich, da Randgeräte einen weiten restriktiveren Speicher haben als Rechenzentren, wodurch die Gewinne aus Quantierung und Paging auf begrenzter Hardware noch verstärkt werden.
Dies erklärt, warum sich die jüngste Inferenzoptimierungsforschung vom reinen Streben nach Modellgenauigkeit hin zum Abwägen von Speicher gegen Durchsatz verschoben hat. Der Flaschenhals in den meisten Produktionsbereitstellungen ist selten langsame GPU-Rechnung, sondern VRAM, das vom KV-Cache voll belegt ist und die Parallelität deckelt. Ingenieure, die ihr VRAM-Budget bis zum Äußersten ausschöpfen, erreichen auf identischer Hardware höheren Durchsatz und niedrigere Kosten, und genau dort entstehen die echten Wettbewerbslücken beim Einsatz großer Modelle.
Ausblick
Mehrere Signale verdienen Beachtung. Die Quantierung setzt ihren Abstieg in feinere Genauigkeiten fort, wobei die KV-Cache-Quantierung von INT8 aus weiter absteigt und den Qualitätsverlust kontrolliert hält, was den Speicherbedarf weiter zusammendrückt. Speicherrückholung und Planungsmechanismen werden schlauer, zukünftige Scheduler prognostizieren den Echtzeit-Verkehr, um Speicherdruck vorauszusehen und Anfragen proaktiv zu stauen oder auszulagern, wodurch OOM von reaktiver Schadensbegrenzung zu aktiver Vermeidung wird. Inferenzframeworks heben die Speichereffizienz auf die Stufe eines ersten architektonischen Bürgers statt einem nachträglichen Patch und integrieren Quantierung, Paging und Rückholung nativ.
Der kognitive Fallstrick, den Praktiker meiden müssen, besteht darin, Inferenzleistungsprobleme schlicht auf fehlende Rechenleistung zurückzuführen. In der Wahrheit ist die GPU-Rechengeschwindigkeit selten der begrenzende Faktor; es ist der vom KV-Cache gefüllte VRAM, der die Parallelität am Aufsteigen hindert. Wer ihr Speicherbudget optimiert, gewinnt den BereitstellungsWettlauf und liefert auf dem gleichen Silizium höheren Durchsatz und niedrigere Kosten.
Sources
FAQ
Warum kommt es bei Inferenzservern zu einem Speicherfehler (OOM), bevor die Rechenressourcen erschöpft sind?
Beim Dekodieren speichert der KV Cache die Key/Value-Tensor jeder Transformer-Einheit, um Rechenleistung zu sparen, aber seine Nutzung wächst linear mit der Kontextlänge und der Anzahl paralleler Anfragen und kann nicht wie Modellgewichte quantisiert werden, sodass er den Speicher vor Rechenende auffüllt.
Warum wird die Speichernutzung des KV Cache zum Flaschenhals?
Wenn die parallelen Anfragen zunehmen und jede Zehntausende von Tokens trägt, übersteigt die KV-Nutzung schnell die Modellgewichte und wird zum begrenzenden Faktor für den Durchsatz unter begrenzter VRAM sowie für die Anzahl pro Karte Tragbarer Anfragen.
Welche Optimierungsrichtungen gibt es zukünftig angesichts des Speicherdrucks durch den KV Cache?
Die Quantisierung entwickelt sich von INT8 zu niedrigeren Präzisionen mit kontrolliertem Qualitätsverlust weiter, Speicherfreigabe und Scheduling werden durch Prognose des Live-Verkehrs intelligenter, und Frameworks integrieren die Speicher natives Effizienz als ersten Bürger.