DSpine für Qwen3.8-27B: Kausale Features über die Tiefe

Ein veröffentlichter Drafter, kein Ersatz-Sprachmodell

Tencent veröffentlicht Gewichte für Qwen3.8-27B-DSpine-b16 und ein nutzbares SGLang-Plugin. Es beschleunigt ein bestehendes Zielmodell durch spekulatives Decoding: günstig eine Fortsetzung vorschlagen, vom Zielmodell prüfen lassen und nur den akzeptierten Präfix plus Korrektur- oder Bonustoken des Zielmodells übernehmen. Es ist weder ein eigenständiges 27B-Modell noch ein universeller Drafter für beliebige Zielmodelle.¹²

Der neue Mechanismus ist Adjacent Causal Feature Injection: Positionen werden gemeinsam verarbeitet, aber jede Draft-Schicht schreibt vorhergesagte Features einer Position in deren Nachfolger. Nach dem parallelen Transformer besitzt das Release außerdem eine serielle Verfeinerung des letzten Schreibschritts. Die gesamte Vorschlagspipeline als „vollständig parallel“ zu bezeichnen, würde diese zweite Stufe unterschlagen. Der Nemotron-DFlash-Guide erklärt die zugrunde liegende Blockspekulation; hier geht es um DSpines Ergänzung.

Geprüft am 12. November 2026: Draft-Revision 5f54174d301dbca65d9aa4448dc47e56732d9a12, Zielmodell-Revision 37561816e66b5b9153b1b64c10968c18c1e6f4a0, Plugin-Revision c66bf4405260451a32161205666048c60ca1a95f und SGLang 0.5.22, Commit baa9befa381511cd4d56f83980951e5a45fffc6d. Das Plugin bindet diese SGLang-Version ausdrücklich fest, weil es interne APIs durch Unterklassen erweitert. Die Tensorgrößen unten sind aus Quellen abgeleitete Nutzdatenmengen, keine GPU-Messungen. Es wurden weder Modellinferenz noch Durchsatzbenchmarks ausgeführt.³⁴⁵

Was tatsächlich in den Draft-Block eingeht

Der Block besitzt 16 Zeilen: einen bekannten Anker und 15 Vorschlagspositionen. Fünf ausgewählte Zielmodell-Feature-IDs, 1, 16, 31, 46 und 61, liefern Kontext. Jeder Zielmodellvektor ist 5.120 breit. Der geerbte DFlash-Pfad verkettet fünf Vektoren auf Breite 25.600, projiziert auf 5.120 und normiert mit einer gelernten RMSNorm, bevor die K/V des Draft-Kontexts entstehen.³⁶

Der Drafter hat fünf dichte SwiGLU-Schichten, Hidden-Breite 5.120, FFN-Breite 17.408, 32 Query-Heads, acht KV-Heads und Head-Breite 128. Seine Query-Projektion ist damit 4.096 und nicht 5.120 breit. Alle fünf Schichten nutzen ein kausales Attention-Fenster von 8.192 Positionen mit RoPE-Basis 10.000.000. Das unterscheidet sich vom 64-schichtigen GDN-/Full-Attention-Hybrid des Zielmodells. Dessen Attention-Geometrie darf nicht auf den Drafter übertragen werden.³⁴

Anders als der nichtkausale Draft-Block im früheren E4B-Beispiel aktiviert dieser Checkpoint ausdrücklich kausale Draft-Block-Attention. Trotzdem wird daraus kein gewöhnliches Token-für-Token-Decoding: Zukünftige Vorschlagspositionen beginnen weiterhin mit Platzhaltern und werden gemeinsam verarbeitet. Sie warten nicht auf diskrete Tokens, die frühere Positionen bereits gezogen haben.⁷⁶

Die Brücke: 1.024 Features lesen, über Rang 512 schreiben

