Speculative Decoding: Wann LLMs schneller antworten

Für die Anwendungsentwicklung zählt, ob die Antwort unter der eigenen Arbeitslast schneller ausgegeben wird. Im Betrieb stellt sich die Frage, ob dieser Vorteil auch bei parallelen Anfragen und knappem Speicher bestehen bleibt. Wer eine gehostete API nutzt, muss zunächst klären, ob der Anbieter die Optimierung überhaupt zugänglich macht oder dokumentiert.

Dokumentation geprüft am 30. Oktober 2026: vLLM, SGLang und NVIDIA TensorRT-LLM. Die folgenden Befehle entsprechen der aktuellen Dokumentation. Es handelt sich um Konfigurationsbeispiele, nicht um Benchmark-Ergebnisse dieses Artikels.

Was ist Speculative Decoding?

Ein Vorschlagsverfahren mit geringem Rechenaufwand schätzt die nächsten Tokens; das Zielmodell entscheidet, welche davon in die Antwort gelangen. Ein Token ist eine Texteinheit, die das Modell verarbeitet, häufig ein Teil eines Wortes. Das Zielmodell ist das Modell, dessen Verhalten erhalten bleiben soll.

Das Prinzip ähnelt einer Assistenz, die einen Satz für einen sorgfältigen Redakteur vorformuliert. Die Assistenz kann vorarbeiten, doch erst nach der Prüfung erreicht der Text die Leserschaft. Der entscheidende Vorteil: Das Zielmodell kann die vorgeschlagene Fortsetzung gemeinsam auswerten. Es muss nicht für jedes neue Token einen eigenen Generierungsschritt abwarten. NVIDIA beschreibt das Verfahren als Entwurfserzeugung mit anschließender Prüfung durch das Zielmodell. TensorRT-LLM-Dokumentation

In der Abbildung stehen die Buchstaben für Token-IDs. Das Entwurfsmodell schlägt A B C vor. Beim Greedy Decoding wird jeweils das nächste Token mit der höchsten Wahrscheinlichkeit gewählt. Angenommen, das Zielmodell stimmt mit A B überein, bevorzugt danach aber X: Dann lautet die übernommene Antwort A B X. Auch eine bereits entworfene Fortsetzung nach dem abgelehnten C würde verworfen, weil sie auf dem falschen Präfix beruhte.

Beim Sampling reicht es nicht, zu prüfen, ob beide Modelle dasselbe Wort gewählt haben. Das übliche Speculative Sampling verwendet die Wahrscheinlichkeiten des Ziel- und des Vorschlagsmodells. Wird ein Vorschlag abgelehnt, kommt eine Korrekturverteilung zum Einsatz. Diese Korrektur erhält die Wahrscheinlichkeitsverteilung des Zielmodells. Der ursprüngliche Algorithmus erlaubt außerdem ein zusätzliches Token des Zielmodells, wenn der gesamte Entwurf akzeptiert wird. Originalarbeit von Leviathan, Kalman und Matias

Das kleinere Modell liefert also Vorschläge; es springt nicht als Ersatz für das antwortende Modell ein. Bei einer exakten Prüfung sollte ein ungeeignetes Entwurfsmodell die Geschwindigkeit beeinträchtigen, statt unbemerkt die Antwort zu übernehmen.

Was bedeutet „ohne ein schlechteres Modell“?

Die entscheidende Zusage ist der Erhalt der Verteilung des Zielmodells. Das bedeutet weder, dass bei jedem Durchlauf dieselbe zufällige Antwort entsteht, noch dass Fehler des Zielmodells verschwinden oder seine Schlussfolgerungen besser werden. vLLM dokumentiert numerische und durch Batching verursachte Effekte, die selbst bei einem verlustfreien Algorithmus zu Unterschieden führen können. vLLM zu den Garantien verlustfreier Verfahren

Bei der Bewertung müssen Gewichte, Quantisierung und Sampling-Einstellungen des Zielmodells unverändert bleiben. Werden mehrere Dinge zugleich geändert, lässt sich ein Qualitätsunterschied keiner einzelnen Ursache mehr zuordnen.

Die wichtigsten Varianten und ihre Dokumentation

Entscheidend ist, welches Vorschlagsverfahren das konkrete Zielmodell und die eingesetzte Version der Serving-Engine unterstützen. Das Grundprinzip bleibt gleich: Entwurf erstellen, anschließend prüfen. Was sich ändert, ist die Herkunft des Entwurfs.

