Kontextfenster & der KV-Cache
Das Kontextfenster hat ein Preisschild, und es wird in VRAM bezahlt. Jedes im
Kontext behaltene Token zwingt das Model, sich zwei kleine Vektoren pro Layer zu
merken, und dieser Speicher — der KV-Cache — wächst mit jedem Token und frisst
leise die Reserve, von der Sie dachten, Sie hätten sie. Er erklärt die seltsamsten
lokalen LLM-Fehler: das OOM in Runde vierzig, das Model, das langsamer zu werden
schien, je länger der Chat wuchs, die 8-GB-Karte, die „128k Kontext“ nur im
Datenblatt fährt.
Was der Cache speichert
Attention braucht die Key- und Value-Projektion jedes vergangenen Tokens, bevor sie
auf dieses Token attendieren kann. Sie werden einmal während des Prefills berechnet
und für die Lebensdauer der Anfrage gehalten: pro Layer, pro Token, ein K-Vektor
und ein V-Vektor aus je kv_heads × head_dim Zahlen. Dieser Speicher ist der
KV-Cache, und er ist der Grund, warum Kontext für jede bediente Anfrage linear,
für immer, Speicher kostet.
Die Formel
bytes per token = 2 (K and V) × layers × kv_heads × head_dim × 2 bytes (fp16)
Durchgerechnet, GQA der Llama-3-8B-Klasse (32 Layer, 8 KV-Heads, head_dim 128):
2 × 32 × 8 × 128 × 2 = 131.072 Bytes = 128 KB pro Token.
Bei 32k Kontext sind das 32.768 × 128 KB ≈ 4 GB KV-Cache — vergleichbar mit den
Q4-Gewichten daneben. Schlankere Konfigurationen mit 4 KV-Heads landen nahe 2 GB
pro 32k. Größenordnung für 8B-Klasse-Modelle bei fp16-KV: Planen Sie 0,5–4 GB pro
32k je nach Architektur. Exakte Zahlen für einen Checkpoint stammen direkt aus
seiner config.json — num_key_value_heads, num_hidden_layers und Head-Größe.
GQA ist der Grund, warum langer Kontext billig wurde
Grouped-Query-Attention teilt eine Handvoll KV-Heads über viele Query-Heads —
sagen wir 32 Query-Heads, bedient von 8 KV-Heads — und schrumpft den Cache um 4×
gegenüber voller Multi-Head-Attention bei vernachlässigbaren Qualitätskosten. Ohne
GQA wäre die Tabelle unten 4–8× größer, und langer Kontext auf einer 24-GB-Karte
wäre eine Fantasie. Sie ist das größte einzelne architektonische Geschenk an lokale
Langkontext-Arbeit und der Grund, warum moderne 7–9B-Modelle überhaupt
32k–128k-Fenster ausliefern.
Wie schnell er wächst
Ein GQA-Modell der 8B-Klasse bei fp16-KV, 128 KB pro Token:
| Kontext | KV-Cache-Größe | Auf einer 8-GB-Karte |
|---|---|---|
| 4k | ~0,5 GB | unsichtbar |
| 16k | ~2,1 GB | spürbar neben 5 GB Gewichten |
| 64k | ~8,4 GB | passt nicht, Punkt |
| 128k | ~16,8 GB | 3× das Model selbst |
Der Speicher wächst linear pro Token, aber die Attention-Rechenleistung wächst mit
dem Quadrat des Kontexts — lange Kontexte kosten also gleichzeitig VRAM und Zeit
pro Token.
Hebel, wenn KV explodiert
- Den Cache quantisieren. q8_0 halbiert ihn, q4_0 viertelt ihn, bei moderaten
Qualitätskosten — oft der beste Kapazitätsdeal im ganzen Stack. In llama.cpp
braucht die KV-Quantisierung Flash Attention, unten gezeigt. - Kürzeren Kontext serven.
-c 8192kostet nichts, wenn Ihre Prompts 2k sind.
Die beworbenen 128k „für alle Fälle“ zu allocieren reserviert VRAM, den Sie nie
produktiv nutzen werden. - Sliding-Window-Modelle. Manche Architekturen deckeln das KV-Fenster pro Layer
unabhängig vom nominalen Kontext — Langkontext-Verhalten ohne die lineare
Rechnung, mit etwas Recall-Verlust auf altem Material. - Flash Attention. Im Kern ein Gewinn an Rechenleistung und Kernel-Effizienz —
exakte Attention ohne die quadratische Aktivierungs-Explosion — und in llama.cpp
zugleich das Tor, das die KV-Quantisierung freischaltet.
llama-server -m model-8b-q4_k_m.gguf -c 65536 -fa --cache-type-k q8_0 --cache-type-v q8_0
Beworbener vs. effektiver Kontext
Ein Model, das 128k bewirbt, läuft bei 128k — der Cache passt und die Mathematik
geht. Ob es bei 128k denkt, ist eine andere Behauptung. Gestrecktes RoPE und
Langkontext-Fine-Tuning halten Needle-Retrieval-Scores hoch, während das breitere
Verständnis oft lange vor dem Limit erschlafft. Behandeln Sie das beworbene Fenster
als physisches Maximum, nehmen Sie an, dass die Qualität in der letzten Hälfte
weicher wird, und suchen Sie nach Community-Langkontext-Evals des konkreten
Checkpoints, bevor Sie einen Workflow darauf verwetten.
Lost in the Middle, und Hygiene-Gewohnheiten
Der Positions-Bias ist real: Modelle attendieren am stärksten auf Anfang und Ende
des Prompts und erschlaffen in der Mitte. Setzen Sie Anweisungen und kritische
Fakten nach vorn oder hinten; vergraben Sie nie die Spezifikation, der das Model
folgen soll, in einem eingefügten Dokument. Gewohnheiten, die Kontexte klein und
scharf halten:
- Alte Runden kürzen oder zusammenfassen, statt den ganzen Chat erneut zu senden.
- Den relevanten Chunk abrufen und injizieren, nicht die gesamte Datei.
- Halten Sie den System-Prompt kurz; er wird mit jeder Anfrage erneut gesendet.
- Beobachten Sie den VRAM in langen Sitzungen — KV-Wachstum ist die stille
Variable (VRAM-Mathematik), und die Serving-Flags, die es
steuern, sind in Engine-Regler katalogiert.
Verwandt: VRAM-Mathematik · Engine-Regler ·
Geschwindigkeit