KV-Cache auf Diät: Was gelernte „Türsteher“ bei langen Texten vergessen

Darum geht es

Ein Sprachmodell merkt sich beim Lesen jedes Token in einem Zwischenspeicher, dem KV-Cache. Das ist eine Art Notizzettel, auf dem für jedes Wortstück zwei Zahlenreihen stehen, ein „Key“ zum Wiederfinden und ein „Value“ mit dem Inhalt. Dieser Zettel wächst mit jedem Token mit. Bei kurzen Chats fällt das nicht auf, bei einem 300-seitigen Vertrag schon: Auf der eigenen Grafikkarte ist dann meist nicht mehr das Modell zu groß, sondern sein Kurzzeitgedächtnis.

Am 12. November 2026 kamen zwei Meldungen zusammen. Im Reddit-Forum r/LocalLLM stellte ein Entwickler ein selbst trainiertes Lösch-Gate vor, mit dem Qwen3-4B auf einer 16-GB-Karte 123.000 Token liest. Zugleich bekam llama.cpp einen FP8-KV-Cache. Seit dem Sommer sind außerdem mehrere Forschungsarbeiten zu solchen gelernten „Türstehern“ erschienen. Wir erklären die drei Wege, die es derzeit gibt, und sehen genau nach, was die Türsteher dabei vergessen.

Wie groß der Notizzettel wirklich wird

Die Größe lässt sich ausrechnen: Schichten × KV-Köpfe × Kopfdimension × 2 (Key und Value) × Bytes pro Zahl × Token. Für Qwen3-4B ergibt die offizielle Konfiguration (36 Schichten, 8 KV-Köpfe, Dimension 128) 147.456 Byte, also 144 KiB pro Token in 16 Bit. Qwen3-8B hat dieselben Werte und braucht deshalb genauso viel Cache, obwohl das Modell doppelt so groß ist.

*Linear hochgerechnet aus den Angaben im vLLM-Blog (83,9 bzw. 9,62 GiB bei 1 Million Token in bf16). Gemma-Werte nach der Formel aus der Analyse von Kaitchup, ohne mögliche Ersparnis durch die gemeinsame Speicherung von Keys und Values in den globalen Schichten. Alle Werte gelten für 16 Bit und eine einzelne Anfrage.

Ein Beispiel: Qwen3-4B ist als 4-Bit-Datei nur ein paar Gigabyte groß, sein Cache bei 128k aber 18 GiB. Damit ist der Notizzettel mehr als doppelt so groß wie das ganze Modell in voller 16-Bit-Genauigkeit. Das deckt sich mit der Angabe im Reddit-Post, der volle Cache liege bei 61.000 Token bei „etwa 9 GB“ (gerechnet sind es 8,4 GiB).

Weg 1: Kleiner rechnen

Am einfachsten ist KV-Quantisierung. Jede Zahl auf dem Zettel wird gröber gespeichert, mit 8 oder 4 statt 16 Bit. Es bleiben alle Einträge erhalten, sie werden nur ungenauer. In llama.cpp schaltet man das mit -ctk und -ctv um. Laut aktueller Server-Dokumentation stehen f32, f16, bf16, f8_e4m3, q8_0, q4_0, q4_1, iq4_nl, q5_0 und q5_1 zur Wahl. Der FP8-Typ ist neu: PR #28392 von ORippler wurde um den 10. November 2026 gemergt. Laut dem Bericht von Marais Software zielt FP8 auf Nvidia-Karten ab der Ada-Lovelace-Generation, also ab RTX 40. Ein Drittprojekt merkt an, dass es unter Vulkan keinen FP8-Cache gibt. Messwerte zur Qualität enthält der PR nicht.