Ein separates Entwurfsmodell

Ein kleineres Sprachmodell erzeugt mit eigenen Gewichten die Token-Kandidaten. Das ist der anschaulichste Aufbau, erfordert aber, ein weiteres Modell zu laden und zu betreiben. Kompatibilität und Übereinstimmung sind entscheidend: Ein kleineres Modell ist nicht automatisch ein nützliches Entwurfsmodell. vLLM setzt normalerweise ein gemeinsames Vokabular voraus, dokumentiert aber auch eine eingeschränkte Option für unterschiedliche Vokabulare. Entwurfsmodelle in vLLM

Läuft ein Dienst bereits nahe an seiner Speichergrenze, kann ein zweites Modell der falsche erste Schritt sein. Für einen latenzkritischen Dienst mit freien Kapazitäten und einem gut passenden Entwurfsmodell ist ein kontrollierter Versuch dagegen sinnvoll.

Speculative Decoding mit EAGLE

EAGLE steht für Extrapolation Algorithm for Greater Language-model Efficiency und verwendet einen trainierten, dem Zielmodell zugeordneten Hilfsmechanismus für die Entwurfserzeugung. Dieser nutzt interne Repräsentationen des Zielmodells, um die Fortsetzung vorzuschlagen. Die trainierten Komponenten, oft als Heads bezeichnet, benötigen einen kompatiblen Checkpoint. vLLM unterscheidet die Konfigurationen eagle und eagle3. EAGLE-Dokumentation von vLLM

Zielmodell und EAGLE-Checkpoint müssen ein kompatibles Paar bilden. Der Name derselben Modellfamilie allein ist kein ausreichendes Auswahlkriterium. Die richtige Familie, die Modellrevision und die Serving-Implementierung gehören gemeinsam in die Dokumentation der Bereitstellung.

Speculative Decoding mit MTP

Multi-Token Prediction, kurz MTP, nutzt die im Modell selbst angelegte Fähigkeit, künftige Tokens vorzuschlagen. vLLM dokumentiert MTP für unterstützte Modellfamilien und zeigt einen Startbefehl, der keine Kennung für ein separates Entwurfsmodell benötigt. Ein Modell ohne diese Fähigkeit erhält sie nicht dadurch, dass method auf mtp gesetzt wird. MTP-Dokumentation von vLLM

Wer bereits einen unterstützten MTP-Checkpoint betreibt, sollte dessen dokumentierte Konfiguration erproben, bevor ein unabhängiges Entwurfsmodell hinzukommt. Das verringert die Zahl der zu klärenden Kompatibilitätsfragen. Die Leistung muss dennoch gemessen werden.

Die folgende Übersicht verlinkt direkt auf die Dokumentation der jeweiligen Engines. Sie zeigt die Einstiegspunkte für die Konfiguration und bedeutet nicht, dass jedes Modell mit jedem aufgeführten Verfahren funktioniert.

Der Name eines Algorithmus sagt noch nichts darüber aus, wie seine Ausführung organisiert ist. Laut den aktuellen Versionshinweisen von TensorRT-LLM entfällt der Ausführungspfad mit einer separaten Draft-Engine. Erhalten bleiben Implementierungen, die den Entwurfsmechanismus als Untermodul in das Modell integrieren. Das bedeutet nicht, dass der Ansatz aus Entwurfs- und Zielmodell verschwunden ist. Ältere Bereitstellungsanleitungen können aber einen Ausführungspfad beschreiben, den die installierte Version nicht mehr bietet. Versionshinweise zu TensorRT-LLM

Wann wird die LLM-Inferenz schneller – und wann nicht?

Speculative Decoding lohnt sich nur, wenn nutzbare Ausgabe auch unter Einrechnung des gesamten Zusatzaufwands schneller entsteht. Die Akzeptanzrate ist wichtig, bildet aber nur einen Teil dieser Rechnung ab.

Die akzeptierten Tokens müssen den Entwurfsaufwand aufwiegen

Die Akzeptanzrate ist die Zahl der akzeptierten Entwurfstokens geteilt durch die Zahl der vorgeschlagenen Entwurfstokens. Für sich genommen sagt sie nichts darüber aus, wie aufwendig die Vorschläge waren. Ein langsameres Entwurfsmodell kann häufiger mit dem Zielmodell übereinstimmen und den Dienst trotzdem ausbremsen.

Eine hilfreiche Entscheidungsregel lautet:

(Entwurfszeit + Prüfzeit + Koordinationszeit) ÷ übernommene Ausgabetokens < Dekodierzeit pro Token ohne Speculative Decoding

Das ist eine Aufwandsrechnung, keine Benchmark-Prognose. Gemessen werden muss die vollständige Runde auf der eingesetzten Hardware. Zu den „übernommenen Ausgabetokens“ zählen auch Korrektur- oder Bonustokens des Zielmodells, nicht nur akzeptierte Entwurfsvorschläge.

Bei einem Assistenten für Codeänderungen können wiederkehrende lokale Strukturen die Vorschläge nützlich machen. Ein Supportassistent stimmt möglicherweise bei höflichen Überleitungen häufig mit dem Zielmodell überein, hat aber Schwierigkeiten mit produktspezifischen Antworten. Beide Arbeitslasten sollten getrennt gemessen werden, bevor eine durchschnittliche Akzeptanzrate zur Grundlage einer Bereitstellungsentscheidung wird.

Längere Entwürfe erzeugen zudem mehr Arbeit, die später verworfen werden kann. Die Entwurfstiefe sollte nur steigen, solange die zusätzlich übernommene Ausgabe den Aufwand für Entwurf, Prüfung und Speicher ausgleicht. Fireworks trifft in seinen Hinweisen zur Optimierung dieselbe Unterscheidung für den Betrieb: Akzeptanz allein belegt keinen Geschwindigkeitsgewinn. Benchmark-Hinweise von Fireworks

Die Batchgröße beeinflusst das Verbesserungspotenzial

Der Einstieg empfiehlt sich bei interaktiven Arbeitslasten mit einem Engpass in der Dekodierung. Danach folgt der Test bei der Spitzenzahl gleichzeitiger Anfragen. vLLM sieht Speculative Decoding ausdrücklich für speicherbandbreitenlimitierte Arbeitslasten bei niedrigen bis mittleren Anfrageraten vor. In einem solchen Schritt begrenzt die Übertragung der Modelldaten den Fortschritt stärker als die verfügbare Rechenleistung. vLLM zu geeigneten Arbeitslasten

Die parallele Prüfung kann ansonsten ungenutzte Rechenleistung auslasten. Ein stark ausgelasteter Server verwendet diese Kapazität womöglich bereits für andere Anfragen. Daraus folgt: Eine geringere Latenz in einem einzelnen Chat belegt noch keinen höheren Gesamtdurchsatz eines stark genutzten Endpunkts.

Continuous Batching verändert, welche Anfragen jeweils einen Generierungsschritt gemeinsam durchlaufen. Speculative Decoding muss unter diesem Scheduler und mit dem tatsächlich auftretenden Ankunftsmuster der Anfragen bewertet werden. Ein kaum genutzter Entwicklungsendpunkt und ein Produktivendpunkt mit Warteschlange sind unterschiedliche Testszenarien.

Eine allgemeingültige Grenze für die Batchgröße ist nicht sinnvoll. Wo der Vorteil endet, hängt von Modell, Hardware, Entwurfsverfahren und Scheduler ab. Latenz und Kapazität müssen gleichermaßen betrachtet werden: Wie schnell wird eine Antwort ausgegeben, und welches Anfragevolumen bewältigt der Dienst innerhalb seiner Latenzvorgabe?

Speicherbedarf kann den Vorteil zunichtemachen

Der Entwurfsmechanismus beansprucht einen Teil des begrenzten GPU-Speichers. Separate Gewichte, der Entwurfszustand und Arbeitsbereiche für die Prüfung können Platz belegen, der sonst für Anfragen verfügbar wäre. Auch der KV-Cache, der den Attention-Zustand bereits vorhandener Tokens speichert, gehört in diese Speicherbilanz.

Ein Dokumentenassistent kann bei kurzen Prompts schnell sein und bei langen Dokumenten dennoch nahe an seiner Kapazitätsgrenze laufen. Ein erfolgreicher Test mit kurzen Prompts klärt nicht, ob das Entwurfsmodell auch neben dem Cache im Produktivbetrieb noch Platz findet. Getestet werden sollte die längste vorgesehene Kontextlänge bei realistischer Zahl gleichzeitiger Anfragen.

Die Hinweise von SGLang zu Speicherengpässen nennen ausdrücklich das Reduzieren der Speicherreservierung, der Größen für Graph Capture, der Größe des Entwurfsbaums und der gleichzeitigen Anfragen. Muss die Zahl paralleler Anfragen sinken, damit Speculative Decoding in den Speicher passt, ist das eine abzuwägende Einschränkung, keine kostenlose Optimierung. SGLang zur Behebung von Speicherproblemen

