Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit

Fable-Fusion-711 27B — MTPLX 4-bit (native MTP + vision)

Explore the model guide · All public work

Release at a glance

MLX 4-bit build of DavidAU's Qwen3.6-27B Fable-Fusion-711 tune, packaged as a native MTPLX artifact: working multi-token-prediction head (bf16 sidecar + calibrated runtime contract) for exact speculative decoding, plus the vision tower for image input. Root tensor payload: 16.90 GB (15.74 GiB).

This release reconstructs the source GGUF into an MLX artifact with MTP and vision.

Compare the family: 4-bit · 6-bit · 8-bit · BF16 reconstruction.

Behavioral correction — July 26, 2026

This conversion faithfully reproduces the released Fable-Fusion weights, but those weights do not reproduce the source card's 4/100 refusal claim. On the exact Heretic KeywordRate protocol (same 100 prompts, system prompt, 100-token cap, and 33 substring markers), official Qwen scored 99/100, DavidAU's released Q6_K scored 81/100, and this converted tune scored 79/100. All outputs were non-empty.

KeywordRate is a refusal-marker proxy, not a semantic compliance judge. Accordingly, this repository is no longer described or tagged as uncensored. For the later official-Qwen reduced-refusal artifact, see Qwen3.6-27B-Refusal-Ablation-v2-MTPLX-6bit.

Decode throughput receipt — M5 Max (128 GB)

Measurement revision, 2026-07-30. The earlier single-sample figures were plausible observations, but they under-characterized an output-dependent distribution. A much lower correction posted on 2026-07-28 was itself wrong because that run was load-confounded; it has been withdrawn. The condition-instrumented receipt below supersedes both for this exact protocol.

These are decode rates for one pinned long-code prompt and sampler on one Apple M5 Max. They are not universal rates for the model, every prompt, or every serving stack.

Default MTP is bimodal on this workload

The default MTPLX runtime is a hybrid: it can use ordinary MTP drafting and a separate prompt-context-copy path. The 30-trial sample at each depth split into two clearly separated throughput clusters:

The six same-seed AR sentinels bracketing the expanded run measured 30.35–30.76 tok/s. The before/after token streams were identical for each seed.

Conditions were captured around every value above:

There is deliberately no single “default D1/D2/D3” number here. On these samples, the high cluster coincided with the prompt-context-copy path accepting large blocks: 112–137 copied tokens at D1, 108–137 at D2, and 127–137 at D3. MTPLX matched generated context to prompt history, proposed a prompt block, verified it in one target pass, committed the accepted tokens, and bypassed the corresponding ordinary MTP draft/verify cycles. Disabling context copy removed every high observation.

Small copy events also occurred in the low cluster: context copy accepted at least one token in 25/30 trials at every depth. Therefore 37–40% is the observed frequency of the copy-heavy high-throughput cluster, not the frequency with which context copy did anything. Both frequencies are specific to this prompt, sampler, and seed set.

Draft acceptance

These are ordinary-MTP positional accepted/drafted ratios. They exclude copied prompt tokens, which have separate counters. Each entry is pooled ratio [minimum–maximum per trial].

The high-rate regime is therefore not a second ordinary-MTP acceptance mode; accepted prompt-copy blocks displace ordinary MTP work.

Exact measurement scope

The measurement tool was the local probe_fable711_4bit_mtp_distribution.py harness, which calls mtplx.generation.generate_ar and generate_mtpk directly rather than mtplx tune. The recorded command was:

python probe_fable711_4bit_mtp_distribution.py \
  --bridge-pid 35920 \
  --protocol fable711_4bit_mtp_distribution_protocol_v2.json \
  --out fable711_4bit_mtp_distribution_raw_v2.json

Held fixed: the checkpoint and hashed MTP runtime contract; the single long_code_uncapped prompt; chat template with thinking disabled; temperature 0.6, top-p 0.95, top-k 20; 256-token cap; 24-token warmup per arm/depth; performance-cold; persistent MTP cache; committed MTP history; capture_commit; and linear-gdn-from-conv-tape. Default-runtime seeds were 0–29 at D1/D2/D3; copy-disabled controls were seeds 0–9, interleaved. One default D1 trial stopped normally at 241 tokens in the low cluster; the other 119 MTP trials reached 256 tokens.

The completed run used macOS 27.0, MLX 0.32.0, MTPLX 2.3.0, and Python 3.13.14 on AC power. Conditions were captured immediately before and after every trial: 1-minute load average was 1.62–3.59; no known competing GPU benchmark was detected; and NSProcessInfo.thermalState ranged from nominal to fair. The stable same-seed AR sentinels did not show a coherent system-wide slowdown. Fan RPM was not determinable, and actual per-process GPU attribution was not determinable without privileged telemetry.

