Jedes KI-Modell hat ein grundlegendes Problem: Tokens werden eines nach dem anderen berechnet – sequentiell, langsam, teuer. Die KI-Industrie hat verschiedene Ansätze entwickelt, um diesen Flaschenhals zu überwinden. Einer der vielversprechendsten ist Speculative Decoding: Ein kleines Modell schlägt Tokenfolgen vor, das große Modell verifiziert sie parallel. Doch selbst der aktuelle Stand der Technik, EAGLE-3, stößt bei einem Speedup von nur 2–3× an seine Grenzen.
Seit Anfang 2026 gibt es einen neuen Ansatz: DFlash – Block Diffusion for Flash Speculative Decoding. Entwickelt vom Z-Lab-Team und auf der ICML 2026 vorgestellt, erreicht DFlash auf Qwen3-8B bis zu 6× Speedup – und ist damit nahezu 2,5× schneller als EAGLE-3. Was dahintersteckt, warum der Ansatz fundamental anders ist und was das für die Praxis bedeutet.
Das Problem mit dem sequentiellen Denken
Warum ist KI-Inferenz so langsam? Die Antwort liegt in der Architektur: Große Sprachmodelle generieren Token für Token – und jedes Token hängt vom vorherigen ab. Es gibt keinen Weg, diesen Prozess trivial zu parallelisieren, ohne die Ausgabequalität zu gefährden. Das Ergebnis: Selbst teure GPU-Cluster verbringen einen erheblichen Teil ihrer Rechenzeit damit, auf das nächste Token zu warten.
Speculative Decoding versucht, genau diesen Flaschenhals zu entschärfen. Die Grundidee ist elegant: Ein kleines, schnelles Draft-Modell generiert mehrere Token-Vorschläge auf einmal. Das große Zielmodell verifiziert diese Vorschläge dann parallel in einem einzigen Forward Pass. Wenn die Vorschläge korrekt sind, hat das große Modell in derselben Zeit deutlich mehr Output geliefert. Wenn nicht, verwirft es die fehlerhaften Tokens und generiert neu.
Der Haken an EAGLE-3 – dem bisherigen Stand der Technik: Das Draft-Modell arbeitet autoregressiv. Es erzeugt Token für Token, also sequentiell. Um die Latenz niedrig zu halten, setzt EAGLE-3 auf eine extrem flache Architektur (oft nur eine einzige Transformer-Layer). Das begrenzt die Draft-Qualität und damit den Speedup auf etwa 2–3×.
DFlash: Der Diffusionsansatz
DFlash geht das Problem von einer anderen Seite an. Anstatt das Draft-Modell autoregressiv arbeiten zu lassen, nutzt es Block-Diffusion – eine Technik, die ursprünglich aus der Bildgenerierung bekannt ist. Die zentrale Idee: Das kleine Draft-Modell erzeugt einen ganzen Block von Tokens (typischerweise 16 Stück) in einem einzigen parallelen Forward Pass.
Das klingt zunächst nach einem großen Modell – aber DFlash ist bewusst klein. Es nutzt nur wenige Transformer-Layer, teilt Embedding und LM-Head mit dem Zielmodell und trainiert nur die dazwischenliegenden Schichten. Entscheidend ist, was in diese wenigen Schichten hineingibt: Kontext-Features aus dem Zielmodell.
Warum die Target-Conditioning den Unterschied macht
Ein naiver Diffusion-Drafter ohne Zugriff auf das Zielmodell hat ein Problem: Er muss die nächsten Tokens aus nahezu nichts vorhersagen. Ohne die versteckten Repräsentationen des großen Modells fehlt ihm der Kontext, um wirklich gute Vorschläge zu machen. Die Speedups bleiben bescheiden – im Bereich von 3×.
DFlash löst das, indem es Hidden States aus mehreren Layern des Zielmodells extrahiert, sie durch eine leichte Projektion fused und dann in den KV-Cache jedes einzelnen Draft-Layers injiziert. Das ist ein entscheidender Unterschied zu EAGLE-3, wo die Target-Features nur als Input für die erste Schicht dienen – und das Signal mit zunehmender Tiefe verwässert.
In DFlash bekommt jeder Draft-Layer den vollen Kontext. Das bedeutet: Die Akzeptanzlänge – also wie viele Tokens das Zielmodell ohne Neuberechnung übernehmen kann – skaliert mit der Tiefe des Draft-Modells. Mehr Tiefe, mehr korrekte Vorschläge, mehr Speedup.
Bidirektionale Aufmerksamkeit statt sequentieller Vorhersage
Der zweite technische Unterschied: DFlash nutzt bidirektionale Aufmerksamkeit (mit KV-Cache) statt kausaler Maskierung. Jede Query kann gleichzeitig auf alle Mask-Token und alle Target-Kontext-Features zugreifen. Das ermöglicht die simultane Vorhersage eines ganzen Blocks – statt Token für Token zu raten.
Das Ergebnis in der Praxis: Ein DFlash-Drafter mit 16 Layern, der 16 Tokens gleichzeitig erzeugt, hat geringere Latenz als ein EAGLE-3-Drafter mit nur einem Layer, der 8 Tokens sequentiell erzeugt. Mehr Tiefe, mehr Output, weniger Zeit.
Die Zahlen: Speedup im Detail
Die Benchmarks des Z-Lab-Teams auf gängigen KI-Benchmarks zeigen das Potenzial deutlich:
| Benchmark | EAGLE-3 Speedup | DFlash Speedup | Vorteil DFlash |
|---|---|---|---|
| GSM8K (Math) | 2,13× | 5,20× | +144% |
| MATH-500 | 2,18× | 6,17× | +183% |
| AIME25 (Math-Wettbewerb) | 1,88× | 2,27× | +21% |
| HumanEval (Code) | 2,25× | 5,91× | +163% |
| MBPP (Programmierung) | 2,48× | 5,20× | +110% |
| SWE-Bench (Bugfixes) | 2,27× | 4,75× | +109% |
| MT-Bench (Chat) | 1,90× | 2,92× | +54% |
| LiveCodeBench | 1,94× | 2,79× | +44% |
Bei Reasoning-Modellen mit aktivierter Thinking-Funktion erreicht DFlash unter Sampling (Temperatur=1) immer noch rund 4,5× Beschleunigung – ein Wert, der in der Praxis bedeutet, dass dieselbe Hardware fast fünfmal so viele Anfragen bedienen kann.
Was das für die Hardware-Frage bedeutet
Hier wird es unternehmerisch interessant. Wenn DFlash denselben GPU-Cluster um den Faktor 4–6× effizienter auslastet, verschiebt das die Rechnung für Self-Hosting signifikant. Wer bereits in Infrastruktur investiert hat, kann mit DFlash deutlich mehr Kapazität aus derselben Hardware herausholen.
Für Betreiber, die bereits GPU-Cluster im Einsatz haben, ist das keine theoretische Zahl: DFlash lässt sich auf bestehende Setups aufsetzen, ohne die Infrastruktur grundlegend zu ändern. Wer vLLM oder SGLang betreibt, kann das Draft-Modell als zusätzliche Komponente hinzufügen – der Rest der Pipeline bleibt unverändert.
Warum DFlash gerade für mittelständische Betreiber relevant ist
In der KI-Industrie dominieren zwei Erzählungen: Hyperscaler wie AWS, Google und Azure mit unbegrenzter GPU-Kapazität, und Tech-Giganten mit eigenen Forschungsteams. Was selten diskutiert wird: der Mittelbau. Unternehmen mit vier, acht oder sechzehn GPUs, die produktiv mit LLMs arbeiten wollen, aber nicht die Ressourcen haben, dafür ganze Rechenzentren zu betreiben.
Für diese Gruppe ist DFlash ein besonders starker Hebel. Wenn ein 4-GPU-Setup mit DFlash plötzlich so viele Anfragen bedient wie vorher ein 16-GPU-Cluster, verändert das die Wirtschaftlichkeit grundlegend. Die Hardware amortisiert sich schneller, die Betriebskosten pro Anfrage sinken, und die Latenz bleibt akzeptabel. Das macht Self-Hosting für eine deutlich größere Gruppe von Unternehmen attraktiv – nicht nur für die wenigen Firmen, die sich teure GPU-Cluster leisten können.
Und noch ein Effekt, der selten erwähnt wird: Wenn Inference günstiger wird, werden auch KI-gestützte Produkte günstiger. Ein Unternehmen, das einen KI-Chatbot oder einen automatisierten Dokumentenverarbeitungs-Workflow betreibt, kann mit DFlash seine Kosten pro Anfrage um 60–70 % senken. Das kann den Unterschied machen zwischen einem Produkt, das sich rechnet, und einem, das es nicht tut.
Noch spannender: Wenn die großen API-Anbieter wie Moonshot, Google oder Anthropic DFlash in ihre Serving-Pipelines integrieren, sinkt deren Rechenbedarf pro Anfrage. Das könnte mittelfristig den Druck auf die ohnehin angespannte Chip-Versorgung ein Stück weit reduzieren – zumindest in der Cloud.
Für kleinere und mittlere Betreiber eröffnet DFlash eine weitere Chance: Es ermöglicht effiziente Inferenz auch auf Hardware, die für ein reines Zielmodell nicht ausreichen würde. Ein Setup mit 2–4 High-End-GPUs, das zuvor nur für kleine Modelle reichte, könnte mit DFlash ein größeres Modell mit akzeptabler Latenz betreiben.
DFlash im Vergleich zu anderen Inferenz-Optimierungen
DFlash ist nicht die einzige Technik, die in modernen KI-Infrastruktur-Stacks zur Beschleunigung eingesetzt wird. Es lohnt sich, den Ansatz im Kontext zu sehen:
- KV-Cache-Offloading (z. B. Mooncake): Lagert Attention-States aus dem GPU-Speicher in einen schnellen External Cache aus, um lange Kontexte ohne Speicherfehler zu verarbeiten. DFlash profitiert davon indirekt, weil ein längerer Kontext mehr Draft-Tokens erzeugen kann.
- Continuous Batching: Fasst Anfragen verschiedener Nutzer dynamisch zusammen, um die GPU-Auslastung zu maximieren. Funktioniert synergistisch mit DFlash, weil der Speedup pro Anfrage den overall throughput zusätzlich erhöht.
- Prefill/Decode Disaggregation: Trennt die rechenintensive Prefill-Phase von der dekoding-intensiven Decode-Phase auf verschiedene Hardware-Gruppen. DFlash kann auf beiden Phasen eingesetzt werden.
- Tensor Parallelism: Verteilt ein einzelnes Modell über mehrere GPUs. DFlash skaliert damit ebenfalls – die Draft-Qualität bleibt erhalten, während die Verifikation auf mehreren GPUs gleichzeitig läuft.
DFlash ersetzt diese Techniken nicht, sondern ergänzt sie. In einer produktiven KI-Infrastruktur würde DFlash typischerweise zusammen mit Continuous Batching und Tensor Parallelism betrieben – was die Gesamtperformance nochmal über das reine Draft-Speedup hinaus steigert.
Interessant ist auch der Vergleich mit dem früheren Standard: Ohne Speculative Decoding generiert ein KI-Modell Token für Token und wartet bei jedem einzelnen Schritt auf die GPU. DFlash reduziert diese Wartezeit drastisch, weil das Zielmodell nur noch die Tokens verifiziert, die das Draft-Modell bereits vorgeschlagen hat. Bei einer Akzeptanzrate von 80–90 % bedeutet das: Nur 10–20 % der GPU-Zyklen gehen tatsächlich in Neugenerierung – die restlichen 80–90 % liefern fertige Tokens.
Verfügbarkeit und Integration
DFlash ist kein reines Forschungsergebnis mehr. Das Framework ist produktionsreif und unterstützt mehrere Serving-Backends:
- vLLM – Core-Support ab v0.20.1; für Gemma4 gibt es einen speziellen Docker-Build
- SGLang – Produktionsreifer Support mit experimentellem Scheduling-Overlap
- Hugging Face Transformers – Für Exploration (Qwen3 und LLaMA-3.1)
- MLX – Apple-Silicon-Support über Community-Implementierung
Die vortrainierten DFlash-Draft-Modelle sind auf HuggingFace verfügbar – unter anderem für Qwen3.5-27B, Qwen3-Coder-30B-A3B, Gemma-4-31B und die Kimi-K2.5-Familie. Wer ein anderes Zielmodell beschleunigen möchte, kann zudem ein eigenes DFlash-Draft-Modell trainieren – ein Rezept dafür hat das Z-Lab-Team in Kürze als Open Source veröffentlicht.
DFlash und Speculative Decoding als Baustein
DFlash steht in einer Reihe mit anderen Speculative-Decoding-Ansätzen, die in modernen KI-Infrastruktur-Stacks zum Einsatz kommen. Der Kimi K3-Artikel auf Biteno erwähnt DSpark als Draft-Strategie für Kimi K3 – eine Technik, die etwa 3× Speedup liefert. DFlash geht darüber hinaus und erreicht auf vergleichbaren Setups bis zu 6×.
Für Betreiber, die bereits Speculative Decoding nutzen, ist DFlash ein nahtloser Ersatz: Gleiche Architektur, bessere Ergebnisse. Für alle anderen ist es ein guter Einstiegspunkt, um sich mit dem Konzept vertraut zu machen – die Installation über vLLM dauert wenige Minuten.
Mehr Hardware-Effizienz ohne Qualitätsverlust
Der eigentliche Wert von DFlash liegt nicht nur im Speedup-Zahlen, sondern in der Philosophie dahinter: Diffusionsmodelle müssen nicht mit autoregressiven LLMs bei der Qualität konkurrieren. Sie müssen nur gute Draft-Modelle sein. Diese Arbeitsteilung macht den Ansatz so effizient.
DFlash zeigt, dass die KI-Industrie noch längst nicht am Ende dessen ist, was mit cleverer Serving-Optimierung aus bestehender Hardware herauszuholen ist. Die Frage, ob Selbsthosting für ein Unternehmen sinnvoll ist, wird durch Technologien wie DFlash ein Stück weit neu gestellt – und die Antwort fällt für eine wachsende Zahl von Betrieben positiver aus als noch vor einem Jahr.
Sie möchten wissen, ob DFlash für Ihre KI-Infrastruktur relevant ist?
Wir unterstützen Unternehmen bei der Evaluierung von Inferenz-Optimierungen – herstellerunabhängig und datenbasiert. Sprechen Sie mit uns.
