Den Speicherbedarf eines Sprachmodells verringern: Die Einsparungen sind geringer, als die Fachartikel vermuten lassen

Wenn ein Sprachmodell einen langen Prompt verarbeitet, speichert es für jedes Token einen Schlüssel und einen Wert. Dieser Speicher heißt KV-Cache. Bei 32.000 Tokens belegt er im getesteten Modell 2,4 GB pro Anfrage. Viele Fachartikel schlagen vor, den Großteil davon zu verwerfen und nur wichtige Tokens zu behalten. Wir haben das auf einer kostenlos verfügbaren GPU getestet und zwei Fragen gemeinsam untersucht, die in den Fachartikeln selten zusammen betrachtet werden: Findet das Modell weiterhin die benötigten Fakten? Und wird der Speicher tatsächlich wieder frei?

Kurze Antwort: bei 25 % und 12,5 % des Caches verlor jede getestete Methode die benötigten Fakten fast jedes Mal.

Wir nutzten Qwen3-4B-Instruct auf einer kostenlos verfügbaren Kaggle-T4. Die Aufgabe war künstlich erstellt: Mehrere Projekteinträge ("Project X has status S and codeword C") waren zwischen thematisch unabhängigen Dokumenten versteckt. Anschließend stellten wir eine Frage zu einem, zwei oder allen drei Einträgen. Entscheidend war die exakte Übereinstimmung des Codeworts. Die Prompts umfassten 8k, 16k und 32k Tokens, mit jeweils 6 Fällen. Der Lauf endete zum vereinbarten Zeitlimit; daher wurden in der 32k-Stufe nur 3 von 6 Fällen abgeschlossen. Insgesamt liegen 255 von 306 geplanten Ergebnissen vor. Für jede unten gezeigte Kombination aus Auswahlverfahren und Speicherbudget gibt es 15 Fragen.

Wir verglichen sechs Auswahlmethoden: keine Eviction, ein Sliding Window, zufällige Tokens, einen Key-Norm-Score und unsere eigenen Re-Implementierungen der SnapKV- und H2O-Scoring-Ideen. Jede lief auf Token-Ebene und auf Page-Ebene (Blöcke von 16 Tokens).

Quelle: aufgezeichnete Ergebnisse des Laufs, 255 Datensätze. Das 12,5-%-Budget ist schlechter: 0 oder 1 richtig von 15 für jede Methode.

Mit vollem Cache beantwortete das Modell 15 von 15. Mit einem Viertel davon schafften die besten Methoden 2 von 15. Die typische falsche Antwort behielt den Projektnamen, erfand aber die Ziffern, zum Beispiel „cobalt-381“ statt „cobalt-2609“. Unsere Lesart: das Scoring behält die Bedeutung eines Tokens und verwirft die seltene Zahl, die die Antwort trägt. Das ist eine Hypothese aus diesen Läufen, kein getesteter Mechanismus.

Inferenz-Server speichern den Cache in Seiten von 16 Tokens. Eine Seite kann nur wiederverwendet werden, wenn alle ihre 16 Tokens weg sind. Löscht man verstreute Tokens, wird viel weniger frei als gedacht. Wir haben diese Buchführung auf denselben Läufen simuliert. Die seitenorientierten Methoden geben fast alles frei, verloren aber die Antwort. Die Methoden, die etwas Genauigkeit behielten, gaben weit weniger frei.

Quelle: simulierte 16er-Block-Seiten-Buchführung auf den aufgezeichneten Läufen (Mittel von 30 Fällen pro Methode). Keine Messung auf einem echten Paging-Server. Jede Scoring-Methode entfernte logisch etwa 1962 MB pro Frage, 320 MB frei bedeutet also 16 % davon. Die Window-Methode entfernte logisch 2376 MB pro Frage, und 2373 MB davon wurden ganze Seiten (der geplottete Wert). Warum sie mehr entfernt als die anderen Methoden wurde nicht geprüft; daher ist beim Vergleich Vorsicht geboten.

Noch ein Ergebnis. Im von uns verwendeten statischen Hugging-Face-Cache wurde das Decoding nach der Eviction nicht schneller (etwa 1510 bis 1640 ms pro Token). Das heißt, die Bibliothek berechnet weiterhin die Attention über die volle Breite. Es heißt nicht, dass sich ein Paging-Server genauso verhalten würde.

• Ein offenes 4B-Modell auf einer kostenlosen T4. Das sagt nichts über Frontier-Modelle aus.
• SnapKV und H2O sind hier unsere Re-Implementierungen, ohne Abgleich mit den publizierten Zahlen.
• Freigegebene Seiten sind simuliert. Auf der GPU wurde nur die Cache-Allokation gemessen.
• Die 32k-Stufe ist zur Hälfte fertig. Alle abgeschlossenen 32k-Fälle scheiterten ebenfalls.
• Nur eine künstlich erstellte Aufgabenlast. Reale Aufgaben könnten weniger empfindlich sein.

Was dies stützt: eine Frage, die sich zu testen lohnt. Eine Methode müsste ganze Seiten auswählen und Zahlen und Namen behalten. Eine solche haben wir nicht gebaut.