Primary evidence receipts: fable711_4bit_mtp_distribution_protocol_v2.json, fable711_4bit_mtp_distribution_raw_v2.json, and fable711_4bit_mtp_distribution_analysis_v2.json. Their SHA-256 values are, respectively, 36eaae0a…, a5bd7db5…, and d170be6c…; the structural validator passed 27/27 checks.

Other measured checks

Perplexity context, same harness throughout: the bf16 reconstruction measures 5.7525, so this quantization costs +0.1974, a real degradation well outside the ±0.034 measurement uncertainty. That is the price of 4-bit; the 6-bit build is indistinguishable from bf16 if you can spare the memory. DavidAU's Q8_0 GGUF measures 5.6635 under llama.cpp's own methodology (different tokenizer/BOS handling, so treat it as a sanity anchor rather than a directly comparable number).

Serving

mtplx pull philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit      # native MTP speculative decoding + vision
mtplx serve --model philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit

It is also a plain MLX checkpoint — mlx_lm will run it autoregressively and ignore the MTP sidecar:

mlx_lm.generate --model philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit --prompt "Hello" --max-tokens 100

What carried over from the source name

• Fable-Fusion-711 / NM are weight-level: this is DavidAU's exact tune, dequantized from his own Q8_0 export. The source repository includes Uncensored-Heretic in its name, but that behavioral claim did not survive the released multi-stage tune/merge.
• MTP is his tune's own head, kept at bf16 — higher precision than the Q8_0 MTP tensors in the GGUF — then forge-calibrated and verified at depths 1–3.
• NEO / MAX do not apply. NEO-Imatrix shapes his sub-8-bit GGUF quants only; the Q8_0 source doesn't use it, so nothing was lost taking this path. MAX (16-bit output tensor) is GGUF packaging — here lm_head sits at body precision.
• Vision works (tower grafted from mmproj-BF16.gguf, verified on real images).

How this was made (and the traps if you try it)

DavidAU published GGUF only, so this was reconstructed from his highest-precision export — the Q8_0 MTP GGUF — by inverting every transform llama.cpp applies when it converts Qwen3.5/3.6. Get any of these wrong and the model degenerates while still passing consistency-style checks:

1. Zero-centered RMSNorm baking. GGUF stores these norms as weight + 1: input/post-attention layernorms, q/k norms, the final norm, and all mtp.* norms (nextn.enorm / hnorm / shared_head_norm). mlx-lm's qwen3_5 sanitize adds +1 itself, so a naive conversion double-shifts. Gated linear_attn.norm and the vision norms are NOT baked.
2. Gated-DeltaNet value-head reorder (_LinearAttentionVReorderBase in llama.cpp's conversion/qwen.py). V heads move from HF grouped order to ggml tiled order in in_proj_qkv (V rows), in_proj_z, in_proj_a, in_proj_b, A_log, dt_bias, conv1d (V channels), and out_proj (columns, not rows). Note the first V head occupies the same offset in both orderings — spot-checks at offset 0 are blind to this bug.
3. ssm_a = -exp(A_log) — recover with log(-x), then apply the reorder.

MTP head mapping: blk.<last>.nextn.{eh_proj,enorm,hnorm,shared_head_norm} → mtp.{fc,pre_fc_norm_embedding,pre_fc_norm_hidden,norm}, and the final block's attention/MLP → mtp.layers.0.*.

Every tensor was shape-checked against Qwen/Qwen3.6-27B and the layout verified by cosine similarity against base values (a finetune leaves many tensors at or near base, so a residual permutation shows up as ~0 correlation). All families landed at 0.99–1.0000 after inversion.

Independently validated. After these builds were published, an F32 copy of the same tune surfaced: nightmedia/Qwen3.6-27B-Architect-Polaris2-Fable-B-F451-F32 (112 GB, mergekit nuslerp). It has the identical structure — 1199 tensors, 15 mtp.*, 333 vision — and this reconstruction matches it at cosine 0.99997 on mtp.fc.weight and 1.00000 on model.language_model.norm.weight. The residual is precisely the Q8_0 step this copy came through, so the inverse transforms above are confirmed correct against a source never used to derive them.

If you want the highest-fidelity starting point for your own quants, prefer that F32 repo over this reconstruction — it never passed through a quantizer.

Credits and license

• DavidAU — the Fable-Fusion-711 tune and the Q8_0 MTP export this is reconstructed from. Please read his model card for the tune's capabilities, sampler guidance, and class notes.
• Qwen — Qwen3.6-27B base.
• MTPLX — forge pipeline and MTP runtime.

Apache-2.0, inherited from the source model.

Intended use

Research and creative work. Do not assume this model is refusal-free; deploy behind your own policy and logging layer.