Dort beschleunigen, wo die Wartezeit entsteht

Eine langsame Antwort kann verschiedene Ursachen haben: lange Wartezeit vor Beginn der Ausgabe, langsames Streaming danach oder Verzögerungen außerhalb des Modells. Speculative Decoding setzt bei der Generierung an. Verbringt eine Anwendung den Großteil ihrer Zeit mit der Dokumentensuche oder dem Warten auf einen Tool-Aufruf, verändert eine schnellere Dekodierschleife das Nutzungserlebnis womöglich kaum.

Warteschlange, Prefill und Decode sollten getrennt gemessen werden. Prefill verarbeitet den Prompt, Decode erzeugt die Fortsetzung. Der Leitfaden zur LLM-Inferenz erklärt diese Phasen. Der Leitfaden zu Tokens pro Sekunde grenzt die Ausgabegeschwindigkeit vom gesamten Anfragedurchsatz ab.

So lässt sich Speculative Decoding aktivieren

Speculative Decoding wird im Serving-Prozess aktiviert und anschließend mit demselben Zielmodell ohne diese Funktion verglichen. Die Beispiele setzen voraus, dass die Engine bereits installiert ist, die ausgewählten Modelle in den Speicher der Hardware passen und Zugriff auf ihre Gewichte besteht. Die Dokumentation muss zur eingesetzten Version passen. Eine aktuelle latest-Seite garantiert keine Kompatibilität mit einem älteren Container.

Speculative Decoding in vLLM

vLLM erhält die Einstellungen als JSON-Objekt über --speculative-config. Dieses Beispiel mit separatem Entwurfsmodell übernimmt Zielmodell, Entwurfsmodell und Entwurfslänge aus der Dokumentation zum Online-Serving:

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

Die 5 ist die Anzahl der vorgeschlagenen Tokens in diesem Beispiel, kein empfohlenes Optimum. Die Dokumentation kennzeichnet die älteren separaten Optionen --speculative-model und --num-speculative-tokens als veraltet. Startbeispiele für vLLM

Das dokumentierte Beispiel für native MTP mit dem Basis-Checkpoint von Xiaomi MiMo lautet:

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

Das Beispiel verwendet ein anderes Modell. Es liefert kein direkt einsetzbares Entwurfsmodell für das oben gezeigte Qwen-Zielmodell. Entscheidend ist die Unterstützung durch den Checkpoint: MTP muss im Modell vorhanden sein und von der Engine unterstützt werden. MTP-Startbeispiel für vLLM

Speculative Decoding in SGLang

Das aktuelle Beispiel von SGLang für den Overlap-Scheduler verwendet ein Qwen-Zielmodell mit separatem Qwen-Entwurfsmodell:

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

Der aktuelle Overlap-Ausführungspfad setzt --speculative-eagle-topk 1 voraus. Ein breiterer Baum, der aus einem anderen Beispiel übernommen wurde, ist damit nicht kompatibel. Die dokumentierten Einstellungen für Scheduler und Entwurfserzeugung müssen zusammenpassen. SGLang-Beispiel für den Overlap-Scheduler

Für wechselnde Arbeitslasten dokumentiert SGLang separat adaptive Spekulation für unterstützte EAGLE-Konfigurationen. Ob sich die Entwurfstiefe automatisch anpassen kann, hängt von den Voraussetzungen dieses Features ab. Adaptive Spekulation in SGLang

Konfiguration in TensorRT-LLM

TensorRT-LLM übernimmt die Einstellungen aus einer YAML-Konfiguration. Der folgende Inhalt wird als speculative.yaml gespeichert:

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

Entwurfslänge und Checkpoint stammen aus NVIDIAs Konfigurationsbeispiel für Speculative Decoding. Das passende Zielmodell wird mit der dokumentierten Serving-CLI gestartet:

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

Neben dem Konfigurationsnamen muss auch die Checkpoint-Generation geprüft werden. NVIDIA dokumentiert Eagle als Kompatibilitätsalias für Eagle3. Ältere EAGLE-Checkpoint-Generationen bleiben mit diesem Ausführungspfad inkompatibel. TensorRT-LLM zu den Einschränkungen bei Checkpoints

