Was ist speculative decoding? Wie LLM Token schneller entwerfen und prüfen

speculative decoding ist eine Inferenztechnik für LLM, die die Token-Erzeugung beschleunigt, ohne die Ausgabequalität zu verändern. Ein kleineres, schnelleres Entwurfsmodell schlägt mehrere Kandidaten-Token im Voraus vor. Das größere Zielmodell prüft sie alle in einem einzigen parallelen Durchlauf, behält gültige Vorhersagen und zieht ab der ersten Abweichung neue Stichproben, um seine exakte Ausgabeverteilung zu erhalten.

Große Sprachmodelle erzeugen Antworten normalerweise Token für Token. Jeder neue Ausgabeschritt erfordert das Lesen der Modellgewichte aus dem Speicher. Während auf die Speicherbandbreite gewartet wird, bleibt die Rechenleistung des Beschleunigers ungenutzt. speculative decoding durchbricht diesen Engpass von einem Token pro Schritt, indem es sequenzielle Prüfungen in eine parallele Verifizierung umwandelt.

Warum ist die herkömmliche autoregressive Decodierung langsam?

Die herkömmliche autoregressive Decodierung ist langsam, weil jedes Token einen eigenen Vorwärtsdurchlauf durch das gesamte Modell erfordert. Der Prozess wird daher durch die Speicherbandbreite und nicht durch die Rechenleistung begrenzt.

Wenn ein Sprachmodell eine Antwort schreibt, hängt jedes Token von allen vorherigen Token ab. Bei der herkömmlichen Decodierung muss ein Modell mit 70 Milliarden Parametern seine Gewichte aus dem Speicher mit hoher Bandbreite laden, um das erste Token zu erzeugen, dieselben Gewichte für das zweite Token erneut laden und diesen Zyklus Hunderte Male wiederholen.

Viele Token einer Antwort sind jedoch leicht vorherzusagen. Funktionswörter, schließende Klammern in Code, häufige Wendungen und Standardsyntax erfordern nicht die gesamte Denktiefe eines riesigen Modells, um sie genau zu erraten, auch wenn dessen abschließende Beurteilung der gesamten Antwort weiterhin erwünscht ist. Da GPU und TPU einen kurzen Tokenblock parallel in nahezu derselben verstrichenen Zeit verarbeiten können wie ein einzelnes Token, liegt bei der Decodierung einzelner Token zusätzliche Rechenkapazität brach. speculative decoding nutzt diese freie parallele Kapazität.

Wie funktioniert speculative decoding Schritt für Schritt?

Bei speculative decoding läuft eine Schleife aus vier Schritten, bis die Antwort vollständig ist: Kandidaten-Token entwerfen, sie mit dem Zielmodell parallel prüfen, passende Token annehmen und beim ersten abgelehnten Token erneut eine Stichprobe ziehen.

Statt das große Zielmodell jedes Token sequenziell erzeugen zu lassen, kombiniert die Inferenz-Engine es mit einer viel kleineren, schnelleren Näherung (oft Entwurfsmodell genannt). Jeder Zyklus durchläuft vier unterschiedliche Phasen:

