I tested freshly merged DFlash in llama.cpp on Qwen 3.6 27B Local AI win. 4.44x faster at 36K context. Here are my findings RTX 6000 PRO.

A month ago I posted my MTP benchmarks here (3.34x on Gemma 4). DFlash support just merged into llama.cpp (PR #22105), so I ran it on the same rig with the Qwen 3.6 27B and it beat my best MTP numbers at every draft length. DFlash is speculative decoding with a block diffusion drafter from z-lab. Instead of drafting tokens one by one, it fills a block of 15(currently limit) tokens in a single pass. You can get the docker compose from repo and run it on your hardware as Llama server in one click too.

https://preview.redd.it/pltg3n2i7ubh1.png?width=1700&format=png&auto=webp&s=3aa3306e95908b1c8eddb504c13865e9fbf17bb3

- Speed: NVIDIA aiperf synthetic sweeps, ISL = OSL at 512 / 4K / 12K / 36K, fixed lengths (stddev 0), ignore EOS + min_tokens pinned so every request generates the full size

- Measured requests per size: 30 / 10 / 5 / 3 (fewer as context grows, but 3 runs at 36K is still ~110K generated tokens), warm-up requests before each measured set: 2 / 2 / 1 / 1, random seed 42

- Greedy decoding (temperature 0, top-k 1, top-p 1.0), concurrency 1, so the "serving yourself at home" scenario.

- tok/s comes from llama.cpp's own timings, acceptance rate from draft_n / draft_n_accepted

https://preview.redd.it/4oh5rqgt5ubh1.png?width=1030&format=png&auto=webp&s=3183585fe446b00d2da2fb40e0a9e5c1abb3a919

- MATH-500, first 100 problems, same subset for both configs, seed pinned, reasoning off. Looking to run LiveCodeBench too but need to check some issues on ai perf and packages.

- Target: unsloth/Qwen3.6-27B-GGUF (UD-Q4_K_XL) via llama.cpp server (Docker)

- Draft: Alittlehammmer/Qwen3.6-27B-DFlash-GGUF-llama.cpp (Q8_0, ~1.9GB), post-merge arch

Hardware: AMD Ryzen 9 9950X | NVIDIA RTX PRO 6000 Blackwell | 96GB VRAM | CUDA 13 | Ubuntu

Best result: 273.04 vs 61.47 tok/s at 36K context = 4.44x faster. Best leaderboard config was n_max=12 at 256 tok/s (3.64x). My best MTP config on the same model was 190 tok/s (2.70x).

On quality: last time I couldn't measure degradation and you rightly asked about it, so this time I did. Base scored 87% vs DFlash 86% on MATH-500 (100 problems), identical in 6 of 7 subjects, one prealgebra problem differed. The DFlash run generated at 270 vs 72 tok/s (3.75x) while doing it. I only run 100 problems as I have some failures before and needed PC for something else. Architecturally it should be lossless at greedy since the target model verifies every drafted token, but I wanted to actually measure it this time instead of arguing from the design. I think this one mistake is in error range as it's early implementation.

On VRAM: also measured this time. 26GB loaded with DFlash vs 21GB baseline, so around 5GB overhead (Q8 drafter weights + buffers).

1.44x at 512 ctx, 2.70x at 4K, 3.40x at 12K, 4.44x at 36K. Normally models get slower as context grows. Here the gap widens because the baseline decays while DFlash holds. I also ran a reasoning server at 98K context and it was still doing 241 tok/s.

Acceptance per cycle is similar (tau around 7.3 vs 6.7), but MTP pays one forward pass per drafted token while the diffusion drafter fills the whole block in one pass. Same tokens on the output at a fraction of the drafting cost.

43% acceptance at n_max=12 beat 91% acceptance at n_max=2. What pays is accepted tokens per verification pass, not the acceptance percentage. Note that the current llama.cpp implementation caps draft tokens at 15.

Same story as my MTP post. Every decode step re-reads the weights and your GPU mostly waits on memory, so a drafter amortizes that cost across multiple accepted tokens. The extra trick in DFlash is that the target model's hidden states get injected into every drafter layer (KV injection), so the drafter stays accurate deep into big blocks instead of fading after a few tokens.

Catch one: I do quick test with nvtop and have around 5GB VRAM difference with drafter and without but I will need to confirm it later as it was not the only thing running as I was recording. So not so professional testing xd Catch two: this is a low concurrency win. I haven't tested high batch production serving, where the diffusion passes could start competing for compute.

Also a troubleshooting tip that will save you an hour: your draft GGUF must have architecture dflash. Repos tagged dflash-draft are pre-merge and won't load.

https://preview.redd.it/6kafythk4ubh1.png?width=1700&format=png&auto=webp&s=119da75b6d1f3b4887a715935fe6aa25de508c6d

What are your findings and speeds this look like quite nice setup for this local 128GB AI boxes like DGX Spark to get on better speeds at this economy