From what I can tell, the model choice may not be the issue
:
I would not start by downloading random alternative draft models.
The mlx-community/Qwen3.8-27B-MTP-8bit model you found is the right kind of artifact: its model card says it is an MTP drafter split from Qwen3.8-27B, is not a standalone model, and is intended to be used alongside a compatible Qwen3.8-27B target with mlx-vlm.
The error you are seeing instead looks very close to an existing LM Studio MLX issue: lmstudio-ai/mlx-engine#368. In that path, VLM targets are rejected for speculative decoding before LM Studio even evaluates whether a particular draft model is compatible, which produces the same kind of empty “No compatible draft models found” list.
That issue was reported with MLX runtime 1.11.0, the same runtime version you mentioned, and it is still open. The current public mlx-engine source also still has the batched-vision draft path disabled.
So my default route would be:
Want to understand the empty Draft Model list?
-> Check mlx-engine #368 first.
Another drafter probably will not change that gate.
Want to test whether this exact Qwen3.8 + MTP pairing works?
-> Try the pair directly with a current mlx-vlm release.
Main goal is simply more output speed in LM Studio?
-> If macOS >= 26.4, compare the Splash Qwen3.8 path.
-> If switching to GGUF is okay, LM Studio's llama.cpp path
also supports MTP / DFlash / DSpark assistant drafters.
Want to know whether 15-17 tok/s itself is unusually low?
-> Exact target quantization + normal context length matter a lot.
I would treat those as separate questions rather than trying to solve all of them by finding a different drafter.
Why the empty draft-model list looks like an LM Studio MLX/VLM limitation
There are two slightly different compatibility questions here:
- Is this target/drafter pair conceptually compatible?
- Does this particular LM Studio runtime expose an execution path that can use it?
The second one appears to be the immediate blocker.
The Qwen3.8 MLX checkpoints are VLM-style models. mlx-engine#368 documents that models dispatched through LM Studio’s BatchedVisionModelKit currently hit:
def is_draft_model_compatible(...):
return False
and attempting to load a drafter directly reaches an explicit:
Speculative decoding is not currently supported for batched vision models
The important part is that this happens before a candidate drafter is compared with the target.
So in this particular case:
"No compatible draft models found"
does not necessarily mean:
"The MTP-8bit model you downloaded is incompatible."
It can instead mean:
"This target is currently on an LM Studio MLX path that does not
offer speculative decoding at all."
That is why I would investigate #368 before trying several other draft checkpoints.
This is also a useful exception to LM Studio’s otherwise reasonable generic speculative-decoding guidance, which suggests finding a smaller compatible model when the draft-model list is empty. That advice makes sense when candidate compatibility is actually being evaluated; #368 describes a case where the target is rejected earlier.
I cannot see the live model-kit object inside your LM Studio instance, so I would call this a very close match rather than a confirmed diagnosis.
About the Qwen3.8 MTP-8bit model you downloaded
The Qwen3.8-27B-MTP-8bit card describes it as:
- MTP drafter weights split from
Qwen/Qwen3.8-27B
qwen3_5_mtp- about 0.4B parameters
- MLX affine 8-bit
- intended for
mlx-vlm
- not a standalone model
It also explains an important difference from an ordinary small independent draft LLM: the MTP sidecar relies on the target for things such as the token embeddings and language-model head.
The card’s own example is essentially:
mlx_vlm generate \
--model mlx-community/Qwen3.8-27B-8bit \
--draft-model mlx-community/Qwen3.8-27B-MTP-8bit \
--prompt "Write a quicksort in Python." \
--max-tokens 256 \
--enable-thinking
and mlx-vlm can identify qwen3_5_mtp as an MTP drafter automatically.
So if your main model is that matching 8-bit Qwen3.8 checkpoint, the drafter choice itself looks quite reasonable.
If your target is a different quantization or a derivative checkpoint, I would preserve the same general rule from the card: use a drafter and target derived from the same compatible Qwen3.8 source family rather than mixing models arbitrarily.
There is also a separate LM Studio issue, #371, about draft-only Qwen MTP repositories being indexed as though they were ordinary runnable models. That is not the same failure you are seeing, but it is another reason to keep “base model” and “MTP sidecar” conceptually separate.
Why simply forcing the draft model may not be enough
I would be cautious about workarounds that only bypass the UI compatibility test.
For Qwen3.8 MTP, “LM Studio accepts the path” and “LM Studio actually performs correct MTP speculative decoding” are two different things.
Current mlx-vlm has explicit machinery for the target/drafter interaction: target hidden-state verification, shared/cache state, accepted/rejected drafts, and rollback of speculative state. #368 specifically notes that merely changing the compatibility flag would not wire those semantics into LM Studio’s existing batched generation loop.
There is also mlx-engine#370, concerning another part of MLX-side MTP support: checkpoints containing built-in MTP/nextn heads. That is not exactly your external sidecar case, but it shows why “MTP support” is not one single on/off feature.
So I would avoid things like editing metadata purely to make the dropdown accept the model. It could get you past discovery without actually giving you a working speculative path.
If you want to test this exact target + MTP pair outside LM Studio
A small direct mlx-vlm A/B test would be a useful control because it answers a much narrower question:
Does a current runtime that explicitly implements Qwen3.8 MTP run this exact target/drafter pair?
mlx-vlm is moving fairly quickly; the current release is v0.7.2, so I would not assume that its current behavior is identical to whatever version is bundled behind an LM Studio MLX runtime.
If your target is the matching community 8-bit checkpoint, the model-card command above is already a good starting point.
For a useful comparison I would keep everything else fixed:
A: target only
B: same target + MTP drafter
same prompt
same context
same thinking setting
same sampling
same stopping/max-token policy
Then compare at least:
decode tok/s
generated tokens
draft rounds
draft tokens proposed
draft tokens accepted
Current mlx-vlm documentation exposes draft counters including:
draft_kind
draft_rounds
draft_n
draft_n_accepted
That makes this more informative than simply asking whether the command starts.
The interpretation I would use is roughly:
drafter cannot load/run
-> pairing/runtime contract still needs investigation
drafter runs but acceptance is near zero
-> pairing / artifact / verification problem is plausible
acceptance is good but tok/s does not improve
-> drafter + verification overhead is eating the gain
acceptance is good and tok/s improves
-> speculative decoding is helping this workload
One subtle point: high acceptance by itself is not enough. The extra draft work still costs time, so the final metric should remain actual end-to-end decode performance.
If your real goal is just more speed in LM Studio
There are at least two other branches worth knowing about.
1. Splash
LM Studio 0.4.25 added the Splash engine on Apple Silicon.
The published requirements are:
- M3 or newer
- macOS 26.4 or newer
- at least 36 GB unified memory
Your M5 Max / 128 GB obviously clears the hardware side; the remaining condition is your macOS version.
One important detail: I would think of Splash as a separate Qwen3.8 model/runtime path, not as a switch you turn on for the MLX checkpoint you already downloaded.
LM Studio’s instructions use a Splash-specific model such as:
incoai/Qwen3.8-27B-Splash
and Splash has its own Qwen3.8-specific optimization plus a dedicated DFlash 2 speculative drafter.
LM Studio/Inco publish impressive benchmark numbers for it, but I would not map those numbers directly onto your setup because context length, prompt, model format, engine, and measurement conditions differ.
If you simply want a low-friction “can this Mac run Qwen3.8 faster?” comparison, however, this seems like a very relevant branch.
2. GGUF / llama.cpp
LM Studio 0.4.22 added support on its llama.cpp path for:
- MTP assistant drafters
- DFlash assistant drafters
- DSpark assistant drafters
and later releases improved some of the compatibility heuristics.
That gives you another supported way of pursuing the same goal if switching from MLX to GGUF is acceptable.
I would treat it as a comparison rather than assuming GGUF is inherently faster than MLX on an M5 Max. Different engines can win under different model/context/speculation configurations.
About your current 15-17 tok/s
I do not think there is enough information in the post to call 15-17 tok/s abnormal by itself.
The two biggest missing variables are:
exact Qwen3.8 checkpoint / quantization
typical context length
plus things such as thinking/sampling settings.
For example, an 8-bit 27B target has a very different memory-bandwidth profile from a 4-bit target, and decode speed can also fall as context grows.
So I would separate:
"Can I enable speculative decoding?"
from:
"Is my baseline unexpectedly slow?"
If your target is 8-bit, 15-17 tok/s does not immediately look implausible for this class of model on an M5 Max. If it is 4-bit and you are measuring short-context decoding, then the exact runtime/settings would be more interesting.
I would therefore establish the exact target repo/quantization before spending time tuning the drafter.
Version note for anyone finding this later
There are several layers here that are easy to accidentally treat as one thing:
LM Studio application version
LM Studio MLX runtime version
lmstudio-ai/mlx-engine source
the mlx-vlm version bundled/pinned by that runtime
current upstream mlx-vlm
model artifact revision
They can move independently.
As of this writing:
- your reported LM Studio version is
0.4.25+1
- your reported MLX runtime is
1.11.0
mlx-engine#368, #370, and #371 are still open- the public
mlx-engine source still rejects draft loading on the batched-vision path
- current upstream
mlx-vlm is already at 0.7.2
So a report that “Qwen3.8 MTP works in current mlx-vlm” and a report that “LM Studio MLX 1.11.0 does not offer the drafter” can both be true.
That version boundary is probably the most useful thing to preserve when comparing future reports.
In short, I would keep the MTP model you found and separate the runtime question from the model-pair question before downloading more drafters.
For the lowest-effort path:
- Check
mlx-engine#368 against what you are seeing.
- If you specifically want Qwen3.8 MTP, use direct current
mlx-vlm as the clean control.
- If the real goal is simply faster Qwen3.8 in LM Studio, compare the Splash branch if your macOS version qualifies, or the GGUF/llama.cpp assistant-drafter branch if changing format is acceptable.
- Judge speculative decoding by actual tok/s plus draft acceptance, not by the fact that a drafter loaded successfully.
Also, LM Studio’s own speculative-decoding documentation explicitly notes that a drafter can make generation slower if its proposals are not good enough or the draft overhead is too high, so there is no need to force speculative decoding if one of the other runtime paths already gives you the performance you want.