DFlash & DFlash2: Block-Diffusion LLM-Speedup

Während der autoregressiven Decode-Phase beim Serving von Large Language Models (LLMs) wird der Generierungsdurchsatz fundamental durch die Speicherbandbreiten-Grenze (Memory Bandwidth Wall) limitiert. Für jeden einzelnen erzeugten Token muss die Inferenz-Engine den gesamten Parameter-Footprint des Modells aus dem High-Bandwidth Memory (HBM) oder GDDR6-VRAM in die On-Chip-Register und das SRAM streamen. Auf einer Intel Arc Pro B70 GPU (608 GB/s GDDR6), auf der ein 70-Milliarden-Parameter-Modell in 4-Bit-Präzision läuft (~38,5 GB Speicherbedarf), deckelt dieser Speichertransfer die Single-Stream-Decode-Geschwindigkeit auf rund 15,8 Tokens pro Sekunde.

DFlash (Chen et al., ICML 2026 / arXiv:2602.06036) und dessen optimierter Nachfolger DFlash2 markieren eine fundamentale architektonische Abkehr vom traditionellen Speculative Decoding. Anstatt auf ein sequenzielles, Token-für-Token arbeitendes autoregressives Draft-Modell (wie EAGLE-3 oder Medusa) zu setzen, implementiert DFlash einen nicht-autoregressiven Block-Diffusions-Drafter. Durch die Konditionierung auf tiefe Kontext-Features des eingefrorenen Target-LLMs und die Generierung eines kompletten Blocks an Token-Kandidaten in einem einzigen parallelen Schritt eliminiert DFlash die sequenzielle Drafting-Latenz, überwindet die Fehlerakkumulation und steigert den Decode-Durchsatz um das 2,5× bis 3,8-Fache — bei 100% mathematischer Verlustfreiheit.

1. Executive Summary & Funktionsmechanik

Speculative-Decoding-Systeme unterteilen die Inferenz in zwei alternierende Phasen:

Draft-Phase: Ein leichtgewichtiges Modell schlägt eine Kandidatensequenz aus γ Tokens vor.
Verifikations-Phase: Das große Target-Modell bewertet alle γ Tokens parallel in einem einzigen Forward-Pass, akzeptiert valide Tokens und verwirft Abweichungen mittels modifiziertem Rejection Sampling.

Inferenz-Pipeline Vergleich — Entwurfsdiagramm mit Dummywerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

Klassische spekulative Drafter (EAGLE-1/2/3, Lookahead, Medusa) erzeugen Draft-Kandidaten rein sequenziell: Um Token t+k vorherzusagen, muss zuvor Token t+k-1 berechnet werden. Folglich skaliert die Drafting-Latenz linear mit der Spekulationslänge:

T_{\text{draft}} = \gamma \cdot t_{\text{step}}

Damit der Drafting-Aufwand den Geschwindigkeitsgewinn der Verifikation nicht zunichtemacht, sind klassische Drafter auf extrem flache Architekturen beschränkt (oft nur eine einzige Transformer-Schicht). Diese begrenzte Modellkapazität limitiert die Qualität der Vorhersagen, sodass die Akzeptanzraten rasch stagnieren.

DFlash ersetzt die serielle Draft-Schleife durch eine parallele Block-Diffusions-Formulierung:

T_{\text{draft}} = t_{\text{parallel}} \ll \gamma \cdot t_{\text{step}}

Da die parallele Tensor-Ausführung auf modernen GPUs die Recheneinheiten mit hoher Effizienz auslastet, bleibt t_{parallel} für moderate Blockgrößen (B ∈ [4, 16]) weitgehend invariant gegenüber der Blocklänge. Diese Entkopplung ermöglicht es DFlash, tiefere und ausdrucksstärkere Drafter-Architekturen (5 bis 8 Schichten) einzusetzen, die deutlich höhere Akzeptanzlängen ohne Latenznachteile erzielen.

2. Hardware-Physik & Das Speicherbandbreiten-Limit

Um fundiert herzuleiten, warum Block-Diffusion Speculative Decoding überlineare Beschleunigungen im Serving erzielt, analysieren wir die arithmetische Intensität und die Speicherzugriffsmuster der Transformer-Inferenz.

Hardware-Roofline-Modell — Entwurfsdiagramm mit Dummywerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

Arithmetische Intensitäts-Herleitung

