Spekulatives Decoding für LLM-Inferenz: Durchsatzgewinne und Kompromisse

Spekulatives Decoding für LLM-Inferenz: Durchsatzgewinne und Kompromisse

Das Bereitstellen von LLMs mit spekulativem Decoding kann die Wartezeit auf das nächste Token verkürzen, ohne dass das Zielmodell zu einem anderen Modell werden muss. Anstatt das große Zielmodell bei jedem Decoding-Schritt nur ein Token erzeugen zu lassen, entwirft ein kostengünstigerer Vorschlaggeber eine kurze Fortsetzung. Das Zielmodell überprüft diese Fortsetzung parallel, übernimmt das akzeptierte Präfix und fährt ab der ersten Abweichung fort.

Das klingt nach einem universellen Beschleuniger. Ist es nicht. Das Ergebnis hängt von der Qualität des Entwurfs, dem Anfrage-Mix, Batching, Sampling-Einstellungen, verfügbarem GPU-Speicher und davon ab, ob Ihr Workload tatsächlich durch das Decoding begrenzt ist. Dieser Leitfaden erklärt, was unter der Haube passiert, wie EAGLE und Medusa das Design verändern und wie Sie entscheiden, ob spekulatives Decoding in Ihren Serving-Stack gehört.

Die praktische Regel: Betrachten Sie spekulatives Decoding als messbare Serving-Optimierung – nicht als Einstellung für Beschleunigungen aus wissenschaftlichen Veröffentlichungen. Behalten Sie es nur bei, wenn es die für Ihren tatsächlichen Traffic relevante Latenz oder den Durchsatz an Ausgabe-Tokens verbessert, ohne Parallelität oder Zuverlässigkeit zu verringern.

Was ist spekulatives Decoding bei der LLM-Inferenz?

Autoregressive Generierung erfolgt sequenziell: Token t + 1 hängt von den vorherigen Token ab. Ein normaler Decoder wartet daher darauf, dass ein großes Zielmodell einmal pro generiertem Token ausgeführt wird. Spekulatives Decoding verändert den Zeitplan, nicht die Zielverteilung: Ein kleinerer oder spezialisierter Entwurfsmechanismus prognostiziert mehrere Kandidaten-Token; das Zielmodell bewertet oder verifiziert die Kandidatenpositionen gemeinsam; das System akzeptiert das übereinstimmende Präfix und fällt an der ersten abgelehnten Position zurück.

Die ursprüngliche Arbeit zum spekulativen Decoding beschreibt dies als Möglichkeit, exakte Samples aus dem Zielmodell zu erhalten, während mehrere Kandidatenpositionen parallel ausgewertet werden. Das berichtete Ergebnis von 2–3× war ein Benchmark-Ergebnis für das T5-Setup der Arbeit, keine Zusage für jedes Modell oder jeden Dienst. Lesen Sie die Originalarbeit.

Ein Diagramm zur LLM-Inferenz mit spekulativem Decoding

request + current context
            |
            v
  draft mechanism proposes:  [A] [B] [C] [D]
            |
            v
  target model verifies all proposed positions in one pass
            |
            +-- accepts [A] [B] [C] -> commit that prefix (and possibly one extra target token)
            |
            +-- rejects at [C] -> commit [A] [B], sample/correct at [C], then repeat

Die eingesparte Arbeit ist nicht die Entwurfsberechnung selbst. Der potenzielle Gewinn entsteht dadurch, dass mehrere serielle Zielmodell-Decodierungsschritte durch einen Verifizierungsdurchlauf des Zielmodells ersetzt werden. Wenn der Vorschlag oft falsch ist, muss das Zielmodell weiterhin häufig korrigieren, und der Gewinn schrumpft.

Die entscheidende Kennzahl: akzeptierte Token pro Zielverifizierung

Das nützlichste Gesundheitssignal ist die Anzahl vorgeschlagener Token, die die Verifizierung überstehen. Teams bezeichnen dies häufig als Akzeptanzrate oder akzeptierte Länge. Verfolgen Sie beides:

