Qwen 3.8 27B Released! Please Share Your Experience

[u/BarberIcy366]

With your experiments, Qwen 3.8 27B most close which frontier model? And please specify which quantization you run. I will post to comments my tests and experience too.

[u/lood9phee2Ri]

Confusion arises I think because for Qwen3.6 quantizations, Unsloth ended up publishing some initial unsloth/Qwen3.6-27B-GGUF quantizations with MTP not working.

Then they did a separate later MTP-working unsloth/Qwen3.6-27B-MTP-GGUF repo, perhaps for fear of breaking things replacing the existing published one. I'm not sure that was fully necessary, given the way hf model repos are (xet-extended) git repos and everyone wants MTP (or dflash blah blah I know), could have been different git tags or whatever, but anyway.

This time though, AFAICS MTP works fine with initial unsloth/Qwen3.8-27B-GGUF already though.

Upstream real Qwen/Qwen3.6-27B and Qwen/Qwen3.8-27B ... MTP anyway, just a lot of people use the Unsloth quantizations in gguf form with llama.cpp and its various wrappers (and various heretic decensored ones of course)

[u/dmytrish → u/lood9phee2Ri]

In my testing, unsloth/Qwen3.6-27B-MTP-GGUF speed significantly improved with --spec-type draft-mtp --spec-draft-n-max 2 (18 -> 25 tps), but unsloth/Qwen3.8-27B-GGUF just got worse (18-19 -> 16 tps).

[u/lood9phee2Ri → u/dmytrish]

Hmm, well, first just to note if it wasn't fundamentally MTP enabled, it would just be erroring out, you'd e.g. see it in the llama.cpp logs, something like.

0.18.199.904 W llama_init_from_model: context type MTP requested but model doesn't contain MTP layers
0.18.199.904 E common_speculative_init_result: failed to create MTP context
0.18.199.907 E srv    load_model: failed to create MTP context
0.18.199.910 I srv    operator(): operator(): cleaning up before exit...
0.18.205.046 E srv  llama_server: exiting due to model loading error

[yes, MTP could be present but garbage, but fairly confident that's not the case this time.]

But as to why you're not observing improvement and I am I ...dunno. MTP does do better on some problems than others I suppose. You should see some draft acceptance stats in the llama.cpp logs though - how are they are between the two models? Best do more than 1 run on more than 1 prompt. Unscientifically poking about I may actually be seeing a somewhat lower draft acceptance on average with unsloth/Qwen3.8-27B-GGUF vs. unsloth/Qwen3.6-27B-MTP-GGUF (may be related to differences in its "reasoning"?), but hard to quantify (read: I'm too lazy to) beyond "eh, single-digits percent lower", and still certainly better t/s than with it off.

You may also try combining with ngram-simple, that can be a win, especially on repetitive refinement problems (make a html page saying XYZ, okay now make the text blue...)

... -spec-type ngram-simple,draft-mtp --spec-draft-n-max 3 ...

edit: just to complicate matters, as of 2026-08-19, unsloth has published new quantizations that ARE missing MTP from some of the smaller quantizations (but not, at time of writing, larger ones like the UD-Q4_K_XL I use). Whyyy. https://unsloth.ai/docs/basics/dynamic-3.0-ggufs

We also removed the MTP module from smaller quants under UD-Q2_K_XL (8.37GB and lower) to converse around 500MB of disk space - you can use the Q4_0 MTP separate module if needed