Research and creative work with Fable-Fusion-711 on Apple Silicon, including MTP decoding and image input.
What did I contribute?
Philip John Basile's Q8_0 reconstruction, 6-bit MLX packaging, MTP calibration, and evaluation work. DavidAU created the tune; Qwen created the base; MTPLX provides conversion/runtime tooling.
What runs it?
MTPLX for the calibrated BF16 MTP sidecar and vision. MLX-LM provides ordinary autoregressive generation without activating the sidecar.
What was tested?
The card records M5 Max 128 GB measurements with MTPLX 2.6.0 and MLX 0.32.0, plus earlier versioned receipts. Results are specific to the recorded prompts, modes, and conditions.
How much memory?
About 23.6 GB of weights. This is not a peak-RAM figure or a guarantee that the model fits a 24 GB Mac; runtime and KV-cache memory are additional. The recorded machine had 128 GB.
What are the limits?
The source name's refusal claim did not reproduce. Small coding/math checks and one-machine throughput receipts are not general quality or universal speed guarantees.
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.
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.
Mode
Decode throughput across 3 trials
Trial completion
Conditions captured with trials
Autoregressive
21.69–22.48 tok/s
3/3 reached 256 tokens
load1 3.39–3.62; nominal
MTP depth 1
36.77–38.83 tok/s
3/3 reached 256 tokens
load1 2.87–3.51; nominal
MTP depth 2
45.36–46.50 tok/s
3/3 reached 256 tokens
load1 2.74–2.89; nominal
MTP depth 3
52.00–52.70 tok/s
3/3 reached 256 tokens
load1 2.60–2.66; nominal
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.
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.
Mode
tune 2.6.0
direct probe 2.6.0 (3-trial median)
HTTP serve 2.6.0
2.3.0 receipt (Jul 30, for reference)
Autoregressive
20.98
19.2
19.6
21.69–22.48
MTP depth 1
35.5
32.9
—
36.77–38.83
MTP depth 2
41.2
37.1
40.4
45.36–46.50
MTP depth 3
47.5
38.4
—
52.00–52.70
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].
Mode
Position 1
Position 2
Position 3
D1
94.76% (362/382) [93.94–95.80%]
—
—
D2
95.51% (255/267) [94.57–96.47%]
83.90% (224/267) [78.82–88.89%]
—
D3
93.49% (201/215) [93.06–94.29%]
85.05% (182/214) [82.86–88.89%]
74.77% (160/214) [72.22–76.39%]
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:
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
Check
Result
AIME quick bench (5 problems)
5/5
Executable coding eval (8 tasks, tests run)
8/8
Perplexity — wikitext-2, ctx 2048
5.7358
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.
ctx
PP tok/s AR → D2
TG tok/s AR → D2
TTFT AR → D2
4k (3,957 tok)
270 → 275
7.7 → 6.9
15s → 14s
32k (31,674 tok)
358 → 412
6.6 → 13.7
89s → 77s
64k (63,349 tok)
301 → 497
6.7 → 12.3
210s → 127s
131k (126,702 tok)
191 → 272
5.9 → 6.9
663s → 466s
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).
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:
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.
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.
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.