Kennzahl	Was sie aussagt	Warum sie allein irreführend sein kann
Akzeptanzrate	Welchen Anteil der vorgeschlagenen Token das Ziel akzeptiert	Sie berücksichtigt weder Entwurfskosten noch Kosten der Zielverifizierung.
Mittlere akzeptierte Länge	Wie viele bestätigte Entwurfs-Token Sie pro Runde erhalten	Durchschnittswerte können Long-Tail-Anfragen und unterschiedliche Sampling-Modi verbergen.
Inter-Token-Latenz (ITL)	Zeit zwischen gestreamten Token	Dies ist in der Regel die für Nutzer sichtbare Decodierungskennzahl.
Aggregierte Ausgabe-Token/Sekunde	Nützliche Serving-Kapazität über gleichzeitige Anfragen hinweg	Sie kann sich verbessern, während ein interaktiver Nutzer mit niedriger QPS kaum profitiert – oder umgekehrt.
GPU-Speicher und Anzahl aktiver Anfragen	Ob der Proposer den KV-Cache oder die Parallelität verdrängt	Eine schnellere Einzelanfrage kann auf Flottenebene eine schlechtere Konfiguration sein.

Halten Sie für einen fairen A/B-Test Modellrevision, Tokenizer, Quantisierung, maximale Ausgabelänge, Prompt-Mix, Sampling-Parameter, Hardware und Parallelitätsrichtlinie konstant. Vergleichen Sie End-to-End-Latenz, Zeit bis zum ersten Token, p50/p95-ITL, Ausgabe-Token/Sekunde und Fehlerrate. Eine einzelne Zahl für „Token/Sek.“ ohne das zugehörige Lastprofil reicht nicht aus, um eine Konfiguration auszuwählen.

Wo spekulatives Decoding hilft – und wo nicht

LLM-Serving mit spekulativem Decoding ist in der Regel am attraktivsten, wenn die Decodierung speichergebunden ist und jede Anfrage genügend Generierungslänge besitzt, damit wiederholte Verifizierungsrunden relevant sind. Die aktuelle vLLM-Anleitung ordnet es ausdrücklich als Möglichkeit ein, die Inter-Token-Latenz bei speichergebundenen Workloads mit mittlerer bis niedriger QPS zu reduzieren, und weist darauf hin, dass reale Gewinne von Modellfamilie, Traffic, Hardware und Sampling-Einstellungen abhängen. Siehe die vLLM-Anleitung zum spekulativen Decoding.

In diesen Fällen ist es weniger überzeugend:

• Das Prefill dominiert die Anfrage. Lange Prompts mit kurzen Antworten verbringen den Großteil ihrer Zeit mit der Aufnahme des Kontexts. Entwurfserstellung verändert die Decodierungsarbeit, nicht die Prompt-Prefill-Arbeit, die bereits die End-to-End-Latenz dominiert.
• Die Akzeptanz ist schlecht. Kreatives Decoding, ein nicht passendes Entwurfsmodell oder eine Konfiguration mit schwachen Kandidatenfortsetzungen können wiederholte Verifizierungsfehler verursachen.
• Ihr Server ist bereits batch-ausgelastet. Bei hoher Parallelität kann die Ziel-GPU durch den normalen Scheduler effizient ausgelastet sein. Das Hinzufügen eines Drafters kann Speicher oder Rechenleistung verbrauchen, die andernfalls mehr Anfragen bedienen würde.
• Der Spielraum im KV-Cache ist knapp. Ein zusätzliches Entwurfsmodell oder ein Proposer-Zustand kann die Zahl aktiver Sequenzen reduzieren, bevor Eviction oder Warteschlangenbildung beginnt. Prüfen Sie GPU-Speicheranforderungen für LLMs, bevor Sie einen Geschwindigkeitsgewinn bei Einzelanfragen als Gewinn für die Flotte interpretieren.
• Das Zielmodell ist nicht mit dem gewählten Proposer kompatibel. Modellbasierte Methoden erfordern kompatible Artefakte, Tokenisierung und Serving-Unterstützung; nehmen Sie niemals an, dass ein kleines Modell allein deshalb ein gültiges Entwurfsmodell ist, weil es günstiger ist.

Die richtige Frage lautet daher nicht: „Kann spekulatives Decoding dieses Modell schneller machen?“ Sondern: „Welche Service-Level-Einschränkung verbessert es unter unserer Traffic-Verteilung?“