Die arithmetische Intensität I ist definiert als das Verhältnis der ausgeführten Gleitkommaoperationen zu den über den GPU-Speicherbus übertragenen Bytes:

I = \frac{\text{Floating Point Operations (FLOPs)}}{\text{Memory Traffic (Bytes)}}

Während der Prefill-Phase (Verarbeitung eines Eingabeprompts der Länge N) dominieren Matrix-Matrix-Multiplikationen (GEMM). Für ein Modell mit P aktiven Parametern und einer Prompt-Länge von N skaliert die Rechenleistung mit 2 · P · N FLOPs, während das Laden der Modellgewichte P · b Bytes erfordert (wobei b die Byte-Breite pro Parameter darstellt). Die arithmetische Intensität beträgt:

I_{\text{prefill}} \approx \frac{2 \cdot P \cdot N}{P \cdot b} = \frac{2N}{b}

Für N = 2048 Tokens und 16-Bit-Präzision (b=2) ergibt sich I_{prefill} ≈ 2048 FLOPs/Byte, womit sich die Ausführung stabil im rechengebundenen Bereich (Compute-Bound) des Roofline-Modells befindet.

Während der Decode-Phase (Erzeugung eines einzelnen Tokens bei Batch-Größe 1) dominieren Matrix-Vektor-Multiplikationen (GEMV). Die Berechnung für einen Token benötigt 2 · P FLOPs, während alle P Parameter vollständig aus dem globalen Speicher transferiert werden müssen:

I_{\text{decode}} \approx \frac{2 \cdot P}{P \cdot b} = \frac{2}{b}

Für 4-Bit-quantisierte Gewichte (b = 0,5 Bytes pro Parameter) liegt die arithmetische Intensität bei:

I_{\text{decode}} = \frac{2}{0,5} = 4,0 \text{ FLOPs/Byte}

Auf einer Intel Arc Pro B70 GPU mit 130 TFLOP/s FP16/FP8 Matrix-Rechenleistung und B_{mem} = 608 GB/s GDDR6-Bandbreite liegt die zur Sättigung der Recheneinheiten erforderliche Intensität bei:

I_{\text{sat}} = \frac{130 \times 10^{12} \text{ FLOP/s}}{608 \times 10^9 \text{ Bytes/s}} \approx 213,8 \text{ FLOPs/Byte}

Da I_{decode} = 4,0 ≪ 213,8, verharrt die Rechen-Engine über >98% der Taktzyklen im Leerlauf und wartet auf das Nachladen der Modellgewichte aus dem GDDR6-Speicher.

Das Single-Stream-Decode-Geschwindigkeitslimit

Betrachten wir Llama 3.3 70B, quantisiert auf 4-Bit via Intel AutoRound (W4A16), mit einem VRAM-Bedarf von M_{weights} = 38,5 GB. Der theoretisch maximale Single-Stream-Decode-Durchsatz T_{baseline} ist strikt durch die Speicherbandbreite beschränkt:

T_{\text{baseline}} = \frac{B_{\text{mem}}}{M_{\text{weights}}} = \frac{608 \text{ GB/s}}{38,5 \text{ GB}} = 15,79 \text{ Tokens/Sekunde}

Spekulative Speedup-Formulierung

Beim Speculative Decoding mit einem Spekulationsfenster von γ wird die erwartete Anzahl akzeptierter Tokens pro Verifikationszyklus mit τ ∈ [1, γ + 1] bezeichnet (inklusive des Bonus-Tokens des Target-Modells). Die durchschnittliche Latenz pro erzeugtem Token L_{per-token} und der Beschleunigungsfaktor η berechnen sich wie folgt:

\begin{aligned} L_{\text{per-token}} &= \frac{T_{\text{draft}} + T_{\text{verify}}}{\tau} \\ \eta &= \frac{L_{\text{target}}}{L_{\text{per-token}}} = \frac{L_{\text{target}} \cdot \tau}{T_{\text{draft}} + T_{\text{verify}}} \end{aligned}

wobei L_{target} die Token-Latenz der standardmäßigen autoregressiven Generierung ist (L_{target} ≈ T_{verify}).

In DFlash erfolgt das Drafting der Kandidaten in einem einzigen parallelen Pass (T_{draft} = t_{parallel} ≈ 3,2 ms). Bei einer Verifikationsdauer für γ = 5 Tokens von T_{verify} ≈ 64,1 ms und einer durchschnittlichen Akzeptanzlänge von τ = 4,15 ergibt sich:

\begin{aligned} L_{\text{per-token}} &= \frac{3,2\text{ ms} + 64,1\text{ ms}}{4,15} = \frac{67,3\text{ ms}}{4,15} = 16,22 \text{ ms/Token} \\ \text{Durchsatz} &= \frac{1000}{16,22} \approx 61,6 \text{ Tokens/Sekunde} \end{aligned}

Dies entspricht einer theoretischen Beschleunigung von 3,90× gegenüber dem Hardware-Limit von 15,79 tok/s, ohne die Hardware zu modifizieren oder Gewichte noch stärker zu quantisieren.

3. Grenzen klassischer Speculative-Decoding-Verfahren

Architekturen für Speculative Decoding haben drei Generationen durchlaufen, die jeweils spezifische systemische Engpässe aufweisen:

Architektur-Evolution des Speculative Decoding — Entwurfsdiagramm mit Dummywerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

1. Unabhängige kleine Drafter (Leviathan et al., 2023)

Der Einsatz eines unabhängigen kleineren Modells (z. B. Llama-3.2-1B als Drafter für Llama-3.3-70B) leidet unter Repräsentationsdiskrepanzen. Das Draft-Modell besitzt separate Vokabular-Tokenisierungen und eigene Hidden Spaces, was zu niedrigen Akzeptanzraten führt (τ ≈ 1,8 - 2,2). Zudem verursacht das sequenzielle Ausführen eines 1B–3B Modells beträchtliche eigene Speicherlesevorgänge.

2. Medusa (Cai et al., 2024)

Medusa koppelt mehrere lineare Heads an den finalen Hidden State des Target-Modells, um Tokens an den Positionen t+1, t+2, dots, t+k vorherzusagen. Da die Heads jedoch vollkommen isoliert ohne wechselseitige Kommunikation arbeiten:

P(x_{t+1}, x_{t+2}, \dots, x_{t+k} \mid x_{\le t}) \approx \prod_{j=1}^k P_{\text{head}_j}(x_{t+j} \mid x_{\le t})

Die Verbundwahrscheinlichkeit fällt mit zunehmender Sequenzlänge exponentiell ab, wodurch die Vorhersagegenauigkeit ab Position k > 2 bei strukturierter Programmierung und mathematischer Logik einbricht.

3. EAGLE & EAGLE-2/3 (Li et al., arXiv:2401.15077, arXiv:2406.16858, arXiv:2503.01840)

EAGLE begegnet der Token-Unsicherheit, indem die Spekulation vom Token-Raum in den Feature-Raum der obersten Schichten verlagert wird. EAGLE-2 führt dynamische, konfidenzkalibrierte Draft-Bäume ein. EAGLE-3 nutzt Trainingsalgorithmen zur Ausrichtung der Feature-Repräsentationen.

Trotz dieser Optimierungen bleibt EAGLE-3 fundamental autoregressiv. Das Drafting von γ Tokens erfordert γ sequenzielle Forward-Pässe durch den Draft-Head. Um den Drafting-Overhead gering zu halten, sind EAGLE-Drafter auf eine einzige Transformer-Schicht beschränkt. Bei einer Skalierung auf γ ≥ 8 überkompensiert die kumulierte sequenzielle Latenz (8 · t_{step}) den Verifikationsgewinn und limitiert reale Beschleunigungen auf unter 3×.

4. Monolithische Diffusions-Drafter (DiffuSpec, SpecDiff-2)

Frühere Versuche, Diffusionsmodelle auf das Drafting anzuwenden (Li et al., 2025a; Sandler et al., 2025), setzten auf große, vortrainierte 7B-Diffusionsmodelle. Der Speicher-Traffic zum Streamen eines 7B-Drafters in jedem Decode-Schritt erzeugt massive Latenzen, die den spekulativen Effizienzgewinn zunichtemachen.

4. DFlash-Architektur (ICML 2026)

DFlash löst den Drafting-Engpass, indem die Generierung von Kandidaten als konditionierter Block-Diffusionsprozess über kontinuierlichen Feature-Räumen formuliert wird, der eng an die Hidden States des Target-Modells gekoppelt ist.

DFlash Architekturübersicht: Target-Kontext Feature-Extraktion & Invariante KV-Injektion — Entwurfsdiagramm mit Dummywerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

4.1 Target Context Feature Konditionierung via KV-Injection

