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):
bash
1git clone https://github.com/ciru-ai/ROCmFPX.git ROCmFPX
2cd ROCmFPX
3git checkout 68f23f34c12d7e61177a034b0d8d3fea2129565e
4# then build per the fork's own README
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:
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.
An importance matrix is actually used. The original shipped with none.
Worth knowing: stock Q8_0discards 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:
Build
Size
PPL
Loss vs BF16
original Q8
28.2 GB
6.2626
+0.43%
BF16Out-imatrix
29.4 GB
6.2455
+0.16%
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):
Build
pp512 t/s
tg128 t/s
PPL
original Q8 (ROCMFPX head)
216.2
7.64
6.2626 (+0.43%)
-BF16Out-imatrix
201.6
7.34
6.2455 (+0.16%)
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):
bash
1# Interactive chat (--jinja uses the model's embedded chat template)2llama-cli -m Qwen3.6-27B-Fable-Fusion-711-MTP-Q8_0_ROCMFPX.gguf -c 8192 --jinja -cnv
34# Server mode5llama-server -m Qwen3.6-27B-Fable-Fusion-711-MTP-Q8_0_ROCMFPX.gguf -c 8192 --port 8080 -ngl 99 -fa on --jinja
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