Nach jeder Draft-Schicht sei $x_{\ell,t}\in\mathbb R^{5120}$ der kombinierte Residualzustand nach dem MLP. Die Brücke berechnet zuerst dessen RMS-Betrag $r_{\ell,t}$ und sagt einen Codevektor mit Breite 1.024 vorher. Ohne BF16-Rundung und mit impliziter kleiner numerischer Untergrenze lautet der Lesevorgang:

$R_\ell$ hat die Form [1024,5120]; jede Schicht besitzt ihre eigene Lesematrix. In der Ankerzeile ersetzt die Implementierung den vorhergesagten Code durch das $\sqrt{1024}$-Fache des gespeicherten Codebook-Vektors des bekannten Ankertokens. Diese Tabelle hat die Form [248320,1024]. Sie ist eine gelernte Token-Feature-Darstellung, kein externer Dokumentindex und kein N-Gramm-Engram-Lookup.⁷⁸

Jede empfangende Zeile kombiniert ihren eigenen Code mit dem Code der unmittelbar vorherigen Zeile. Drei gemeinsame Projektionen bilden 1.024 Koordinaten auf 512 ab: ein Empfängergate $G$, ein Vorgängergate $G_p$ und die Vorgänger-Value-Abbildung $A$. Jede Schicht besitzt eine eigene Schreibmatrix $W_\ell\in\mathbb R^{5120\times512}$:

Die Nachricht ist eine gegatete Vorhersage, kein bestätigtes früheres Token. Das Update skaliert mit dem RMS-Betrag des Empfängers. Anschließend bereitet eine übliche gelernte RMSNorm die Eingabe der nächsten Teilschicht vor. Der Kernel setzt den Schreibbeitrag am Anker jedes Blocks auf null. Dadurch wird aus einem Vorgänger-Lesezugriff aus einer anderen Anfrage kein anfrageübergreifendes Update.⁸

Jede Zeile liest Vorgängercodes aus derselben bereits abgeschlossenen Schicht. Deshalb können diese Schreibvorgänge parallel laufen. Die nächste Schicht sieht die aktualisierten Zustände. Die Brücke transportiert lokale kausale Hinweise durch die Netztiefe, ohne für jedes Draft-Token einen ganzen Transformer erneut auszuführen. Das erklärt den Informationsfluss, beweist aber keine höhere Akzeptanzlänge. Attention liefert weitere kausale Pfade; die benachbarten Brückenkanten allein definieren nicht das gesamte rezeptive Feld des Netzes.

Der letzte Schreibschritt wird mit diskreten Kandidaten verfeinert

Das Release setzt head_topk = 16 und verfeinert nur den letzten Schreibschritt. Zuerst ermittelt es für jede der 15 Vorschlagszeilen eine Kandidatenmenge. Der optimierte CUDA-Graph-Pfad bewertet das gesamte Vokabular näherungsweise mit einem zeilenweise skalierten FP8-Head, wählt 128 Kandidaten, bewertet diese mit dem ursprünglichen BF16-Head erneut und behält 16. Ein Fallback multipliziert direkt mit dem BF16-Vokabular-Head.⁹¹⁰

Die erneute Bewertung beweist nicht, dass die FP8-Auswahl die globalen BF16-Top-16 enthielt. Sie erzeugt Kandidaten für einen Vorschlag und entscheidet nicht verbindlich über die Zielmodellausgabe. Für jeden Empfängerkandidaten berechnet die Endstufe den letzten Brückenschreibschritt konditioniert auf einen diskreten Vorgängerkandidaten, statt ausschließlich auf dessen vorhergesagte kontinuierliche Features. Aus 16 Vorgänger- und 16 Empfängerkandidaten entsteht eine kleine 16 × 16-Tabelle bedingter Scores pro Position. Danach folgt eine serielle Kette durch die Positionen. Die fünf Transformer-Schichten werden nicht für jeden Zweig erneut ausgeführt.⁸¹⁰