1. Kandidaten-Token entwerfen: Ausgehend von der aktuellen Sequenz erzeugt das kleine Entwurfsmodell schnell nacheinander ein kurzes Vorschaufenster von $K$ Kandidaten-Token und zeichnet für jede Position seine Wahrscheinlichkeitsverteilung auf.
2. Parallele Verifizierung: Das große Zielmodell nimmt die ursprüngliche Sequenz und alle $K$ entworfenen Token und führt einen einzigen Vorwärtsdurchlauf aus. Da Transformer-Architekturen bekannte Tokensequenzen parallel auswerten können – genau wie bei der Verarbeitung des Prompts –, berechnet das Zielmodell gleichzeitig seine eigenen Wahrscheinlichkeitsverteilungen für jede entworfene Position.
3. Entworfene Token annehmen oder ablehnen: Von links nach rechts vergleicht die Engine bei den $K$ entworfenen Token in jedem Schritt die Wahrscheinlichkeit des Entwurfsmodells mit der des Zielmodells. Dazu verwendet sie eine formale Regel für das Rejection Sampling (oft speculative sampling genannt). Bei der gierigen Decodierung (Temperatur null) wird ein entworfenes Token angenommen, wenn es der ersten Wahl des Zielmodells entspricht. In Sampling-Modi werden Token immer angenommen, denen das Zielmodell mindestens ebenso viel Wahrscheinlichkeit zuweist wie das Entwurfsmodell; Token mit geringerer Wahrscheinlichkeit werden proportional zum Verhältnis der Wahrscheinlichkeit des Zielmodells zu der des Entwurfsmodells angenommen.
4. Erneutes Sampling und Erzeugung eines Bonus-Tokens: Tritt die erste Abweichung an Position $m$ auf, werden dieses Token und alle nachfolgenden entworfenen Token verworfen. Ein Ersatztoken für Position $m$ wird direkt aus einer angepassten Restverteilung gezogen, die die Wahrscheinlichkeiten beider Modelle berücksichtigt. Werden alle $K$ entworfenen Token angenommen, liegt dem Zielmodell aus demselben parallelen Durchlauf bereits die Wahrscheinlichkeitsverteilung für Position $K + 1$ vor. Damit kann es ohne zusätzliche Kosten ein weiteres Bonus-Token ziehen.

Da die Regeln für Ablehnung und erneutes Sampling die Fehler des Entwurfsmodells mathematisch ausgleichen, ist speculative decoding verlustfrei. Jeder Schritt mit mehreren Token erzeugt Stichproben aus exakt derselben Wahrscheinlichkeitsverteilung wie das Zielmodell allein – die Benchmark-Genauigkeit, die Denkfähigkeit und der Ton verschlechtern sich also nicht.

Wie viel schneller ist speculative decoding in der Praxis?

Grundlegende Forschungsarbeiten zeigen, dass speculative decoding bei großen Sprachmodellen mit einem gut passenden Entwurfsmodell und ausreichender paralleler Rechenleistung die verstrichene Zeit ungefähr um den Faktor 2X bis 3X verkürzt.

Die grundlegenden Arbeiten, die die Technik Ende 2022 und Anfang 2023 vorstellten, zeigten erhebliche Latenzgewinne sowohl bei Encoder-Decoder- als auch bei reinen Decoder-Transformern, ohne Modellgewichte oder Ausgabeverteilungen zu verändern:

Studie	Zielmodell	Entwurfskonfiguration	Berichtete Beschleunigung nach verstrichener Zeit	Bedingungen und Aufgaben
Leviathan et al. (2023)	T5-XXL (11B Parameter)	T5-small (77M Parameter)	2X–3X (bis zu 2.6X–3.4X in den Konfigurationstabellen für T5-small)	Unveränderte T5X-Implementierung für Übersetzung (EN-DE) und Zusammenfassung (CNN/DM) mit argmax (temp 0) und Standard-Sampling (temp 1).
Chen et al. (2023)	Chinchilla (70B Parameter)	Entwurfsmodell mit 4B Parametern, für speculative sampling trainiert	2X–2.5X	Verteilte Konfiguration auf TPU v4 für Zusammenfassung (XSum) und Codegenerierung (HumanEval).

Beachten Sie den Größenunterschied zwischen Ziel- und Entwurfsmodell in beiden Studien: T5-small ist ungefähr zwei Größenordnungen kleiner als T5-XXL, und das Entwurfsmodell mit 4B ist nur ein kleiner Bruchteil des Chinchilla-Modells mit 70B. Ein Entwurfsmodell muss klein genug sein, damit $K$ sequenzielle Schritte darauf gegenüber einem einzigen Schritt des Zielmodells nur sehr wenig zusätzlichen Aufwand verursachen.

Was bestimmt die Annahmerate und warum ist eine Beschleunigung nicht garantiert?

Die Beschleunigung durch speculative decoding hängt von zwei Hauptfaktoren ab: wie gut das Entwurfsmodell mit dem Zielmodell übereinstimmt (die Annahmerate) und wie viel freie parallele Rechenleistung die Hardware hat. Eine Nettobeschleunigung ist daher nie garantiert.

