Warum der 2. Token schneller ist als der 1.

Die Illusion der Antwortzeit

Du stellst ChatGPT eine Frage. Es braucht eine Sekunde, um zu antworten. Dann kommen die Wörter fast augenblicklich, in der Geschwindigkeit einer schnellen Lektüre.

Diese Asymmetrie ist keine Spielerei der Oberfläche. Sie ist der Fingerabdruck einer fundamentalen Optimierung, ohne die Texterzeugung mit einem LLM hundertmal teurer wäre: der KV-Cache.

Wie ein Transformer einen Token erzeugt

Bei jedem Generierungsschritt muss der Transformer einen neuen Token produzieren. Dafür berechnet er die Attention des letzten Tokens auf alle vorherigen Tokens. So kann er den gesamten Kontext berücksichtigen.

Aber Attention erfordert für jeden Token im Kontext zwei Vektoren: einen Key (K) und einen Value (V). Ohne Optimierung berechnet das Modell bei jedem neu erzeugten Token K und V für die gesamte Sequenz neu — einschließlich der Tokens, die im vorherigen Schritt bereits verarbeitet wurden. Das ist eine Arbeit von O(n²) über die Länge der Sequenz: Eine Verdopplung der Token-Anzahl vervierfacht die Kosten.

Das ist sinnlos: Diese Vektoren haben sich nicht geändert. Token Nr. 3 hat denselben Key K₃ wie im vorherigen Schritt.

Der KV-Cache: nie neu berechnen, was man schon hat

Die Idee ist trivial und entscheidend. Man behält im Speicher (auf der GPU) die K und V aller bereits verarbeiteten Tokens. Bei jedem neuen Generierungsschritt berechnet man nur den K und V des neuen Tokens und fügt ihn dem Cache hinzu.

Die Attention betrachtet dann den vollständigen Cache, aber die Berechnung in diesem Schritt ist O(1) in der Größe — nicht O(n).

Ohne Cache berechnet jedes neue Token die gesamte Attention über das Präfix neu — O(n²)-Kosten. Mit Cache wird nur die neue Zeile berechnet. Das ist der Unterschied zwischen dem ersten (langsamen, Prefill) und dem zweiten Token (schnellen, Decode).

Links, ohne Cache: Jeder Schritt zeichnet alle Zeilen neu. Rechts, mit Cache: Es wird einfach eine Zeile hinzugefügt. Nach einigen Tokens wird die Differenz in den kumulierten Operationen erheblich.

Prefill vs. Decode: zwei klar getrennte Phasen

Die Generierung mit einem LLM gliedert sich in zwei Phasen, die Inference-Engineers sorgfältig unterscheiden.

Prefill. Das Modell empfängt den vollständigen Prompt und berechnet K und V für alle seine Tokens parallel. Das ist schnell in Bezug auf den Durchsatz — die GPU ist ausgelastet — aber es dauert, wenn der Prompt lang ist. Das bestimmt die TTFT (Time To First Token), die Verzögerung, bevor das erste Wort erscheint.

Decode. Das Modell erzeugt den Rest, einen Token nach dem anderen, indem es den Cache wiederverwendet. Jeder Schritt ist einzeln schnell, aber sequentiell: Die kommenden Tokens lassen sich nicht parallelisieren, da jeder vom vorherigen abhängt. Das bestimmt die ITL (Inter-Token Latency).

Diese beiden Phasen haben völlig unterschiedliche Profile:

	Prefill	Decode
Parallelisierbar?	Ja (alle Tokens auf einmal)	Nein (sequentiell)
Hardware-Limit	Compute (FLOPs)	Speicher (Cache-Lesen)
Längeneffekt	Linear in N	Linear in N pro Token
Schlüsselmetrik	TTFT	ITL

Bei einem langen Prompt kann der Prefill mehrere Sekunden dauern. Bei einer langen Ausgabe dominiert das Decode — und es ist begrenzt durch die Geschwindigkeit, mit der man den KV-Cache aus dem HBM-Speicher der GPU lesen kann.

Warum die Provider „Input-Tokens" anders abrechnen

Wenn du dir die Preise von OpenAI, Anthropic oder Google ansiehst, sind Input-Tokens systematisch günstiger als Output-Tokens — oft 4× bis 5× günstiger. Das ist nicht willkürlich. Der Prefill, der die Input-Tokens verarbeitet, ist massiv parallel und nutzt die GPU effizient. Das Decode hingegen erzeugt die Output-Tokens einzeln und lastet die Hardware schlecht aus.

