Feature Request: Add `draft-dflash` to the PrismML llama.cpp fork

[Milor123]

TL;DR: The PrismML fork has two unique features I can't get elsewhere — --kv-mean-center (K-cache mean-centering bias for Q4_0) and draft-dspark (Bonsai 27B speculative decoding). But it's missing draft-dflash, which is already merged in mainline llama.cpp. I'd love to use both dflash and the KV bias in the same binary.

Context

I'm running the PrismML fork (prism-b9591-62061f9) on a Windows CUDA setup. The --kv-mean-center feature is excellent — it recovers a significant amount of quality from the Q4_0 K-cache at zero decode cost, which lets me push context to ~200K tokens on a 12 GB GPU without sacrificing quality.

However, I also have models with DFlash drafters (e.g., z-lab/Qwen3-4B-DFlash) that I'd like to run with speculative decoding. The current fork only supports draft-dspark (Bonsai-specific):

--spec-type [none|draft-simple|draft-eagle3|draft-mtp|draft-dspark|ngram-*]

draft-dflash was merged into mainline ggml-org/llama.cpp in PR #22105 (2026-06-28). It's a block-diffusion speculative decoding method that produces an entire block of draft tokens in a single forward pass, achieving up to 8x speedup on compatible models.

The ask

Please cherry-pick or merge the DFlash support from upstream (draft-dflash as --spec-type draft-dflash with the corresponding --spec-draft-n-max flag) into the PrismML fork.

The main value is that users could then combine:

• --kv-mean-center (fork-exclusive, Q4_0 KV quality recovery)
• draft-dflash (mainline feature, block-diffusion speculative decoding)
• draft-dspark (existing, Bonsai-specific)

…all in one binary, instead of having to choose between the KV bias and modern speculative decoding support.

Why it matters

Right now the choice is:

Binary	KV bias (Q4_0)	dflash	dspark
PrismML fork	✅	❌	✅
Mainline ggml-org	❌	✅	❌
Bee fork (Anbeeld)	❌	✅	❌

Users who want long context (Q4_0 KV + bias) and fast single-shot inference (dflash) have to keep two binaries around. Merging dflash upstream would make the PrismML fork the single best build for both use cases.

Additional context

• DFlash is already part of mainline common/speculative.cpp (type: draft-dflash) and the llama-server interface — it's a clean integration with no disruptive changes.
• The fork already carries speculative checkpointing support, so hybrid target models (Qwen3.5, etc.) work correctly with DFlash on the verify/replay path.
• I'm happy to test a pre-release build on Windows CUDA

Thanks for considering it!

[khosravipasha]

Thanks this is a good idea, we are in a middle of migration for upstreaming our changes to llama.cpp for ternary (Q2_0), so watinint for that to finalize and then we will rebase our fork to latest llama.cpp might need to wait 1-2 weeks realistically.