Spekulative Dekodierung: 20–50 % schnellere LLM-Inferenz

Ein 70B-Modell erzeugt pro Vorwärtsdurchlauf (Forward Pass) genau ein Token, und bei jedem Durchlauf werden Gewichte aus dem VRAM nachgeladen, die Aufmerksamkeit (Attention) über den Kontext berechnet und der Speicher synchronisiert. Zwischen den Tokens ist die GPU untätig, während sie auf die Auflösung sequentieller Abhängigkeiten wartet.

Auf einer H100 erzeugt ein 70B-Modell alle 30–50 ms ein Token. Die GPU verfügt über ausreichend Rechenkapazität, um mehrere Tokens parallel zu verarbeiten, doch die sequentielle Abhängigkeit verhindert dies – jedes Token hängt vom vorherigen ab, und die Pipeline bleibt stehen.

Spekulative Dekodierung (Speculative Decoding) durchbricht diesen Engpass, indem sie es ermöglicht, mehrere Tokens in der Zeit zu erzeugen, die normalerweise für ein einziges Token benötigt wird, ohne die Ausgabe-Verteilung zu verändern. Die erhaltenen Tokens sind statistisch identisch mit denen der Standard-Autoregressiven Dekodierung; der einzige Unterschied liegt in der Geschwindigkeit ihrer Erzeugung.

Dieser Leitfaden behandelt die Mechanik, die 2026 verfügbaren Varianten, die Abwägungen bei der Akzeptanzrate und die praktische Einrichtung in llama.cpp, vLLM, SGLang und TensorRT-LLM.

Wie autoregressive Dekodierung funktioniert (und warum sie langsam ist)

Bevor man die spekulative Dekodierung verstehen kann, muss man die autoregressive Einschränkung verstehen, die sie umgeht. Standardautoregressive Generierung verarbeitet Tokens sequentiell:

1. Führe einen Vorwärtsdurchlauf durch das Modell mit dem aktuellen Kontext durch.
2. Sample das nächste Token aus der Ausgabe-Verteilung.
3. Hänge das Token an den Kontext an.
4. Wiederhole den Vorgang.

Jeder Schritt erfordert einen vollständigen Vorwärtsdurchlauf – das Laden von Gewichten aus dem VRAM, die Berechnung der Aufmerksamkeit über den gesamten Kontext und die Erzeugung eines einzelnen Tokens. Für ein Modell mit 70B Parametern dauert dies auf einer H100 etwa 30–50 ms pro Token. Die GPU hat Rechenkapazität im Überfluss – sie könnte mehr Arbeit parallel verarbeiten –, doch die sequentielle Abhängigkeit verhindert dies.

Die Lücke zwischen Rechenleistung und VRAM

Moderne GPUs haben mehr FLOPs (Floating Point Operations), als sie für die Generierung eines einzelnen Tokens benötigen. Der eigentliche Engpass ist daher die Speicherbandbreite – die Gewichte müssen für jeden Vorwärtsdurchlauf vom VRAM zu den Recheneinheiten gestreamt werden. Bei der Generierung eines Tokens nach dem anderen verbringt die GPU die meiste Zeit mit Warten auf Speicherübertragungen, anstatt nützliche Berechnungen durchzuführen.

Spekulative Dekodierung behebt dies, indem sie der GPU mehr Arbeit pro Speicherübertragung gibt. Anstatt ein Token pro Vorwärtsdurchlauf zu erzeugen, generiert sie K Tokens pro Vorwärtsdurchlauf und verteilt die Speicherkosten auf mehrere Ausgaben.

Der Draft-Verify-Mechanismus (Entwurf-Verifizierung)

Spekulative Dekodierung funktioniert in sich wiederholenden Entwurf-Verifizierungs-Zyklen. Ein schneller Entwurfsmechanismus schlägt K Kandidaten-Tokens vor – von einem kleinen Entwurfsmodell (Draft Model), einer n-Gramm-Suche oder einem Vorhersagekopf, der an das Zielmodell angehängt ist – und das Zielmodell verifiziert alle K in einem einzigen Vorwärtsdurchlauf. Die Entwurfsphase ist günstig, typischerweise 5–20 % der Zeit des Vorwärtsdurchlaufs des Zielmodells, während die Verifizierung jedes entworfene Token mit dem vergleicht, was das Zielmodell generiert hätte, und das längste übereinstimmende Präfix akzeptiert, beginnend mit dem ersten Ablehnungsfall neu sampelt.

Die Verifizierung von K Tokens kostet etwa so viel wie die autoregressive Generierung eines Tokens. Wenn der Entwurf korrekt ist, erhält man also K Tokens zum Preis eines einzigen Verifizierungsschritts.