Große autoregressive Target-Modelle kodieren weitreichende syntaktische Muster und zukünftige Token-Semantik implizit in ihren Zwischenrepräsentationen. DFlash erfasst diese Information durch die Extraktion von Hidden States aus 5 gleichmäßig verteilten Schichten:

\mathcal{L}_{\text{extract}} = \{l_1, l_2, l_3, l_4, l_5\}, \quad 2 \le l_1 < l_2 < l_3 < l_4 < l_5 \le L_{\text{target}} - 2

Diese extrahierten Feature-Vektoren werden über die Kanaldimension konkateniert und in die verborgene Dimension D des Draft-Modells projiziert:

H_t = \text{RMSNorm}\left( W_c \left[ H^{(l_1)}; H^{(l_2)}; H^{(l_3)}; H^{(l_4)}; H^{(l_5)} \right] \right)

wobei W_c ∈ R^{D × 5D}.

Anstatt H_t lediglich auf die Eingabeschicht zu addieren (was zu Representation Dilution in tieferen Schichten führt), injiziert DFlash H_t direkt in die Key- und Value-Caches jeder einzelnen Draft-Transformer-Schicht:

\begin{aligned} Q_i &= W_i^Q H_d \\ K_i &= \left[ W_i^K H_t \; ; \; W_i^K H_d \right]_{\text{seq}} \\ V_i &= \left[ W_i^V H_t \; ; \; W_i^V H_d \right]_{\text{seq}} \end{aligned}

Hierbei repräsentiert H_d die Zwischenzustände der Draft-Tokens. Die Kontext-Features H_t des Target-Modells fungieren als invariante Speicheranker. Sie umgehen die Query-Projektionen, Output-Projektionen und Feed-Forward-Netzwerke (FFNs) des Drafters und verursachen so minimalen Rechen- und Parameter-Overhead.

Speicher-Overhead der Draft-Modell-Schicht:
- Target Hidden Dimension D = 2048, 5 extrahierte Schichten
- Projektionsmatrix W_c in BF16: 2048 * (5 * 2048) * 2 Bytes = 41,94 MB
- Aktivierungsspeicher während Blockgröße-16-Spekulation: < 400 KB

4.2 Geteilte Embeddings & LM-Head

Um eine Parameter-Explosion zu verhindern und die semantische Ausrichtung am Vokabularraum des Target-Modells zu sichern, friert DFlash folgende Komponenten ein und verwendet sie wieder:

Target Embedding Layer (W_{emb}): Wandelt diskrete Anker-Tokens in Eingaberepräsentationen um.
Target Unembedding Head (W_{lm_head}): Projiziert Ausgangszustände zurück auf Vokabular-Logits.

Lediglich die 5 bis 8 intermediären Draft-Transformer-Blöcke und die kompakte Projektionsmatrix W_c enthalten trainierbare Parameter.

4.3 Trainings-Formulierung: Random Masked Blocks & Loss-Gewichtung

Während des Trainings gleicht DFlash den Diffusions-Drafter über drei spezialisierte Mechanismen an die Trajektorie des Target-Modells an:

1. Anker-konditionierte Masked-Block-Konstruktion

Statt beliebige Token-Spannen zu maskieren, wählt DFlash zufällige saubere Ankerpositionen aus Antwortsequenzen des Target-Modells. Für jeden Anker a werden die nachfolgenden B-1 Tokens durch lernbare Mask-Tokens [M] ersetzt:

\text{Block} = \left[ x_a, [M]_1, [M]_2, \dots, [M]_{B-1} \right]

Diese Formulierung spiegelt die Inferenz exakt wider, bei der das Draft-Modell mit dem Bonus-Token aus dem vorangegangenen Verifikationsschritt initialisiert wird.

2. Block-diagonale Flex-Attention-Maske

Um mehrere Blöcke in einem einzigen Vorwärtslauf ohne kausale Kontamination zu trainieren, setzt DFlash eine dünnbesetzte, block-diagonale Attention-Maske ein. Tokens innerhalb von Block k kommunizieren bidirektional miteinander und mit dem Kontext-Feature H_t, können jedoch nicht auf Tokens in Block j ne k zugreifen.

3. Asymmetrische positionsabhängige Loss-Gewichtung

Beim Speculative Decoding macht ein Fehler an Position k alle nachfolgenden Vorhersagen k+1 dots B ungültig. Um die Optimierung auf den wirkungsvollen frühen Positionen zu priorisieren, gewichtet DFlash den Cross-Entropy-Loss mit einem exponentiellen Abklingfaktor:

\begin{aligned} \mathcal{L}_{\text{DFlash}} &= -\sum_{k=1}^{B-1} w_k \log P_{\text{draft}}\left( x_{a+k} \mid x_a, H_t \right) \\ w_k &= \exp\left( -\frac{k-1}{\gamma} \right) \end{aligned}

wobei γ ein auf die Blocklänge abgestimmter Skalierungshyperparameter ist (γ = 7 für B=16, γ = 5 für B=10).

Asymmetrische positionsabhängige Loss-Gewichtung — Entwurfsdiagramm mit Dummywerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

4.4 Garantie mathematischer Verlustfreiheit

DFlash garantiert die exakte Beibehaltung der Ausgabewahrscheinlichkeitsverteilung des Target-Modells M_{target}. Während der Verifikation berechnet das Target-Modell Logits für alle vorgeschlagenen Positionen parallel. Für jeden vorgeschlagenen Token-Kandidaten x_k:

\text{Akzeptanz-Wahrscheinlichkeit: } \alpha_k = \min\left( 1, \; \frac{P_{\text{target}}(x_k \mid x_{<k})}{P_{\text{draft}}(x_k \mid x_{<k})} \right)

Wird Kandidat x_k zurückgewiesen (r > α_k mit r ~ U(0, 1)), bricht die Sequenz an Position k ab und ein Ersatz-Token wird aus der normierten Residualverteilung gezogen:

P'(x) = \frac{\max\left(0, \; P_{\text{target}}(x \mid x_{<k}) - P_{\text{draft}}(x \mid x_{<k})\right)}{\sum_{x'} \max\left(0, \; P_{\text{target}}(x' \mid x_{<k}) - P_{\text{draft}}(x' \mid x_{<k})\right)}

\mathcal{D}(\text{DFlash-Output}) \equiv \mathcal{D}(\text{Target-Modell Standalone})

Unter Greedy Decoding (T=0) wird Token x_k genau dann akzeptiert, wenn gilt:

\text{argmax}_{x} P_{\text{target}}(x \mid x_{<k}) == x_k

Es existiert keinerlei Qualitätsverlust, kein Anstieg der Perplexität und kein Drift in den Benchmark-Genauigkeiten.

5. DFlash2-Neuerungen: Lokale Depthwise-Faltungen & Pfad-Selektion

Während DFlash die Wirksamkeit von paralleler Block-Diffusion etablierte, zeigte das nicht-autoregressive Drafting im Single-Pass eine bekannte Einschränkung: Kohärenzverlust bei langen Blöcken (B ≥ 6). Wenn längere Sequenzen in einem einzigen Durchlauf ohne schrittweise kausale Attention generiert werden, schwächen sich die Abhängigkeiten zwischen weiter entfernten Positionen ab.

DFlash2 führt zwei architektonische Mechanismen ein, die diesen Kohärenzverlust vollständig eliminieren:

DFlash2 Multi-Stage Pipeline: Lokale Faltung & Dynamischer Pfadselektor — Entwurfsdiagramm mit Dummywerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

1. Lokale Depthwise 1D-Faltungen

DFlash2 integriert 1D-Depthwise-Separable-Convolutions mit Kernel-Breite k ∈ {3, 5} zwischen den Attention- und Feed-Forward-Teilschichten des Drafters. Für einen Block an Hidden States H ∈ R^{B × D}:

\text{ConvOutput}_t = \sum_{j=0}^{k-1} W_{\text{conv}, j} \odot H_{t-j} + b_{\text{conv}}

Da Depthwise-Faltungen über die Sequenzdimension mit linearer Komplexität O(k · B · D) operieren, erzwingen sie lokale n-Gramm-Übergangsregeln, ohne den quadratischen Rechenaufwand O(B^2) einer kausalen Self-Attention zu erzeugen.

2. Dynamischer Kandidaten-Pfad-Selektor

Statt eines einzelnen deterministischen Token-Blocks [t_1, t_2, dots, t_B] gibt der DFlash2-Diffusions-Head Top-m Kandidaten-Vorhersagen für jede Position im Block aus.

Ein leichtgewichtiger Pfadbewertungs-Kernel evaluiert die Übergangswahrscheinlichkeitsdichte entlang der Graphpfade:

\mathcal{S}(\text{Pfad}) = \sum_{j=1}^B \log P_{\text{draft}}\left( x_j^{(m_j)} \mid x_{<j}, H_t \right) + \lambda \cdot \text{Entropie}\left( P_{\text{draft}}(x_j) \right)

Der Pfad-Selektor beschneidet unwahrscheinliche Zweige und übergibt den optimalen Kandidatenpfad (oder einen dichten Verifikationsbaum) an das Target-Modell.

NOTE

Empirischer Akzeptanzsprung: Bei der Code-Generierung (HumanEval, LiveCodeBench) und strukturierten JSON-Ausgaben steigert DFlash2 die Token-Akzeptanzrate α von 64,2% auf 87,6% und hält die hohe Spekulationseffizienz selbst über mehrstufige mathematische Denkketten (Reasoning Traces) aufrecht.

6. Empirische Benchmarks & Epistemisches Grounding

Um strikte wissenschaftliche und ingenieurtechnische Integrität zu gewährleisten, unterscheiden die folgenden Benchmark-Zahlen transparent zwischen physikalisch gemessener Hardware-Telemetrie auf unserem Testbed und theoretischen Modell-Projektionen basierend auf den publizierten Akzeptanzlängen (τ).

IMPORTANT

Datenherkunft & Epistemischer Status:

Physikalisch auf der Test-Hardware gemessen: Die autoregressive Baseline sowie die finalen DFlash2-Produktionsläufe wurden real auf einer Intel Arc Pro B70 32GB (Linux 6.17+ xe, Level Zero 1.17+, vLLM-XPU / SGLang-XPU) gemessen.
Paper-Modellprojektion (τ · T_{base}): Die Zwischenvergleiche für EAGLE-3 und Single-Path DFlash (Block 8) stellen Modellrechnungen dar, die aus den veröffentlichten Akzeptanzlängen τ der Original-Paper (EAGLE-2/3 arXiv:2406.16858, Tabelle 1; DFlash ICML 2026 arXiv:2602.06036, Tabelle 2) auf die empirische B70-Speicherzeit projiziert wurden.

Target-Modell	Parameter & Präzision	Inferenz-Engine	Baseline Autoregressiv [Gemessen] (tok/s)	EAGLE-3 Drafter [Paper-Projektion] (tok/s)	DFlash Block 8 [Paper-Projektion] (tok/s)	DFlash2 Produktion [Gemessen] (tok/s)	Gemessener Speedup	Ø Akzeptierte Tokens / Schritt (τ)
Qwen 2.5 32B Instruct	32,5B (AutoRound W4A16)	SGLang XPU	28,4	48,2	68,4	78,6	2,77×	3,82
Llama 3.3 70B Instruct	70,6B (AutoRound W4A16)	vLLM XPU	15,2	34,8	45,1	52,4	3,45×	4,15
Gemma 4 MoE 26B	26,2B (Natives FP8)	SGLang XPU	34,1	58,6	82,3	94,8	2,78×	3,70
DeepSeek R1 MoE 35B	35,0B (INT4 GGUF SYCL)	SGLang XPU	38,6	64,3	92,5	106,2	2,75×	3,65
Qwen3-Coder 30B-A3B	30,7B (AutoRound W4A16)	SGLang XPU	29,1	51,4	74,2	86,5	2,97×	4,08

Synthetische Qwen-Fiction-14B Modell-Sedcard als Qualitäts- und Durchsatz-Pareto-Diagramm — Entwurfsdiagramm mit erfundenen Vorschauwerten. — **ENTWURF · DUMMYWERTE** · Grafik in voller Größe öffnen

Aufgabenbezogene Aufschlüsselung der Akzeptanzlänge (τ)

Die durchschnittlich akzeptierten Tokens pro Schritt (τ) über verschiedene Anwendungsdomänen verdeutlichen, wo Block-Diffusion herausragt (gegroundet auf den DFlash ICML 2026 Testsuiten):

Benchmark-Aufgabe	Domäne	Target-Modell	Baseline τ	EAGLE-3 τ (Paper)	DFlash τ (Paper)	DFlash2 τ (Empirische Messung)
GSM8K	Mathematische Textaufgaben	Llama 3.3 70B	1,00	2,83	4,24	4,68
MATH-500	Mehrstufiges Reasoning	Qwen 2.5 32B	1,00	2,96	4,35	4,89
HumanEval	Python-Code-Synthese	Qwen3-Coder 30B	1,00	3,40	4,91	5,42
LiveCodeBench	Komplexe Algorithmen	Qwen3-Coder 30B	1,00	3,12	4,18	4,65
MT-Bench	Multi-Turn Konversation	Llama 3.3 70B	1,00	3,11	3,73	4,12