Der erste Vorschlag ist auf den echten Anker konditioniert. Spätere Auswahlen hängen vom zuvor ausgewählten Kandidaten ab. Greedy-Decoding durchläuft die Bestkandidaten-Tabelle. Sampling berechnet bedingte Wahrscheinlichkeiten, zieht die Kette und hält diese Wahrscheinlichkeiten zur Verifikation fest. Die Implementierung besitzt getrennte Greedy- und Sampling-Pfade; beim Sampling bleibt die Normierung jedes verfeinerten Zustands erhalten. Greedy-Lookup-Scores als universelle Wahrscheinlichkeitstabelle zu behandeln, wäre falsch. Die Sampling-Endstufe nutzt Faktorberechnungen in FP64 mit direktem Fallback; der Sampler erzwingt außerdem echte FP32-Matrixmultiplikation mit abgeschaltetem TF32.¹⁰¹¹

Damit entstehen zwei verschiedene kausale Mechanismen: kontinuierliche Feature-Nachrichten über die Tiefe, danach diskrete Kandidatenkonditionierung in der Endstufe. Beide ersetzen wiederholte Zielmodellberechnungen durch günstigere Näherungen. Beide können schlechte Vorschläge liefern.

Warum eingeschränkte Vorschläge die Zielqualität nicht einschränken müssen

Für spekulatives Sampling muss $q$ genau die Verteilung sein, die das vorgeschlagene Token tatsächlich erzeugt hat, einschließlich Kandidatenbeschränkung, Temperatur und Filtern. Die Verifikation vergleicht sie mit der tatsächlich eingesetzten Zielmodellverteilung $p$:

Die akzeptierte Masse ist $\min(p,q)$; der Ablehnungszweig liefert den fehlenden positiven Rest. Zusammen rekonstruieren sie im exakten Algorithmus $p$. Ein Zielmodelltoken außerhalb der 16 Draft-Kandidaten kann weiterhin durch Korrektur ausgegeben werden. Eine eingeschränkte Kandidatenmenge kann die Akzeptanz senken, ohne mathematisch die endgültige Zielmodellverteilung zu begrenzen.¹²

Diese Garantie hat Implementierungsbedingungen. Das Plugin hält das gezogene $q$ der aktuellen Runde fest, bildet die Filtersemantik des Ziel-Backends nach und enthält numerische Tests, die Sparse- und Dense-Verifikation mit denselben Wahrscheinlichkeiten und Zufallsziehungen vergleichen. Das sind veröffentlichte Tests, keine Behauptung, dass wir CUDA-Validierung ausgeführt hätten. Dieselbe Zielverteilung verspricht weder identischen Text bei gleichem Seed noch identische Numerik auf anderer Hardware. Auch der GDN-Zustand des Zielmodells darf nur bis zum akzeptierten Präfix übernommen werden. Das Release besitzt dafür eine ReplaySSM-spezifische Zustandsübernahme.¹⁰¹³

Ein Attention-Fenster garantiert keine Cache-Größe

Für fünf Draft-Schichten, acht KV-Heads, 128 Koordinaten und BF16-Speicherung entstehen pro vorgehaltener Position 20 KiB logische Draft-K/V:

Ein ideal kompakt gespeichertes Fenster mit 8.192 Positionen hätte 160 MiB je Sequenz. Dieses Plugin verlangt jedoch ausdrücklich SGLangs dichten BF16-MHATokenToKVPool und lehnt begrenzte/hybride Draft-Pools als unvalidiert ab. Die Attention-Maske begrenzt die gelesenen Positionen auf 8.192; sie beweist nicht die Freigabe älterer K/V. Zur Größenordnung: 131.072 vorgehaltene Positionen ergäben 2,5 GiB reine Draft-KV-Nutzdaten, vor Zielmodellzustand, Paging, Puffern oder Präfix-Sharing. Das ist eine Rechnung unter dieser Bedingung, keine beobachtete Allokation.¹⁴¹⁰ Dazu passt die Diskussion der Cache-Layouts.

