TL;DR: Spekulatives Dekodieren beschleunigt die Token-Generierung von LLMs, ohne das Ergebnis zu verändern: Ein kleines Draft-Modell schlägt mehrere Tokens schnell vor, das große Modell prüft sie in einem gemeinsamen Forward-Pass. Die eine Frage, die über den Nutzen entscheidet: Läuft meine Inferenz memory-bound (dann lohnt sich der Boost, bis ~2x) oder compute-bound (dann kaum Gewinn)? Für die meisten Einzelnutzer und kleine Batch-Setups auf lokaler Hardware ist die Antwort memory-bound — und der Boost real.
Was spekulatives Dekodieren leistet
Die spekulative Dekodierung (speculative decoding) trennt das Generieren vom Prüfen. Ein kleines, schnelles Draft-Modell erzeugt k Token-Vorschläge am Stück. Das große Verifikations-Modell liest alle k Vorschläge in einem einzigen Forward-Pass und akzeptiert so viele davon, wie mit seiner eigenen Verteilung übereinstimmen. Ab der ersten Abweichung wird an dieser Stelle neu dekodiert.
Das Ergebnis: statt k sequenziellen Schritten braucht es einen Pass für den Draft plus einen für die Prüfung. Bei einer Akzeptanzrate von 4 von 5 Vorschlägen halbiert sich die Zahl der großen Forward-Passes in etwa.
Warum der Boost verlustfrei ist
Anders als Quantisierung oder Kürzung des Kontexts verändert die Prüfung die Ausgabe nicht: Die Akzeptanzregel ist so konstruiert, dass die verteilte Ausgabe exakt der des großen Modells entspricht. Der Mechanismus heißt deshalb im Originalpapier von Levi et al. (2022) "Lossless Speedup of Autoregressive Decoding" — die Länge des Drafts ist dabei ein Trade-off zwischen Parallelität und Akzeptanzrate.
Die eine Frage, die über den Gewinn entscheidet
Der Speedup hängt vom Regime der Inferenz ab. Diese Entscheidungsregel trägt den ganzen Artikel:
| Regime | Kennzeichen | Effekt von spekulativem Dekodieren |
|---|---|---|
| Memory-bound | Kleine Batches (oft 1), GPU-Rechenkerne warten auf Daten aus dem Speicher | Groß: bis ~2x weniger Schritte |
| Compute-bound | Große Batches, FLOPs der GPU voll ausgelastet | Klein bis null: die Prüfung "verbraucht" die parallelisierten Einheiten |
Praxisregel: Bei einem einzelnen Prompt auf einer lokalen GPU (Mac mini, RTX-Karte im Single-Stream) läuft fast immer memory-bound — spekulatives Dekodieren zahlt sich aus. Bei voll gebündelten Server-Batches schrumpft der Gewinn.
Messwerte aus Produktion
Die im Original-Video gezeigten und von Berkeley bzw. Red Hat publizierten Größenordnungen:
- Berkeley: ~1,96x Speedup bei kleinen Batches, ~1,21x bei größeren — der Gewinn fällt mit zunehmender Batchgröße.
- Red Hat: +27 % Tokens/s und −19 % Kosten pro Million Tokens mit aktivierter spekulativer Dekodierung im vLLM-Stack.
Weniger Schritte bei gleicher Ausgabe bedeuten direkt niedrigere Kosten pro Million Tokens — der Boost ist damit auch ein Kosten-Artefakt, nicht nur ein Latenz-Trick.
Kopierbarer vLLM-Config-Block
Draft-Modell aus derselben Familie wählen (kleinster Vertreter), Länge des Drafts 4–8 Tokens:
vllm serve Qwen/Qwen3-32B \
--speculative-config '{"method": "draft", "model": "Qwen/Qwen3-0.6B", "num_speculative_tokens": 5}'
Alternativ mit eingebautem Methodensatz (z. B. EAGLE), falls das gewählte Modell ihn unterstützt:
# vllm serve Qwen/Qwen3-32B --speculative-config
method: eagle3
num_speculative_tokens: 2
Checkliste für den eigenen Stack
- Ist mein Setup memory-bound? (Einzelne Prompts, kleiner Batch → ja.)
- Draft-Modell aus derselben Familie wie das Zielmodell — gleiche Tokenizer, bessere Akzeptanz.
- num_speculative_tokens zwischen 4 und 8 starten, Akzeptanzrate loggen und nachjustieren.
- Bei großen Batches: Gewinn messen statt voraussetzen; der Boost kann gegen null gehen.
FAQ
Warum ist spekulatives Dekodieren wirklich verlustfrei, obwohl ein kleineres Modell vorschlägt? Weil das kleine Modell nur Vorschläge liefert, die finale Verteilung aber vom großen Modell in einem einzigen Pass geprüft wird. Die Akzeptanzregel stellt mathematisch sicher, dass die verteilte Ausgabe identisch zur sequenziellen Ausgabe des großen Modells ist. Das Draft-Modell kann also die Ausgabe nicht "verwässern" — es kann nur die Zahl der Pässe reduzieren.
Wie wähle ich das Draft-Modell? Nimm den kleinsten Vertreter derselben Modellfamilie, etwa Qwen3-0.6B als Draft zu Qwen3-32B. Gleiche Familie bedeutet gleichen Tokenizer und ähnliche bedingte Verteilungen, was die Akzeptanzrate hoch hält. Ein fachfremdes, generisches Draft-Modell führt meist zu häufigeren Verwürfen und damit zu geringerem Speedup.
Lohnt sich der Boost auch bei großen Batches? Ja, aber mit fallender Tendenz. Bei memory-bound-Lagen (Batch 1–8) sind ~1,9x üblich; je mehr FLOPs der GPU ausgelastet sind, desto mehr geht der Gewinn Richtung 1,2x oder weniger. Der Grund: die Prüfung der Draft-Tokens belegt dieselben parallelen Recheneinheiten, die im Batch-Betrieb schon voll besetzt sind.
Wie hängen die Kosten daran? Weniger große Forward-Passes pro Textbedeutung heißen direkt weniger GPU-Sekunden pro Million Tokens — die −19 % bei Red Hat sind genau diese Rechnung. Bei gleichbleibender Hardwarekapazität steigt der Durchsatz, also sinkt der Preis pro Million Tokens. Die Kostenersparnis ist allerdings an die memory-bound-Bedingung gekoppelt — im Voll-Batch-Modell schrumpft sie mit dem Speedup selbst.
Woran erkenne ich, dass die spekulative Dekodierung bei mir nicht greift? Die meisten Serving-Stacks (vLLM inklusive) loggen die Akzeptanzrate des Drafts pro Schritt. Eine Akzeptanzrate nahe der Draftlänge zeigt den vollen Gewinn; eine Rate unter ~50 % heißt: Draft zu lang oder Modellfamilie zu entfernt — Draft-Länge reduzieren oder Modell aus derselben Familie nehmen. Wenn die GPU im Vollauslastungsmodus (großer Batch) läuft, ist ein geringer Gewinn normal und kein Konfigurationsfehler.
Quellen
- Levi, G., Fusco, J., Sakr, S., Gerards, M. (2022): Lossless Speedup of Autoregressive Decoding — https://arxiv.org/abs/2203.16487
- Original-Video zum Mechanismus: Speculative Decoding: The ONLY Video You Need to Speed Up Inference — https://www.youtube.com/watch?v=_hEGvCwHyH8
- vLLM-Dokumentation zu Speculative Decoding — https://docs.vllm.ai/en/latest/features/spec_decode.html
- Berkeley LLM-Inferenz-Optimierung (Speedup-Zahlen) — https://llm-d.ai/
- Red Hat: Benchmark zu +27 % Tokens/s / −19 % Kosten mit spekulativer Dekodierung — https://www.redhat.com/en