Die Idee
Ein Sprachmodell schreibt Text Token für Token, und jeder Schritt kostet einen vollen Durchlauf durch das Netz. Beim spekulativen Dekodieren rät ein kleiner, schneller Teil mehrere Token im Voraus, und das große Modell prüft die Vorschläge in einem einzigen Durchlauf. Stimmen sie, entstehen mehrere Token zum Preis von einem. Stimmen sie nicht, verwirft das Modell alles ab der ersten Abweichung und rechnet normal weiter. Das Verfahren verkürzt nur die Zeit und lässt die Verteilung der Ausgabe unverändert, von Rundungseffekten abgesehen.
Qwen3.8-27B bringt den ratenden Teil selbst mit, einen kleinen zusätzlichen Kopf, der mit dem Modell veröffentlicht wird. Ein zweites Modell und die Abstimmung zwischen zweien entfallen damit. Der Server vLLM kann diesen Kopf nutzen, und einzustellen bleibt nur die Tiefe, also die Zahl der Token, die der Kopf pro Schritt vorausrät.
Die Messung
Wir maßen am 25. September 2026 auf einer RTX 5090 mit 32 GB. Das Modell lief in der vierbittigen NVFP4-Fassung mit einem Kontextfenster von 130.000 Token, jeweils einer Anfrage und abgeschaltetem Denkmodus, und wir nahmen den Median aus drei Läufen. Die drei Spalten stehen für drei Arten von Aufgabe, weil das Raten ungleich gut gelingt: eine Datei mit kleiner Änderung wiedergeben, neuen Code nach Vorgabe schreiben, einen Sachverhalt in Prosa erklären.
| Tiefe | Datei ändern | Code schreiben | Prosa | angenommene Vorschläge |
|---|---|---|---|---|
| ohne | 23,7 | 23,7 | 23,7 | — |
| 1 | 49,9 | 48,5 | 47,3 | 95 % |
| 2 | 71,8 | 68,2 | 62,0 | 89 % |
| 3 | 93,9 | 86,4 | 75,5 | 86 % |
| 4 | 115,4 | 96,9 | 83,9 | 79 % |
Die Tabelle nennt Token pro Sekunde. Mit Tiefe 4 schreibt dieselbe Karte dreieinhalb- bis fünfmal so schnell. Am meisten gewinnt die Aufgabe, bei der das Modell viel abschreibt, und für einen Coding-Agenten ist das der Normalfall, denn er gibt bestehenden Code mit kleinen Änderungen zurück. Die Quote angenommener Vorschläge sinkt mit der Tiefe von 95 auf 79 %, und deshalb flacht der Gewinn ab. Eine Unstimmigkeit bleibt stehen: Rechnerisch kann Tiefe 1 höchstens das Doppelte bringen, gemessen sind 2,1. Wir haben die Grundlinie also etwas zu niedrig gemessen, innerhalb der Streuung, die weiter unten sichtbar wird.
Wo der Speicher zur Grenze wird
Der zusätzliche Kopf belegt rund 1,3 GiB und bringt das geladene Modell auf 22,15 GiB, und schon das verknappt den Speicher. Was nach Abzug des Arbeitsspeichers für die Berechnung übrig bleibt, nimmt der Zwischenspeicher für den Kontext. In der Voreinstellung nutzt vLLM 90 % der Karte. Damit blieben für den Zwischenspeicher 4,35 GiB, während eine einzige Anfrage über 130.000 Token 4,73 braucht, und der Server verweigerte den Start. Erst mit einem höheren Anteil der Karte passte das volle Fenster wieder. Bei Tiefe 5 und 6 reichte der Speicher auch dann nicht mehr für eine solche Anfrage.
Dieselbe Rechnung betrifft die CUDA-Graphen, die vLLM sonst standardmäßig nutzt und ohne die die Messung oben lief. Mit ihnen zeichnet vLLM die Folge der Rechenschritte auf der Karte einmal auf und spielt sie danach als Ganzes ab. Die Graphen beschleunigen das Schreiben und brauchen selbst Speicher, und zusammen mit dem Kopf und 130.000 Token passt das nicht auf die Karte. Mit 100.000 Token passt es:
| Einstellung | Datei / Code / Prosa | Einlesen, Token pro Sekunde |
|---|---|---|
| 130.000 Token, ohne CUDA-Graphen, Tiefe 4 | 97 / 81 / 70 | 5.200 |
| 100.000 Token, mit CUDA-Graphen, Tiefe 4 | 228 / 190 / 159 | 5.500 |
| 100.000 Token, mit CUDA-Graphen, Tiefe 5 | 253 / 202 / 159 | — |
Diese zweite Reihe stammt vom selben Tag. Ihre erste Zeile liegt mit 70 bis 97 unter den 84 bis 115 aus der Tabelle davor, obwohl die Einstellung dieselbe ist; wir führen beide Messungen auf und mitteln sie nicht. Bei 110.000 Token mit Graphen reichte der Speicher für eine volle Anfrage nicht mehr. Zur Wahl stehen also 130.000 Token Fenster bei rund 100 Token pro Sekunde oder 100.000 Token bei rund 200. Die Tabelle zeigt nicht, was das kleinere Fenster kostet, denn der Agent muss seinen Verlauf dann früher verdichten.
Unter Last
Die Messung oben läuft mit einer Anfrage, ohne Denkmodus und mit der wahrscheinlichsten Fortsetzung. Im Betrieb des Agenten lasen wir während eines Benchmarks mit fünf schwereren Aufgaben die Zähler des Servers aus. Dort sank die Annahmequote der vier vorausgeratenen Token auf 73, 54, 42 und 33 %, weil das Modell mit Temperatur 1,0 lief und beim Nachdenken weniger vorhersehbar schreibt. Danach senkten wir die Temperatur für lokale Modelle auf 0,6.
In demselben Lauf las der Agent 2,57 Millionen Token und schrieb 158.000, ein Verhältnis von sechzehn zu eins. 74 % des Gelesenen kamen aus dem Zwischenspeicher, weil der Anfang der Anfrage gleich blieb. Der Zwischenspeicher erspart also knapp drei Viertel des Einlesens, und ein Verlauf mit stabilem Anfang lohnt sich neben dem schnelleren Schreiben. In einem zweiten, einfacheren Benchmark bestand der Agent mit Tiefe 4 alle fünf Aufgaben, in 22 bis 94 Sekunden je Aufgabe.
Grenzen
Die Grundlinie von 23,7 Token pro Sekunde maßen wir ohne CUDA-Graphen. Wie schnell das Modell mit Graphen und ohne Vorausraten schreibt, haben wir nicht gemessen, und ein Teil des Gewinns in der zweiten Tabelle geht auf die Graphen zurück. Alle Zahlen gelten für diese Karte, dieses Modell in dieser Quantisierung und die vLLM-Version vom September 2026. Die Messung mit einer Anfrage sagt nichts über mehrere gleichzeitige Nutzer, die sich den Zwischenspeicher teilen. Die Annahmequoten unter Last stammen aus einem einzelnen Benchmark-Lauf. Die beiden Messreihen desselben Tages weichen für dieselbe Einstellung um rund ein Sechstel voneinander ab, ohne dass wir die Ursache kennen, und diese Abweichung zeigt, wie genau die Zahlen sind.