Local model users running llama.cpp now have a concrete reason to revisit their decoder parameters. Version 0.8.0 added support for DFlash2 on Qwen3.8-Flash-Next, and an independent test on Apple Silicon M5 Max quantifies the change: decoding throughput improves by 17 percent on average compared with MTP.

The numbers vary by workload. On code the gain is 18 percent (95.1 tps versus 80.5), on list-like prompts it climbs to 39 percent (127 tps versus 91.4), while on prose there is a 3 percent regression (51.9 tps versus 53.8) that the author treats as noise. With a 6k-token context the advantage is 19 percent, but at a long 25k context DFlash2 drops to roughly the same level as MTP, while MTP stays nearly flat. The runs followed an extensive parameter sweep: n-max=3 and p-min=0.75 for MTP, n-max=5 and p-min=0.75 for DFlash2.

The most interesting finding is not the average gain but the memory trade-off. The DFlash2 Q4_0 draft head is about 350MB, against 2.2GB for the Q4_0 ggml MTP head used as reference. That looks like a clear win for systems with limited VRAM, but it is not: the compute buffer required by DFlash2 almost exactly offsets the head’s smaller size. In other words, DFlash2 buys speed, not memory. The comparison between Q4_0 and Q8_0 heads shows no measurable difference in speed or acceptance, so the Q4_0 choice helps contain footprint but does not change the overall VRAM budget.

This shifts how self-hosted deployment benchmarks should be read. A drafter is often assessed only by tokens per second, but these results show acceptance and buffer cost matter just as much. On list prompts DFlash2 acceptance matches MTP at 98 percent and throughput rises 39 percent; on code acceptance falls to 84 percent versus 94 percent for MTP, yet speed remains higher. On prose acceptance drops to 64 percent and the advantage disappears. That is not a defect: it is evidence that draft heads must be tuned for the workload, not for an abstract idea of a faster model.

There is also a multimodal development. Unlike DFlash2 for the 3.8 27B model, image prompts work here. In testing, drafts with vision enabled produced coherent responses and good acceptance. For local infrastructure that needs to process documents, screenshots or photos without leaving an on-premise perimeter, that is a meaningful technical signal: the drafter is no longer text-only but can operate on visual inputs locally.

Structurally, the DFlash2 case shows that speculative decoding is becoming a major front in on-premise optimization. Efficiency increasingly depends on the base-model/drafter pairing and on acceptance parameter quality, not just on picking a smaller LLM. For teams running local servers or Apple Silicon hardware, attention shifts from a single tokens-per-second figure to per-category acceptance profiles, perceived latency and compute buffer sustainability. The drop at 25k context also shows that draft gains are not guaranteed on long windows, a structural constraint for capacity planning.

llama.cpp v0.8.0 makes these tests reproducible without cloud APIs. That matters for anyone calculating TCO and data sovereignty: the throughput uplift can be measured on owned hardware, with self-quantized GGUFs and parameters adapted to real workloads. AI-RADAR’s /llm-onpremise section offers analytical frameworks to separate real gains from marketing numbers in such cases. The bottom line remains that DFlash2 does not remove the memory-compute trade-off; it moves it.