GEO

Speculative Decoding

Speculative Decoding ist eine Inferenzoptimierung, bei der ein kleines, schnelles "Draft"-Modell mehrere Tokens vorausberechnet, und das große Zielmodell sie dann in einem einzigen parallelen Vorwärtsdurchlauf verifiziert, wobei es jene akzeptiert, die mit dem übereinstimmen, was es selbst erzeugt hätte, und den Rest verwirft. Der Nutzer erhält exakt dieselbe Ausgabe wie beim einfachen Decoding, aber 2- bis 4-mal schneller.

Speculative Decoding ist eine Inferenzoptimierung, bei der ein kleines, schnelles "Draft"-Modell mehrere Tokens vorausberechnet, und das große Zielmodell sie dann in einem einzigen parallelen Vorwärtsdurchlauf verifiziert, wobei es jene akzeptiert, die mit dem übereinstimmen, was es selbst erzeugt hätte, und den Rest verwirft. Der Nutzer erhält exakt dieselbe Ausgabe wie beim einfachen Decoding, aber 2- bis 4-mal schneller.

Warum es wichtig ist

Die LLM-Generierung ist durch sequenzielle Abhängigkeiten gebunden: Jedes Token muss auf das vorige warten. Große Modelle werden nicht durch die reine Rechenleistung ausgebremst, sondern durch die Speicherbandbreite, also das Bewegen ihrer riesigen Gewichte zu den GPU-Recheneinheiten, einmal pro Token. Speculative Decoding durchbricht die sequenzielle Kette, indem es mehrere spekulative Tokens in einen Vorwärtsdurchlauf bündelt und so die Zahl der teuren Aufrufe des großen Modells drastisch verringert. Google veröffentlichte es erstmals 2022; bis 2024 bis 2025 liefert jede große Inferenz-Engine (vLLM, TensorRT-LLM, llama.cpp, together.ai) Speculative Decoding als Standardoptimierung aus und senkt die Servierkosten bei gleicher Ausgabequalität um 30 bis 70 %.

Wie es funktioniert

1. Draft-Modell schlägt vor: Ein kleines, günstiges Modell (etwa ein 1-Milliarde-Parameter-Zwilling des 70-Milliarden-Ziels) erzeugt die nächsten k Tokens autoregressiv. Das ist schnell, weil die Gewichte des Draft-Modells klein sind.

2. Zielmodell verifiziert: Das Zielmodell führt einen Vorwärtsdurchlauf über die k Draft-Tokens parallel aus und berechnet, was es an jeder Position erzeugt hätte.

3. Akzeptieren oder verwerfen: Beginnend beim ersten Draft-Token akzeptiert das Zielmodell es, wenn seine eigene Top-Wahl (oder eine wahrscheinlichkeitsabgeglichene Stichprobe) übereinstimmt, und fährt fort, bis es widerspricht.

4. Korrigieren und fortfahren: Beim ersten Widerspruch ersetzt das Token des Ziels das des Drafts. Der Prozess startet von dort neu.

5. Nettoeffekt: Wenn der Draft im Schnitt zu 70 % richtig liegt, erzeugt das Zielmodell etwa 3-mal mehr Tokens pro Vorwärtsdurchlauf und senkt die Latenz entsprechend.

Warum es verlustfrei ist

Richtig ausgeführt, erzeugt Speculative Decoding exakt dieselbe Ausgabeverteilung wie einfaches Decoding. Die Mathematik geht auf, weil das Zielmodell als Verifizierer fungiert: Jedes vom Draft vorgeschlagene Token muss den Akzeptanztest des Ziels bestehen, sodass die endgültige Sequenz identisch mit der ist, die das Ziel allein erzeugt hätte. Es gibt keinen Qualitätskompromiss, nur einen Geschwindigkeitsgewinn.

Varianten

Klassisches Speculative Decoding (Google 2022): Ein Draft-Modell, ein Ziel. Die ursprüngliche Formulierung.