Entwurfsmodelle, EAGLE und Medusa: drei Wege, Token vorzuschlagen

Separates Entwurfsmodell

Das klassische Design kombiniert ein schnelles Entwurfsmodell mit einem größeren Zielmodell. Der Entwurf schlägt k Token vor; das Zielmodell verifiziert sie. Konzeptionell kann dies einfach sein, fügt jedoch ein weiteres Modellartefakt, Speicherbedarf, Kompatibilitätsaufwand und eine operative Oberfläche hinzu, die versioniert und überwacht werden muss.

Setzen Sie es ein, wenn Sie einen nachweislich kompatiblen Proposer mit niedriger Latenz haben und genügend GPU-Kapazität vorhanden ist, um die Parallelität des Ziel-Services zu erhalten. Beginnen Sie mit einer kleinen Auswahl spekulativer Längen, statt anzunehmen, dass ein tieferer Vorschlag immer besser ist.

EAGLE für spekulatives LLM-Decoding

EAGLE ist ein modellbasierter Ansatz, der auf Feature-Ebene entwirft, statt ausschließlich einen konventionellen kleinen Token-Modell-Vorschlagspfad zu verwenden. Die Arbeit beschreibt, wie die Feature-Vorhersage mit einer um einen Schritt vorausliegenden Token-Sequenz konditioniert wird, um Unsicherheit auf Feature-Ebene zu adressieren. In den getesteten Einstellungen der Arbeit werden verbesserte Latenz und höherer Durchsatz bei Erhalt der Verteilung des generierten Texts berichtet; das ist ein nützlicher Nachweis des Potenzials der Methode, aber keine Kapazitätsprognose für ein anderes Modell oder eine andere GPU-Flotte. Lesen Sie die EAGLE-Arbeit.

Für Betreiber ist die Schlussfolgerung einfach: EAGLE kann attraktiv sein, wenn unterstützte Artefakte für die Zielfamilie verfügbar sind, aber es ist kein generischer Schalter für jeden Checkpoint. Validieren Sie die genaue Zielmodell-/Proposer-Kopplung und die Version der Serving-Engine, bevor Sie sie produktiv einsetzen.

Medusa für spekulatives LLM-Decoding

Medusa setzt mehrere Decodierungsköpfe auf ein Backbone-Modell und verwendet baumbasierte Attention, um mehrere Kandidatenfortsetzungen zu erzeugen und zu verifizieren. Dadurch muss kein separates, vollständig unabhängiges Entwurfsmodell gepflegt werden, die Köpfe müssen jedoch für das Backbone trainiert oder feinabgestimmt werden. Die Medusa-Arbeit unterscheidet einen Pfad mit eingefrorenem Backbone von gemeinsamem Fine-Tuning und berichtet Benchmark-Beschleunigungen für diese experimentellen Setups. Lesen Sie die Medusa-Arbeit.

Der operative Kompromiss unterscheidet sich von einem Entwurfsmodell-Paar: potenziell weniger Verwaltung separater Modelle, jedoch ein modellspezifisches Artefakt sowie Trainings- oder Integrationsaufwand. Betrachten Sie es als Entscheidung für das Modell-Serving, nicht als Laufzeittrick.

Ein praktischer Einführungsplan für GPU-Inferenz

1. Eine repräsentative Baseline erstellen

Erfassen Sie mindestens einen produktionsähnlichen Ausschnitt von Anfragen: Prompt-Längenbereiche, Ausgabe-Längenbereiche, Sprach- oder Aufgabentyp, Temperature-/Top-p-Einstellungen, Streaming-Verhalten und Parallelitätsstufen. Zeichnen Sie die Baseline getrennt für Zeit bis zum ersten Token und Decodierung auf. Wenn der Workload promptlastig ist, lassen Sie nicht zu, dass ein Ausgabe-Token-Benchmark ein Prefill-Problem verschleiert.

2. Eine Proposer-Strategie und eine konservative Tiefe auswählen