Ein konkretes Beispiel

Nehmen wir an, das Entwurfsmodell schlägt 5 Tokens vor: ["Ich", " mag", " kochen", " und", " reisen"]. Das Zielmodell verifiziert sie in einem einzigen Vorwärtsdurchlauf:

Das Zielmodell akzeptiert Tokens 1 und 2, generiert dann " spielen" für Token 3 und erzeugt so drei Tokens in einem Zyklus statt drei separater Vorwärtsdurchläufe. Wäre der Entwurf bis Token 5 korrekt gewesen, hätte man fünf Tokens zum Preis einer einzigen Verifizierung erhalten – eine 5-fache Beschleunigung allein in diesem Zyklus.

Der Verifizierungs-Engpass

In der Praxis dominiert die Verifizierung die Ausführungszeit – 42–95 % des Zyklus, abhängig von der Methode und der Modellgröße. Der Vorwärtsdurchlauf des Zielmodells ist der Engpass, und abgelehnte Tokens stellen vergebliche Rechenarbeit dar.

Deshalb ist die Akzeptanzrate so wichtig. Jedes abgelehnte Token nach dem ersten ist verschwendete Verifizierungsarbeit. Die besten Methoden der spekulativen Dekodierung maximieren die erwartete Anzahl akzeptierter Tokens pro Zyklus, nicht nur die reine Akzeptanzrate.

Die mathematische Garantie

Eine der wichtigsten Eigenschaften der spekulativen Dekodierung ist, dass sie Tokens aus der exakt gleichen Verteilung erzeugt wie die Standard-Autoregressive Stichprobenerhebung aus dem Zielmodell. Der Verifizierungsschritt verwendet Ablehnungssampling (Rejection Sampling) – wenn der Entwurf Token x vorschlägt, berechnet das Zielmodell seine eigene Wahrscheinlichkeit p(x) und der Entwurf berechnet p_draft(x). Die Akzeptanzwahrscheinlichkeit beträgt:

min(1, p(x) / p_draft(x))

Wenn das Zielmodell zustimmt (p(x) ≥ p_draft(x)), wird das Token immer akzeptiert. Wenn das Zielmodell nicht zustimmt, wird das Token mit einer Wahrscheinlichkeit proportional zum Verhältnis akzeptiert, und abgelehnte Tokens werden aus einer Residualverteilung neu gesampelt:

r(x) = max(0, p(x) - p_draft(x)) / Σ max(0, p(y) - p_draft(y))

Dieses Verfahren garantiert, dass die Ausgabefolge exakt der Verteilung des Zielmodells folgt, weshalb spekulative Dekodierung verlustfrei ist. Das Entwurfsmodell beeinflusst die Geschwindigkeit, nicht die Qualität – die erhaltenen Tokens sind statistisch nicht von der Standarddekodierung zu unterscheiden, mit derselben Perplexität und Verteilung. Der einzige Unterschied ist die Latenz.

Strategien für Entwurfsmodelle

Der Entwurfsmechanismus ist die Variable, die am meisten zählt. Verschiedene Ansätze haben unterschiedliche Abwägungen zwischen Einrichtungskomplexität, Akzeptanzrate und Beschleunigung.

Standalone-Entwurfsmodelle

Der einfachste Ansatz lädt ein kleineres Modell neben dem Zielmodell – typischerweise ein 1B-3B-Modell, das für ein 7B-70B-Zielmodell entwirft.

Vorteile:

• Konzeptlich straightforward (geradlinig)
• Funktioniert mit jedem Zielmodell
• Entwurfsmodell kann angepasst werden, um der Verteilung des Ziels zu entsprechen

Nachteile:

• Erfordert das Laden eines zweiten Modells in den VRAM (1–4 GB, abhängig von der Größe)
• Die Qualität des Entwurfsmodells bestimmt direkt die Akzeptanzrate
• Entwürfe über Familien hinweg (z. B. Qwen entwirft für Llama) performen typischerweise schlecht

Faustregel: Verwende Modelle aus derselben Familie. Gemma 2 2B entwirft gut für Gemma 2 27B. Llama 3.2 1B entwirft gut für Llama 3.1 70B. Entwürfe über Familien hinweg neigen zu niedrigen Akzeptanzraten, da die Token-Verteilungen divergieren.

Finden kompatibler Entwurfsmodelle

Nicht alle kleinen Modelle funktionieren als Entwurfsmodelle für ein gegebenes Ziel. Der kritische Faktor ist die Verteilungsausrichtung – wie eng die Ausgabe-Wahrscheinlichkeiten des Entwurfsmodells mit denen des Ziels übereinstimmen.