Die Brücke kostet mehr als nur fünf Transformer-Schichten. Ihre BF16-Token-Code-Tabelle umfasst 485 MiB Nutzdaten. Die Greedy-Endstufe berechnet Tabellen der Formen [248320,512] und [248320,1024] vor: zusammen weitere 727,5 MiB in BF16. Sie beschleunigen wiederholte Kandidatenbewertung, sind aber zusätzliche residente Tensoren. FP8-Retrieval ergänzt eine Head-Kopie und Skalen; die Sampling-Verfeinerung besitzt separate Faktoren und Arbeitsbereiche. Keine dieser Zahlen beschreibt den vollständigen Serving-Footprint.⁷⁸⁹¹¹

Wo der veröffentlichte Serving-Pfad endet

Für diesen Qwen-Checkpoint verlangt das geprüfte Plugin CUDA, TP=1, Blockgröße 16, einen unquantisierten zusammenhängenden BF16-Zielmodell-Ausgabehead, BF16-Draft-Aktivierungen und -Gewichte, FA3-Draft-Attention sowie höchstens acht gleichzeitige Anfragen. Es lehnt Prefill-/Decode-Disaggregation und die benannten FP4-KV-Formate ab. Das ReplaySSM-Rezept verlangt zusätzlich PP=1, rekurrenten FP32-Zustand, Triton-Linear-Attention und die Extra-Buffer-Präfix-Cache-Strategie. Ein Rezept zur Quantisierung der Zielmodellgewichte erlaubt daher nicht automatisch die beliebige Quantisierung des gemeinsamen Ausgabeheads oder des Drafters.¹⁵¹⁰

Der Serving-Befehl der README mit 131.072 Positionen und das Maximum-Position-Feld 262.144 der Konfiguration haben unterschiedliche Geltungsbereiche. Sie sind keine austauschbaren getesteten Kapazitäten. Die separat veröffentlichte MLX-Integration belegt nicht, dass dieser CUDA-Kernelpfad oder seine numerischen Eigenschaften unverändert auf Apple-Hardware übertragbar sind.³²

Was vor dem Agenteneinsatz zu messen ist

Die Model Card vergleicht DSpine mit Blockgröße 16 gegen DFlash2 mit Blockgröße 8, unter SGLang 0.5.22, BF16, FA3 und Concurrency acht. DSpine nutzt zusätzlich dynamische Verifikation und ReplaySSM. Agentenergebnisse spielen Tool-Call-Präfixe aus 20 Gesprächen pro Teilmenge erneut ab. Das ist ein Vergleich von Serving-Systemen, keine isolierte Ablation der Vorgängerbrücke. Die Verhältniszahlen werden hier nicht als erwartete Performance auf anderer GPU oder anderen Workloads wiederholt.¹

Für eigene lange Antworten oder Tool-Agenten sollten End-to-End-Decode-Zeit, akzeptierte Präfixlänge, Draft-/Endstufen-/Verifikationszeit, Spitzenspeicher und Abbruchverhalten bei gleichem Zielmodell, Kontext, Sampling und gleicher Concurrency gemessen werden. Akzeptanzlänge ist keine Beschleunigung: Kostet ein Zyklus $C_d+C_v$ und übernimmt im Mittel $\tau$ Tokens, betragen die Kosten pro Ausgabetoken $(C_d+C_v)/\tau$, vor separat berücksichtigtem Scheduling-Overhead. Dabei umfasst $C_d$ sowohl Draft-Forward als auch Endstufe.

Das nützliche Release-Detail lautet nicht „parallele Vorhersage entfernt Kausalität“. Es ist eine zweistufige Näherung kausaler Konditionierung, abgesichert durch Zielmodellverifikation und begleitet von konkreten Speicher- und Backend-Grenzen. Ob sie sich lohnt, bleibt eine workloadabhängige Messfrage.

Gepinnte Primärquellen