Subtiler: Anthropic, OpenAI und andere bieten jetzt Prefix Caching an. Wenn mehrere Anfragen mit demselben System-Prompt beginnen, berechnet man den KV-Cache dieses Präfixes einmalig und verwendet ihn wieder. Das ist es, was Agenten und Multi-Turn-Chatbots wirtschaftlich tragfähig macht: Ohne Präfix-Cache würde jede Runde die vollständige Neuberechnung der gesamten Konversation kosten.

Die versteckten Kosten: GPU-Speicher

Der KV-Cache ist nicht gratis im Speicher. Er belegt:

speicher = 2 × n_layers × n_heads × d_head × seq_len × batch_size × 2 bytes (FP16)

Bei einem Modell mit 70 Milliarden Parametern, einem Kontext von 128.000 Tokens und einem Batch von 1 sprechen wir von mehreren Dutzend GB. Das ist oft das, was die praktikable Kontextlänge begrenzt, mehr als die Fähigkeit des Modells selbst, über die Sequenz nachzudenken.

Um weiterzukommen, gibt es mehrere Techniken:

• Cache-Quantisierung: K und V in INT8 oder INT4 statt in FP16 speichern, was den Speicher um den Faktor 2 oder 4 reduziert.
• MQA / GQA (Multi-Query / Grouped-Query Attention): K/V zwischen mehreren Heads teilen. Llama 2 70B und Llama 3 verwenden GQA, was die Cache-Größe drastisch reduziert.
• Sliding Window Attention: nur ein aktuelles Fenster des Caches behalten (Mistral, Gemma).
• PagedAttention (vLLM): den Cache wie virtuelle Speicherseiten behandeln, um dynamisches Batching besser zu verwalten.

Quantisierung, in zwei Worten

Das Wort taucht überall in diesem Teil auf: QLoRA in 4 Bit (Kapitel 14), Cache-Quantisierung gerade eben, GGUF-Modelle, die du dir von Hugging Face herunterlädst. Höchste Zeit zu erklären, was das bedeutet.

Quantisieren heißt, jeden Modellparameter mit weniger Bits darzustellen. Eine 32-Bit-Gleitkommazahl (FP32) belegt 4 Bytes. In FP16 sind es 2 Bytes. In INT8 1 Byte. In INT4 ein halbes Byte — der Speicher für die Gewichte wird im Vergleich zum ursprünglichen FP32 durch 8 geteilt.

Präzision	Bytes / Parameter	70B-Modell belegt
FP32	4	280 GB
FP16 / BF16	2	140 GB
INT8	1	70 GB
INT4	0,5	35 GB
INT2 (extrem)	0,25	17,5 GB

Der Trick: Ein Gewicht von 0,237 wird in INT4 (das nur 16 mögliche Werte hat) nicht exakt zu 0,237, sondern zum nächstgelegenen Wert auf einem diskreten Raster. Der Qualitätsverlust hängt vom Modell und der Methode ab, ist aber typischerweise klein bis hinunter zu INT8, moderat bei INT4 (ein paar % Einbußen auf Benchmarks), deutlich darunter.

Moderne Techniken (GPTQ, AWQ, GGUF) quantisieren nicht alle Gewichte gleich — sie bewahren die Präzision sensibler Schichten und komprimieren die anderen aggressiver. Und die oben erwähnte KV-Cache-Quantisierung wendet genau dieselbe Idee auf die während der Generierung im Speicher gehaltenen Aktivierungen an.

Das ist die Technik, die es erlaubt, Llama 70B auf einem MacBook mit 64 GB RAM laufen zu lassen, wo die FP16-Version einen Cluster braucht.

Die Lektion

Ohne den KV-Cache wären LLMs in Produktion unpraktikabel. Eine lange Konversation, ein Agent, der nachdenkt, ein Chatbot, der sich daran erinnert, was du fünf Nachrichten zuvor gesagt hast — nichts davon wäre wirtschaftlich tragfähig.

Aber dieser Cache ist auch das, was die Kontextlänge einschränkt. Wenn man von einem „Fenster von 1 Million Tokens" spricht, ist das größtenteils ein Cache-Speicher-Problem, kein Problem der Attention-Berechnung.

Der KV-Cache ist nicht eine Optimierung unter anderen. Er ist das, was Attention von einem theoretischen Mechanismus in eine produktionstaugliche Infrastruktur verwandelt.

Aktualisiert am 10. Mai 2026