Tencent DSpine: Hilfsmodell macht Qwen3.8-27B bis zu 3,8-mal schneller

Worum es geht

Tencent hat auf Hugging Face ein ungewöhnliches Modell veröffentlicht: Qwen3.8-27B-DSpine-b16. Es ist kein Chatbot, sondern ein Hilfsmodell. Es soll das Sprachmodell Qwen3.8-27B beim Antworten deutlich schneller machen. Die Technik dahinter heißt DSpine. Sie wird in einem Fachartikel beschrieben, der als arXiv-Preprint (arXiv:2609.36173) erschienen ist. Der Titel lautet „Draft in Parallel, Condition Through Depth: Adjacent Causal Injection for Speculative Decoding“, Autoren sind Haohui Zhang und Kollegen. Die Gewichte findest du unter huggingface.co/tencent/Qwen3.8-27B-DSpine-b16, den Code unter github.com/Tencent/DSpine. In der Community r/LocalLLaMA wurde die Veröffentlichung schnell aufgegriffen, dort mit der Frage: „3x schnelleres Dekodieren für 27B-Modelle?“

Was spekulatives Dekodieren ist

Normalerweise schreibt ein Sprachmodell seine Antwort Token für Token, also Wortstück für Wortstück. Für jedes einzelne Token muss das komplette große Modell einmal durchgerechnet werden. Fachleute nennen das autoregressives Dekodieren (AR). Das ist langsam, vor allem weil die Grafikkarte dabei ständig die gesamten Modelldaten aus dem Speicher laden muss.

Spekulatives Dekodieren setzt hier an. Man kann es sich wie einen Assistenten vorstellen, der Sätze vorschreibt, die eine Chefin nur noch absegnet. Ein kleines, schnelles Entwurfsmodell (Draft-Modell) rät mehrere der nächsten Tokens im Voraus. Das große Modell prüft diese Vorschläge dann in einem einzigen Durchgang, das nennt man Verifikation. Alle Tokens, die es selbst genauso erzeugt hätte, werden übernommen. Ab dem ersten Fehler rechnet das große Modell selbst weiter. Weil am Ende immer das große Modell entscheidet, bleibt die Qualität der Antwort grundsätzlich gleich, es geht nur schneller.

Wie viel man gewinnt, hängt davon ab, wie viele Entwurfs-Tokens im Schnitt angenommen werden und wie wenig Zeit das Entwerfen selbst kostet.

Was DSpine anders macht

Klassische Entwurfsmodelle raten ebenfalls Token für Token, nur eben mit einem kleineren Netz. Neuere Verfahren wie DFlash entwerfen dagegen einen ganzen Block auf einmal, also parallel. Das ist schnell. Das Problem dabei: Jede Position im Block „weiß“ nicht genau, was an der Position davor steht. Die Entwürfe passen deshalb schlechter zusammen.

DSpine will beides verbinden. Laut Modellkarte entwirft es die Tokens parallel, aber jede Schicht des Netzes gibt ihre vorhergesagten Merkmale des Vorgängers an die benachbarte Position weiter. So werden die kausalen Abhängigkeiten, also „Token B folgt auf Token A“, Schicht für Schicht durch die Tiefe des Netzes getragen. Daher kommt auch der Titel des Papers: parallel entwerfen, über die Tiefe abhängig machen.

Der veröffentlichte Checkpoint hat folgende Eckdaten:

• fünf Schichten als Entwurfsmodell für Qwen3.8-27B
• Blockgröße 16: Es werden 16 Tokens auf einmal vorgeschlagen. Zum Vergleich: Bei DFlash2 sind es offiziell 8.
• gleitendes Fenster (Sliding Window) von 8.192 Tokens: Das Entwurfsmodell betrachtet nur die letzten rund 8.000 Tokens des Textes.
• dynamische Verifikation nach dem Vorbild des Verfahrens DSpark sowie ReplaySSM. Qwen3.8-27B nutzt offenbar teils lineare Attention bzw. Zustandsraum-Schichten (SSM), wie man an den Startparametern sieht. Bei abgelehnten Entwürfen muss deren interner Zustand korrekt zurückgespult werden.

