⚠️ Read this before downloading: enabling Lightning MTP makes this model slower
Mixed-precision quant of
llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved, produced with
oQ (oMLX v0.6.1). The MTP head is preserved so Lightning MTP can be enabled —
but on this model, enabling it actually reduces generation speed instead of improving it.
TL;DR: If you don't need to test MTP on this specific model, don't download it. It's slower with Lightning MTP on, and no faster than other oQ4e quants with it off.
The MTP problem — measured, not guessed
Two oMLX benchmark runs on the same machine (M4 10-core, 32 GB), identical settings except mtp_enabled:
| Setting | 1k TG tok/s | 4k TG tok/s | TTFT (4k) | Peak mem (4k) |
|---|
Lightning MTP on (mtp_enabled: true) | 41.2 | 35.1 | 8,879 ms | 22.1 GB |
MTP off (mtp_enabled: false) | 39.2 | 37.6 | 8,817 ms | 20.7 GB |
At 1k context, MTP on wins by ~2 tok/s; at 4k context, MTP off is ~7% faster and uses ~1.4 GB less memory. In real use (longer contexts), MTP on is the slower option.
This is not unique to this quant: the exact same regression is documented upstream in
jundot/omlx#2150 — on Qwen3.6-35B-A3B (MoE), Lightning MTP is
8–12% slower than the old fixed depth-1 MTP at every context length tested. The depth-k draft controller's cost model was tuned for dense backbones, and each extra verify token in this fine-grained MoE (256 experts) pulls a nearly disjoint routed-expert set — so the extra verification work isn't amortized. The issue also notes Lightning MTP is completely inactive during continuous batching (2×/4×), so batching speedups in the benchmark UI reflect plain batching, not MTP.
What this model is
This is an oQ4e (mixed-precision, ~4.6 bits-per-weight) MLX quant of the Heretic-abliterated Qwen3.6-35B-A3B with all 19 MTP tensors preserved — the first MTP-preserved MLX version of this model line, so anyone who wants to test Lightning MTP behavior on Qwen3.5/3.6 MoE can do so.
- Base: Qwen/Qwen3.6-35B-A3B — 35B total / 3B activated, 256 experts (8 routed + 1 shared), 262k native context
- Uncensored: Heretic v1.3.0 + MPOA abliteration — 10/100 refusals vs 83/100 original, KL divergence 0.0015
- MTP: All 19 MTP tensors intact (
mtp.layers.*, mtp.fc, mtp.norm, …)
- Vision: Qwen3.6 VL tower intact — image + video input works (needs
vlm_mtp_enabled for MTP on vision)
What is oQ?
Unlike uniform 4-bit quantization,
oQ is a data-driven mixed-precision quantizer that calibrates per-layer sensitivity and allocates bits where they matter most. Critical layers (embeddings, LM head, the most sensitive transformer layers) are automatically promoted to 8-bit, while less sensitive layers stay at 4-bit. Typical result: ~4.6 bits-per-weight.
Benchmarked on Qwen3.5-35B-A3B (oMLX project):
| Benchmark | mlx-lm 4-bit | oQ4 |
|---|
| MMLU (300) | 79.7% | 83.3% |
| TruthfulQA (300) | 87.7% | 88.0% |
| HumanEval (full) | 87.2% | 85.4% |
| MBPP (300) | 71.7% | 74.3% |
Quick start
1# oMLX — MTP off (recommended for this model)
2omlx serve --model underlotus/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-oQ4e-mtp
3
4# To test Lightning MTP anyway (expect *slower* generation, see above)
5omlx serve --model underlotus/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-oQ4e-mtp \
6 --set mtp_enabled=true
Feedback welcome
If you measure Lightning MTP behavior on this model on different hardware (M3 Ultra, M4 Max, M5…) or a newer oMLX build, please post the benchmark link in the
Community Discussion. The upstream issue is
jundot/omlx#2150.
License
Apache 2.0, inherited from base model.