Die goldene Regel: Wenn die Akzeptanzrate des Entwurfsmodells unter 50 % fällt, kann spekulative Dekodierung dich tatsächlich verlangsamen. Der Overhead des Ausführens des Entwurfsmodells plus der Verifizierung überwiegt den Nutzen, wenn die meisten Vorschläge abgelehnt werden.

EAGLE und EAGLE-3: Vorhersageköpfe

EAGLE (Efficient Architecture Guided Language Model Estimation) eliminiert die Notwendigkeit eines separaten Entwurfsmodells. Stattdessen werden lightweight autoregressive Vorhersageköpfe an die internen Schichten des Zielmodells angehängt.

Wie EAGLE funktioniert

EAGLE trainiert Vorhersageköpfe, die Hidden States aus den Zwischenschichten des Zielmodells aufnehmen und zukünftige Tokens vorhersagen. Während der Inferenz:

1. Das Zielmodell führt einen Vorwärtsdurchlauf durch seine Schichten durch.
2. In jeder Schicht liest der EAGLE-Kopf den Hidden State und schlägt Tokens für zukünftige Positionen vor.
3. Mehrere Köpfe arbeiten parallel, jeder vorhersagt einen anderen zukünftigen Zeitstempel.
4. Das Zielmodell verifiziert alle Vorschläge in einem einzigen Durchlauf.

Der Vorteil: EAGLE-Köpfe sind speziell darauf trainiert, der Verteilung des Zielmodells zu entsprechen. Sie sehen die internen Repräsentationen des Ziels direkt, was ihnen eine viel bessere Ausrichtung gibt als ein Standalone-Entwurfsmodell.

EAGLE-3-Verbesserungen

EAGLE-3 (2025) verfeinert den Ansatz mit drei Schlüsseländerungen:

1. Schichtenauswahl: Anstatt Köpfe an jede Schicht anzuhängen, verwendet EAGLE-3 Bayesianische Optimierung, um die optimale Ausgangsschicht auszuwählen und den Overhead zu reduzieren.
2. Multi-Token-Vorhersage: Jeder Kopf vorhersagt mehrere Tokens gleichzeitig und erhöht die Entwurfstiefe ohne proportionalen Rechenkostenanstieg.
3. Trainings-effizienz: EAGLE-3 trainiert auf den eigenen Generierungsdaten des Zielmodells, was die Akzeptanzraten bei in-der-Verteilung-Workloads verbessert.

Akzeptanzraten: EAGLE-3 erreicht typischerweise Akzeptanzraten von 60–80 % bei in-der-Verteilung-Workloads, im Vergleich zu 40–60 % für Standalone-Entwurfsmodelle. Bei Code-Generierungs-Workloads mit hoher Wiederholung kann die Akzeptanz 85 % überschreiten.

Einrichtung: EAGLE-3 erfordert vortrainierte Köpfe für dein Zielmodell. NVIDIA stellt EAGLE-3-Köpfe für mehrere populäre Modelle über TensorRT-LLM und die Speculative Decoding Modules-Sammlung auf HuggingFace bereit. Drittanbieter-Implementierungen existieren für vLLM und SGLang.

P-EAGLE: Paralleles Entwerfen (März 2026)

Die Hauptbeschränkung von EAGLE-3 ist das autoregressive Entwerfen – jedes Entwurfs-Token hängt vom vorherigen ab, sodass das Generieren von K Entwurfs-Tokens K sequentielle Vorwärtsdurchläufe durch den Entwurfskopf erfordert, und der Entwurfs-Overhead wächst linear mit K. P-EAGLE entfernt diese Obergrenze, indem es alle K Entwurfs-Tokens in einem einzigen Vorwärtsdurchlauf durch einen lightweight 4-Schichten-Drafter erzeugt, der darauf trainiert ist, bis zu 10 Tokens parallel vorherzusagen.

Das Ergebnis: P-EAGLE liefert auf NVIDIA B200 bis zu 1,69x Beschleunigung gegenüber vanilla EAGLE-3 bei echten Workloads. Der Vorteil vergrößert sich bei höheren K-Werten – wo das sequentielle Entwerfen von EAGLE-3 zum Engpass wird, verursacht paralleles Entwerfen bei P-EAGLE keine zusätzlichen Kosten.

Einrichtung in vLLM: Lade einen vortrainierten P-EAGLE-Kopf von HuggingFace herunter, setze "parallel_drafting": true in deiner vLLM-Konfiguration und verwende dasselbe --speculative-model-Flag – vLLM kümmert sich um den Rest. P-EAGLE ist der aktuelle State-of-the-Art für EAGLE-basierte spekulative Dekodierung, und wenn du EAGLE 2026 einsetzt, ist P-EAGLE die Variante der Wahl.

