128k Kontext auf dem Desktop ist gelogen. Der KV-Cache frisst ihn.

Jede Modellkarte prahlt inzwischen mit einem 128k-Kontextfenster. Auf dem Desktop ist diese Zahl ein Mietvertrag, den dein RAM unterschreibt, ohne ihn zu lesen. Was entscheidet, wie weit du ein langes Dokument tatsächlich schieben kannst, sind nicht die Gewichtungen — es ist der KV-Cache, und er skaliert mit dem Kontext wie eine Steuer in fremder Währung.

Das Kontextfenster ist kein Feature, das du umlegst. Es ist ein Speichermietvertrag, den du jede Sekunde bezahlst, solange der Server läuft.

Wie viel RAM frisst ein 128k-Kontext wirklich?

Die Arithmetik ist öffentlich und kurz. Wie Transformer Inference Arithmetic ausführt, hält der KV-Cache zwei Tensoren — Keys und Values — für jede Schicht, jeden KV-Kopf, jede Token:

cache_bytes = 2 × Layer × Kontext × KV-Köpfe × head_dim × Bytes_pro_Element

Nimm Llama 3.1 8B: 32 Layer, 8 KV-Köpfe, head_dim 128, direkt aus der config.json auf Hugging Face. Bei 131.072 Tokens in fp16 (2 Bytes):

2 × 32 × 131072 × 8 × 128 × 2 = 17.179.869.184 Bytes ≈ 16 GiB

Die Gewichtungen desselben Modells in fp16 wiegen etwa 16 GiB. Bei maximalem Kontext ist der Cache so groß wie das Modell, zu dem er gehört. Aus dem „8B-Modell, das in 16 GiB passt” wird still ein 32-GiB-Problem, sobald du num_ctx auf 128k setzt.

Warum wächst der Cache mit dem Fenster?

Weil Attention jedes Token mit allen vorherigen vergleichen muss und Inferenz autoregressiv ist — nichts wird neu berechnet, alles wird behalten. Das ist der ganze Trick, der Generierung schnell macht: Keys und Values jedes Token werden einmal berechnet und gespeichert. Der Speicher pro Token ist konstant, also ist der Gesamtbedarf linear im Kontext. 128k ist keine „größere Zahl” — es ist das 128-fache des Caches eines 1k-Fensters, allokiert für die gesamte Sitzung.

Grouped-Query-Attention (GQA) ist der Rabatt auf Modellseite: weniger KV-Köpfe, schlankerer Cache. Qwen2.5 7B nutzt 28 Layer mit nur 4 KV-Köpfen (config hier), also kostet dasselbe 128k-Fenster etwa 7 GiB in fp16 — echte Erleichterung, und ein Grund, warum sich diese Modelle auf bescheidenen Maschinen großzügiger anfühlen.

Modell (fp16)	Layer × KV-Köpfe	KV-Cache @ 128k	Gewichtungen	Cache vs. Gewichtungen
Llama 3.1 8B	32 × 8	~16 GiB	~16 GiB	~100 %
Qwen2.5 7B	28 × 4	~7 GiB	~15 GiB	~47 %

Rechne selbst nach — das ist die ganze Prüfung:

def kv_cache_gib(layers, kv_heads, head_dim, ctx, bytes_per=2):
    return 2 * layers * ctx * kv_heads * head_dim * bytes_per / 2**30

print(kv_cache_gib(32, 8, 128, 131_072))  # Llama 3.1 8B  -> 16.0
print(kv_cache_gib(28, 4, 128, 131_072))  # Qwen2.5 7B    -> 7.0

Was die Marketingzahl verschweigt

Hier ist das ehrliche Verzeichnis dieses Arguments — inklusive der Stellen, an denen es sich biegt:

• Prefill ist die zweite Rechnung. Bevor das erste Antwort-Token kommt, wird der ganze Prompt auf einmal verarbeitet. Ein 100k-Prompt bedeutet 100k Tokens kauen, bevor das erste Zeichen erscheint. Auf einer 3060 sind das Minuten, keine Millisekunden.
• Sliding-Window-Modelle brechen die Rechnung — zu deinen Gunsten. Mistral-artige Architekturen begrenzen Attention auf ein festes Fenster pro Schicht, der Cache hört auf zu wachsen. Die einfache Formel überschätzt sie. Dieser Post gilt Full-Attention-Transformern, also dem Großteil dessen, was Leute laufen haben.
• KV-Quantisierung ist echt, aber Teilbank. llama.cpp kann den KV-Cache in q8_0 halten, etwa halbiert bei etwas Qualitätsrisiko. Die Hälfte von 16 GiB sind immer noch 8 GiB.
• Specs nennen selten KV-Köpfe. Du wirst in der config.json graben müssen, was etwas darüber sagt, wie die Zahl gelesen werden soll.

Nichts davon macht langen Kontext nutzlos. RAG existiert genau deshalb, weil ein volles Fenster die teure Art ist, „lies Abschnitt 4” zu sagen. Aber eine Karte, die „128k” druckt ohne die Speicherrechnung, verkauft ein Auto über die Höchstgeschwindigkeit und verschweigt den Tank.

Niemand liest 128.000 Token. Dein RAM bezahlt sie trotzdem, jeden einzelnen.

Die Abhilfe ist langweilig: Setz den Kontext auf das, was deine Workload wirklich nutzt. Ein 32k-Fenster kostet ein Viertel des 128k-Caches und deckt fast jeden Prompt ab, den ein einzelner Entwickler tatsächlich schickt. Das ist dieselbe Disziplin wie die RAM-Arithmetik für lokale LLMs — Modellgröße ist nur die Hälfte des Budgets, und Quantisierungsstufen schrumpfen die Gewichtungen, lassen die Cache-Rechnung aber unberührt.

Wenn der Cache der wahre Preis des Kontexts ist — warum verkaufen Modellkarten das Fenster und nie die Rechnung? Und die Beichtstunde: Welchen Kontext hast du tatsächlich bis zum letzten Token gefüllt — und hat der Output die Gigabytes gerechtfertigt? Die Kommentare sind offen; das nächste Stück der Serie nimmt die Seite, die verliert.