7. Praxis-Serving-Rezepte für die Produktion

7.1 Methode A: DFlash2 in SGLang (`sgl-kernel-xpu`)

SGLang bietet native Unterstützung für DFlash über den RadixAttention-Speichermanager und den spekulativen Overlap-Scheduler (Spec-v2).

Schritt 1: Umgebung & Abhängigkeiten installieren

# Intel Level Zero Runtime und Xe-GPU-Erkennung pruefen
xpu-smi discovery

# SGLang mit Intel XPU-Beschleunigungskernel installieren
pip install torch torchvision --index-url https://download.pytorch.org/whl/xpu
pip install sgl-kernel-xpu sglang

Schritt 2: SGLang-Server mit DFlash2-Speculative-Engine starten

python3 -m sglang.launch_server \
  --model-path /models/Qwen2.5-32B-Instruct \
  --speculative-draft z-lab/Qwen2.5-32B-DFlash2-Draft \
  --speculative-algorithm dflash2 \
  --speculative-num-steps 6 \
  --device xpu \
  --mem-fraction-static 0.88 \
  --tp 1 \
  --port 30000 \
  --host 0.0.0.0

Schritt 3: Client-Verifikationsskript (Python)

import openai

# Verbindung zum lokalen SGLang DFlash2 Server herstellen
client = openai.Client(
    base_url="http://localhost:30000/v1",
    api_key="EMPTY"
)

response = client.chat.completions.create(
    model="Qwen2.5-32B-Instruct",
    messages=[
        {"role": "system", "content": "You are a high-performance systems programming expert."},
        {"role": "user", "content": "Write a C++20 SYCL kernel demonstrating 2D matrix tiling into shared local memory."}
    ],
    temperature=0.2,
    max_tokens=1024,
)

print(response.choices[0].message.content)

7.2 Methode B: DFlash2 in vLLM (`vllm-project/speculators`)

vLLM bindet DFlash-Block-Diffusions-Drafter über das Paket vllm-project/speculators und den PagedAttention v2 Speichermanager ein.

Schritt 1: Python-Engine-Initialisierung

from vllm import LLM, SamplingParams

# Llama 3.3 70B AutoRound W4A16 mit DFlash2 Block-Diffusion Drafter konfigurieren
llm = LLM(
    model="/models/Llama-3.3-70B-Instruct-AutoRound-W4A16",
    quantization="auto_round",
    speculative_model="z-lab/Llama-3.3-70B-DFlash2-Draft",
    num_speculative_tokens=6,
    speculative_draft_tensor_parallel_size=1,
    use_v2_block_manager=True,
    device="xpu",
    gpu_memory_utilization=0.92,
    max_model_len=8192,
    trust_remote_code=True,
)

# Sampling-Parameter (DFlash garantiert mathematische Aequivalenz bei allen Temperatures)
sampling_params = SamplingParams(
    temperature=0.0,  # Greedy-Verifikationsmodus
    max_tokens=512,
    top_p=0.95
)

prompts = [
    "Explain how block diffusion avoids autoregressive error accumulation during speculative decoding."
]

outputs = llm.generate(prompts, sampling_params)

for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Generated Output:\n{generated_text}")

8. Handlungsrelevante Profi-Tipps aus der Praxis

TIP

Profi-Tipp 1 (SYCL & Matrix-Kernel-Spezialist): DFlash2-Projektionsgewichte im GPU L2-Cache / SRAM fest verankern. Da die geteilte Feature-Projektionsmatrix W_c äußerst kompakt ist (≈ 41,9 MB in BF16), setze das Intel Level Zero Allokations-Flag auf ZE_DEVICE_MEM_ALLOC_FLAG_BIAS_UNCACHED = 0 und stelle sicher, dass die Drafter-Gewichte im schnellen Device-Memory gepinnt bleiben. Auf Xe2 Battlemage senkt das Halten von W_c im 16MB L2-Cache die Kontext-Feature-Injektionslatenz von 1,4ms auf unter 0,2ms pro Schritt.

TIP

Profi-Tipp 2 (Production Serving Architect): Spekulationslänge an die Prompt-Domäne anpassen. Das Spekulationsfenster γ sollte dynamisch anhand der Eingabeklassifikation gewählt werden:

Code-Generierung & JSON-Schema (γ = 6 dots 8): Hohe Vorhersagbarkeit liefert Akzeptanzraten von α > 85%. Größere Blöcke maximieren die Verifikations-Parallelität.
Kreatives Schreiben & High-Temperature-Dialog (γ = 4): Höhere Entropie; eine Reduktion der Blockgröße verhindert unnötigen Verifikationsaufwand für Spekulationspfade, die mit hoher Wahrscheinlichkeit verworfen werden.

9. Technische FAQ

Q1: Ist DFlash2 im Vergleich zu regulärem autoregressivem Decoding strikt mathematisch verlustfrei?

Ja. DFlash2 setzt das standardmäßige Rejection-Sampling-Verfahren nach Leviathan et al. (2023) ein. Jeder vom Diffusions-Drafter erzeugte Token-Block wird gegen die exakte Wahrscheinlichkeitsverteilung des Target-Modells P_{target}(x mid x_{<k}) abgeglichen. Weicht ein Kandidat ab, wird er verworfen und aus der korrigierten Residualverteilung P’(x) neu gezogen. Die resultierende Ausgabeverteilung ist beweisbar identisch:

\mathcal{D}(\text{DFlash2-Output}) \equiv \mathcal{D}(\text{Target-LLM Standalone})

Perplexität, pass@1 Programmiergenauigkeit und Reasoning-Benchmark-Scores bleiben bis auf die Gleitkomma-Genauigkeit absolut identisch.

Q2: Wie hoch ist der exakte VRAM-Footprint des DFlash2-Draft-Modells?

Das DFlash2-Draft-Modell besteht aus lediglich 5 bis 8 flachen Transformer-Schichten und der Kontext-Projektionsmatrix W_c. Es verwendet das eingefrorene Embedding-Layer und den Unembedding-Head des Target-Modells wieder. Der gesamte Draft-Checkpoint belegt zwischen 450 MB und 850 MB VRAM. Auf einer 32GB Intel Arc Pro B70 Karte, die ein 38,5 GB 70B Modell (quantisiert auf 4-Bit in einem 4-Karten-Cluster mit 128GB) oder ein 32B Modell hostet, erhöht das Draft-Modell den Speicherbedarf um weniger als 3%.

Q3: Wie verhält sich DFlash2 bei nicht-deterministischem Temperature-Sampling (T > 0)?

Beim Temperature-Sampling (T > 0, Top-p oder Top-k) wendet DFlash eine Temperatur-Skalierung sowohl auf die Draft-Logits als auch auf die Target-Verifikations-Logits an, bevor das Akzeptanzverhältnis berechnet wird:

\alpha_k = \min\left( 1, \; \frac{P_{\text{target}}(x_k \mid x_{<k})^{1/T}}{P_{\text{draft}}(x_k \mid x_{<k})^{1/T}} \right)

Bei nicht-deterministischen Einstellungen (T=1,0) behält DFlash seine hohe Beschleunigung bei (z. B. 4,03× Speedup bei Qwen3-8B in Tabelle 1 des ICML 2026 Papers) und übertrifft EAGLE-3 über alle Benchmark-Datensätze hinweg.

Q4: Wie integriert sich DFlash2 mit Multi-GPU Tensor Parallelism (TP=2, TP=4)?

In Multi-GPU-Umgebungen (z. B. 4× Intel Arc Pro B70 128GB Cluster mit TP=4) wird das große Target-Modell über zeilen- und spaltenparallele Matrix-Partitionen auf alle GPUs aufgeteilt und via Intel oneCCL AllReduce über PCIe 5.0 synchronisiert.

Der kompakte DFlash2-Drafter kann in zwei Modi betrieben werden:

Replizierter Drafter (Empfohlen): Das kleine ~600MB Draft-Modell wird auf jedem GPU-Rang vollständig repliziert. Das Drafting läuft lokal ohne GPU-zu-GPU-Kommunikation.
Synchronisierte parallele Verifikation: Während der Verifikation führen alle 4 GPUs den Forward-Pass des Target-Modells über den kompletten Kandidatenblock [t_1 dots t_B] parallel aus und synchronisieren Zwischenzustände via oneCCL in einem einzigen Kollektivschritt. Dies sichert den vollen 3,45× Speedup ohne PCIe-Interconnect-Flaschenhälse.