n-Gramm-Spekulative Dekodierung

N-Gramm-spekulative Dekodierung ersetzt einen neuronalen Entwurf durch Mustervergleich gegen Prompt-Historie. Der Algorithmus sucht nach wiederholten n-Gramm-Sequenzen im Kontext, und wenn die aktuelle Token-Sequenz einem zuvor gesehenen Muster entspricht, schlägt er die Tokens vor, die diesem Muster früher gefolgt sind – zum Beispiel, wenn das Modell bereits def calculate_total(items): generiert hat und erneut auf def calculate_total( trifft, weiß es, dass die nächsten Tokens wahrscheinlich items): sein werden, basierend auf der vorherigen Vorkommens.

Die n-Gramm-Map-Varianten (ngram-map-k, ngram-map-k4v) verwenden Hash-Tabellen für schnellere Lookups anstatt linearer Scans, wobei der Hash-Schlüssel das aktuelle n-Gramm der Größe N ist und der Wert die Token-Sequenz, die gefolgt ist.

Vorteile:

• Null VRAM-Overhead – kein zusätzliches Modell zu laden (~16 MB für die Hash-Tabelle)
• Extrem schnell bei repetitiven Workloads (Code-Editierung, Refactoring, Template-Generierung)
• Akzeptanzraten können bei Workloads mit hoher Selbstähnlichkeit 90 %+ erreichen

Nachteile:

• Nutzlos für neue Generierung – wenn das Muster vorher nicht aufgetreten ist, hat n-Gramm nichts vorzuschlagen
• Akzeptanzrate fällt bei kreativen oder diversen Workloads auf nahezu null
• Begrenzte Entwurfstiefe (typischerweise 2–4 Tokens pro Treffer)

Am besten für: Code-Refactoring, Template-Füllung, repetitive Dokumentation und jede Workload, bei der das Modell ähnliche Muster wiederholt. Am schlechtesten für: kreatives Schreiben, offenes Chatting und Reasoning-Aufgaben.

Parameter-Tuning

Die n-Gramm-Parameter sind wichtiger, als man erwarten würde. Die Standardwerte funktionieren für Code, aber Text-Workloads benötigen Anpassung:

Für Text-Workloads, reduziere size-n auf 8–10 und erhöhe min-hits auf 2. Dies tauscht Trefferhäufigkeit gegen höhere Akzeptanzraten pro Treffer.

Selbst-Spekulative Dekodierung

Selbst-spekulative Dekodierung (auch LayerSkip oder Selbst-Spekulation genannt) verwendet die partielle Berechnung des Modells selbst als Entwurf, sodass kein separates Modell benötigt wird.

Wie es funktioniert

Anstatt das vollständige Modell für jedes Token auszuführen, führt selbst-spekulative Dekodierung eine abgeschnittene Version aus – einige Transformer-Schichten werden übersprungen –, um Entwurfs-Tokens kostengünstig zu erzeugen, und das vollständige Modell verifiziert dann die Vorschläge.

Zum Beispiel könnte ein 32-Schichten-Modell mit nur 16 Schichten für das Entwerfen laufen, dann mit allen 32 Schichten verifizieren. Der abgeschnittene Vorwärtsdurchlauf ist schneller, weil er weniger Schichten verarbeitet, und die Entwurfs-Tokens profitieren davon, dieselben anfänglichen Schichten wie das Ziel zu sehen.

Vorteile:

• Keine zusätzlichen Modellgewichte zu laden
• Natürlich ausgerichtet mit der Zielverteilung (gleiche Architektur, partielle Schichten)
• Funktioniert gut für Modelle mit signifikanter Redundanz in tieferen Schichten

Nachteile:

• Erfordert Modifikation des Inferenz-Engines, um partielle Vorwärtsdurchläufe zu unterstützen
• KV-Cache-Komplikationen – der Entwurf verwendet einen partiellen KV-Cache, der mit dem Cache des vollständigen Modells in Einklang gebracht werden muss
• Akzeptanzraten sind typischerweise niedriger als bei EAGLE oder gut abgestimmten Entwurfsmodellen

llama.cpp-Implementierung: PR #18471 führte selbst-spekulative Dekodierung unter Verwendung von Kontexthistorie als Entwurf ein. Das Modell reutilisiert Tokens aus seiner eigenen Generierungshistorie, um Fortsetzungen vorzuschlagen, was besonders effektiv für Coding-Workloads ist, bei denen Muster innerhalb desselben Kontextfensters wiederkehren.