Wenn das Entwurfsmodell ständig falsch rät, trägt das System die Latenzkosten für $K$ sequenzielle Schritte auf dem Entwurfsmodell, nur damit das Zielmodell bereits das erste Token ablehnt. In diesem schlechtesten Fall erzeugt ein spekulativer Zyklus nur ein erneut gezogenes Token und dauert dabei länger als ein herkömmlicher Schritt des Zielmodells.

Mehrere praktische Faktoren bestimmen, ob speculative decoding die Inferenz beschleunigt oder verlangsamt:

• Abstimmung zwischen Entwurfs- und Zielmodell: Das Entwurfsmodell muss exakt denselben Tokenizer und dasselbe Vokabular wie das Zielmodell verwenden, und seine Trainingsverteilung sollte eng übereinstimmen. Codevervollständigung, strukturierte JSON-Ausgabe und die Übersetzung vorhersehbarer Formulierungen erzielen tendenziell höhere Annahmeraten als kreatives Schreiben bei hoher Temperatur, bei dem viele sehr unterschiedliche Token gleichermaßen plausibel sind.
• Zusätzliche Latenz des Entwurfsmodells: Selbst eine hohe Annahmerate beschleunigt die Erzeugung nicht, wenn das Entwurfsmodell selbst zu groß und langsam ist. Leviathan et al. zeigten, dass ein kleineres Entwurfsmodell T5-small bei der Gesamtbeschleunigung nach verstrichener Zeit die größeren Kandidaten T5-base und T5-large übertraf, weil sein Entwurfsaufwand pro Schritt viel geringer war.
• Länge des Vorschaufensters ($K$): Eine zu kurze Vorschau begrenzt die Anzahl der Token, die in einem Durchlauf geprüft werden können. Eine zu lange Vorschau verschwendet Entwurfszeit für spätere Token, die verworfen werden, sobald ein früheres Token abgelehnt wird.
• Verfügbare parallele Rechenleistung (Auslastung bei Batch-Größe): speculative decoding tauscht ungenutzte Rechenleistung gegen geringere Latenz. Bei latenzkritischer Bereitstellung mit kleinen Batches haben Beschleuniger reichlich freie Leistung, um $K$ Token parallel mit nahezu keinem zusätzlichen Zeitaufwand zu prüfen. Bei sehr großen gleichzeitigen Batches, wenn die Recheneinheiten der GPU bereits voll ausgelastet sind, erhöhen $K$ zusätzliche Prüfpositionen pro Anfrage die Durchlaufzeit und können die Beschleunigung aufheben.

Wie hängt speculative decoding mit KV cache und Prompt-Caching zusammen?

speculative decoding beschleunigt nur die Decode-Phase der Ausgabeerzeugung. Das Caching im KV cache vermeidet dagegen die erneute Berechnung der Aufmerksamkeit über Token hinweg, und Prompt-Caching beschleunigt und verbilligt das Prefill wiederholter Eingaben.

Da alle drei Optimierungen die Inferenzlatenz von Transformern betreffen, verwechseln Entwickler häufig ihre jeweilige Rolle im Lebenszyklus einer Anfrage:

• Prefill und Decode: Jede LLM-Anfrage besteht aus zwei Phasen. Prefill verarbeitet alle Token des Eingabeprompts parallel, um den Anfangszustand aufzubauen. Diese Phase ist bereits rechenleistungsgebunden und pro Token schnell. Decode erzeugt die Ausgabetoken Schritt für Schritt und ist durch die Speicherbandbreite begrenzt. speculative decoding hilft nur in der Decode-Phase; das Lesen eines langen Eingabeprompts wird dadurch nicht beschleunigt.
• Rolle des KV cache: Sowohl das Zielmodell als auch das Entwurfsmodell nutzen bei speculative decoding jeweils ihren eigenen KV cache. Während Kandidaten-Token entworfen und geprüft werden, werden ihre Key- und Value-Zustände an den Cache angehängt. Lehnt das Zielmodell entworfene Token nach Position $m$ ab, setzt die Inferenz-Engine die KV cache beider Modelle einfach zurück, indem sie sie kürzt. So werden die abgelehnten Einträge vor dem nächsten Zyklus entfernt.
• Abgrenzung zum Prompt-Caching: Prompt-Caching verwendet vorberechnete KV cache-Blöcke für identische Prompt-Präfixe über separate API-Aufrufe hinweg erneut. Das verkürzt die Zeit bis zum ersten Token (TTFT) und senkt häufig die Preise für Eingabetoken. speculative decoding verringert die Latenz zwischen Token (ITL), während die Antwort gestreamt wird.

