⚠️ 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

# oMLX — MTP off (recommended for this model)
omlx serve --model underlotus/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-oQ4e-mtp

# To test Lightning MTP anyway (expect *slower* generation, see above)
omlx serve --model underlotus/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-oQ4e-mtp \
  --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.

Downloads last month
580
Safetensors
Model size
36B params
Tensor type
U32
·
BF16
·
MLX
Hardware compatibility
Log In to add your hardware

4-bit

Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Model tree for underlotus/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-oQ4e-mtp