MTP (Multi-Token Prediction)

MTP ist eine spezialisierte Form der spekulativen Dekodierung, die direkt in bestimmte Modell-Checkpoints eingebaut ist. Qwen 3.6 liefert sowohl Standard- als auch MTP-fähige GGUF-Varianten.

Wie es sich unterscheidet: MTP-Köpfe sind während des Trainings in die Modellarchitektur eingearbeitet. Das Modell trägt zusätzliche Vorhersageköpfe, die in einem einzigen Vorwärtsdurchlauf mehrere zukünftige Tokens vorschlagen. Es gibt kein separates Entwurfsmodell – die MTP-Köpfe sind Teil des Zielmodells selbst.

Abwägungen:

• Kein Entwurfsmodell zu verwalten – MTP wird aktiviert mit --spec-type draft-mtp --spec-draft-n-max N
• MTP-Köpfe fügen ~1–2 GB VRAM-Overhead hinzu
• Funktioniert am besten auf MoE-Architekturen (Qwen 3.6 35B-A3B), wo sparse Routing die MTP-Köpfe günstig hält

Für detaillierte Benchmarks zu MTP vs. Standarddekodierung über Qwen 3.6 27B und 35B, siehe Qwen 3.6 MTP vs Standard on 16GB GPU.

Akzeptanzraten: Was sie in der Praxis bedeuten

Akzeptanzrate (α) ist der wichtigste Metrik für die Performance der spekulativen Dekodierung. Sie bestimmt, ob du eine Beschleunigung erhältst oder Overhead zahlst.

Die Beschleunigungsformel

Erwartete akzeptierte Tokens pro Verifizierungsdurchgang:

E[accepted] = α × K

Wobei K die Anzahl der pro Zyklus vorgeschlagenen Entwurfs-Tokens ist. Wenn α = 0,7 und K = 5, akzeptierst du 3,5 Tokens pro Durchgang – eine 3,5-fache Beschleunigung gegenüber der Standarddekodierung (die 1 Token pro Durchgang erzeugt).

Akzeptanzrate nach Methode

Wenn die Akzeptanzrate sinkt

Die Akzeptanzrate ist über eine Generierung hinweg nicht konstant. Sie variiert je nach:

• Token-Position: Frühe Tokens neigen zu höherer Akzeptanz (mehr Kontext, weniger Unsicherheit). Spätere Tokens sinken, während das Modell diverse Fortsetzungen erkundet.
• Workload-Typ: Code-Editierung mit wiederholten Mustern sieht α > 80 %. Offenes kreatives Schreiben sieht α < 40 %.
• Temperatur: Höhere Temperatur erhöht die Divergenz zwischen Entwurf und Ziel, was die Akzeptanz senkt. Spekulative Dekodierung funktioniert am besten bei niedriger Temperatur (0,0–0,7).

Kritische Schwelle: Wenn deine effektive Akzeptanzrate (α × K) unter 1,0 fällt, ist spekulative Dekodierung langsamer als Standarddekodierung. Der Entwurfs-Overhead plus Verifizierungszeit übersteigt die Kosten eines einzelnen autoregressiven Schritts.

Spekulative Dekodierung in der Produktion: Was tatsächlich passiert

Forschungspapiere berichten von 2–4x Beschleunigungen, aber Produktions-Benchmarks erzählen eine nuanciertere Geschichte – Beschleunigungen schrumpfen mit der Batch-Größe, Verifizierung dominiert die Zykluszeit, und keine einzelne Methode gewinnt bei jeder Workload.

SpecDecode-Bench-Befunde (2026)

Eine systematische Evaluierung von fünf SD-Varianten (n-Gramm, EAGLE, EAGLE-3, Draft-Model, MTP) auf vLLM über vier Modelle und sechs Workloads enthüllte:

1. SD funktioniert, aber Beschleunigungen schrumpfen mit der Batch-Größe. Bei Batch-Größe 1 erreicht EAGLE bis zu 1,96x auf Llama-3-70B. Bei Batch-Größe 128 fällt dies auf 1,21x. Das System wird bei hoher Konnektivität rechengebunden, und die GPU hat weniger untätige Kapazität, die für Spekulation zur Verfügung steht.

2. Verifizierung dominiert die Ausführungszeit (42–95 %). Der Vorwärtsdurchlauf des Zielmodells ist der Engpass. Die Reduzierung verschwendeter Verifizierung bei abgelehnten Tokens ist der vielversprechendste Ansatz für Verbesserungen.