Was bedeutet speculative decoding für API-Entwickler und Selbsthoster?

Für API-Entwickler zeigt sich speculative decoding in einer geringeren Streaming-Latenz über die gesamte Anfrage hinweg, nicht als separater Rechnungsposten. Selbsthoster konfigurieren es direkt in Inferenz-Engines, um die Reaktionszeit je Anfrage zu verbessern.

Wie Sie mit speculative decoding umgehen, hängt davon ab, ob Sie gehostete Modellendpunkte aufrufen oder eine eigene GPU-Flotte verwalten:

1. Die Abrechnung gehosteter APIs pro Token ändert sich selten: Gehostete KI-Anbieter rechnen aus Nutzersicht im Allgemeinen pro Million verarbeiteter Eingabe- und Ausgabetoken ab. Auch wenn ein Anbieter intern speculative decoding verwendet, bleiben abgelehnte Entwurfs-Token innerhalb der Bereitstellungs-Engine: Berechnet werden die endgültig erzeugten Ausgabetoken zum Standardsatz des Modells. Um nicht nur die Wartezeit, sondern die direkte API-Rechnung zu senken, betrachten Sie Prompt Engineering, Batch-APIs und praktische Möglichkeiten zur Senkung der KI-API-Kosten oder vergleichen Sie die Preise bei der Entscheidung, wie man ein KI-Modell auswählt.
2. Vorteile für die Echtzeit-Nutzererfahrung: Für Anwendungsentwickler liegt die Stärke von speculative decoding in der Nutzererfahrung. Sprachagenten, Code-Assistenten in IDEs und interaktive Produktionsabläufe – von Live-Coding-Copiloten bis zu Skript-Pipelines mit kreativen Werkzeugen wie AI Studio Video – wirken spürbar flüssiger, wenn Ausgabetoken doppelt so schnell eintreffen, ohne zu einem schwächeren Modell zu wechseln.
3. Konfiguration beim Selbsthosting: Wenn Sie Modelle mit offenen Gewichten auf eigener Infrastruktur betreiben, konfigurieren Sie speculative decoding direkt in Ihrem Bereitstellungs-Stack. Sie müssen Ziel- und Entwurfsmodell in den GPU-Speicher laden (oder eine Variante ohne Entwurfsmodell verwenden), sicherstellen, dass beide exakt denselben Tokenizer nutzen, und die Vorschaulänge auf Ihre typische Anzahl gleichzeitiger Anfragen abstimmen.

Braucht man immer ein separates Entwurfsmodell?

Spätere Varianten von speculative decoding machen es unnötig, ein separates kleines Entwurfsmodell zu trainieren und bereitzustellen, behalten aber dasselbe Prinzip aus Entwurf und Prüfung bei.

Zwei separate Modelle im Speicher zu verwalten und ein kleines Modell mit exakt demselben Tokenizer und einem zum Zielmodell passenden Verhalten zu finden, kann im Betrieb umständlich sein. Um das zu lösen, haben Inferenzforscher und Bereitstellungs-Frameworks mehrere Ansätze ohne Entwurfsmodell eingeführt:

• Entwurf durch N-Gramm- und Prompt-Suche: Statt ein neuronales Netz zum Entwerfen von Token auszuführen, durchsucht die Engine den Eingabeprompt und die kürzlich erzeugte Ausgabe nach übereinstimmenden Textabschnitten und kopiert die folgenden Token als Kandidaten. Das funktioniert besonders gut beim Zusammenfassen von Dokumenten, Bearbeiten von Code oder Extrahieren von Zitaten, die bereits im Kontextfenster vorkommen.
• Vorhersageköpfe für mehrere Token und Hilfsschichten: Statt ein vollständiges eigenständiges Modell zu verwalten, kann eine kleine Gruppe leichtgewichtiger Vorhersageköpfe oder Entwurfsschichten direkt an die verborgenen Zustände des Zielmodells angehängt werden, um die nächsten Token in einem Durchlauf vorzuschlagen.
• Self-speculative decoding: Manche Konfigurationen verwenden eine Teilmenge der eigenen Schichten des Zielmodells und überspringen beim Entwerfen Zwischenschichten, um Kandidaten-Token zu erzeugen. Anschließend durchlaufen sie alle Schichten zur Prüfung.

Unabhängig davon, wie die Kandidaten-Token vorgeschlagen werden, bleibt die zentrale Garantie gleich: Das vollständige Zielmodell prüft die Kandidaten parallel und setzt bei jedem angenommenen Token seine exakte Wahrscheinlichkeitsverteilung durch.

Häufig gestellte Fragen

Verändert speculative decoding die Modellgenauigkeit oder Ausgabequalität?

Nein. Herkömmliches speculative decoding (speculative sampling) ist mathematisch verlustfrei. Bei gieriger Decodierung nimmt es nur Token an, die exakt der wichtigsten Vorhersage des Zielmodells entsprechen. Beim Sampling mit Temperatur stellen die Regeln für Ablehnung und erneutes Sampling aus der Restverteilung sicher, dass erzeugte Sequenzen exakt derselben Wahrscheinlichkeitsverteilung folgen wie bei herkömmlicher autoregressiver Decodierung mit dem Zielmodell.

Verkürzt speculative decoding die Zeit bis zum ersten Token (TTFT)?

Nein. Die Zeit bis zum ersten Token misst, wie lange das Modell benötigt, um Ihren Eingabeprompt in der Prefill-Phase zu lesen und das allererste Ausgabetoken auszugeben. Da Prefill die Prompt-Token bereits parallel verarbeitet, beschleunigt speculative decoding nur die anschließenden Decode-Schritte und reduziert so die Latenz zwischen Token und die gesamte Fertigstellungszeit für den Rest der Antwort.

Warum kann speculative decoding bei großen Batches langsamer sein?

speculative decoding nutzt freie parallele Rechenleistung der GPU oder TPU, um mehrere Entwurfs-Token in ungefähr derselben Zeit zu prüfen wie ein einzelnes Token. Bearbeitet ein Server einen sehr großen Batch gleichzeitiger Anfragen, ist die Rechenkapazität des Beschleunigers bereits vollständig ausgelastet. Die Prüfung zusätzlicher Entwurfs-Token pro Anfrage erhöht dann tatsächlich die Ausführungszeit und kann die eingesparten Speicherzugriffe aufwiegen.

Kann jedes kleine Modell für jedes große Modell als Entwurfsmodell dienen?

Bei herkömmlichem speculative decoding auf Tokenebene nicht unmittelbar. Entwurfs- und Zielmodell müssen ein kompatibles Vokabular und einen kompatiblen Tokenizer teilen, damit sich die IDs der Kandidaten-Token und ihre Wahrscheinlichkeitsverteilungen sauber zwischen beiden Modellen zuordnen lassen. Deshalb stammen solche Paare gewöhnlich aus derselben Modellfamilie, etwa T5-small als Entwurfsmodell für T5-XXL.

Quellen

• Yaniv Leviathan, Matan Kalman, and Yossi Matias — Fast Inference from Transformers via Speculative Decoding (arXiv:2211.17192, ICML 2023)
• Charlie Chen, Sebastian Borgeaud, Geoffrey Irving, Jean-Baptiste Lespiau, Laurent Sifre, and John Jumper — Accelerating Large Language Model Decoding with Speculative Sampling (arXiv:2302.01318, 2023)