localaiforum
Anmelden
Guide › Hardware

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 8192 kostet 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