Verbreitet ist die Annahme, spekulative Dekodierung sei schnell, weil sie Rechenarbeit spart. Der Forscher Joe Barrow hält in seinem Blog dagegen: Wer nachrechnet, findet das Gegenteil: Für dieselbe Sequenz steigt die Zahl der Floating-Point-Operationen. Das ist kein Widerspruch. Schneller wird das Verfahren nicht, weil weniger gerechnet wird, sondern weil anders gerechnet wird. Um zu verstehen, warum spekulative Dekodierung schnell ist, hilft ein Blick darauf, was die GPU physisch tut, statt auf die Token pro Sekunde. Ein Lieferwagen, der für ein einziges Paket eine komplette Tour fährt, ist ein gutes Bild dafür.
Bei der klassischen LLM-Inferenz passiert genau das. Jeder Token, den das Modell ausgibt, kostet eine vollständige Fahrt durch den Speicher: Alle aktiven Gewichte müssen einmal gelesen werden, egal wie wenig damit anschließend gerechnet wird. Die GPU wartet dabei die meiste Zeit auf Daten, nicht auf Rechenoperationen. Spekulative Dekodierung belädt diesen Lieferwagen voller: dieselbe Strecke, mehr Ladung pro Tour. Darin liegt der Geschwindigkeitsvorteil.
Draft-Modell schlägt vor, großes Modell verifiziert in einem Durchlauf
Ein kleines Draft-Modell erzeugt autoregressiv vier oder fünf Tokens und schiebt sie als Vorschlag nach vorn. Das große Modell bekommt Prompt und Entwurf zusammen und verarbeitet beides in einem einzigen Forward Pass. Für jede Position entsteht eine vollständige Wahrscheinlichkeitsverteilung, nicht bloß ein Ja oder Nein.
Akzeptiert wird der längste zusammenhängende Präfix, der zu diesen Verteilungen passt; das erste abweichende Token wird durch die korrigierte Variante ersetzt. Ein Durchlauf bringt die Sequenz um mehrere Tokens voran statt um einen. Daher die höhere FLOP-Zahl: Der Verifizierer rechnet für jede vorgeschlagene Position mit, und das ist mehr Arbeit als das Erzeugen eines einzelnen Tokens.
Die Verifikation ist kein Vergleich zweier fertiger Tokenlisten. Es ist ein echtes Vorwärtsrechnen des großen Modells, nur parallel über mehrere Positionen. Die Kosten skalieren mit der Spekulationstiefe, der Gewinn hängt an der Annahmequote. Ist sie hoch, ist der Tausch gut. Ist sie niedrig, wird Rechenzeit auf Vorschläge verwendet, die anschließend verworfen werden.
Speichergebunden oder compute bound: zwei Arten von Arbeit auf derselben GPU
Auf einer GPU laufen zwei Dinge gleichzeitig, die man leicht verwechselt. Das eine sind die Tensoroperationen — Matrixmultiplikationen, Skalarprodukte, kurz: Rechnen. Das andere ist Datenverkehr: Werte müssen aus dem globalen Speicher geholt und in lokale Register oder Caches geschrieben werden. Beides kostet Zeit, aber nicht im selben Verhältnis. Je nach Situation wartet die GPU auf das eine oder das andere.
Wartet sie auf Daten, ist der Vorgang speichergebunden. Wartet sie auf die Rechenoperationen, ist er compute bound. Das liegt nicht an der Hardware allein, sondern am Verhältnis von Arbeit zu Datenmenge. Das Roofline-Modell macht das sichtbar: Es trägt die erreichte Rechenleistung gegen die arithmetische Intensität auf, also gegen die Zahl der Operationen pro geladenem Byte. Bis zu einem Knickpunkt begrenzt die Speicherbandbreite, danach die Rechenleistung.
Zurück zum Lieferwagen. Die Straße steht für die Speicherbandbreite und ist die eigentliche Engstelle. Der Laderaum steht für die Rechenwerke. Solange nur ein Paket auf der Ladefläche liegt, entscheidet die Straße über die Lieferzeit, egal wie groß der Laderaum ist. Erst wenn mehr Pakete mitfahren, wird die Fahrt wirtschaftlich — die Strecke bleibt gleich, der Ertrag pro Tour steigt.
Warum ein einzelner Token die GPU unterfordert
Beim Token-für-Token-Dekodieren ist genau das der Fall. Barrow nennt als Beispiel Qwen3.5-27B mit 27 Milliarden aktiven Parametern, die für jeden Token komplett aus dem Speicher gestreamt werden müssen. Gerechnet in 16-Bit-Präzision sind das rund 54 Gigabyte pro Token; bei einigen Terabyte pro Sekunde Speicherbandbreite dauert allein der Transport also Millisekunden. Die zugehörigen Rechenoperationen sind bei dieser Datenmenge erledigt, bevor der Transport abgeschlossen ist. Ein Matrix-Vektor-Produkt mit einem einzelnen Vektor ist rechnerisch anspruchslos.
Die GPU könnte also mehr tun, während sie wartet. Dieses ungenutzte Potenzial ist das Budget, aus dem spekulative Dekodierung schöpft. Würde man statt einer Sequenz zwei gleichzeitig dekodieren, kostete das pro Token praktisch keine zusätzliche Zeit, weil die Gewichte ohnehin geladen werden. Mehr Sequenzen im selben Schritt erhöhen die arithmetische Intensität, bis der Knickpunkt der Roofline erreicht ist.
Spekulative Dekodierung erzeugt keine neue Bandbreite und keine schnellere Hardware. Sie nutzt Rechenleistung, die ohnehin brachliegt, um die teure Speicherfahrt mit mehr Arbeit zu bezahlen. Die Antwort auf die Frage, warum sie schnell ist, ist deshalb keine Frage der Einsparung, sondern der Auslastung.
Breite gegen Tiefe: Batch-Größe und Spekulationstiefe teilen sich dasselbe Budget
Angenommen, ein Forward Pass läuft dann optimal, wenn fünf Tokens darin verarbeitet werden: darunter speichergebunden, darüber compute bound. Bei fünf ist die GPU ausgelastet, ohne in die Rechengrenze zu laufen. Es gibt zwei Wege, diese fünf zu erreichen.
Der erste ist Breite: fünf Sequenzen, jede mit einem Token in derselben Runde. Alle fünf Anfragen kommen ein Stück voran. Der zweite ist Tiefe: eine einzelne Sequenz mit fünf Tokens, wovon vier aus dem Entwurf akzeptiert werden. Der Rechenaufwand ist in beiden Fällen ungefähr gleich. Der Unterschied liegt darin, wem der Fortschritt zugutekommt: fünf Nutzern ein klein wenig oder einem Nutzer sehr viel.
Deshalb wirkt spekulative Dekodierung vor allem bei kleinen Batch-Größen. Solange die Batch-Größe deutlich unter der optimalen Tokenzahl liegt, ist Rechenleistung übrig, und die Spekulation kostet nichts, was nicht schon bezahlt wäre. Bei geringer Last verschenkt das System sonst Kapazität. Spekulative Dekodierung und Batch-Größe sind zwei Seiten desselben Budgets.
Wo die Rechnung kippt: hoher Durchsatz und abgelehnte Tokens
Sobald die Batch-Größe nahe am Optimum liegt oder darüber, wird zusätzliche Spekulationstiefe zu verschwendeter Rechenzeit. Man arbeitet dann gleichzeitig gegen die Speichergrenze und gegen die Rechengrenze, statt Rechenleistung kostenlos abzuschöpfen. Bei fünf Sequenzen mit je vier spekulierten Tokens landet man bei zwanzig Positionen in einem Schritt — deutlich über dem, was die GPU sinnvoll verarbeiten kann.
Dazu kommt die Annahmequote. Jede abgelehnte Position ist bezahlte Arbeit ohne Ertrag. Bei einer hohen Annahmequote fällt das kaum ins Gewicht, bei einer niedrigen frisst es den Vorteil auf. Die Konfiguration dieser Systeme ist deshalb eine Betriebsentscheidung. vLLM stellt dafür den Parameter --speculative-disable-by-batch-size bereit, der spekulative Dekodierung ab einer bestimmten Batch-Größe abschaltet — genau, um nicht in den compute-bound Bereich hinein zu spekulieren.
Wer nur auf die Latenz einer einzelnen Anfrage schaut, gewinnt mit spekulativer Dekodierung. Wer einen Dienst mit hohem Durchsatz betreibt, kann damit Rechenzeit verbrennen, die anderswo fehlt. Beide Sichten sind korrekt, sie beschreiben unterschiedliche Lastprofile.
Dynamische Spekulationstiefe und die praktische Einordnung
Wenn Tiefe und Breite aus demselben Budget kommen, liegt die nächste Frage nahe: Warum sollte man zu jedem Zeitpunkt gleich tief spekulieren? Bei kleiner Batch-Größe ist Rechenleistung übrig, bei großer nicht. Eine feste Tiefe verschenkt in beiden Fällen etwas. Naheliegend ist eine variable Tiefe — tief spekulieren, wenn Platz ist, flach oder gar nicht, wenn die Rechenwerke ausgelastet sind, und das möglichst pro Sequenz statt global.
Genau diese Überlegung steckt laut Barrow hinter Ansätzen wie dSpark, die die Tiefe an die Last anpassen und sie im Idealfall pro Sequenz wählen, statt allen dieselbe aufzuzwingen. Das Budget einer GPU ist eine gemeinsame Ressource, und wer sie ausgibt, sollte wissen, wo gerade welche übrig ist.
Spekulative Dekodierung ist kein allgemeiner Beschleuniger, sondern ein Werkzeug für niedrige Batch-Größen. Sie zahlt sich aus bei Einzelnutzer-Chats, lokaler Inferenz und allem, was auf Latenz optimiert ist. Bei hohem Durchsatz lohnt es sich, sie lastabhängig abzuschalten oder zu begrenzen. Und wer sie einsetzt, sollte neben den FLOPs vor allem die Annahmequote des Draft-Modells im Blick behalten — dort entscheidet sich, ob die zusätzliche Arbeit tatsächlich in akzeptierte Tokens mündet.
Quelle: jbarrow.ai