Medusa: Fügt dem Zielmodell selbst mehrere "Köpfe" hinzu, die mehrere Tokens vorausberechnen, und macht ein separates Draft-Modell überflüssig. Einfacheres Deployment.

EAGLE: Eine genauere Variante, die die internen Repräsentationen des Zielmodells selbst zum Entwerfen nutzt und höhere Akzeptanzraten als externe Drafts erreicht.

Tree Speculative Decoding: Mehrere Kandidaten-Token-Bäume parallel entwerfen. Höhere Akzeptanzwahrscheinlichkeit, mehr Rechenaufwand für die Verifikation.

Self-Speculative: Schichten des Zielmodells überspringen, um aus denselben Gewichten einen günstigen "Draft" zu bilden.

Wann es am meisten hilft

Batch-of-One-Inferenz: Interaktiver Einzelnutzer-Chat ist speichergebunden. Hier glänzt Speculative Decoding.

Lange Ausgaben: Je mehr Tokens das Modell erzeugt, desto stärker summieren sich die kumulierten Einsparungen.

Repetitive Struktur: Wenn die Ausgabe vorhersagbaren Mustern folgt (Code, JSON), sind die Akzeptanzraten des Drafts sehr hoch.

Auslastung kalter Hardware: Auf GPUs, die andernfalls beim Warten auf den Speicher leerlaufen würden, füllt die Spekulation die Rechenlücke.

Wann es weniger hilft

Großes Batch-Serving: Workloads mit hohem Durchsatz sind bereits rechengebunden, nicht speichergebunden. Spekulation fügt Mehraufwand hinzu, ohne viel zu sparen.

Sehr kreative / zufällige Ausgaben: Niedrige Akzeptanzraten des Drafts begrenzen die Beschleunigung.

Winzige Modelle: Ein 1-Milliarde-Draft über einem 3-Milliarden-Ziel spart wenig, weil das Ziel ohnehin günstig ist.

Kurze Prompts mit kurzen Antworten: Der Mehraufwand für das Einrichten der Spekulation überwiegt den Gewinn.

Kompromisse

Zusätzliches Modell im Speicher: Sie servieren nun sowohl das Ziel als auch den Draft. Der Speicherbedarf steigt, sofern Sie nicht Self-Speculative nutzen.

Implementierungskomplexität: Die Verwaltung der Verifikationsschleife, des Rejection Sampling und des KV-Cache-Rollbacks ist nicht trivial. Nutzen Sie eine Bibliothek.

Empfindlichkeit gegenüber der Akzeptanzrate: Ein schlecht abgestimmter Draft kann die Sache sogar verlangsamen, wenn Ablehnungen überwiegen.

Kaltstart: Die ersten paar Tokens profitieren nicht von der Spekulation, während der Draft warmläuft.

Häufige Fehler

Ein Draft-Modell aus einer anderen Familie verwenden: Ein Llama-Draft für ein Mistral-Ziel akzeptiert selten. Der Draft muss auf das Ziel abgestimmt sein.

Ein zu großer Draft: Ein 7-Milliarden-Draft unter einem 70-Milliarden-Ziel hat eine großartige Akzeptanzrate, kostet aber zu viel im Betrieb. Der Draft sollte 5 bis 20 % der Größe des Ziels betragen.

KV-Cache-Rollback ignorieren: Abgelehnte Tokens müssen den KV-Cache des Ziels zurücksetzen. Vergisst man das, beschädigt es den Zustand.

Es auf bereits schnelle Modelle anwenden: Modelle der Haiku-/Flash-Klasse sind speicherleicht. Spekulation spart weniger.

Nicht End-to-End messen: Benchmarken Sie den gesamten Anfragepfad. Naive Gewinne bei Tokens pro Sekunde verschwinden mitunter unter Last oder wenn die Netzwerklatenz dominiert.

Sources: