Warum wächst der KV-Cache mit der Kontextlänge von Home-KI?

Der KV-Cache wächst mit der Kontextlänge, weil die Laufzeitumgebung die Attention-Keys und -Values für jedes beibehaltene Token über mehrere Modellebenen hinweg speichert.

Ein kurzer Home-KI-Prompt kann genügend Speicher für mehrere Nutzer übrig lassen, während ein langes Dokument, ein umfangreicher Chatverlauf oder ein Agenten-Trace deutlich mehr Arbeitsspeicher verbrauchen kann, ohne dass sich die Modelldatei selbst verändert. Der Cache wird während der Prompt-Verarbeitung angelegt und wächst weiter, sobald das Modell neue Tokens generiert. Seine Größe hängt außerdem von der Anzahl der Ebenen, der Attention-Architektur, der numerischen Präzision und der Anzahl gleichzeitiger Anfragen ab. Die folgenden Abschnitte verfolgen dieses Wachstum von einem Token bis zur serverweiten Speichergrenze.

Jedes beibehaltene Token fügt einen Attention-Zustand hinzu

Während der Transformer-Inferenz erzeugt jede Ebene aus den bereits verarbeiteten Tokens Key- und Value-Tensoren. Die Laufzeitumgebung behält diese Tensoren, damit das nächste Token auf den bisherigen Kontext zugreifen kann, ohne die gesamte Sequenz neu zu berechnen.

Die vLLM-Arbeit identifiziert den KV-Zustand pro Token als einen wichtigen Speicherbedarf bei der Bereitstellung. Neue Tokens fügen neue Cache-Einträge hinzu, während zuvor beibehaltene Einträge für spätere Attention-Schritte verfügbar bleiben.

Der Cache ist daher ein veränderlicher Anfragezustand und kein Bestandteil der statischen Modellgewichte. Wird dasselbe Modell mit einer längeren aktiven Unterhaltung geladen, entsteht ein größerer Speicherbedarf.

Das Cache-Wachstum verläuft ungefähr linear mit der Länge der beibehaltenen Sequenz

Bei einer festen Modellarchitektur und Cache-Präzision verdoppelt eine Verdopplung der Anzahl beibehaltenen Tokens ungefähr die Anzahl der KV-Einträge für diese Anfrage. Sowohl der Prompt als auch die generierte Antwort zählen zur aktiven Sequenz.

H2O beschreibt, wie der KV-Cache mit der Sequenzlänge und der Batchgröße skaliert. Der Zusammenhang bleibt ungefähr linear, weil jedes zusätzliche Token auf jeder Cache-erzeugenden Ebene Keys und Values beisteuert.

Deshalb kann die Erhöhung einer Laufzeiteinstellung von einem kleinen Kontext auf ein deutlich größeres Maximum die praktische Speichergrenze verändern, selbst wenn das Modell identische Gewichte verwendet.

Die Maximaleinstellung und die tatsächliche Nutzung sind nicht dasselbe. Manche Laufzeitumgebungen reservieren Cache-Blöcke bei Bedarf, während andere frühzeitig einen größeren Bereich reservieren, um künftiges Wachstum zu garantieren.

Die Modellarchitektur verändert die Byte-Anzahl pro Token

Zwei Modelle mit derselben Parameteranzahl können unterschiedlich viel KV-Speicher benötigen, da sie eine unterschiedliche Anzahl von Ebenen, Head-Dimensionen, Attention-Heads, Grouped-Query-Attention oder Multi-Query-Attention verwenden können.

KIVI untersucht die KV-Cache-Präzision und zeigt, dass die Speicherung von Keys und Values mit weniger Bits den Spitzenbedarf an Speicher deutlich reduzieren kann. Dieser Vorteil betrifft den Anfragezustand und verkleinert nicht die zugrunde liegenden Modellgewichte.

Grouped-Query- und Multi-Query-Architekturen teilen Key-Value-Heads über mehrere Query-Heads hinweg, wodurch im Vergleich zu vollständiger Multi-Head-Attention weniger Cache-Bytes pro Token anfallen können. Die Anzahl der Ebenen und die Head-Breite vervielfachen den beibehaltenen Zustand weiterhin.

Eine brauchbare Schätzung muss daher die exakte Modellarchitektur und das Cache-Format der Laufzeitumgebung berücksichtigen und darf sich nicht nur auf eine allgemeine Bytes-pro-Token-Regel stützen, die von einem anderen Modell übernommen wurde.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Generierte Tokens erweitern den Cache auch nach dem Prefill weiter

