Spekulatives Decoding: Draft-Modelle, N-Gramme, MTP und EAGLE

Das Problem: Autoregressives Decoding ist langsam

LLMs generieren Text 1 Token nach dem anderen. Jedes Token erfordert einen vollstaendigen Vorwaertsdurchlauf durch das Modell – jedes Gewicht, jede Schicht – bevor das naechste Token beginnen kann. Wie How inference works erklaert, ist diese Decode-Phase speicherbandbreitengebunden: Die GPU liest Gigabytes an Gewichten aus dem Speicher, um ein einzelnes Token zu erzeugen, und wiederholt dies dann fuer das naechste. Die Recheneinheiten sitzen die meiste Zeit untätig da und warten auf Daten. Ihre GPU verrichtet keine nuetzliche Arbeit – sie wartet auf den Speicher. Spekulatives Decoding nutzt diese ungenutzte Kapazitaet. Statt 1 Token pro Vorwaertsdurchlauf zu generieren, raet es mehrere Tokens im Voraus und verifiziert sie alle auf einmal.

Die Kernidee

Spekulatives Decoding verwendet 2 Modelle, die zusammenarbeiten:

Draft model – ein kleines, schnelles Modell schlaegt N Tokens im Voraus vor (typischerweise 4-8 Tokens).
Target model – das grosse Modell, das Sie tatsaechlich verwenden wollen, verifiziert alle N vorgeschlagenen Tokens in einem einzigen Vorwaertsdurchlauf.

Wenn das Target-Modell K der vorgeschlagenen Tokens akzeptiert, erhalten Sie K+1 Tokens fuer den Preis von 1 Vorwaertsdurchlauf des grossen Modells (plus 1 guenstiger Vorwaertsdurchlauf des kleinen Modells). Falsche Vorhersagen werden verworfen und die Generierung setzt am letzten akzeptierten Token fort. Die Rechnung ist einfach: Bei einer 75%-Akzeptanzrate und 5 Draft-Tokens erhalten Sie durchschnittlich etwa 2-3 Tokens pro Vorwaertsdurchlauf des grossen Modells statt 1. Das uebersetzt sich direkt in 2-3x schnellere Generierung.

Speculative Decoding veraendert die Ausgabequalitaet nicht. Das Target-Modell trifft weiterhin jede Akzeptanzentscheidung, daher ist die Ausgabeverteilung mathematisch identisch zum normalen autoregressiven Decoding.

N-Gramm-spekulatives Decoding

Funktionsweise

