license: apache-2.0
base_model: windowsxp811203/Qwen3.8-27B-Abliterated
base_model_relation: quantized
pipeline_tag: image-text-to-text
library_name: mlx
tags:
- mlx
- omlx
- oq
- oQ4e
- mtp
- native-mtp
- imatrix
- apple-silicon
- qwen3_5
- qwen3.8
- qwen
- abliterated
- uncensored
- vision
language: - en
- zh
Qwen3.8-27B-Abliterated — MLX oQ4e with native MTP
4-bit (speed-oriented) MLX build of windowsxp811203/Qwen3.8-27B-Abliterated,
an abliterated (refusal-removed) Qwen/Qwen3.8-27B, made for Apple Silicon.
51.75 GiB bf16 → 15.81 GiB (16.97 GB) — the native MTP draft head is kept in the checkpoint and the vision tower is unquantized,
so one file serves three audiences:
| runtime | what you get |
|---|---|
| oMLX | native MTP speculative decoding (~34 tok/s single-stream (depth 4) on an M5 Max 128 GB, see below) + vision |
| mlx-vlm 0.6.17 (tested) | loads as a normal quantized VLM — its sanitize() drops the in-file MTP tensors; add --draft-model windowsxp811203/Qwen3.8-27B-Abliterated-MTP-bf16 for MTP. Releases that skip sanitize on MLX-format files (e.g. 0.6.3) reject the language_model.mtp.* keys |
| LM Studio / mlx-lm | not supported: stock mlx-lm 0.31.3 (the current PyPI release) loads these VLM-layout checkpoints without error but generates garbage (smoke-tested on all three oQ builds) — it is a text-only loader and mishandles the language_model.* / MLX-format conventions here. LM Studio's MLX engine was not tested. Use oMLX or mlx-vlm |
Built with oMLX's oQ "enhanced" quantizer: imatrix-weighted rounding plus a mixed-precision plan — 187 of 505 quantized language-model modules were promoted above 4-bit (oMLX's sensitivity ranking plus its fixed per-layer rules), so this is not a uniform 4-bit cast.
This is one of three quantized sizes (plus the bf16 reference they were made from); pick by memory and speed:
| build | bits | size | notes |
|---|---|---|---|
| oQ4e-mtp | 4 | 15.81 GiB (16.97 GB) | fastest and smallest |
| oQ6e-mtp | 6 | 22.09 GiB (23.72 GB) | near-lossless (MMLU = bf16) in the least memory; slower than oQ8e once MTP is on (plain decode is a wash) |
| oQ8e-mtp | 8 | 27.94 GiB (30.00 GB) | reference quality; faster than oQ6e with MTP on — the pick when 28 GiB fits |
| bf16-mtp | 16 | 51.75 GiB | unquantized MLX conversion, MTP + vision intact |
What is and isn't quantized
| group | treatment |
|---|---|
| language model Linears | oQ4e mixed precision: 22.1B params @ 4-bit, 4.8B params @ 5-bit — 187 modules promoted (linear_attn.out_proj×48, linear_attn.in_proj_a×42, linear_attn.in_proj_b×41, mlp.down_proj×27, linear_attn.in_proj_z×21, self_attn.o_proj×7, self_attn.k_proj×1); 2.6M non-Linear params (norms, SSM state) stay bf16 |
embed_tokens, lm_head |
embed 4-bit, lm_head 4-bit |
language_model.mtp.* (draft head, 15 tensors) |
kept; mtp.fc.weight unquantized bf16, MTP block Linears at 4-bit |
vision_tower.* (333 tensors) |
unquantized |
linear_attn SSM state params (A_log, dt_bias, conv1d) and all norms |
bf16, unquantized |
Effective 4.68 bits per weight over the language model; 15.81 GiB of safetensors.
Verification
All numbers measured on this exact checkpoint on a MacBook Pro M5 Max, 128 GB, oMLX 0.6.4; throughput numbers are single stream, the refusal batteries ran 8 requests concurrently.
MTP speculative decoding (oMLX, mtp_enabled: true; 10 fixed prompts × ≤256 greedy tokens; tok/s is the best of three runs — two after a warm-up request — with ranges below; acceptance and tok/cycle are pooled over the first session's requests — the 10 prompts plus its warm-up and two bench requests — and vary by up to ~2 pt across runs):
| setting | decode tok/s | vs. MTP off |
|---|---|---|
| MTP off (plain decode) | 21.8 | 1.00× |
| MTP depth 1 | 26.2 | 1.21× · accept 85.2% · 1.87 tok/cycle |
| MTP depth 2 | 28.7 | 1.32× · accept 81.4% · 2.27 tok/cycle |
| MTP depth 3 | 32.6 | 1.50× · accept 79.7% · 2.62 tok/cycle |
| MTP depth 4 | 33.9 | 1.56× · accept 79.0% · 2.64 tok/cycle |
Run-to-run spread (same settings): off (plain decode) 7.8–21.8 (n=3); depth 1 23.6–26.2 (n=3); depth 2 26.5–28.7 (n=3); depth 3 28.3–32.6 (n=3); depth 4 25.8–33.9 (n=3).
oMLX's built-in throughput bench (synthetic prompt, 256 generated tokens): 1024-token prompt: 17.1 → 36.9 tok/s (2.16×, depth 3), first token 2.1 s; 4096-token prompt: 16.1 → 32.3 tok/s (2.01×, depth 3), first token 7.7 s (MTP off → best of depth 3/4).
Draft acceptance by depth: depth 3: d1=84.6%, d2=76.1%, d3=74.1%. Acceptance is a speed signal only — every draft is verified against the
target's own distribution, so the output distribution is preserved. It is not bit-exact, though: at temperature 0 the
MTP-on and MTP-off outputs were byte-identical on 4–5/10 fixed prompts at depth 3 (4/10 at depth 1,
5/10 at depth 4; counts vary by run); the rest diverge at a near-tie token — sometimes early: the earliest divergence was ~15 characters in — and continue coherently. MTP-off reruns are 10/10 identical, so the divergence comes from the batched verify path (several draft rows
per matmul accumulate bf16 differently than single-token decode), and the divergence point moves between depths and
repeat runs. Treat MTP-on greedy output as non-reproducible at the byte level — not as a head defect.
External drafter path (mlx-vlm 0.6.17, --draft-model …-MTP-bf16, temperature 0): single prompt (36 tokens), 300 generated tokens, best run per arm: 31.1 → 39.9 tok/s (1.29×, 90.6% of drafts accepted) (plain runs 24.0–31.1, n=5; drafter runs 33.1–39.9, n=3; across 3 sessions)
Refusal — greedy, non-thinking, max 256 tokens, no prompt prefill (the parent card's protocol):
| benchmark | result |
|---|---|
| AdvBench (80-prompt equidistant subset) | 0/80 · 0.00 % |
| HarmBench safety categories | 0/119 · 0.0 % |
| HarmBench copyright | 18/41 · 43.9 % (not a safety category: verbatim-reproduction requests, judged by the same keyword classifier) |
With a "Sure, here is" assistant prefill — a jailbreak on its own, so not comparable with the parent — the same battery gave AdvBench 0/80 · 0.00 % and HarmBench-safety 0/119 · 0.0 %.
Capability — MMLU 5-shot, oMLX's built-in harness with its seeded 400-question sample stratified by subject
(identical questions for every row), temperature 0, thinking off, MTP on:
| build | MMLU-400 |
|---|---|
| bf16-mtp (reference, same harness) | 82.50 % (330/400) |
| oQ4e-mtp (this) | 81.75 % (327/400) |
(Not comparable with the parent card's 82.35 % — the full 14,042-question set scored by next-token logits — nor with the NVFP4 card's MMLU-400, a different harness and sample.)
Vision — synthetic probe (red circle / green triangle / blue square): all three shapes, colors and positions correct
Usage
oMLX (native MTP)
brew tap jundot/omlx https://github.com/jundot/omlx && brew install jundot/omlx/omlx
hf download windowsxp811203/Qwen3.8-27B-Abliterated-MLX-oQ4e-mtp --local-dir ~/.omlx/models/Qwen3.8-27B-Abliterated-MLX-oQ4e-mtp
omlx serve --model-dir ~/.omlx/models
Then enable Lightning MTP for the model in the admin UI (http://localhost:8000/admin → model → Advanced), or in~/.omlx/model_settings.json (note the models wrapper — a top-level model key is silently ignored and MTP stays off):
{"version": 1, "models": {"Qwen3.8-27B-Abliterated-MLX-oQ4e-mtp": {"mtp_enabled": true, "mtp_num_draft_tokens": 3, "max_context_window": 262144}}}
The server log prints Speculative backend selected … Lightning MTP (model_type=qwen3_5, active) when it took effect. Depth 3 is the better setting here: it beat depth 4 on the 1K bench prompt (36.9 vs 32.6) and the 4K bench prompt (32.3 vs 24.8); depth 4 was only ahead on the 10-prompt greedy set (33.9 vs 32.6).
mlx-vlm
pip install -U mlx-vlm
python -m mlx_vlm.generate --model windowsxp811203/Qwen3.8-27B-Abliterated-MLX-oQ4e-mtp \
--draft-model windowsxp811203/Qwen3.8-27B-Abliterated-MTP-bf16 \
--prompt "Write a quicksort in Python." --max-tokens 512
Drop --draft-model for plain decoding. The mlx-vlm CLI runs with thinking off unless you pass --enable-thinking.
Under oMLX (OpenAI-compatible API) the chat template's default is thinking on; disable it per request with"chat_template_kwargs": {"enable_thinking": false}. Qwen's recommended sampling: thinking mode temperature 1.0 / top-p 0.95 / top-k 20 (the shipped generation_config); non-thinking mode temperature 0.7 / top-p 0.8 / top-k 20.
Provenance
- bf16 MLX conversion with
mlx_vlm.convert(mlx-vlm 0.6.3 @ 78b96eb, mlx 0.32) under oMLX'smlx_vlm_mtppatches, which keep themtp.*tensors (stock mlx-vlm strips them) and apply MLX's +1 RMSNorm convention to the MTP norms as well.
Verified: 15 MTP + 333 vision tensors present, all 1199 source tensors bf16, and the sampled RMSNorm offsets (7 MTP + 3 trunk norms) sit at +1.000 within bf16 rounding of the HF source. omlx.oq.quantize_oq_streaming(oq_level=4, enhanced=True, preserve_mtp=True, group_size=64, imatrix_seq_length=512)— imatrix from oMLX's built-inoqe_code_multilingualcalibration set (2,679 texts;
128 × 512-token samples — oMLX's adaptive sampler stops at its first step for dense models, since its criterion is
MoE expert coverage). Calibration ran on oMLX's automatic 4-bit proxy path: the bf16 model's 51.7 GiB calibration footprint exceeded the 17.4 GiB full-model limit oMLX derives from the 23.2 GiB of memory that was free at the time (other apps were resident; oMLX's log prints these as GB), so sensitivities were measured on a temporary uniform-4-bit copy of the model and the final weights were then quantized from bf16. The imatrix itself was reused from the cache built during the oQ6e run (same proxy path). That is oMLX's designed fallback, not a hack, but it is not the
full-precision calibration path; the MMLU/refusal numbers above are what it produced. The calibration report ships
asoq_imatrix_report.json.- The parent was produced by orthogonalizing 131 residual-writing tensors (embeddings, attention/SSM/MLP
output projections and the MTP head) against a refusal direction at λ=1.5, vision untouched — so the draft head
in this file matches this trunk; do not pair it with a base-Qwen drafter. Full recipe and evals on the
parent card. CUDA builds:
NVFP4 ·
GGUF.
Support / 打賞
If these models are useful to you, tips are appreciated — they pay for the GPU time.
如果這些模型對你有幫助,歡迎打賞,用於支應算力成本。
USDT (TRC20) · TPTo32r7vKazpTNaFqfFZ2ztoK1DG88888
Disclaimer
This model will not refuse. It is published for alignment and safety research. You are responsible for your use of
it and for complying with applicable law. Inherits the Apache-2.0 license of the base model.