Warum dieselbe KI-Anfrage zwei Geschwindigkeiten hat

Was ist der Unterschied zwischen Prefill und Decode?

Prefill verarbeitet den gesamten Prompt in einem einzigen parallelen Rechenschritt und legt fest, wie lange man auf das erste Wort wartet. Decode erzeugt danach jedes weitere Wort einzeln und legt fest, wie schnell die Antwort weiterläuft. Beide Phasen laufen an unterschiedlichen Grenzen.

Zwei Anfragen an dasselbe Modell. Dieselbe Hardware, derselbe Tag. Die eine Antwort kommt sofort, tröpfelt dann aber quälend langsam. Die andere lässt lange auf sich warten, läuft danach zügig durch.

Gleiches Modell, gleiches System, zwei völlig unterschiedliche Wartegefühle. Zufall ist das nicht. Es liegt daran, wie lang der Prompt ist. Und wie lang die Antwort wird. Hinter jeder Anfrage stecken zwei verschiedene Arbeitsschritte, in zwei verschiedenen Tempi.

Erst alles auf einmal, dann Wort für Wort

Den Prompt verarbeitet das Modell in einem einzigen Durchlauf: alle Tokens gleichzeitig, in einem parallelen Rechenschritt. Je länger der Prompt, desto mehr Arbeit steckt in diesem einen Durchlauf. Das ist die Wartezeit vor dem ersten Wort.

Die Antwort entsteht anders. Das Modell erzeugt genau ein Token, schaut auf alles, was inzwischen dasteht, und erzeugt erst dann das nächste. Jedes weitere Wort kostet einen eigenen Schritt. Das ist das Tröpfeln danach.

Diese zwei Phasen haben Namen: Prefill und Decode.

Hier sitzt dieser Begriff in der Serie:

Für die Technik-Tiefe

Beim Prefill verarbeitet das Modell alle Prompt-Tokens gleichzeitig in einem einzigen Rechendurchlauf. Das sättigt die Matrix-Multiplikationseinheiten der GPU vollständig: die Phase ist rechengebunden (compute-bound) und bestimmt die Time to First Token (TTFT).

Beim Decode entsteht jeweils genau ein neues Token pro Schritt. Jeder Schritt liest dafür die kompletten Modellgewichte und den KV-Cache erneut aus dem Speicher, bei vergleichsweise wenig Rechenarbeit pro gelesenem Byte. Die Phase ist speichergebunden (memory-bound) und bestimmt die Zeit zwischen zwei Tokens (Inter-Token Latency, ITL, auch Time per Output Token, TPOT).

Wie stark eine Phase welche GPU-Ressource sättigt, lässt sich als arithmetische Intensität ausdrücken: Rechenoperationen pro bewegtem Byte. Das Roofline-Modell trägt diese Intensität gegen die erreichbare Leistung auf. Hohe Intensität (Prefill) trifft die Rechengrenze, niedrige Intensität (Decode) trifft die Speichergrenze. Genau diese eine Unterscheidung erklärt, warum eine Optimierung wie Quantisierung oder Continuous Batching der einen Phase hilft und der anderen kaum.

Dieser Begriff baut auf dem KV-Cache auf: Warum ein Modell teurer wird, je länger es spricht

Wo es bricht

Wer Kapazität nur über eine einzige Kennzahl namens “Antwortzeit” plant, optimiert regelmäßig am falschen Hebel. Mehr parallele Anfragen im Batch erhöhen den Gesamtdurchsatz. Das hilft vor allem, wenn viele Anfragen mit kurzen Prompts anstehen, also bei Decode-lastigen Anfragen. Wartet ein Nutzer aber auf die Zusammenfassung eines langen Vertrags, zählt vor allem, wie schnell das erste Wort kommt, also die Prefill-lastige Seite. Mehr Batching kann genau das verschlechtern, weil die Anfrage länger in der Warteschlange steht.

Für deutsche Unternehmen kommt ein zweiter Effekt dazu: deutsche Fachtexte mit zusammengesetzten Substantiven und Umlauten zerfallen in gängigen Tokenizern in spürbar mehr Tokens als derselbe Inhalt auf Englisch. Ein einzelnes Wort zeigt es: Auftragsverarbeitungsvertrag zerfällt in cl100k, dem Tokenizer der GPT-4-Generation von 2023, in acht Teile, nämlich Auf, tr, ags, ver, arbeit, ungs, ver, trag. Das englische data processing agreement wird genauso zerlegt, aber jedes der drei Wörter ist als eigenes Token im Vokabular: drei Tokens gesamt. Neuere Tokenizer verkleinern den Abstand, im selben Beispiel auf sechs zu drei, weg ist er nicht. Das verlängert vor allem den Prompt, also die rechengebundene Prefill-Phase. Wer die Kosten eines KI-Projekts an englischen Benchmarks bemisst, unterschätzt regelmäßig, wie viel mehr Prefill-Arbeit ein deutscher Vertrag oder ein deutsches Protokoll erzeugt.

Die Abhilfe ist, TTFT und ITL getrennt zu messen statt einer verschwommenen “Antwortzeit”, und Kapazität nach Goodput zu planen: dem Anteil des Durchsatzes, der die eigenen Latenz-Vorgaben tatsächlich einhält. Die konkreten Stellschrauben dafür, Continuous Batching und Paged Attention, sind eigene Kapitel dieser Serie.

Prefill verarbeitet den Prompt auf einmal, Decode erzeugt die Antwort Wort für Wort. Wer beide mit derselben Zahl misst, optimiert am falschen Hebel.

Nächster Begriff: Sampling, Temperature und Top-p. Warum dasselbe Modell auf dieselbe Frage nie exakt dieselbe Antwort gibt.

Häufige Fragen

Was ist der Unterschied zwischen Prefill und Decode? Prefill verarbeitet den kompletten Prompt in einem parallelen Rechendurchlauf und bestimmt, wie lange es bis zum ersten Wort der Antwort dauert. Decode erzeugt danach jedes weitere Token einzeln und bestimmt, wie schnell die Antwort danach weiterläuft.

Was ist TTFT (Time to First Token)? TTFT ist die Wartezeit vom Absenden einer Anfrage bis zum ersten sichtbaren Wort der Antwort. Sie wird von der Prefill-Phase bestimmt.

Warum braucht Decode pro Token länger als Prefill pro Token? Prefill verarbeitet alle Prompt-Tokens gleichzeitig und nutzt damit die volle Rechenleistung der GPU aus. Decode erzeugt ein Token nach dem anderen und muss dabei bei jedem einzelnen Schritt die kompletten Modellgewichte und den KV-Cache neu aus dem Speicher lesen.

Was bedeutet “compute-bound” und “memory-bound”? Compute-bound heißt, die Rechenleistung der GPU ist der Engpass. Memory-bound heißt, die Geschwindigkeit, mit der Daten aus dem Speicher gelesen werden, ist der Engpass. Prefill ist typischerweise compute-bound, Decode memory-bound.

Teil der Serie AI-Engineering-Begriffe erklärt. Verwandt: Warum ein Modell teurer wird, je länger es spricht (KV-Cache) und Was kostet ein KI-Projekt im Mittelstand?