Wenn neben dem Verfahren auch die Serving-Engine zur Wahl steht, hilft der umfassendere Vergleich von vLLM und SGLang. Ein gutes Entwurfsmodell kann ein anderes Feature, das die Anwendung benötigt und der Engine fehlt, nicht ersetzen.

Profitieren auch Teams mit einer gehosteten API?

Ja, sofern der Anbieter das Verfahren dokumentiert und aktiviert. Welche Einstellungen zugänglich sind, hängt vom Dienst ab. Eigene GPUs sind keine Voraussetzung, um von der Serving-Optimierung eines Anbieters zu profitieren.

Der Anbieter für gehostete Inferenz Fireworks AI dokumentiert voreingestellte Entwurfsmodelle für die meisten unterstützten Modelle auf dedizierten Bereitstellungen. Ein Modell ohne voreingestelltes Entwurfsmodell läuft ohne modellbasiertes Speculative Decoding, sofern nichts anderes konfiguriert wurde. Die Serverless-Konfiguration verwaltet Fireworks selbst. Aus den Optionen für dedizierte Bereitstellungen lässt sich deshalb nicht ableiten, dass jeder Serverless-Endpunkt Speculative Decoding nutzt. Fireworks-Dokumentation zur Bereitstellung

Für Anwendungen, die eine Datei mit kleinen Änderungen neu erzeugen, dokumentiert Fireworks außerdem Predicted Outputs: Der erwartete Text wird im Feld prediction der Anfrage übergeben. Dieser bekannte Text dient als andere Quelle für Vorschläge und kann zusammen mit modellbasiertem Speculative Decoding verwendet werden. Das ist hilfreich, wenn große Teile der Antwort bereits feststehen, weniger bei offenen Fragen. Predicted Outputs von Fireworks

Bei einem anderen gehosteten Endpunkt muss dessen eigene Dokumentation den Vorteil belegen, bevor er zugesagt oder eine entsprechende Einstellung ergänzt wird. API-Kompatibilität allein sagt nichts darüber aus, welches Entwurfsmodell hinter einem Endpunkt läuft – oder ob dort überhaupt eines eingesetzt wird.

Welche Erwartungen sind überzogen?

Speculative Decoding verbessert das Serving unter bestimmten Bedingungen. Es ist kein allgemeingültiger Geschwindigkeitsmultiplikator. Dieser Artikel verspricht bewusst keinen konkreten Beschleunigungsfaktor: Ein Ergebnis mit einem anderen Zielmodell, Entwurfsmodell, einer anderen GPU und einem anderen Anfragemix beschreibt nicht den eigenen Dienst.

„Mehr akzeptierte Tokens machen die Anwendung schneller“ lässt den Entwurfsaufwand, Warteschlangen und sämtliche Arbeit der Anwendung rund um die Generierung außer Acht. „Ein längerer Entwurf ist besser“ ignoriert die Arbeit, die nach einer Ablehnung verworfen wird. „Verlustfrei bedeutet identische Zeichenfolgen“ verwechselt eine Sampling-Verteilung mit einem bestimmten Zufallsergebnis.

Der teuerste Fehler besteht darin, aus dem Ergebnis eines kaum ausgelasteten Endpunkts eine Aussage über die Produktivkapazität abzuleiten. Ein Programmierassistent kann sich für den Entwickler schneller anfühlen, während der gemeinsam genutzte Endpunkt weniger parallele Sitzungen bewältigt. Ob Antwortlatenz, dauerhafter Durchsatz oder beides optimiert werden soll, muss feststehen und in den Kriterien für die Einführung sichtbar sein.

Was lässt sich nächste Woche konkret umsetzen?

In der Anwendungsentwicklung lohnt sich ein Test mit einem kompatiblen Vorschlagsverfahren, wenn Decode den Engpass bildet. Im Betrieb zählt ein nachweisbarer Vorteil unter Produktivlast. Teams mit gehosteten APIs sollten bei den Einstellungen beginnen, die ihr Anbieter tatsächlich dokumentiert.

Entsteht die meiste Wartezeit vor der Generierung, sollte zuerst dieser Engpass behoben werden. Passt das Entwurfsmodell nicht in den Speicher oder existiert kein kompatibler Checkpoint, läuft das Zielmodell regulär weiter. Dass ein Feature verfügbar ist, belegt noch nicht, dass die eigene Bereitstellung es braucht.

Häufige Fragen aus der Entwicklung

Den Newsletter abonnieren für praxisnahe Leitfäden zur Entwicklung und zum Betrieb von KI-Systemen.