3. Keine einzelne Methode gewinnt überall. EAGLE-3 ist die beste Allround-Wahl. Draft-Model-Methoden excelieren, wenn das Zielmodell groß ist (70B+). n-Gramm ist optimal für Code-Editierung und Aufgaben mit hoher Überlappung.

4. Oracle-Analyse offenbart eine Lücke. Die theoretische Obergrenze für kombinierte n-Gramm + EAGLE-Strategien erreicht ~4,9x bei Code-Editierungs-Workloads, aber aktuelle Implementierungen erreichen 2–3x. Es gibt Raum für Optimierung.

Praktische Beschleunigungserwartungen

Der Batch-Größen-Effekt ist kritisch. Bei kleinen Batches hat die GPU untätige Rechenleistung, die für Spekulation zur Verfügung steht. Bei großen Batches ist das System bereits gesättigt, und spekulative Dekodierung fügt Overhead hinzu, ohne proportionalen Nutzen.

Monitoring in der Produktion

Du solltest die Akzeptanzrate in der Produktion tracken. Eine sinkende Akzeptanzrate signalisiert, dass sich dein Entwurfsmodell vom Ziel entfernt – entweder weil sich die Workload geändert hat, oder weil das Entwurfsmodell neu trainiert werden muss.

Wichtige Metriken zum Tracken:

• Akzeptanzrate pro Anfrage (sollte stabil um deinen Basismwert liegen)
• Tokens pro Sekunde mit vs. ohne spekulative Dekodierung (die tatsächliche Beschleunigung)
• Verifizierungszeit als Prozentsatz der Zykluszeit (sollte 42–95 % betragen)
• Vorwärtsdurchlaufzeit des Entwurfsmodells (sollte < 20 % der Zeit des Zielmodells betragen)

Wenn deine Akzeptanzrate unter 40 % fällt, deaktiviere spekulative Dekodierung für diese Anfrage. Der Overhead ist es nicht wert.

Praktische Einrichtung

Die Wahl des Engines ist genauso wichtig wie die Entwurfsstrategie – siehe Ollama vs vLLM vs LM Studio and other local runtimes für eine Übersicht, wie jeder Runtime Batching, API-Kompatibilität und Durchsatz handhabt, bevor du einen Pfad der spekulativen Dekodierung wählst.

llama.cpp

Für die allgemeine Server-Einrichtung und GGUF-Loading, beginne mit dem llama.cpp quickstart; die Flags unten fügen spekulative Dekodierung hinzu.

llama.cpp unterstützt mehrere Methoden der spekulativen Dekodierung über das --spec-type Flag:

# Entwurfsmodell (standalone)
llama-server \
  --model target-model.gguf \
  --draft-model draft-model.gguf \
  --spec-draft-n-max 4 \
  --parallel 1  # Pflicht: --parallel 1 für spekulative Dekodierung

# n-Gramm
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 12 \
  --spec-ngram-simple-size-m 48

# n-Gramm (Text-Workload-Tuning)
llama-server \
  --model target-model.gguf \
  --spec-type ngram-simple \
  --spec-ngram-simple-size-n 8 \
  --spec-ngram-simple-size-m 32 \
  --spec-ngram-simple-min-hits 2

# MTP (Qwen 3.6)
llama-server \
  --model Qwen3.6-27B-MTP.gguf \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

# Selbst-spekulative (Coding-Workloads)
llama-server \
  --model target-model.gguf \
  --spec-type draft-self

Kritische Flags:

• --parallel 1 – Spekulative Dekodierung in llama.cpp erfordert den Single-Batch-Modus. Dies ist eine aktuelle Beschränkung.
• --spec-draft-n-max – Anzahl der Entwurfs-Tokens pro Zyklus. Beginne mit 3–5; höhere Werte erhöhen den VRAM-Druck.
• --spec-ngram-simple-size-n – Lookup n-Gramm-Länge. Standard 12 funktioniert gut für Code; reduziere auf 8 für Text.

Häufige Fallstricke:

• Vergessen von --parallel 1 – der Server ignoriert spekulative Dekodierung stillschweigend.
• Verwendung von Entwurfsmodellen über Familien hinweg – Akzeptanzraten kollabieren, was jede Beschleunigung zunichte macht.
• Setzen von --spec-draft-n-max zu hoch – jedes zusätzliche Entwurfs-Token kostet VRAM für den Entwurfsbuffer. Abnehmende Renditen treten bei etwa 5–8 auf.

vLLM

Der vLLM quickstart deckt die Basisbereitstellung ab; die Flags unten aktivieren spekulative Dekodierung auf einem bestehenden vLLM-Server.

vLLM unterstützt spekulative Dekodierung über die --speculative-model und --speculative-num-steps Flags:

# Entwurfsmodell
vllm serve target-model \
  --speculative-model draft-model \
  --speculative-num-steps 5 \
  --speculative-accept-length 5

# EAGLE-3
vllm serve target-model \
  --speculative-model EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-draft-tensor-parallel-size 1

# P-EAGLE (paralleles Entwerfen)
vllm serve target-model \
  --speculative-model P-EAGLE-target-model/ \
  --speculative-num-steps 7 \
  --speculative-parallel-drafting true

# n-Gramm
vllm serve target-model \
  --speculative-method ngram \
  --speculative-num-steps 5 \
  --ngram-context-size 12

Die spekulative Dekodierung von vLLM ist mit kontinuierlichem Batching integriert, sodass sie bei koncurrenten Workloads funktioniert. Der Scheduler handhabt mehrere Token-Slots innerhalb eines einzigen Vorwärtsdurchlaufs, und der Memory-Manager handhabt den KV-Cache für Entwurfs- und Zielmodelle.

SGLang

SGLang unterstützt spekulative Dekodierung über sein --speculative-algorithm Flag:

python -m sglang.launch_server \
  --model-path target-model \
  --speculative-algorithm ngram \
  --ngram-context-size 12 \
  --ngram-max-candidate-tokens 6

SGLangs RadixAttention-Architektur paart sich gut mit spekulativer Dekodierung, weil Prefix-Caching die Verifizierungskosten reduziert – das Zielmodell reutilisiert gecachte Aufmerksamkeit für gemeinsame Präfixe, was jeden Verifizierungsdurchlauf günstiger macht als einen kalten Vorwärtsdurchlauf.

TensorRT-LLM

TensorRT-LLM bietet spekulatives Dekodieren in Produktionsqualität mit Triton Inference Server. Die Einrichtung ist komplexer, bietet aber die beste Performance auf NVIDIA-Hardware:

1. Baue den TensorRT-Engine für Ziel- und Entwurfsmodelle.
2. Konfiguriere das Model Repository mit model.yaml, das die Konfiguration der spekulativen Dekodierung spezifiziert.
3. Starte Triton mit der LLM API / PyTorch Backend.

TensorRT-LLM unterstützt sowohl Entwurfs-Modell- als auch EAGLE-3-Varianten. Für Code-Generierungs-Workloads hat TensorRT-LLM mit n-Gramm-spekulativer Dekodierung eine Latenzreduktion von 2–3x in Produktionsbereitstellungen demonstriert.

Wann man spekulative Dekodierung verwenden sollte

Verwende es, wenn

• Große Zielmodelle (7B+): Der Overhead des Entwurfsmechanismus wird über die Berechnung des Ziels amortisiert. Spekulative Dekodierung glänzt, wenn das Zielmodell langsam ist – je größer das Ziel, desto wertvoller die Beschleunigung.
• Low-Temperature-Workloads: Spekulative Dekodierung funktioniert am besten bei Temperatur 0,0–0,7, wo die Verteilung des Zielmodells konzentriert ist und der Entwurf eine bessere Chance auf Übereinstimmung hat.
• Interaktive Anwendungen: Latenz-sensitive Workloads (Chat, Code-Vervollständigung, Agent-Tool-Aufrufe) profitieren am meisten. Batch-Verarbeitung, bei der du die GPU bereits sättigst, sieht weniger Nutzen.
• Code-Generierung und -Editierung: Hohe Wiederholung in Code-Mustern macht n-Gramm und selbst-spekulative Dekodierung besonders effektiv.

Überspringe es, wenn

• Kleine Zielmodelle (< 3B): Der Overhead des Entwurfsmodells nähert sich der Vorwärtsdurchlaufzeit des Ziels. Die Beschleunigung ist marginal oder negativ.
• High-Temperature-Sampling: Bei Temperatur > 0,7 ist die Verteilung des Zielmodells zu breit, als dass der Entwurf zuverlässig mithalten könnte.
• Kreatives Schreiben und offene Generierung: Niedrige Akzeptanzraten bei neuem Inhalt machen den Overhead nicht lohnenswert.
• Hohe Batch-Größen (> 32): Das System wird rechengebunden, und spekulative Dekodierung fügt Overhead hinzu, ohne proportionalen Nutzen. SpecDecode-Bench zeigt einen Rückgang der Beschleunigung von 1,96x auf 1,21x, wenn die Batch-Größe von 1 auf 128 steigt.

Kombinieren von Methoden

