Qwen3.6-27B-Fable-Fusion-711-MTP-ROCmFPX-GGUF

⚠️ These files do NOT load on standard llama.cpp

They use AMD-native *_ROCMFPX tensor types from the experimental ciru-ai/ROCmFPX llama.cpp fork (build from source). For files that work with stock llama.cpp / LM Studio / Ollama, use the sibling repo: lmcoleman/Qwen3.6-27B-Fable-Fusion-711-MTP-MagicQuant-GGUF.

Derivative of Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-MTP, quantized using MagicQuant hybrid evolutionary per-tensor search and quantized to AMD-native ROCmFPX formats (fork-only) tuned for Strix Halo (gfx1151).

Base Model

This is a derivative of Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-MTP. All credit for the base model architecture and weights goes to the original authors. The base model's license applies to this derivative.

Quantization Method

Quantized using MagicQuant hybrid evolutionary per-tensor quantization, based on the methodology by magiccodingman:

• Tensors are classified into sensitivity groups (Embeddings, Head, Query, Key, Output, FFN Up/Down, MoE Experts, Router)
• An evolutionary search finds the optimal quantization type per group, balancing size vs. perplexity
• Q4/Q5/Q6 tier targets are searched, and each one ships only if it earns its place (see below)
• Small-row tensors and sensitivity-critical layers (embeddings, output head, router) are kept at F32/F16/BF16
• This is NOT a uniform quantization -- each tensor group gets its own optimal type

A tier name here is a size band, not a promise that every tensor uses that exact type. A "Q5" is whatever mix of schemes landed in the Q5 size band with the lowest measured perplexity loss -- which is the point of the search.

Why a tier is missing

• Q6 was not published. ROCmFPX trades some quality for throughput, but this build measured 6.3 tok/s against the MagicQuant Q6's 6.8 -- no speed gain to justify the tradeoff.

This is deliberate. ROCmFPX types exist to trade a little quality for throughput on AMD hardware, so a ROCmFPX tier is only worth publishing when it is measurably faster than the equivalent MagicQuant tier. When it isn't, it would be strictly worse: same size, lower quality, no speed. The Q6 file is not missing by accident, and nothing here is broken.

If you specifically want that size point, open an issue in the Community tab and I'll build it -- the search results are kept, so it's a rebuild rather than a re-search.

Tiers this build does not produce

• Q5 -- rendering MagicQuant's Q5 config into ROCmFPX types predicts 20.68 GiB against a 50.89 GiB BF16 baseline (ratio 0.4063), which is the Q6 band, not Q5. The ROCmFPX family has no type between 4.5 and 6.5 bpw, so a Q5 layout rounds up into Q6 territory and would ship mislabelled.

These were not built at all. This is a property of how the schemes round into the ROCmFPX type ladder for this particular model, not a temporary gap, so a file for them will not appear in a later build either.

ROCmFPX (AMD-native, fork-only)

These GGUFs use AMD-native quantization schemes from the experimental ciru-ai/ROCmFPX llama.cpp fork, tuned for and benchmarked on AMD Strix Halo (Radeon 8060S iGPU, gfx1151, unified memory):

• ROCmFP3/4/6/8 tensor types with straight and "agent" presets (agent presets keep tool-calling / JSON-structured output reliable at low bit-widths)
• Files load only on the fork -- it is an experimental upstream research build, so build from the pinned commit that produced these files (the default branch may have moved on since):

git clone https://github.com/ciru-ai/ROCmFPX.git ROCmFPX
cd ROCmFPX
git checkout 68f23f34c12d7e61177a034b0d8d3fea2129565e
# then build per the fork's own README

GGUF Files

Perplexity measured on wikitext-2 (100 chunks, ctx 512) against the BF16 baseline of 6.2356; speed is llama-bench tg128 on this project's Strix Halo (gfx1151) box, fully offloaded.

