Qwen3.6-27B-Fable-Fusion-711-Heretic2 — GGUF
GGUF quants of Assiduous42/Qwen3.6-27B-Fable-Fusion-711-Heretic2 — a terminal Heretic ablation of DavidAU's Fable-Fusion-711, targeted at creative-writing refusals rather than AdvBench-style harm refusals.
See the source repo for method, prompt-set design, and honest caveats on the refusal numbers.
Files
| file | size | notes |
|---|---|---|
FF-Heretic2-Q4_K_S.gguf | 15.59 GB | tested; fits 98k ctx on 24 GB with Q4_0 KV |
FF-Heretic2-Q4_K_M.gguf | 16.55 GB | |
FF-Heretic2-Q5_K_M.gguf | 19.23 GB | |
mmproj-F16.gguf | 0.93 GB | vision projector, from the base model (unmodified by the ablation) |
No Q5_1 tensors in any quant — see the note at the bottom on why that matters.
Measured on a single RTX 4090 (24 GB)
FF-Heretic2-Q4_K_S in LM Studio, 98304 context, Q4_0 K and V cache:
| load time | 9 s |
| VRAM | 20311 MiB (18585 MiB model + KV) |
| headroom | 3828 MiB free |
| generation | ~29.5 tok/s |
⚠️ Patched metadata — read this if you compare against the original
The base model is a -MTP build carrying an extra multi-token-prediction layer
(blk.64). transformers does not model that head, so it was dropped during
the LoRA merge — these weights have 64 layers, not 65.
The converter still read nextn_predict_layers: 1 and wrote block_count: 65,
producing files that failed to load with:
check_tensor_dims: tensor 'blk.64.attn_norm.weight' not found
Both keys were corrected in-place in every quant here:
| key | original | patched |
|---|---|---|
qwen35.block_count | 65 | 64 |
qwen35.nextn_predict_layers | 1 | 0 |
Both are UINT32, so this is a same-width byte write with no offset changes — the tensor data is untouched.
Consequence: MTP speculative decoding is not available. If you were getting "draft tokens accepted" percentages from the original, you will not here.
A note on Q5_1
Worth checking on any GGUF before you trust it: if a quant contains Q5_1
tensors in the MoE/expert path, llama.cpp may fall back to CPU for those matmuls
and the model will load almost entirely into system RAM despite ample free VRAM —
silently, with no error. Symptoms are ~100% reported GPU utilisation at very low
power draw.
You can check the tensor-type histogram from the GGUF header alone, without downloading the whole file, using an HTTP range request for the first few MB.
These quants are clean:
Q4_K 485, F32 353, Q5_K 12, Q6_K 1
Suggested settings
- Context 98304 with
Q4_0K/V cache fits comfortably on 24 GB at Q4_K_S. - This is a thinking model. Short
max_tokenswill be consumed entirely by the reasoning channel and you will get empty content. Either allow 600+ tokens, or disable thinking:chat_template_kwargs: {"enable_thinking": false}
License
Apache 2.0, inherited. Derivative work.