Unabhängige Zahlen gibt es für die älteren Typen. Der Blog sotaaz hat Qwen3-8B auf einer A100 gemessen. Mit q8_0 stieg die Perplexität (sie misst, wie „überrascht“ das Modell von einem Text ist) um höchstens 0,1 Prozent, mit q4_0 um 0,5 bis 1,1 Prozent. Dafür kostet das Tempo: Mit 64.000 Token im Cache lief die Ausgabe mit q8_0 nur noch mit 56 Prozent der f16-Geschwindigkeit. Seit April 2026 dreht llama.cpp die Werte vor dem Speichern automatisch mit einer Hadamard-Rotation (PR #21038). Dabei werden Ausreißer verteilt, damit sie sich besser runden lassen. Im PR-Thread stieg gpt-oss-20b im Mathe-Test AIME25 mit q4_0-Cache dadurch von 2,0 auf 21,7 Prozent. Für MLA-Modelle gilt das nicht.

Eine wichtige Einschränkung zeigt Microsofts Benchmark SCBench: In Gesprächen mit mehreren Runden hielt die 2-Bit-Quantisierung KIVI bei exakter Textsuche 12,0 Punkte (voller Cache: 57,1). Das klingt schwach, ist aber doppelt so viel wie beim besten Löschverfahren. Unsere Einschätzung: Quantisierung ist der robusteste Weg, weil nichts verschwindet. Sie spart aber höchstens den Faktor 4.

Weg 2: Wegwerfen, zuerst nach festen Regeln

Bei der Eviction (Verdrängung) fliegen ganze Einträge vom Zettel. Die ersten Verfahren arbeiten mit festen Regeln. H2O (2023) behält die zuletzt gelesenen Token und die „Heavy Hitter“, also Token, auf die bisher viel Aufmerksamkeit fiel. SnapKV (2024) schaut, worauf das Ende des Prompts achtet, meist die Frage, und behält das. RazorAttention (2024) unterscheidet nach Köpfen: Wenige „Retrieval-Köpfe“ behalten alles, die übrigen verwerfen Fernes. Die Autoren melden über 70 Prozent Ersparnis ohne Training.

Das Problem zeigt SCBench: Solche Verfahren sind auf die erste Frage zugeschnitten. Mit Llama-3.1-8B und 1/32 Budget fiel SnapKV bei exakter Textsuche in mehrstufigen Gesprächen auf 6,1 Punkte, bei getrennten Anfragen zum selben Dokument auf 0,3 (voller Cache 57,1 bzw. 29,5). Die KVzip-Autoren beschreiben das so, dass frageabhängige Caches sich an die erste Frage „überanpassen“. Eine Studie von Chen und Kollegen zeigt zudem, dass bei Prompts mit mehreren Anweisungen einzelne Anweisungen nach der Kompression praktisch ignoriert werden.

Weg 2b: Gelernte Türsteher

Die neue Generation trainiert ein kleines Zusatznetz, das Gate. Es entscheidet schon beim Schreiben, ob ein Token später noch gebraucht wird. Das Modell selbst bleibt dabei unverändert.

Die Zahl „94 Prozent der Qualität bei 88 Prozent Kompression“ stammt aus dem Fließtext des KVpop-Papers. Die Tabelle desselben Papers ergibt für Qwen3-4B rechnerisch etwa 97 Prozent. Text und Tabelle passen also nicht zusammen. Für Qwen3-8B sank der Speicherbedarf bei 131.000 Token von 36 auf etwa 19 GB. Getestet wurde das allerdings an Mathe-Aufgaben, bei denen das Modell selbst lange Gedankenketten schreibt und alte Zwischenschritte entbehrlich sind.

Was die Gates im Detail verlieren

Nadel im Heuhaufen: RAZOR findet den versteckten Passkey bei 31.000, 61.000, 96.000 und 123.000 Token. Der Cache belegt dabei 0,72 bis 2,84 GB, rund 83 Prozent werden also verworfen. Ein Passkey ist aber nur eine einzige Zahl in Fülltext. Die härtere InfiniteBench-Aufgabe kv_retrieval schafft das Modell mit nur 0,08, genauso schlecht wie mit vollem Cache, bei nur 12 Beispielen pro Aufgabe. Wichtig: Die RULER-Werte entstanden laut README über einen Maskierungspfad, der nichts an Speicher spart. Genauigkeit und Speicherersparnis wurden also in getrennten Läufen gemessen. Alle Zahlen stammen vom Entwickler selbst, das Repo hatte bei unserem Abruf null Sterne, und das Paper liegt noch nicht auf arXiv.

Exakte Suche und Wiederholungen: Das ist die eigentliche Schwachstelle. RAZOR ist laut eigener Aussage schwach bei RULER-cwe, einer Aufgabe, die jedes Vorkommen eines wiederholten Wortes braucht. Bei TrimKV fallen in SCBench alle Verdrängungsverfahren bei der Schlüssel-Wert-Suche auf 0, der volle Cache erreicht 66. Die Autoren nennen solche Aufgaben selbst „inkompressibel“.

Mehrfachfragen: Hier sind die Gates klar besser als die festen Regeln. TrimKV erreicht bei der mehrstufigen Suche in SCBench 49,16 Punkte (voller Cache 49,60, SnapKV 0,31). Im Gedächtnistest LongMemEval fällt es aber von 49,4 auf 44,8 (Budget 32k) bzw. 34,0 (8k). Fast KVzip ist ausdrücklich darauf trainiert, frageunabhängig zu bleiben, und testet mit SCBench und MRCR genau diesen Fall.

Deutsche Texte: Dazu haben wir keine einzige Messung gefunden. Alle Gates wurden mit englischen Daten trainiert und getestet, meist mit Mathe oder englischem Webtext. Unsere Einschätzung: Ob ein Gate, das auf Mathe-Gedankenketten gelernt hat, in einem deutschen Mietvertrag die richtigen Klauseln behält, ist eine offene Frage. Wer so etwas nutzen will, sollte es mit eigenen Dokumenten prüfen.

Weg 3: Gleich eine andere Bauart

Am meisten spart eine Architektur, die von vornherein wenig Cache braucht. MLA (Multi-head Latent Attention) bei DeepSeek speichert pro Token eine stark gepresste Zusammenfassung statt vollständiger Keys und Values. DeepSeek V4 geht weiter: Es fasst 4 bzw. 128 Token zu einem Eintrag zusammen und liest davon nur eine Auswahl (Sparse Attention). Laut vLLM-Blog braucht V4 damit nur etwa ein Neuntel des Caches von V3.2. Hybride Modelle wie Qwen3.5 nutzen in drei von vier Schichten lineare Attention mit festem Zustand, der nicht mitwächst. Gemma 4 lässt die meisten Schichten nur die letzten 1024 Token sehen. Das ist im Grunde Eviction, nur fest eingebaut und mittrainiert.

Was heute mit einem Schalter geht

Ollama nennt q8_0 laut FAQ meist unmerklich und q4_0 bei großen Kontexten spürbarer. Die Umgebungsvariable muss beim Serverdienst gesetzt werden. vLLM empfiehlt für FP8 eine Kalibrierung mit llm-compressor und erlaubt es, empfindliche Schichten wie Sliding-Window-Attention auszunehmen.

Einordnung

Für lokale Nutzer ist die Lage klar sortiert. Unsere Einschätzung: q8_0 oder neu FP8 sind der sichere erste Schritt. Sie halbieren den Cache, kosten kaum Qualität, bremsen aber bei langen Kontexten die Ausgabe. q4_0 ist der Notnagel, wenn sonst gar nichts passt. Den größten Gewinn bringt die Modellwahl: Ein hybrides 4B-Modell braucht bei 128k etwa ein Viertel des Caches eines klassischen.

Die gelernten Gates sind der spannendste Weg, Faktoren von 4 bis 8 sind ohne Umbau des Modells drin. Sie sind aber Forschungscode für einzelne Qwen-Modelle, mit Transformers statt llama.cpp, meist nur mit einer Anfrage gleichzeitig und fast nur mit Herstellerzahlen belegt. Die Schlagzeilen beruhen vor allem auf Mathe-Benchmarks. Bei exakter Suche, Listen mit Wiederholungen und Anweisungen tief im Prompt verlieren die Gates belegbar. Für deutsche Texte gibt es überhaupt keine Daten. Wer heute einen langen Vertrag auf 16 GB durchsuchen will, fährt mit einem quantisierten Cache und einem passenden Modell sicherer als mit einem Türsteher, der vielleicht genau die Klausel weggeworfen hat, nach der man in der dritten Frage sucht.