Recommended: Q4 (14.64 GiB). It generates at 12.4 tok/s against 8.3 for the equivalent MagicQuant tier -- 1.5x faster -- which is the reason to accept a fork-only file at all. If you would rather have the quality and run on stock llama.cpp, use the MagicQuant repo linked above.

Two Q8 files -- which one?

Use -BF16Out-imatrix. The plain Q8_0_ROCMFPX.gguf is the original build and is kept only so the two can be compared; it is not deleted, but it is superseded.

The rebuild changes two things, both of which the original got wrong:

1. The output tensor (output.weight) stays at BF16. The original quantized it along with everything else. That tensor emits the logits, so error there lands directly on token probabilities and shows up as shorter, flatter generations. It is ~4.7% of parameters and was sitting at the file's lowest precision. Most published quants of this base (including DavidAU's own NEO-MAX line) keep it at full precision; this one now does too.
2. An importance matrix is actually used. The original shipped with none. Worth knowing: stock Q8_0 discards an imatrix outright (quantize_q8_0 does (void)quant_weights; // not used), so "imatrix Q8_0" is a no-op for anyone shipping standard Q8. The ROCmFPX 8-bit path does consume it, so skipping it cost this file something it did not have to. Calibration corpus: ~1 MB across 18 languages plus code, math and agentic prompts, 200 chunks. It applied to 497 of 506 quantized tensors -- the 9 misses are blk.64 (the MTP layer, which a perplexity forward pass never exercises) and token_embd.weight (a lookup, not a matmul, which llama.cpp always skips).

Measured effect, same methodology as the table above:

Quantization loss drops by roughly 63% for about 1.2 GB more on disk.

Measured speed cost of the BF16 head

Community feedback reported the -BF16Out-imatrix file as slower. Measured (llama-bench, Strix Halo gfx1151, full offload, r=3):

So the trade is roughly +0.27% quality for −4% generation / −7% prompt speed on the reference hardware. A middle ground was tested (standard Q8_0 head, imatrix) and measured 6.2669 / 7.62 t/s — no quality gain over the original, so it is not published: the head's benefit only appears at full precision. Pick by what you value; both files stay available.

A note on comparing this to standard Q8 quants

Q8_0_ROCMFPX is not a drop-in equivalent of ggml Q8_0. It is a separate 8-bit format in the ROCmFPX fork (LLAMA_FTYPE_MOSTLY_Q8_0_ROCMFPX = 111, 8.25 bpw against Q8_0's 8.5) with its own rounding. Two builds at the same nominal bit width should land close but not identical, so small differences against a standard Q8_0 are expected rather than a sign something is wrong.

Usage

Requires a from-source build of the ROCmFPX fork (stock llama.cpp, LM Studio, and Ollama cannot load these files):

# Interactive chat (--jinja uses the model's embedded chat template)
llama-cli -m Qwen3.6-27B-Fable-Fusion-711-MTP-Q8_0_ROCMFPX.gguf -c 8192 --jinja -cnv

# Server mode
llama-server -m Qwen3.6-27B-Fable-Fusion-711-MTP-Q8_0_ROCMFPX.gguf -c 8192 --port 8080 -ngl 99 -fa on --jinja

Vision (image input)

llama-server -m Qwen3.6-27B-Fable-Fusion-711-MTP-Q8_0_ROCMFPX.gguf --mmproj mmproj-F16.gguf -c 8192 --port 8080 -ngl 99 -fa on

Caveats

• The base model's license (apache-2.0) applies to all derivative files
• Fork-only files: stock llama.cpp, LM Studio, and Ollama cannot load these -- build ciru-ai/ROCmFPX from source
• Quantization reduces precision -- verify outputs for your specific use case
• The hybrid quantization assigns different precision to different tensor groups, which means quality characteristics may differ from uniform quantizations

Limitations

• Quantized models may exhibit subtle differences from the full-precision fine-tune
• This model inherits any limitations and biases present in the base model

---

Generated with MagicQuant