Beginnen Sie mit einer unterstützten Methode – Entwurfsmodell, EAGLE, Medusa oder einem anderen von der Engine unterstützten Proposer – und einer kleinen Kandidatenlänge. vLLM dokumentiert beispielsweise --speculative-config-Einstellungen wie eine Methode, ein Proposer-Modell und num_speculative_tokens; konsultieren Sie die zur Version passende Dokumentation, bevor Sie eine Konfiguration in die Produktion übernehmen. Informationen zum umfassenderen operativen Setup finden Sie im vLLM-Bereitstellungsleitfaden. Optimieren Sie beim ersten Durchlauf nicht gleichzeitig spekulative Tiefe und Batching.

3. Eine Lastmatrix ausführen, nicht nur einen Benchmark

Testen Sie denselben Traffic-Ausschnitt bei niedriger, mittlerer und peakähnlicher Parallelität. Vergleichen Sie für jeden Punkt:

1. End-to-End-Latenz der Baseline mit der spekulativen Variante.
2. p50- und p95-Inter-Token-Latenz für Streaming-Anfragen.
3. Aggregierte Ausgabe-Token/Sekunde und abgeschlossene Anfragen/Sekunde.
4. Akzeptierte Länge, Häufigkeit von Ablehnungen und Proposer-Latenz.
5. GPU-Speicher, KV-Cache-Druck, Warteschlangenverzögerung und Fehler-/Timeout-Rate.

Wenn möglich, teilen Sie die Ergebnisse nach Prompt-Bereich und Ausgabe-Bereich auf. Eine Konfiguration, die bei langen Code-Vervollständigungen hilft, hilft möglicherweise nicht bei kurzen Chat-Antworten, und ein gutes Offline-Ergebnis kann sich verschlechtern, sobald Warteschlangen einbezogen werden.

4. Leitplanken vor dem Canary setzen

Definieren Sie Rollback-Schwellenwerte, bevor der Traffic die Änderung sieht: zum Beispiel eine Verschlechterung der p95-ITL, ein Rückgang abgeschlossener Anfragen/Sekunde bei Spitzenlast, eine Zunahme von Out-of-Memory-Ereignissen oder ein anhaltender Einbruch der Akzeptanzrate. Leiten Sie anfangs nur einen berechtigten Teil weiter und bewahren Sie einen Baseline-Pfad für schnelle Vergleiche.

5. Nach dem Start weiter messen

Die Akzeptanz verändert sich mit Modellupdates, Prompt-Verteilungen, Tool-Use-Formaten und Sampling-Standardeinstellungen. Wiederholen Sie den Vergleich nach jeder wesentlichen Änderung des Zielmodells, Tokenizers, der Quantisierung, GPU, Serving-Engine oder des Traffic-Profils.

Ein minimaler vLLM-Ausgangspunkt

Bei einer Serving-Engine, die dies unterstützt, sollte die Konfiguration die Proposer-Methode benennen, statt sie in einem undurchsichtigen Standardwert zu verbergen. Die aktuelle vLLM-Dokumentation verwendet für ein separates Entwurfsmodell eine Struktur wie diese:

vllm serve <target-model> \
  --speculative-config '{
    "method": "draft_model",
    "model": "<compatible-draft-model>",
    "num_speculative_tokens": 5
  }'

Die Platzhalter sind absichtlich gewählt. Das kompatible Modell, die Anzahl spekulativer Token, Parallelitätseinstellungen und Speicherbudget müssen anhand der Artefakte und der Engine-Version ausgewählt werden, die Sie getestet haben. Kopieren Sie dieses Snippet nicht als Nachweis dafür, dass ein bestimmtes Ziel-/Entwurfsmodell-Paar unterstützt wird.

Durchsatzgewinne und Kompromisse auf einen Blick

