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

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

Explore the model guide · All public work

Start here

Quick start — MTPLX

mtplx pull philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-6bit
mtplx serve --model philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-6bit

The complete measurement conditions, behavioral corrections, source reconstruction, and license details follow.

MLX 6-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. 23.6 GB.

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 did not characterize run-to-run or path-dependent variation. A much lower correction posted on 2026-07-27 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. Each range contains three measured trials; it is an observed range, not a confidence interval or a universal performance guarantee.

The three trials were internally tight, but three seeds do not characterize every possible MTPLX runtime path. Prompt context copy was left at its default, and this first probe did not capture its separate counters. These ranges are therefore narrow receipts for seeds 0–2, not evidence that a copy-heavy path can never occur on another sample.

Measurement revision 2026-08-11 — MTPLX 2.6.0, mlx 0.32.0

Re-measured on the same M5 Max (128 GB) with three independent harnesses now that MTPLX 2.6.0 has landed: mtplx tune (tool-native), the direct probe below, and plain HTTP serving (mtplx serve, OpenAI shape, 256 tokens, non-streaming). All three now agree within ~10% per mode. The earlier ~2x spread between serving-path and direct-probe absolutes no longer reproduces and is withdrawn, together with the draft-era serving figures that implied it; the withdrawl note above was correct and is now explained, not just suspected.

Draft acceptance on 2.6.0 (direct probe, pooled ratios): D2 93.8% / 85.6%; D3 94.3% / 83.3% / 69.7%. Third-position acceptance is lower than the 2.3.0 receipt (74.8%), which accounts for part of D3's shortfall; the rest is unexplained and not claimed.

Conditions: fans pinned at tune; direct-probe load1 4.5–4.8 (above the 2.3.0 receipt's 2.6–3.6 band — direction of any load effect is favorable to the older receipt); thermal state nominal; macOS 27.0; mlx 0.32.0; MTPLX 2.6.0.

Primary evidence receipts for this revision: remeasure_260_tune.json (sha256 1e559704…) and remeasure_260_probe.json (sha256 edb2c7b5…), plus the serve logs (remeasure_260_serve_ar.log, remeasure_260_serve_d2.log). Serving numbers are single requests, not trials.

The MTPLX 2.6.0 changelog's serial-sampling decode-speed recovery and temperature-0 exactness fixes are the plausible cause of the serving-path convergence; no attribution is asserted.

Draft acceptance

These are ordinary-MTP positional accepted/drafted ratios, pooled over the three trials. They exclude any prompt-context-copy tokens. Each entry is pooled ratio (accepted/drafted) [minimum–maximum per trial].

Exact measurement scope

The measurement tool was the local probe_fable711_mtp_independent.py harness, not mtplx tune. It calls mtplx.generation.generate_ar and generate_mtpk directly with this artifact's hashed MTP runtime contract. The recorded command shape was:

python probe_fable711_mtp_independent.py <model-path> \
  --label 6bit \
  --max-tokens 256 \
  --warmup-tokens 24 \
  --repetitions 3 \
  --bridge-pid 35920 \
  --out fable711_independent_6bit.json

Held fixed: the single long_code_uncapped prompt; chat template with thinking disabled; seeds 0, 1, and 2; temperature 0.6, top-p 0.95, top-k 20; 24-token warmup per mode; 256 measured tokens per trial; performance-cold; persistent MTP cache; committed MTP history; capture_commit; and linear-gdn-from-conv-tape. Modes ran serially in one model process.

The 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 2.60–3.62; thermal state was nominal throughout; and no known competing GPU benchmark was detected. Fan RPM was not determinable, and actual per-process GPU attribution was not determinable without privileged telemetry.

A separate completed single-run mtplx tune receipt used a 512-token cap and reported AR/D1/D2/D3 of 21.70/37.79/47.15/56.19 tok/s. It is not pooled into the table because its orchestration, seed count, and run length differ; in particular, its D3 result lies outside the three-trial direct-probe range. No reconciliation between those harnesses is asserted.

Primary evidence receipts: fable711_independent_throughput_protocol.json, fable711_independent_6bit.json, fable711_independent_throughput_comparison.json, and tune_MTPLX-6bit_clean.json. Their SHA-256 values begin, respectively, 4e9c4134…, a97d9655…, 6862553f…, and ca223937…; the independent-run validator passed 38/38 checks.

Other measured checks

Separate long-context receipt

The following streaming measurements predate the independent short-decode probe above and were not remeasured by it. Prefill and decode were timed separately on prose prompts.

PP corrected 2026-07-30. Prefill figures were originally derived from the labelled context length; the prompts contain about 3.3% fewer tokens than labelled, so published PP was about 3.3% too high. Actual token counts are now shown in the ctx column. TTFT and TG are unchanged wall-clock measurements.

Depth 2 was the practical sweet spot in that long-context receipt; depth 1 and 3 measured 8.7 and 9.2 tok/s at 32k. Time-to-first-token at 131k is 8–11 minutes — if your workload is long-prompt/short-answer, prefill dominates and TG is close to irrelevant.

Perplexity context, same harness throughout: the bf16 reconstruction measures 5.7525, so this quantization costs -0.0167 — inside the ±0.034 measurement uncertainty, i.e. indistinguishable from bf16. 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-6bit      # native MTP speculative decoding + vision
mtplx serve --model philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-6bit

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-6bit --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.