Kapitel 9 — Spekulatives Dekodieren

Neunter Beitrag im Kapitel-für-Kapitel-Walkthrough zu LLM Primer VI: KI-Systeme skalieren. Das Kapitel zeigt, dass der sequenzielle Engpass der Autoregression ein mathematisches Schlupfloch hat — und rechnet vor, wann es sich lohnt.

Warum es dieses Kapitel gibt

Die Kapitel 7 und 8 griffen die Nebenläufigkeit an und hielten die GPU über viele Sequenzen hinweg beschäftigt. Keins davon ändert die Tatsache, dass jede Sequenz weiterhin ein Ausgabe-Token pro Iteration erhält. Dieser Boden sieht unentrinnbar aus, weil der Forward-Pass des Transformers tatsächlich vom zuvor gewählten Token abhängt. Spekulatives Dekodieren ist die Beobachtung, dass die Abhängigkeit an der Erzeugung hängt, nicht an der Verifikation: gegeben ein Kandidat für Token t+1, kann das Zielmodell einen Forward-Pass ausführen, der zugleich fragt „hätte ich das gewählt?" und die Verteilung für t+2 unter der Annahme berechnet, dass der Kandidat richtig ist. Kapitel 9 geht die Mechanik ab, die Entwurfsalgorithmen (EAGLE, Medusa, Lookahead, MTP, n-Gramm, Suffix) und die Arithmetik, wann Spekulation gewinnt.

9.1 Die Verifikationseinsicht bewahrt die Korrektheit exakt

Ein günstiger Entwurfsmechanismus schlägt N Kandidaten-Tokens vor. Das Ziel — das teure Modell, das wir wollen — führt einen Forward-Pass auf dem Präfix, konkateniert mit den N Kandidaten. Weil der Forward-Pass eines Transformers positionsparallel ist, erzeugt das Ziel in genau diesem Durchlauf seine eigene Next-Token-Verteilung an jeder der N+1 Positionen. Das längste Präfix, auf dem die Kandidaten mit dem Ziel übereinstimmen, wird akzeptiert; die erste Abweichung ist der Punkt, an dem sich die Engine auf die eigene Wahl des Ziels festlegt und den Rest verwirft. Die Akzeptanzregel — akzeptiere ein aus dem Entwurf q gezogenes x mit Wahrscheinlichkeit min(1, p(x)/q(x)), sonst sample aus dem normalisierten Residuum (p−q)₊ — sorgt dafür, dass die Ausgabeverteilung mit reinem Ziel-Sampling identisch ist. Spekulation ist korrektheitserhaltend; der Entwurf beeinflusst nur die Geschwindigkeit. Auf modernen GPUs kostet der Verifikationspass für N=4 etwa 1,2–1,5-mal einen normalen Dekodierschritt, weil die Attention nun N+1 Query-Positionen umspannt, aber weiterhin klar im speichergebundenen Regime bleibt.

9.2 EAGLE koppelt den Entwurf an den versteckten Zustand des Ziels

Frühe Implementierungen nutzten ein separates kleines Modell als Entwurf — Llama-7B als Entwurf für Llama-70B —, was funktioniert, aber einen zweiten HBM-Strom für die Gewichte des Entwurfs kostet und die Akzeptanz deckelt, weil die zwei Modelle keine Repräsentationen teilen. EAGLE, über EAGLE-2 und EAGLE-3 zwischen 2024 und 2025 verfeinert, koppelt den Entwurf an das Ziel: eine einzelne Transformer-Schicht, trainiert darauf, den versteckten Zustand der nächsten Schicht des Ziels vorherzusagen, projiziert durch die Ausgabe-Embedding des Ziels selbst. Es gibt keine separaten 7B-Gewichte zu streamen; der Entwurfskopf ist wenige hundert Megabyte. EAGLE-2 fügt dynamische Entwurfsbaum-Expansion hinzu — ein Baum von Kandidaten, in einem Attention-Pass mit spezieller Maske verifiziert — sodass das Ziel unter mehreren Pfaden den besten wählt statt der einen Vermutung des Entwurfs. EAGLE-3 fügt eine Mehrschicht-Feature-Mischung hinzu, die Zwischen­schichten des Ziels konsumiert statt nur der vorletzten. Die Akzeptanzraten landen bei 75–85 Prozent auf Chat und Code mit N in 5–8, was Ende-zu-Ende zu 3–4-fachen Beschleunigungen gegenüber reinem Dekodieren übersetzt. Medusa geht den alternativen Weg — parallele Entwurfsköpfe, die mehrere Zukunfts-Tokens in einem Durchlauf statt autoregressiv vorhersagen — mit einer einfacheren Trainingsgeschichte und etwas geringerer Akzeptanz. N-Gramm- und Suffix-Dekodierung sind das kostenlose Mittag für repetitive Arbeitslasten (Code-Editieren, Template-Ausgabe), bei denen der Entwurf einfach ein Nachschlagen im jüngsten Kontext ist.

9.3 Der Verifikationspass selbst wird zur Obergrenze

Die Beschleunigungsformel ist genau genug, um sie hinzuschreiben: E[akzeptierte_Tokens] / (T_Entwurf/T_Dekodierung + 1 + α·N), wobei α der Verifikations-Overhead pro Position ist, typischerweise 0,05–0,15. Zwei Obergrenzen zeigen sich. Erstens wächst α·N mit N, sodass ein unbegrenztes Erhöhen von N nicht hilft; das Maximum liegt bei etwa N=6–8 bei p=0,8, N=10–12 bei p=0,9. Engines, die N fest verdrahten, verpassen das Optimum bei Arbeitslast-Variation. Zweitens, und subtiler, ist die asymptotische Beschleunigung, wenn p gegen 1 geht, 1/α — rund 10× bei α=0,10, 20× bei α=0,05 —, weil der Verifikationspass selbst die Wand ist. Produktions-Engines haben Spitzen­beschleunigungen in diesem Bereich auf hochrepetitiven Arbeitslasten gemessen und sie nicht übertroffen. Spekulation interagiert auch mit Batching: bei hohen Batchgrößen ist der Forward-Pass des Ziels bereits nahe an rechengebunden, und die zusätzlichen Verifikations-Tokens drücken ihn weiter dorthin, sodass die Beschleunigung mit wachsendem Batch schrumpft. Der Süßpunkt für Spekulation liegt bei niedrigem bis mittlerem Batch auf latenzkritischen Arbeitslasten — genau in dem Regime, in dem die untätige Rechenleistung aus Kapitel 1 lebt.

Was Kapitel 9 vorbereitet

Die Kapitel 5 bis 9 haben das Modell- und Laufzeitwerkzeug erschöpft — Quantisierung, Pruning, Distillation, Batching, paged KV, spekulatives Dekodieren. Nichts davon liefert sich als Bibliothek aus, die man pip installt und vergisst. Jemand muss all das in eine Laufzeit zusammenweben, die ein Modell auf einer GPU besitzt, einen Continuous Batch führt und eine Inferenz-API exponiert. Diese Laufzeit ist die Engine. Kapitel 10 geht die fünf Engines ab, die den Stack von 2026 beherrschen — vLLM, TensorRT-LLM, SGLang, TGI und Ollama — und die mechanischen Kompromisse, die entscheiden, welche für ein bestimmtes Deployment die richtige ist.

Als Nächstes — Kapitel 10: Die LLM-Engine-Schicht. vLLM, TensorRT-LLM, SGLang, TGI, Ollama — Engines als Einzelknoten-Laufzeit, gewählt nach Mechanismus statt nach Benchmark.