Die Zahlen

Tencent hat mit SGLang 0.5.22 gemessen, in BF16, mit FlashAttention 3 und acht gleichzeitigen Anfragen. Die erste Tabelle ist in der Modellkarte nicht eindeutig beschriftet. Höchstwahrscheinlich zeigt sie die durchschnittliche Zahl angenommener Tokens pro Prüfschritt, je höher, desto besser. Gemessen wurde mit gieriger Auswahl (T=0) und mit Zufallsauswahl (T=1, top_p 0,95, top_k 20), bei maximal 4.096 neuen Tokens und höchster Denkstufe („xhigh“).

Am meisten bringt DSpine bei Mathe und Code, also bei Texten mit gut vorhersagbarer Struktur. Bei offenen Gesprächen (MT-Bench) ist der Vorsprung klein.

Praxisnäher sind die Agenten-Tests. Dafür wurden je Teilbereich 20 aufgezeichnete Gespräche samt aller Werkzeug-Entscheidungen der Reihe nach nachgespielt, mit Prefix-Caching und bis zu 32.768 neuen Tokens pro Anfrage. Gemessen wurde der Durchsatz in Tokens pro Sekunde. In Klammern steht der Faktor gegenüber normalem Dekodieren.

Bei der Denkstufe „xhigh“ liegen die Werte für DSpine zwischen 2,87× (τ²-bench) und 3,55× (WorkBuddy Office). DFlash2 erreicht dort 2,56× bis 3,08×. Im Schnitt holt DSpine also gegenüber DFlash2 noch einmal etwa 10 bis 25 Prozent mehr heraus. Die oft zitierten „4× schneller“ werden in keinem Test ganz erreicht, der Spitzenwert liegt bei 3,84×.

Was du zum Ausprobieren brauchst

Das ist nichts für den Spiele-PC. Die Referenzkonfiguration startet das volle Qwen3.8-27B in BF16, also in voller 16-Bit-Genauigkeit. Allein die Gewichte belegen damit grob 54 GB Grafikspeicher. Dazu kommen das Entwurfsmodell und der Zwischenspeicher für bis zu 131.072 Tokens Kontext. In der Praxis brauchst du also eine Rechenzentrumskarte mit 80 GB, etwa eine H100. Zum Startbefehl gehört auch FlashAttention 3, das auf die neueren Nvidia-Rechenzentrums-GPUs (Hopper) zugeschnitten ist. Mac, CPU-Betrieb und Ollama werden nicht unterstützt. Eine GGUF-Version gibt es nicht, und für Kombinationen mit 4-Bit-Varianten macht Tencent keine Angaben. Die Installation läuft über git clone, pip install -e . und einen langen sglang serve-Befehl mit --speculative-algorithm DSPINE.

Einordnung

DSpine ist vor allem für Betreiber interessant, die Qwen3.8-27B auf eigenen Servern laufen lassen, etwa für Coding-Agenten oder Büro-Automatisierung. Gut dreimal so viele Tokens pro Sekunde auf derselben Hardware bedeuten spürbar geringere Kosten und kürzere Wartezeiten, ohne dass die Antworten schlechter werden. Das gilt jedenfalls, solange die Verifikation korrekt arbeitet. Für Heimanwender ist es mittelbar relevant: Wenn das Verfahren in llama.cpp oder ähnliche Programme einzieht, könnten auch lokale Modelle profitieren. Bislang ist es aber an SGLang gebunden.

Einschränkungen: Alle Messungen stammen von Tencent. Die WorkBuddy-Benchmarks sind offenbar Tencents eigene Testsammlungen. Verglichen wird nur mit DFlash2, nicht mit anderen bekannten Verfahren wie EAGLE. Der Gewinn hängt stark von der Aufgabe ab, bei freiem Gespräch ist er deutlich kleiner als bei Mathe. Und das Entwurfsmodell passt nur zu genau einem Zielmodell, Qwen3.8-27B. Für andere Modelle müsste ein eigener Entwurf trainiert werden. Die Lizenz geht aus der Modellkarte nicht hervor.