Entscheidung	Wahrscheinlicher Vorteil	Hauptkosten oder Fehlermodus	Was zuerst gemessen werden sollte
Ein separates Entwurfsmodell aktivieren	Weniger serielle Ziel-Decodierungsschritte bei hoher Akzeptanz	Zusätzlicher Modellspeicher, Kompatibilität und Entwurfslatenz	Akzeptierte Länge, KV-Cache-Spielraum, p95-ITL
Spekulative Länge erhöhen	Mehr potenzielle Token pro Verifizierung	Mehr verschwendete Entwurfsarbeit, wenn spätere Token abgelehnt werden	Netto-ITL und aggregierte Ausgabe-TPS, nicht nur Akzeptanz
EAGLE verwenden	Starker modellbasierter Vorschlagspfad, wo Artefakte unterstützt werden	Anforderungen an Modellfamilien- und Engine-Kompatibilität	Ziel-/Proposer-Kompatibilität und lastprofilierte Benchmark-Ergebnisse
Medusa verwenden	Mehrkopf-Vorschlag ohne separates vollständiges Entwurfsmodell	Modellspezifische Köpfe sowie Integrations-/Trainingsaufwand	Prüfungen der Ausgabequalität, Serving-Unterstützung und Rollback-Pfad
Bei Spitzen-QPS aktivieren	Möglicher Durchsatzvorteil in der richtigen Engine bzw. für den richtigen Workload	Scheduler-, Speicher- oder Rechenkonkurrenz kann den Gewinn aufheben	Abgeschlossene Anfragen/Sek., Wartezeit und Fehlerrate

FAQ

Verändert spekulatives Decoding die Antwort des Zielmodells?

Korrektes spekulatives Sampling verwendet Zielmodell-Verifizierung und -Korrektur, sodass das Sampling die Zielverteilung erhalten kann. Die Garantie hängt von der Verwendung eines korrekten Algorithmus und einer kompatiblen Implementierung ab. Eine Änderung am Serving kann dennoch das Betriebsverhalten beeinflussen – etwa Latenz, Warteschlangenbildung oder Fehler. Bewerten Sie daher Qualität und Zuverlässigkeit ebenso wie Geschwindigkeit.

Verbessert spekulatives Decoding die Zeit bis zum ersten Token?

In der Regel zielt es auf die Decodierungsphase nach Beginn der Generierung. Wenn die Prompt-Verarbeitung Ihre Anfragen dominiert, kann sich die Zeit bis zum ersten Token kaum ändern. Messen Sie Prefill und Decodierung getrennt.

Wie viele spekulative Token sollte ich verwenden?

Es gibt keinen universell besten Wert. Testen Sie einen kleinen Bereich mit Ihrem Modell, Proposer, Sampling-Einstellungen, GPU-Typ und Ihrer Parallelität. Ein längerer Vorschlag gewinnt nur, wenn genügend seiner Token akzeptiert werden und seine zusätzliche Arbeit die Service-Kapazität nicht reduziert.

Sollte ich EAGLE oder Medusa verwenden?

Wählen Sie die Methode, die Ihr Zielmodell und Ihre Serving-Engine gut unterstützen, und benchmarken Sie sie dann mit Ihrem Workload. EAGLE stützt sich auf unterstützte Feature-Level-Entwurfsartefakte; Medusa stützt sich auf mehrere einem Backbone zugeordnete Köpfe. Keine der beiden Methoden ist automatisch mit einem generischen Entwurfsmodell austauschbar.

Die Entscheidung einordnen

Spekulatives Decoding ist eine Schicht der LLM-Serving-Optimierung. Es funktioniert am besten zusammen mit einer klaren Wahl für das Modell-Serving, realistischen Kapazitätsgrenzen und explizitem Monitoring. Einen umfassenderen Vergleich von Serving-Engines finden Sie unter vLLM vs SGLang: Durchsatz, Latenz, Modellunterstützung und Betrieb. Informationen zur Kapazitätsseite von Produktions-APIs finden Sie unter RPM vs. TPM: LLM-Ratenlimits und 429-Korrekturen.

Wenn Sie GPU-Experimente oder eine neue Inferenzumgebung planen, erkunden Sie Flatkey Compute und beginnen Sie mit einem Benchmark-Plan, der sowohl nutzersichtbare Latenz als auch Durchsatz auf Flottenebene berichtet. Die beste Konfiguration für spekulatives LLM-Decoding ist diejenige, die Ihre eingeschränkte Kennzahl unter realer Last verbessert – und sicher zurückgerollt werden kann, wenn sich der Workload ändert. Dieser Leitfaden zum spekulativen LLM-Decoding ist ein Ausgangspunkt für diese Messdisziplin, kein Ersatz dafür.

Quellen

• Leviathan, Kalman und Matias — Fast Inference from Transformers via Speculative Decoding
• Cai et al. — Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads
• Li et al. — EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty
• vLLM-Dokumentation — Spekulatives Decoding