Fortgeschrittene Setups kombinieren mehrere Strategien der spekulativen Dekodierung. Die Oracle-Analyse von SpecDecode-Bench zeigte, dass das adaptive Kombinieren von n-Gramm und EAGLE die Beschleunigung bei Code-Editierungs-Workloads auf 4,9x drücken kann.

Die Idee ist, n-Gramm für Muster zu verwenden, die zuvor aufgetreten sind, wo die Akzeptanz hoch und der Overhead nahe null ist, und auf EAGLE für neue Tokens zurückzugreifen. In der Praxis erfordert dies Engine-Unterstützung für Multi-Method-Spekulation – vLLM und TensorRT-LLM haben experimentelle Unterstützung, aber Produktions-Implementierungen reifen noch.

Für jetzt ist die praktischste Kombination MTP + n-Gramm in llama.cpp. MTP handhabt die neuronale Spekulation, während n-Gramm repetitive Muster einfängt, die MTP verpasst. Auf Qwen 3 27B erreicht diese Kombination 120 Tokens/Sekunde im Vergleich zu 67 Tokens/Sekunde Standard – eine 1,8-fache Beschleunigung.

Kostenüberlegungen

Spekulative Dekodierung tauscht Rechenleistung gegen Latenz. Die gesamte Rechenleistung pro Token ist ungefähr gleich – du machst einfach mehr Arbeit parallel statt sequentiell.

Auswirkung auf GPU-Kosten:

• Die Latenz einzelner Anfragen verbessert sich um 20–50 %, was für interaktive Anwendungen wichtig ist.
• Der Durchsatz (Tokens/Sekunde über viele Anfragen) verbessert sich weniger – die GPU ist bei hohen Batch-Größen bereits gesättigt.
• Die VRAM-Nutzung erhöht sich um den Footprint des Entwurfsmodells (1–4 GB für Standalone-Entwürfe, minimal für n-Gramm/EAGLE).

Cloud-Inferenz: Bei $2–4/Stunde pro H100 reduziert spekulative Dekodierung die Latenz pro Anfrage, ohne die Kosten pro Token zu erhöhen. Für Batch-Verarbeitung, bei der du die GPU bereits sättigst, ist der Kostenvorteil minimal – du zahlst für dieselbe GPU-Zeit auf jeden Fall.

Wann spekulative Dekodierung Geld spart: Interaktive Anwendungen, bei denen du pro Anfrage berechnest und die Time-to-First-Token reduzieren möchtest. Eine 2x-Beschleunigung bedeutet, dass deine Nutzer halb so lange warten, und du kannst mehr Anfragen pro Sekunde auf derselben Hardware bedienen.

Wann sie nicht: Batch-Verarbeitung, bei der du die GPU-Nutzung bereits maximierst. Die zusätzliche Rechenleistung der spekulativen Dekodierung erhöht den Durchsatz nicht – sie ändert nur das Latenzprofil.

Was kommt als Nächstes

Spekulative Dekodierung reift von Forschungsnovelty zum Produktionsstandard. Die Frontier drängt über die aktuellen Beschränkungen hinaus:

• Speculative Speculative Decoding (SSD): Parallelisiert die Entwurfs- und Verifizierungsstufen über separate Hardware. Das Entwurfsmodell läuft asynchron, spekuliert voraus für mehrere wahrscheinliche Verifizierungsergebnisse. Frühe Ergebnisse zeigen bis zu 2x Beschleunigung gegenüber optimierter spekulativer Dekodierung und 5x gegenüber autoregressiver Dekodierung. Noch nicht produktionsreif, aber die Richtung ist klar.

• SpecSA (Sparse Speculative Verification): Kombiniert spekulative Dekodierung mit dynamischer sparse Aufmerksamkeit. Verwandelt sparse Aufmerksamkeit in eine verifizierungsorientierte Workload und erreicht bis zu 3,49x End-to-End-Durchsatz gegenüber autoregressiver sparse Dekodierung. Relevant für Long-Context-Modelle, bei denen sparse Aufmerksamkeit bereits im Einsatz ist.

• Adaptive Spekulation: Automatisches Umschalten zwischen n-Gramm, EAGLE und Entwurfs-Modell-Methoden basierend auf Workload-Eigenschaften. Die Oracle-Analyse zeigt signifikantes ungenutztes Potenzial – aktuelle Implementierungen erreichen 2–3x, aber die theoretische Obergrenze liegt bei 4,9x.

• Multimodale spekulative Dekodierung: Erweiterung von Entwurf-Verifizierung auf Vision-Language-Modelle und Video-Generierung. Frühe Umfragen zeigen, dass dieselben Prinzipien gelten, aber Verifizierungsstrategien für nicht-textuelle Modalitäten angepasst werden müssen.

Entscheidungsframework