Die Prompt-Verarbeitung erstellt den initialen Cache für den Eingangskontext. Beim autoregressiven Decoding wird anschließend für jedes akzeptierte Ausgabe-Token ein weiterer Zustand angefügt, damit spätere Tokens auf die vollständige Unterhaltung zugreifen können.

vAttention behandelt das dynamische Cache-Wachstum als Zuweisungsproblem, da die endgültige Ausgabelänge beim Start einer Anfrage unbekannt ist. Eine zu große Reservierung verschwendet Speicher, während eine zu kleine Reservierung eine Verdrängung oder zusätzliche Erweiterungsarbeit erzwingen kann.

Ein problemlos passender Prompt kann während einer langen Antwort trotzdem die Speichergrenze überschreiten. Ausgabelimits schützen daher sowohl den Speicher als auch die Antwortlänge und die Generierungszeit.

Gleichzeitige Nutzer vervielfachen den separaten Kontextzustand

Die Modellgewichte können von mehreren Anfragen gemeinsam genutzt werden, aber jede aktive Unterhaltung verfügt normalerweise über ihre eigene Token-Historie und ihren eigenen KV-Cache. Fünf Nutzer mit langen Kontexten teilen sich nicht einfach einen universellen Cache, nur weil sie dasselbe Modell verwenden.

Aktuelle Forschung zur KV-Verwaltung betrachtet Reservierungen pro Anfrage als zentralen Zielkonflikt zwischen Speichereffizienz und Verdrängungsrisiko. Unbekannte Ausgabelängen machen den kombinierten Spitzenbedarf schwerer vorherzusagen als eine einfache Nutzeranzahl.

Gemeinsam genutzte Prompt-Präfixe können manchmal wiederverwendet werden, wenn die Laufzeitumgebung eine exakte Präfixübereinstimmung unterstützt. Private Chatverläufe und unterschiedliche Ausgaben erzeugen jedoch weiterhin separate Zweige.

Der Hardware-Leitfaden von ZimaSpace betrachtet Kontext und Parallelität als Speicheranforderungen zusätzlich zur Modelldatei. Ein Test mit nur einem Nutzer kann daher den benötigten RAM- oder VRAM-Bedarf eines Haushaltsassistenten unterschätzen.

Paging, Quantisierung und Verdrängung verändern die Grenze, nicht die Ursache

Die seitenbasierte Zuweisung reduziert Fragmentierung, indem sie den Cache-Zustand in kleinere Blöcke aufteilt. Dadurch benötigt die Laufzeitumgebung keine übergroße zusammenhängende Reservierung für jede mögliche Sequenz.

PagedAttention ermöglicht eine blockbasierte Zuweisung, während die Cache-Quantisierung die Byte-Anzahl pro gespeichertem Wert reduziert und Verdrängungsrichtlinien ausgewählte alte Einträge entfernen. Jede Methode verändert, wie viel Kontext hineinpasst, aber der beibehaltene Attention-Zustand wächst weiterhin, während sich Tokens ansammeln.

Verdrängung oder gleitende Fenster können den Speicherbedarf begrenzen, indem frühere Tokens entfernt werden. Das Modell kann dann jedoch nicht mehr über den normalen vollständigen Kontextpfad auf den verworfenen Zustand zugreifen. Komprimierung und selektive Beibehaltung können ebenfalls Qualitäts- oder workloadabhängige Kompromisse mit sich bringen.

Messen Sie die Cache-Nutzung mit dem tatsächlichen Modell, Kontext, der Cache-Präzision, Batchgröße und Nutzeranzahl. Die praktische Grenze ist erreicht, wenn ein weiteres Token oder eine weitere Anfrage nicht mehr zugelassen werden kann, ohne Verdrängung, Auslagerung, Neuberechnung oder einen Fehler auszulösen.

FAQ

Wird die Modelldatei größer, wenn die Kontextlänge steigt?

Nein. Die Modellgewichte bleiben unverändert. Der zusätzliche Speicher wird durch den Laufzeitstatus für den aktiven Prompt und die generierten Tokens belegt.

Wird bei der Einstellung eines großen maximalen Kontexts sofort der gesamte KV-Speicher reserviert?

Nein. Das Verhalten hängt von der Laufzeitumgebung ab. Manche reservieren die Kapazität frühzeitig, während seitenbasierte Systeme Blöcke zuweisen, sobald Tokens zugelassen werden.

Kann der System-RAM den KV-Cache aufnehmen, wenn der VRAM voll ist?

Einige Laufzeitumgebungen können den Cache auslagern oder verschieben. Übertragungen erhöhen jedoch die Latenz und hängen von der Softwareunterstützung, der Bandbreite und dem aktiven Attention-Pfad ab.