DFlash2 für Qwen3.8 27B auf RTX 5090 getestet: bis zu 200 tk/s
DFlash2 ist eine Erweiterung des spekulativen Decodings, die speziell für Qwen3.8-Modelle entwickelt wurde und auf einem separaten Draft-Modell basiert. Der Reddit-Nutzer /u/Hefty_Wolverine_553 testete die Implementierung über den noch nicht gemergten llama.cpp-Pull-Request #27342 und musste das Framework dafür neu kompilieren. Als Hauptmodell diente bartowski/Qwen3.8-27B-GGUF in der Q5_K_L-Quantisierung, als Draft-Modell incoai/Qwen3.8-27B-DFlash2-GGUF in Q4_K_M. Die Konfiguration nutzt Flash Attention, unified KV-Cache, 8-Bit-KV-Cache-Quantisierung (q8_0) sowie einen maximalen Draft-Ahead von 7 Tokens (--spec-draft-n-max 7). Beim Vergleich mit dem Vorgängerverfahren MTP zeigte sich: Code-Generierung profitiert stärker vom Speedup als Reasoning-Passagen – Thinking-Phasen erreichen nur 80–90 tk/s, während MTP dort zuvor rund 100 tk/s lieferte. Der Nutzer verweist außerdem darauf, dass DFlash (erste Generation) auf Qwen3.6 27B bessere Ergebnisse erbracht hatte als DFlash2 auf Qwen3.8 27B, was auf modellspezifische Unterschiede in der Akzeptanzrate der Draft-Tokens hindeutet. Der erhöhte VRAM-Bedarf von DFlash2 ist der zentrale Nachteil: Bei gleichem Setup musste der Kontext von 220k auf 160k Token reduziert werden.
- Getestete Quantisierungen: Hauptmodell Q5_K_L (bartowski), Draft-Modell Q4_K_M (incoai) — beide als GGUF.
- Konfigurationsdetail: --spec-draft-n-max 7, zwei parallele Slots (-np 2), Batch-Size 2048 / UBatch 1024.
- Thinking-Modus bremst DFlash2 aus: Nur ~80–90 tk/s gegenüber ~200 tk/s bei reiner Code-Generierung.
- Vorgänger DSpark auf llama.cpp hatte der Nutzer wenige Tage zuvor getestet und als 'not really working' eingestuft.
- PR #27342 ist noch nicht in den llama.cpp-Hauptzweig gemergt — Nutzer müssen selbst kompilieren.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
DFlash2 für Qwen3.8 27B auf RTX 5090 getestet: bis zu 200 tk/s
DFlash2 ist eine Erweiterung des spekulativen Decodings, die speziell für Qwen3.8-Modelle entwickelt wurde und auf einem separaten Draft-Modell basiert. Der Reddit-Nutzer /u/Hefty_Wolverine_553 testete die Implementierung über den noch nicht gemergten llama.cpp-Pull-Request #27342 und musste das Framework dafür neu kompilieren. Als Hauptmodell diente bartowski/Qwen3.8-27B-GGUF in der Q5_K_L-Quantisierung, als Draft-Modell incoai/Qwen3.8-27B-DFlash2-GGUF in Q4_K_M. Die Konfiguration nutzt Flash Attention, unified KV-Cache, 8-Bit-KV-Cache-Quantisierung (q8_0) sowie einen maximalen Draft-Ahead von 7 Tokens (--spec-draft-n-max 7). Beim Vergleich mit dem Vorgängerverfahren MTP zeigte sich: Code-Generierung profitiert stärker vom Speedup als Reasoning-Passagen – Thinking-Phasen erreichen nur 80–90 tk/s, während MTP dort zuvor rund 100 tk/s lieferte. Der Nutzer verweist außerdem darauf, dass DFlash (erste Generation) auf Qwen3.6 27B bessere Ergebnisse erbracht hatte als DFlash2 auf Qwen3.8 27B, was auf modellspezifische Unterschiede in der Akzeptanzrate der Draft-Tokens hindeutet. Der erhöhte VRAM-Bedarf von DFlash2 ist der zentrale Nachteil: Bei gleichem Setup musste der Kontext von 220k auf 160k Token reduziert werden.
- Getestete Quantisierungen: Hauptmodell Q5_K_L (bartowski), Draft-Modell Q4_K_M (incoai) — beide als GGUF.
- Konfigurationsdetail: --spec-draft-n-max 7, zwei parallele Slots (-np 2), Batch-Size 2048 / UBatch 1024.
- Thinking-Modus bremst DFlash2 aus: Nur ~80–90 tk/s gegenüber ~200 tk/s bei reiner Code-Generierung.
- Vorgänger DSpark auf llama.cpp hatte der Nutzer wenige Tage zuvor getestet und als 'not really working' eingestuft.
- PR #27342 ist noch nicht in den llama.cpp-Hauptzweig gemergt — Nutzer müssen selbst kompilieren.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.