Field note · llama.cpp
The Qwen3.8-Flash-Next MTP head was missing from the August 26 GGUFs
On August 26, the converter disabled MTP export and the architecture lacked its inference path. This historical field note now links to the August 28 follow-up, which documents working speculative decoding using a third-party head, a draft PR, and a local GGUF graft.
- Hardware
- NVIDIA DGX Spark · GB10 (SM121) · aarch64 · 128 GB unified
- Software
- llama.cpp master @ 5e6a37cb1 + PR #27742 (branch qwen4exp-27742) · unsloth/Qwen3.8-Flash-Next-GGUF UD-IQ4_XS
Update — September 12, 2026
The limitation below describes my August 26 setup. By August 28, I had working speculative
decoding using a third-party MTP head, the graph from draft PR #27836, and a local GGUF graft.
The follow-up essay documents that experiment,
including the tensor-name fix and remaining caveats. At the time of that experiment, neither
upstream change was in master.
The original August 26 account is preserved below. References to "today" and outstanding work describe that investigation.
What the card promises versus what ships
The Qwen3.8-Flash-Next model card advertises "MTP: 1 layer, trained with multi-steps" — a 4B multi-token-prediction head. Every other Qwen model on this host runs speculative decoding off exactly this kind of head. This one can't, today.
The decisive evidence
The tell isn't a missing metadata key — it's the PR's own converter, conversion/qwen4exp.py:
# the MTP block is a separate draft head; vLLM drops it too
supports_mtp_export = False
no_mtp = TrueThat's a decision the converter makes on purpose, not an oversight. It lines up with everything else: the GGUF carries no nextn_predict_layers key, the repository publishes nothing but its seven quant directories plus .gitattributes and README.md — no separate mtp-*.gguf anywhere — and no DFlash or DFlash2 drafter exists for qwen4exp at all.
Two changes, not one
Even if Unsloth exported the head tomorrow, that alone wouldn't be enough. src/models/qwen4exp.cpp has zero references to nextn anywhere in it. The generic blk.%d.nextn.* plumbing already exists in llama-arch.cpp for other architectures, but nothing in this architecture's own code drives it. Exporting the weights and wiring the inference path are two separate pieces of upstream work, and both are outstanding.
Where I got this wrong the first time
My initial "no MTP" call rested on a missing metadata key plus a repository listing I'd truncated with head -40. Neither actually ruled it out. Read the converter, not the symptoms.
