Instructions to use philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- MLX
How to use philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit with MLX:
# Make sure mlx-vlm is installed # pip install --upgrade mlx-vlm from mlx_vlm import load, generate from mlx_vlm.prompt_utils import apply_chat_template from mlx_vlm.utils import load_config # Load the model model, processor = load("philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit") config = load_config("philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit") # Prepare input image = ["http://images.cocodataset.org/val2017/000000039769.jpg"] prompt = "Describe this image." # Apply chat template formatted_prompt = apply_chat_template( processor, config, prompt, num_images=1 ) # Generate output output = generate(model, processor, formatted_prompt, image) print(output) - Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- LM Studio
- Pi
How to use philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit with Pi:
Start the MLX server
# Install MLX LM: uv tool install mlx-lm # Start a local OpenAI-compatible server: mlx_lm.server --model "philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit"
Configure the model in Pi
# Install Pi: npm install -g @mariozechner/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "mlx-lm": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit" } ] } } }Run Pi
# Start Pi in your project directory: pi
- Hermes Agent
How to use philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit with Hermes Agent:
Start the MLX server
# Install MLX LM: uv tool install mlx-lm # Start a local OpenAI-compatible server: mlx_lm.server --model "philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit"
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit
Run Hermes
hermes
- Atomic Chat
- OpenClaw
How to use philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit with OpenClaw:
Start the MLX server
# Install MLX LM: uv tool install mlx-lm # Start a local OpenAI-compatible server: mlx_lm.server --model "philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit"
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit" \ --custom-provider-id mlx-lm \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
Fable-Fusion-711 27B — MTPLX 4-bit (native MTP + vision)
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. 16 GB.
This is the first MLX conversion of Fable-Fusion in any form.
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:
| Mode | Low cluster: mean; range (trials) | High cluster: mean; range (trials) | Observed high-cluster frequency | MTP-only control, context copy off: mean; range (trials) |
|---|---|---|---|---|
| D1 | 51.17; 48.06–62.59 tok/s (18) | 79.23; 68.71–82.49 tok/s (12) | 12/30 = 40.0% | 49.36; 47.82–51.04 tok/s (10) |
| D2 | 58.88; 56.40–62.00 tok/s (18) | 90.69; 79.88–95.92 tok/s (12) | 12/30 = 40.0% | 58.71; 54.82–61.93 tok/s (10) |
| D3 | 66.11; 60.76–77.10 tok/s (19) | 94.12; 81.92–100.79 tok/s (11) | 11/30 = 36.7% | 64.09; 60.85–67.10 tok/s (10) |
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:
| Mode | 1-minute load-average envelope | Thermal states observed |
|---|---|---|
| AR sentinels | 1.92–2.63 | nominal, fair |
| D1, both arms | 1.92–3.53 | nominal, fair |
| D2, both arms | 1.73–3.59 | nominal, fair |
| D3, both arms | 1.62–3.59 | nominal, fair |
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].
| Path | D1 | D2 positions 1/2 | D3 positions 1/2/3 |
|---|---|---|---|
| Default hybrid, 30 trials/depth | 92.76% [85.14–96.64%] | 92.72% [84.44–100.00%] / 81.08% [72.22–89.02%] | 92.86% [84.62–100.00%] / 82.27% [69.23–90.77%] / 69.40% [48.57–84.13%] |
| Context copy disabled, 10 trials/depth | 93.93% [89.63–98.45%] | 93.57% [86.73–98.86%] / 84.84% [73.47–94.25%] | 92.42% [88.31–100.00%] / 85.20% [74.03–92.54%] / 75.28% [67.53–88.06%] |
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
| Check | Result |
|---|---|
| AIME quick bench (5 problems) | 5/5 |
| Executable coding eval (8 tasks, tests run) | 8/8 |
| Perplexity — wikitext-2, ctx 2048 | 5.9499 |
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-Hereticin 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_headsits 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 allmtp.*norms (nextn.enorm/hnorm/shared_head_norm). mlx-lm'sqwen3_5sanitize adds+1itself, so a naive conversion double-shifts. Gatedlinear_attn.normand the vision norms are NOT baked. - Gated-DeltaNet value-head reorder (
_LinearAttentionVReorderBasein llama.cpp'sconversion/qwen.py). V heads move from HF grouped order to ggml tiled order inin_proj_qkv(V rows),in_proj_z,in_proj_a,in_proj_b,A_log,dt_bias,conv1d(V channels), andout_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 withlog(-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.
- Downloads last month
- 2,707
4-bit
Model tree for philipjohnbasile/Qwen3.6-27B-Fable-Fusion-711-MTPLX-4bit
Base model
Qwen/Qwen3.6-27B