Statt ein separates Draft-Modell zu verwenden, schaut die N-Gramm-spekulative Decodierung die letzten N Tokens in der aktuellen Sequenz an, sucht nach uebereinstimmenden Mustern weiter vorne im Kontext und schlaegt die Tokens vor, die auf dieses Muster folgten. Es ist reine Mustererkennung innerhalb des vorhandenen Textes.Wenn beispielsweise die letzten 4 Tokens def calculate_total( sind und der Kontext weiter vorne def calculate_total(items): return sum( enthaelt, schlaegt die Engine items, :, return, sum als die naechsten 4 Tokens vor. Das Target-Modell verifiziert sie dann.

Wann verwenden

Am besten fuer: Code-Generierung, strukturierte Ausgabe, sich wiederholender Text, Vorlagen, Log-Analyse.Am schlechtesten fuer: Kreatives Schreiben, vielfältige offene Antworten, kurze Kontexte ohne sich wiederholende Muster.N-Gramm-Spekulation glaenzt, wenn Ihre Ausgabe wiederholte Strukturen enthaelt – Funktionssignaturen, JSON-Schemata, Boilerplate-Code. Sie versagt stillschweigend (niedrige Akzeptanzrate, Fallback auf normales Decoding), wenn der Text zu vielfaeltig fuer Mustererkennung ist.

Implementierung

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model ngram \
  --num-speculative-tokens 5 \
  --ngram-prompt-lookup-max 5 \
  --gpu-memory-utilization 0.90

./llama-server \
  --model models/llama-3.1-70b-q4_k_m.gguf \
  --draft ngram \
  --n-predict 128 \
  --lookup-cache-static

Kein zusaetzlicher Modell-Download, kein zusaetzlicher VRAM. Die einzigen Kosten sind CPU-Zeit fuer die Suche nach Übereinstimmungen im Kontext – vernachlaessigbar im Vergleich zu GPU-Vorwaertsdurchläufen.

Draft-Modell-spekulatives Decoding

Funktionsweise

Ein kleineres Modell aus derselben Familie generiert Kandidaten-Tokens. Zum Beispiel erstellt Llama-3.1-8B den Entwurf fuer Llama-3.1-70B. Das kleine Modell fuehrt seine eigene autoregressive Generierung durch, um 4-8 Tokens vorzuschlagen, dann verifiziert das grosse Modell sie alle in 1 Vorwaertsdurchlauf.Die Akzeptanzrate – der Anteil der Draft-Tokens, mit denen das Target-Modell uebereinstimmt – liegt typischerweise zwischen 70% und 85% fuer gut abgestimmte Modellpaare. Hoechere Akzeptanz bedeutet mehr Beschleunigung.

Wann verwenden

Am besten fuer: Allgemeine Generierung, wenn Sie VRAM-Reserven fuer das kleinere Modell haben.Speicherkosten: Beide Modelle muessen gleichzeitig geladen werden. Ein 8B-Draft-Modell fuegt etwa 4-5 GB hinzu (bei Q4-Quantisierung) zum Target-Modell. Planen Sie Ihren Modell-Fit entsprechend.Beschleunigung: 1.5-2.5x, abhaengig von Akzeptanzrate und Draft-Token-Anzahl. Abnehmende Erträge jenseits von 6-8 Draft-Tokens, da die Akzeptanz fuer spaetere Tokens in der Sequenz sinkt.

Implementierung

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model meta-llama/Llama-3.1-8B-Instruct \
  --num-speculative-tokens 5 \
  --gpu-memory-utilization 0.90

./llama-server \
  --model models/llama-3.1-70b-q4_k_m.gguf \
  --draft models/llama-3.1-8b-q4_k_m.gguf \
  --n-predict 128

Verwenden Sie dieselbe Modellfamilie fuer Draft und Target. Familienuebergreifende Paare (zum Beispiel Mistral als Draft fuer Llama) haben viel niedrigere Akzeptanzraten, da ihre Token-Verteilungen abweichen.

DFlash: Ein Drafter, der mit dem Modell ausgeliefert wird

Die meisten Draft-Modell-Setups ueberlassen es Ihnen, ein kompatibles kleines Modell zu finden und die Paarung selbst abzustimmen. DFlash, Metas Drafter fuer Muse Glimmer 30B, ueberspringt diesen Schritt: Er wird in derselben Veroeffentlichung wie sein Target ausgeliefert und schlaegt Bloecke von 16 Tokens vor, die Muse Glimmer in 1 Vorwaertsdurchlauf verifiziert. Meta berichtet 3.1x auf einer RTX 5090, 1.8x auf einem Apple M5 Max und 1.5x auf einem Apple M4 Max. Dies sind vom Hersteller gemeldete Zahlen ohne unabhaengige Reproduktion, also benchmarken Sie Ihre eigene Hardware, bevor Sie sich darauf verlassen.

Modell-native Spekulationskoepfe: MTP und DSpark

Funktionsweise

Einige Modellarchitekturen sind darauf trainiert, mehrere zukuenftige Tokens gleichzeitig aus einem einzigen Vorwaertsdurchlauf vorherzusagen. Das Modell selbst erzeugt mehrere Kandidaten-Tokens auf einmal – kein separates Draft-Modell, kein Pattern-Matching. Die eigenen internen Repräsentationen des Modells generieren die spekulativen Tokens.Dies ist grundlegend anders als externe Spekulation: Die Multi-Token-Koepfe werden gemeinsam mit dem Basismodell trainiert, daher teilen sie dasselbe Verstaendnis des Kontexts.

Wann verwenden

Am besten fuer: Modelle, die es nativ unterstuetzen. Es gibt keine Konfigurationsentscheidung – wenn das Modell mit MTP-Koepfen trainiert wurde, aktivieren Sie sie; wenn nicht, koennen Sie sie nicht hinzufuegen.Aktuelles DeepSeek-Beispiel: DeepSeek-V4-Flash-0731 buendelt sein DSpark-Modul im offiziellen Checkpoint. Ausgewaehlte Qwen-Modelle verwenden stattdessen MTP-Koepfe.Vorteil: Kein separates Draft-Modell-Checkpoint oder Modellpaar-Tuning erforderlich.Nachteil: Erfordert spezifisches Modelltraining. Sie koennen MTP nicht auf ein beliebiges Checkpoint anwenden.

Implementierung

vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
  --trust-remote-code \
  --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

Das offizielle 0731-Beispiel verwendet den DSpark-Kopf, der im selben Checkpoint gespeichert ist. Fuegen Sie fuer dieses Modell kein --speculative-draft-model-path hinzu.

Die offizielle 0731-Modellkarte dokumentiert DSpark fuer sowohl vLLM als auch SGLang. Die Hardware-Unterstuetzung variiert noch, verwenden Sie also das passende Runtime-Rezept und benchmarken Sie Ihr genaues Checkpoint. Siehe DeepSeek V4 Flash 0731 lokale Hardware.

EAGLE (Extrapolationsalgorithmus fuer groessere Sprachmodell-Effizienz)

Funktionsweise

EAGLE trainiert ein kleines “Head”-Netzwerk auf den versteckten Zustaenden des Target-Modells. Statt ein vollstaendiges Draft-Modell zu laden, bringt es ein leichtgewichtiges neuronales Netzwerk an den intermediären Repräsentationen des Target-Modells an und verwendet diese, um zukuenftige Tokens vorherzusagen.Da das Head-Netzwerk den eigenen internen Zustand des Target-Modells liest, erzielt es hoechere Akzeptanzraten (80-90%) als naive Draft-Modelle. Das Head-Netzwerk ist winzig im Vergleich zu einem vollstaendigen Modell – typischerweise 5-10% der Groesse des Target-Modells.

Wann verwenden

Am besten fuer: Wenn verfuegbar, bietet EAGLE das beste Beschleunigungs-zu-Speicher-Verhaeltnis aller Techniken.Aktueller Status: Forschungsstadium mit begrenzter Runtime-Unterstuetzung. vLLM und SGLang haben experimentelle EAGLE-Integration, aber sie erfordert vortrainierte EAGLE-Head-Checkpoints, die fuer die meisten Modelfamilien noch nicht weit verbreitet veroeffentlicht sind.Wenn die EAGLE-Unterstuetzung ausgereift ist, erwarten Sie: 2-3x Beschleunigung bei nur 5-10% Speicher-Overhead – deutlich besser als vollstaendige Draft-Modelle.

Implementierung

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model yuhuili/EAGLE-LLaMA3.1-Instruct-70B \
  --num-speculative-tokens 5 \
  --speculative-draft-tensor-parallel-size 1

EAGLE-Head-Checkpoints sind modell- und architekturspezifisch. Ueberpruefen Sie, dass ein veroeffentlichtes EAGLE-Checkpoint fuer Ihr genaues Target-Modell existiert, bevor Sie diese Technik verwenden.

Vergleich

N-Gramm

Zusaetzlicher Speicher: keiner Beschleunigung: 1.2-1.5x Erfordert Training: nein Runtime-Unterstuetzung: vLLM, llama.cpp Am besten fuer: Wiederholende Inhalte, Code, strukturierte Ausgabe

Draft-Modell

Zusaetzlicher Speicher: 20-30% zusaetzlich Beschleunigung: 1.5-2.5x Erfordert Training: nein (kleineres Modell aus derselben Familie verwenden) Runtime-Unterstuetzung: vLLM, llama.cpp Am besten fuer: Allgemeine Generierung mit VRAM-Reserven

Multi-Token-Praediktion

Zusaetzlicher Speicher: keiner Beschleunigung: 1.5-2x Erfordert Training: ja (modellspezifisch) Runtime-Unterstuetzung: vLLM (nur ausgewaehlte Modelle) Am besten fuer: Modell-native Koepfe wie DeepSeek V4 Flash 0731 DSpark und unterstuetzte Qwen MTP-Varianten

EAGLE

Zusaetzlicher Speicher: 5-10% Beschleunigung: 2-3x Erfordert Training: ja (Head-Netzwerk) Runtime-Unterstuetzung: experimentell Am besten fuer: Bestes Beschleunigungs-zu-Speicher-Verhaeltnis, wenn verfuegbar

Technik	Zusaetzlicher Speicher	Typische Beschleunigung	Erfordert Training	Runtime-Unterstuetzung	Am besten fuer
N-Gramm	Keine	1.2-1.5x	Nein	vLLM, llama.cpp	Wiederholende Inhalte
Draft-Modell	20-30%	1.5-2.5x	Nein	vLLM, llama.cpp	Allgemeiner Einsatz
DFlash	~2 GB	1.5-3.1x (vom Hersteller angegeben)	Nein (wird mit dem Modell geliefert)	Ollama (`-dflash` Tags)	Nur Muse Glimmer
MTP	Keine	1.5-2x	Ja (modellspezifisch)	vLLM (ausgewaehlte Modelle)	Nur unterstuetzte Modelle
EAGLE	5-10%	2-3x	Ja (Head-Netzwerk)	Experimentell	Wenn verfuegbar

Wann spekulatives Decoding verwenden

Verwenden Sie es, wenn:

Ihre Workload ist decode-bound – lange Generierungen, bei denen die meiste Zeit mit Token-Erzeugung verbracht wird, nicht mit der Verarbeitung des Prompts
Sie haben VRAM-Reserven fuer ein Draft-Modell (mindestens 5-10 GB frei zusaetzlich zum Target-Modell)
Sie generieren strukturierte oder repetitive Ausgabe – Code, Vorlagen, JSON, Logs
Sie bedienen einen einzelnen Benutzer oder eine Workload mit niedriger Parallelitaet

Verwenden Sie es nicht, wenn:

Ihre Workload ist prefill-bound – kurze Ausgaben mit langen Eingaben (Zusammenfassung, Klassifizierung). Speculative Decoding beschleunigt nur die Decode-Phase.
Sie sind bereits an Ihrem VRAM-Limit. Das Draft-Modell oder zusaetzliche KV-Cache-Eintraege koennen Sie in den OOM-Zustand treiben. Siehe DGX Spark memory tuning fuer die Kapazitaetsplanung.
Sie verwenden Continuous Batching mit hoher Parallelitaet. Speculative Decoding steht in den meisten Runtimes im Konflikt mit effizienter Batch-Planung – der Verifikationsschritt geht von einer festen Draft-Laenge pro Anfrage aus, was die Batch-Zusammensetzung erschwert.

Praktischer Einrichtungsleitfaden

N-Gramm-Spekulation in vLLM

Der einfachste Startpunkt – keine zusaetzlichen Downloads, kein zusaetzlicher Speicher:

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model ngram \
  --num-speculative-tokens 5 \
  --ngram-prompt-lookup-max 5 \
  --gpu-memory-utilization 0.90

Das --ngram-prompt-lookup-max-Flag setzt die Fenstergröße fuer die Mustererkennung. Groessere Werte finden mehr Übereinstimmungen in langen Kontexten, verlangsamen den Draft-Schritt aber leicht. Beginnen Sie mit 5 und erhoehen Sie, wenn die Akzeptanz niedrig ist.

Draft-Modell in vLLM

Fuer hoechere Beschleunigung, wenn Sie den VRAM haben:

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model meta-llama/Llama-3.1-8B-Instruct \
  --num-speculative-tokens 5 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192

Reduzieren Sie --max-model-len, wenn Sie auf OOM stossen. Beide Modelle teilen sich denselben VRAM-Pool, und der KV-Cache des Draft-Modells addiert sich zum Gesamtwert.

Die Beschaffung und Abstimmung eines Draft-Modell-Paars wie diesem ist der normale Weg. Metas Muse Glimmer 30B ueberspringt dies: Ziehen Sie einen Ollama-Tag, der auf -dflash endet (zum Beispiel muse-glimmer:30b-q4_K_M-dflash) und der DFlash-Drafter wird ohne --speculative-model-Flag geladen.

N-Gramm-Spekulation in llama.cpp

./llama-server \
  --model models/llama-3.1-70b-q4_k_m.gguf \
  --draft ngram \
  --n-predict 128 \
  --lookup-cache-static \
  --port 8080

Das --lookup-cache-static-Flag cached N-Gramm-Lookups ueber Tokens hinweg und verbessert die Draft-Geschwindigkeit fuer repetitive Muster.

So messen Sie die Beschleunigung

Fuehren Sie denselben Prompt zweimal aus – einmal mit spekulativem Decoding und einmal ohne – und vergleichen Sie Tokens pro Sekunde:

# Baseline (no speculation)
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 &

# Send a test request and note tok/s in the response headers
curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-70B-Instruct",
    "messages": [{"role": "user", "content": "Write a Python class that implements a binary search tree with insert, delete, and search methods."}],
    "max_tokens": 512
  }'

Stoppen Sie den Baseline-Server, starten Sie den spekulativen Server, senden Sie dieselbe Anfrage und vergleichen Sie. Suchen Sie nach dem x-tokens-per-second-Header oder berechnen Sie aus usage.completion_tokens geteilt durch die Wanduhrzeit. Fuer systematisches Benchmarking verwenden Sie das integrierte Benchmark-Tool von vLLM:

python -m vllm.benchmarks.benchmark_serving \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --num-prompts 10 \
  --request-rate 1

Eine gut abgestimmte spekulative Konfiguration zeigt 1.5-2.5x Verbesserung der mittleren Decode-Latenz ohne Aenderung der Ausgabequalitaet oder Token-Anzahl.

Vertiefung

Decode- und Prefill-Leistungsaufnahme

Optimieren Sie Prefill- und Decode-Phasen fuer maximalen Durchsatz auf Ihrer Hardware.

So funktioniert Inference

Verstehen Sie Prefill, Decode und warum Speicherbandbreite der Engpass ist.

vLLM auf DGX Spark

Konfigurieren Sie vLLM mit optimalen Einstellungen einschliesslich spekulativem Decoding.

Modell-Fit

Berechnen Sie, ob Ihr Target-Modell plus ein Draft-Modell in den VRAM passen.

Ihr Deployment testen

Systematische Benchmarking-Methodik fuer lokale LLM-Deployments.

Hardware und Kompatibilität

Runtime bereitstellen und verbinden

Client oder App verbinden

Vergleich

Spekulatives Decoding: Draft-Modelle, N-Gramme, MTP und EAGLE

Das Problem: Autoregressives Decoding ist langsam

Die Kernidee

N-Gramm-spekulatives Decoding

Draft-Modell-spekulatives Decoding

DFlash: Ein Drafter, der mit dem Modell ausgeliefert wird

Modell-native Spekulationskoepfe: MTP und DSpark

EAGLE (Extrapolationsalgorithmus fuer groessere Sprachmodell-Effizienz)

Vergleich

N-Gramm

Draft-Modell

Multi-Token-Praediktion

EAGLE

Wann spekulatives Decoding verwenden

Praktischer Einrichtungsleitfaden

N-Gramm-Spekulation in vLLM

Draft-Modell in vLLM

N-Gramm-Spekulation in llama.cpp

So messen Sie die Beschleunigung

Vertiefung

Decode- und Prefill-Leistungsaufnahme

So funktioniert Inference

vLLM auf DGX Spark

Modell-Fit

Ihr Deployment testen

​Das Problem: Autoregressives Decoding ist langsam

​Die Kernidee

​N-Gramm-spekulatives Decoding

​Draft-Modell-spekulatives Decoding

​DFlash: Ein Drafter, der mit dem Modell ausgeliefert wird

​Modell-native Spekulationskoepfe: MTP und DSpark

​EAGLE (Extrapolationsalgorithmus fuer groessere Sprachmodell-Effizienz)

​Vergleich

N-Gramm

Draft-Modell

Multi-Token-Praediktion

EAGLE

​Wann spekulatives Decoding verwenden

​Praktischer Einrichtungsleitfaden

​N-Gramm-Spekulation in vLLM

​Draft-Modell in vLLM

​N-Gramm-Spekulation in llama.cpp

​So messen Sie die Beschleunigung

​Vertiefung

Decode- und Prefill-Leistungsaufnahme

So funktioniert Inference

vLLM auf DGX Spark

Modell-Fit

Ihr Deployment testen

Das Problem: Autoregressives Decoding ist langsam

Die Kernidee

N-Gramm-spekulatives Decoding

Draft-Modell-spekulatives Decoding

DFlash: Ein Drafter, der mit dem Modell ausgeliefert wird

Modell-native Spekulationskoepfe: MTP und DSpark

EAGLE (Extrapolationsalgorithmus fuer groessere Sprachmodell-Effizienz)

Vergleich

Wann spekulatives Decoding verwenden

Praktischer Einrichtungsleitfaden

N-Gramm-Spekulation in vLLM

Draft-Modell in vLLM

N-Gramm-Spekulation in llama.cpp

So messen Sie die Beschleunigung

Vertiefung