Speculative decoding: draft models, n-grams, MTP, and EAGLE

Das Problem: Autoregressives Decoding ist langsam

LLMs generieren Text 1 Token für Token. Jedes Token erfordert einen vollständigen Vorwärtsdurchlauf durch das Modell — jedes Gewicht, jede Schicht — bevor das nächste Token beginnen kann. Wie How inference works erklärt, ist diese Decode-Phase speicherbandbreitengebunden: Die GPU liert Gigabytes an Gewichten aus dem Speicher, um ein einzelnes Token zu erzeugen, und wiederholt dies für das nächste. Die Recheneinheiten liegen die meiste Zeit untätig da und warten auf Daten. Ihre GPU verrichtet keine nützliche Arbeit — sie wartet auf den Speicher. Spekulatives Decoding nutzt diese ungenutzte Kapazität aus. Statt 1 Token pro Vorwärtsdurchlauf zu generieren, rät 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 schlägt N Tokens im Voraus vor (typischerweise 4-8 Tokens).
Target model — das große Modell, das Sie tatsächlich verwenden möchten, verifiziert alle N vorgeschlagenen Tokens in einem einzigen Vorwärtsdurchlauf.

Wenn das Target-Modell K der vorgeschlagenen Tokens bestätigt, erhalten Sie K+1 Tokens für den Preis von 1 Vorwärtsdurchläufen des großen Modells (plus 1 günstiger Vorwärtsdurchlauf 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 Entwurfs-Token erhalten Sie durchschnittlich etwa 2-3 Token pro Vorwärtsdurchlauf des großen Modells statt 1. Das führt direkt zu einer um 2-3x schnelleren Generierung.

Speculative Decoding verändert die Ausgabequalität nicht. Das Zielmodell trifft weiterhin jede Akzeptanzentscheidung, sodass die Ausgabeverteilung mathematisch identisch zur normalen autoregressiven Dekodierung ist.

N-Gramm-Spekulative Dekodierung

Funktionsweise

Anstatt ein separates Entwurfsmodell zu verwenden, betrachtet die N-Gramm-spekulative Dekodierung die letzten N Token der aktuellen Sequenz, sucht nach übereinstimmenden Mustern weiter vorne im Kontext und schlägt die Token vor, die auf dieses Muster folgten. Es handelt sich um reine Mustererkennung innerhalb des vorhandenen Textes.Wenn beispielsweise die letzten 4 Token def calculate_total( sind und der frühere Kontext def calculate_total(items): return sum( enthält, schlägt die Engine items, :, return, sum als die nächsten 4 Token vor. Das Zielmodell verifiziert diese anschließend.

Wann Sie es verwenden sollten

Bestens geeignet für: Codegenerierung, strukturierte Ausgabe, sich wiederholender Text, Vorlagen, Loganalyse.Am wenigsten geeignet für: Kreatives Schreiben, vielfältige offene Antworten, kurze Kontexte ohne sich wiederholende Muster.N-Gramm-Spekulation glänzt, wenn Ihre Ausgabe wiederholte Strukturen enthält — Funktionssignaturen, JSON-Schemata, Boilerplate-Code. Sie schlägt stillschweigend fehl (niedrige Akzeptanzrate, Fallback auf normale Dekodierung), wenn der Text für die Mustererkennung zu vielfältig 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 zusätzliches Modell-Download, kein zusätzlicher VRAM-Verbrauch. Die einzigen Kosten sind die CPU-Zeit für die Suche nach Übereinstimmungen im Kontext — im Vergleich zu GPU-Vorwärtsdurchläufen vernachlässigbar.

Entwurf des spekulativen Modell-Decodings

Funktionsweise

Ein kleineres Modell derselben Familie generiert Kandidaten-Token. Zum Beispiel entwirft Llama-3.1-8B für Llama-3.1-70B. Das kleine Modell führt seine eigene autoregressive Generierung durch, um 4-8 Token vorzuschlagen, und das große Modell verifiziert sie alle in 1 Vorwärtsschritten.Die Akzeptanzrate — der Anteil der Entwurfs-Token, mit denen das Zielmodell übereinstimmt — liegt typischerweise zwischen 70% und 85% für gut abgestimmte Modellpaare. Eine höhere Akzeptanz bedeutet mehr Geschwindigkeitsvorteil.

Wann es verwendet werden sollte

Am besten geeignet für: allgemeine Generierung, wenn Sie VRAM-Reserven für das kleinere Modell haben.Speicherbedarf: Beide Modelle müssen gleichzeitig geladen werden. Ein 8B Entwurfsmodell fügt dem Zielmodell etwa 4-5 GB hinzu (bei Q4 Quantisierung). Planen Sie Ihre Modellpassform entsprechend.Geschwindigkeitsvorteil: 1.5-2.5x, abhängig von der Akzeptanzrate und der Anzahl der Entwurfs-Token. Abnehmende Renditen jenseits von 6-8 Entwurfs-Token, da die Akzeptanz für spätere Token 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 für Entwurf und Ziel. Familienübergreifende Paare (zum Beispiel Mistral, das für Llama entwirft) haben viel niedrigere Akzeptanzraten, da sich ihre Token-Verteilungen unterscheiden.

DFlash: Ein Entwerfer, der mit dem Modell ausgeliefert wird

Die meisten Entwurfsmodell-Einrichtungen überlassen es Ihnen, ein kompatibles kleines Modell zu finden und die Paarung selbst zu optimieren. DFlash, Metas Entwerfer für Muse Glimmer 30B, überspringt diesen Schritt: Es wird in derselben Veröffentlichung wie sein Ziel ausgeliefert und schlägt Blöcke von 16 Token vor, die Muse Glimmer in 1 Vorwärtsschritten verifiziert. Meta gibt 3.1x für eine RTX 5090, 1.8x für einen Apple M5 Max und 1.5x für einen Apple M4 Max an. Dies sind herstellerseitig gemeldete Werte ohne unabhängige Reproduktion, also benchmarken Sie Ihre eigene Hardware, bevor Sie sich darauf verlassen.

Modell-native spekulative Köpfe: MTP und DSpark

Funktionsweise

Einige Modellarchitekturen sind darauf trainiert, mehrere zukünftige Token gleichzeitig aus einem einzigen Forward-Pass vorherzusagen. Das Modell selbst erzeugt mehrere Kandidaten-Tokens auf einmal — kein separates Draft-Modell, kein Pattern-Matching. Die internen Repräsentationen des Modells generieren die spekulativen Tokens.Dies unterscheidet sich grundlegend von externer Spekulation: Die Multi-Token-Köpfe werden gemeinsam mit dem Basismodell trainiert, sodass sie dasselbe Verständnis des Kontexts teilen.

Wann es verwendet werden sollte

Bestens geeignet für: Modelle, die dies nativ unterstützen. Es gibt keine Konfigurationswahl — wenn das Modell mit MTP-Köpfen trainiert wurde, aktivieren Sie diese; wenn nicht, können Sie sie nicht hinzufügen.Aktuelles DeepSeek-Beispiel: DeepSeek-V4-Flash-0731 bündelt sein DSpark-Modul im offiziellen Checkpoint. Einige Qwen-Modelle verwenden stattdessen MTP-Köpfe.Vorteil: kein separates Draft-Modell-Checkpoint oder Model-Pair-Tuning erforderlich.Nachteil: erfordert spezifisches Modelltraining. Sie können 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. Fügen Sie für dieses Modell kein --speculative-draft-model-path hinzu.

Die offizielle 0731-Modellkarte dokumentiert DSpark für vLLM und SGLang. Die Hardware-Unterstützung variiert noch, also verwenden Sie das passende Runtime-Rezept und benchmarken Sie Ihren genauen Checkpoint. Siehe DeepSeek V4 Flash 0731 lokale Hardware.

EAGLE (Extrapolationsalgorithmus für höhere Effizienz von Sprachmodellen)

Funktionsweise

EAGLE trainiert ein kleines „Head“-Netzwerk auf den versteckten Zuständen des Zielmodells. Statt ein vollständiges Entwurfsmodell zu laden, wird ein leichtgewichtiges neuronales Netzwerk an die intermediären Darstellungen des Zielmodells angehängt und diese zur Vorhersage zukünftiger Tokens verwendet.Da das Head-Netzwerk den eigenen internen Zustand des Zielmodells liest, erzielt es höhere Akzeptanzraten (80-90%) als naive Entwurfsmodelle. Das Head-Netzwerk ist im Vergleich zu einem vollständigen Modell winzig — typischerweise 5-10% der Größe des Zielmodells.

Wann es verwendet werden sollte

Bestens geeignet für: Wenn verfügbar, bietet EAGLE das beste Geschwindigkeits-zu-Speicher-Verhältnis aller Techniken.Aktueller Status: Forschungsstufe mit begrenzter Runtime-Unterstützung. vLLM und SGLang haben eine experimentelle EAGLE-Integration, aber sie erfordert vortrainierte EAGLE-Head-Checkpoints, die für die meisten Modelfamilien noch nicht weit verbreitet veröffentlicht wurden.Wenn die EAGLE-Unterstützung ausgereift ist, ist zu erwarten: 2-3x Geschwindigkeitssteigerung bei nur 5-10% Speicher-Overhead — deutlich besser als vollständige Entwurfsmodelle.

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. Stellen Sie sicher, dass ein veröffentlichter EAGLE-Checkpoint für Ihr genaues Zielmodell existiert, bevor Sie diese Technik ausprobieren.

Vergleich

N-Gram

Zusätzlicher Speicher: keiner Beschleunigung: 1.2-1.5x Erfordert Training: nein Laufzeitunterstützung: vLLM, llama.cpp Am besten für: wiederholende Inhalte, Code, strukturierte Ausgabe

Entwurfsmodell

Zusätzlicher Speicher: 20-30% zusätzlich Beschleunigung: 1.5-2.5x Erfordert Training: nein (verwenden Sie ein kleineres Modell derselben Familie) Laufzeitunterstützung: vLLM, llama.cpp Am besten für: allgemeine Generierung mit VRAM-Reserven

Mehrfach-Token-Vorhersage

Zusätzlicher Speicher: keiner Beschleunigung: 1.5-2x Erfordert Training: ja (modellspezifisch) Laufzeitunterstützung: vLLM (nur ausgewählte Modelle) Am besten für: modellnative Köpfe wie DeepSeek V4 Flash 0731 DSpark und unterstützte Qwen MTP-Varianten

EAGLE

Zusätzlicher Speicher: 5-10% Beschleunigung: 2-3x Erfordert Training: ja (Kopfnetzwerk) Laufzeitunterstützung: experimentell Am besten für: bestes Beschleunigungs-zu-Speicher-Verhältnis, wenn verfügbar

Technik	Zusätzlicher Speicher	Typische Beschleunigung	Erfordert Training	Runtime-Unterstützung	Am besten geeignet für
N-Gramm	Keine	1.2-1.5x	Nein	vLLM, llama.cpp	Wiederholende Inhalte
Entwurfsmodell	20-30%	1.5-2.5x	Nein	vLLM, llama.cpp	Allgemeiner Gebrauch
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 (modell-spezifisch)	vLLM (ausgewählte Modelle)	Nur unterstützte Modelle
EAGLE	5-10%	2-3x	Ja (Kopfnetzwerk)	Experimentell	Wenn verfügbar

Wann sollte man speculative decoding verwenden

Verwenden Sie es, wenn:

Ihre Workload ist decode-bound — lange Generierungen, bei denen die meiste Zeit mit der Erzeugung von Tokens verbracht wird und nicht mit der Verarbeitung des Prompts
Sie haben VRAM-Reserven für ein Draft-Modell (mindestens 5-10 GB frei zusätzlich zum Zielmodell)
Sie generieren strukturierte oder repetitive Ausgaben — Code, Vorlagen, JSON, Logs
Sie bedienen einen einzelnen Benutzer oder eine Workload mit niedriger Parallelität

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 befinden sich bereits an Ihrer VRAM-Grenze. Das Draft-Modell oder zusätzliche KV-Cache-Einträge können Sie in den OOM-Zustand treiben. Siehe DGX Spark memory tuning für die Kapazitätsplanung.
Sie verwenden Continuous Batching mit hoher Parallelität. Speculative decoding steht in den meisten Runtimes im Konflikt mit einer effizienten Batch-Planung — der Verifikationsschritt geht von einer festen Draft-Länge pro Anfrage aus, was die Batch-Zusammensetzung erschwert.

Praktischer Einrichtungsleitfaden

N-Gramm-Spekulation in vLLM

Der einfachste Startpunkt — keine zusätzlichen Downloads, kein zusätzlicher Speicherbedarf:

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

Die --ngram-prompt-lookup-max-Flag legt die Fenstergröße für die Mustererkennung fest. Größere Werte finden mehr Übereinstimmungen in langen Kontexten, verlangsamen den Entwurfsschritt jedoch leicht. Beginnen Sie mit 5 und erhöhen Sie den Wert, wenn die Akzeptanz niedrig ist.

Entwurfsmodell in vLLM

Für eine höhere Beschleunigung, wenn Sie über den erforderlichen VRAM verfügen:

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 stoßen. Beide Modelle teilen sich denselben VRAM-Pool, und der KV-Cache des Entwurfsmodells erhöht die Gesamtmenge.

Die Beschaffung und Feinabstimmung eines Entwurfsmodell-Paares wie dieses ist der übliche Weg. Metas Muse Glimmer 30B umgeht dies: Ziehen Sie ein Ollama-Tag, das auf -dflash endet (z. B. muse-glimmer:30b-q4_K_M-dflash), und der DFlash-Entwerfer 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

Die --lookup-cache-static-Flag zwischenspeichert N-Gramm-Suchvorgänge über Token hinweg, was die Entwurfsgeschwindigkeit für sich wiederholende Muster verbessert.

So messen Sie die Beschleunigung

Führen Sie denselben Prompt zweimal aus — einmal mit spekulativer Dekodierung und einmal ohne — und vergleichen Sie die 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 usage.completion_tokens geteilt durch die Wanduhrzeit. Für 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 eine 1.5-2.5x-Verbesserung der mittleren Decode-Latenz ohne Änderung der Ausgabequalität oder Token-Anzahl.

Gehen Sie tiefer

Decode- und Prefill-Leistungsaufnahme

Optimieren Sie die Prefill- und Decode-Phasen für maximalen Durchsatz auf Ihrer Hardware.

So funktioniert Inference

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

vLLM auf DGX Spark

Konfigurieren Sie vLLM mit optimalen Einstellungen, einschließlich Unterstützung für spekulatives Decodieren.

Modell-Fit

Berechnen Sie, ob Ihr Zielmodell plus ein Entwurfsmodell in den VRAM passt.

Bewerten Sie Ihre Deployment

Systematische Benchmarking-Methodik für lokale LLM-Deployments.

Hardware und Kompatibilität

Runtime bereitstellen und verbinden

Client oder App verbinden

Vergleich

Speculative decoding: draft models, n-grams, MTP, and EAGLE

Das Problem: Autoregressives Decoding ist langsam

Die Kernidee

N-Gramm-Spekulative Dekodierung

Entwurf des spekulativen Modell-Decodings

DFlash: Ein Entwerfer, der mit dem Modell ausgeliefert wird

Modell-native spekulative Köpfe: MTP und DSpark

EAGLE (Extrapolationsalgorithmus für höhere Effizienz von Sprachmodellen)

Vergleich

N-Gram

Entwurfsmodell

Mehrfach-Token-Vorhersage

EAGLE

Wann sollte man speculative decoding verwenden

Praktischer Einrichtungsleitfaden

N-Gramm-Spekulation in vLLM

Entwurfsmodell in vLLM

N-Gramm-Spekulation in llama.cpp

So messen Sie die Beschleunigung

Gehen Sie tiefer

Decode- und Prefill-Leistungsaufnahme

So funktioniert Inference

vLLM auf DGX Spark

Modell-Fit

Bewerten Sie Ihre Deployment

​Das Problem: Autoregressives Decoding ist langsam

​Die Kernidee

​N-Gramm-Spekulative Dekodierung

​Entwurf des spekulativen Modell-Decodings

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

​Modell-native spekulative Köpfe: MTP und DSpark

​EAGLE (Extrapolationsalgorithmus für höhere Effizienz von Sprachmodellen)

​Vergleich

N-Gram

Entwurfsmodell

Mehrfach-Token-Vorhersage

EAGLE

​Wann sollte man speculative decoding verwenden

​Praktischer Einrichtungsleitfaden

​N-Gramm-Spekulation in vLLM

​Entwurfsmodell in vLLM

​N-Gramm-Spekulation in llama.cpp

​So messen Sie die Beschleunigung

​Gehen Sie tiefer

Decode- und Prefill-Leistungsaufnahme

So funktioniert Inference

vLLM auf DGX Spark

Modell-Fit

Bewerten Sie Ihre Deployment

Das Problem: Autoregressives Decoding ist langsam

Die Kernidee

N-Gramm-Spekulative Dekodierung

Entwurf des spekulativen Modell-Decodings

DFlash: Ein Entwerfer, der mit dem Modell ausgeliefert wird

Modell-native spekulative Köpfe: MTP und DSpark

EAGLE (Extrapolationsalgorithmus für höhere Effizienz von Sprachmodellen)

Vergleich

Wann sollte man speculative decoding verwenden

Praktischer Einrichtungsleitfaden

N-Gramm-Spekulation in vLLM

Entwurfsmodell in vLLM

N-Gramm-Spekulation in llama.cpp

So messen Sie die Beschleunigung

Gehen Sie tiefer