Quality-first GGUF quants of Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-MTP

Source model: https://huggingface.co/DavidAU/Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-MTP

This model excels in writing, storytelling, roleplaying, chat.

If you are after agentic/coding/hard logic download this one (much better): https://huggingface.co/NikiKrutan/GRM-2.6-Plus-0628-MTP-GGUF

These quants were produced by my quality-first experimental tool, niki-allocator.

The main difference of my method is per-tensor type allocation (not per tensor groups, layers, community lore etc.)

Each tensor gets what is estimated to be best for it.

The tool is under active development and testing, and has not been published yet.

Quantization quality comparison

To prove my method I've performed comparison with quants from other providers:

DavidAU

mradermacher

Quants for comparison were downloaded on August 8, 2026.

Lower is better

Main metrics

Tail metrics

p99.9 are extremely corpus-driven with usual test corpus sizes of ~300K tokens

Same top probability

useful for temperature 0, otherwise RMS Δp should be considered

Perplexity (PPL)

very crude metric, cheaper to compute though, that's why so popular

Sizes

I've generated 37 quants to fill 8500-23000 MiB with geometric progression and rounded to 100 MiB. 19 of them were chosen for publication. Most neighbor sizes were dropped but some nearest to foreign quants were kept for better comparison. (I believe we don't need 37 quants, and even 19 is extreme, but they are all good).

niki-allocator is able to produce allocation with ~1 MiB precision.

Which one to choose?

If you are after quality: the bigger - the better. So it is always a compromise of what you can afford considering context size and other constraints. Choose the biggest you can fit.

I haven't measured speed since it is highly hardware and configuration dependable. What is faster for me may be slower for you. If speed is the only that matters and you have Blackwell - get some NVFP4 quant (but quality is considerably worse for the same quant size). Otherwise you should measure speed yourself on your hardware and your configuration to make real decision. By the way, on my setup ubatch is parameter that has huge impact on speed. On 27B models 384 was found to be optimal in my case (2x5060Ti), 512 or 256 are much slower. So probably you should test this first.

Quant names

Hugging Face requires quant type in the filename to properly show it. But all my quants are mixed by design. I decided to include dominating quant type (by size, not by tensor count) to the name therefore. It may easily be less than 50% of the model though. So choose by size, ignore listed quant type. For my quants: bigger --> better quality. Always.

Methodology

niki-allocator

It is quality-first per-tensor quantization allocator for llama.cpp llama-quantize.

Allocator decides, per tensor, which quant type to use so that the resulting GGUF hits an exact target file size with the best estimated quality.

It is not direct measurement of KLD-metrics, it is only estimation. But as you can see from real KLD evaluations estimation is good enough.

Raw results are already good. But I added some calibration levers on top to make it better (for Qwen3.5-0.8B I used uncalibrated estimation). These levers need series of KLD evaluations to move estimation closer to reality.

Corpora

• imatrix: niki-small corpus - ~330K tokens from my own agentic sessions (English, Russian, code, reasoning). Deduped, cleaned, filtered by simhash similarity to include only really different turns, short turns (less than 16K chars) dropped. Used for imatrix only.
• Calibration of niki-allocator: randomly chosen 1/4 of niki-small-plus for faster crude KLD calibration (full corpus is too slow on my hardware).
• Evaluation 1: niki-small-plus corpus - ~405K tokens from my own agentic sessions (English, Russian, code, reasoning). Deduped, cleaned, filtered by simhash similarity to include only really different turns, short turns (less than 12K chars) dropped. Does not include any exact or similar (by simhash) agentic turns from niki-small. So while it is from the same domain as imatrix-corpus, it is different.
• Evaluation 2: wikitext-2 test corpus - ~290 K tokens standard corpus. It wasn't seen during calibration or imatrix at all. Only for final evaluation before publishing. So my quants are not anyhow tuned for this dataset.

Notes:

• While wikitext-2 test may be considered as independent evaluation corpus for my quants. It easily may not be true for others quants (wikitext-2 is the most popular corpus somehow for such jobs). They may have seen it (or part of it) during imatrix creation or their methodology calibration. So for really independent evaluation there should be corpus that wasn't seen anyhow by any quants and even better if it wasn't seen during base model creation. So for now I use my own corpus because I need these quants to be good in my tasks. And wikitext2 as a "standard".
• The main difference from wikitext-2 test and niki-small-plus is that wiki is mostly homogenous (not very easy, but there are very few hard tokens and chunks). My corpus is everything from "walk in the park" to "high mountain climbing". Its tail metrics are much higher. So it is actually more representative for the real model work (if crawling wiki is not your main use case of course).

Chunk sizes

• imatrix (niki-small): 8064 tokens (384 x 21). To catch reasoning and long turn traces, not just basic chat.
• niki-small-plus evaluation: 6144 tokens (384 x 16). 66 chunks total. To catch reasoning and long turns, but to keep chunks amount somewhat reasonable (that's why lower than for imatrix).
• wikitext-2 test evaluation: 768 tokens (384 x 2). 386 chunks total. It is not directly comparable with popular 512 tokens chunks!

Why 384 magic number?

My hardware is fastest with ubatch 384, so I use it. Sorry for inconvenience.

Metrics

All metrics were evaluated with llama-perplexity against Q8_0 standard quant (without imatrix) due to hardware constraints.

Quantization was performed with patched llama-quantize from BF_16 source. Fully compatible with original llama.cpp.

All my and foreign quants were evaluated against the same base.

llama.cpp commit 876a4321163249c43ca4e986818fab5ab081f282.

The main metrics during calibration of niki-allocator were mean KLD and RMS Δp.

Better PPL doesn't always mean better other more important metrics. So it can't be used as a main metric (some people still use). It is just fast indicator (no need for logits base) to check for big problems. It can't be main quality metric. Don't make or accept comparisons done only by PPL. It is noise.

Notes on p99 KLD, p99.9 KLD, max KLD.

With such a small corpus (well, almost everybody seems to use wikitext-2 test with only 290K tokens) these metrics are not very robust. While p99 KLD can give some plausible comparison for the allocation method as a whole, p99.9 is extremely corpus-driven (too little data), max KLD is just random at any corpus size (one hardest token of the whole dataset, saying nothing about other hard tokens). Please correct me if I am wrong.

Evaluation results

niki-small-plus corpus

wikitext-2 test corpus

MTP

I've tested MTP performance and discovered that there is no point to keep MTP head higher than IQ4_XS. Q3_K is near but slightly worse (used for lower quants). Exact allocation of IQ4_XS/Q3_K is chosen by allocator (not pinned). Lower than that there is considerable quality drop, so not used in my quants. Higher is just waste of size.

For numbers check my previous GRM-2.6-Plus-0628 quant's MTP section.

I've done fast test on this model (same architecture). Same conclusions.

Also I've additionally checked fast if there is any degradation on IQ4_XS vs Q8_0 with longer context (tested up to 28K), none found. And temperature = 0.6, still no evidence of degradation. But I must say that doing this test properly and scientifically much time and effort is needed. Since not 0 temperature gives different results: many runs needed to stabilize. Reasonably long context (100K+ from my opinion) is very slow on my hardware. So there actually may be some degradation. But that should be proven and not taken by "it seems" or "everybody knows". If there is such comprehensive analysis already, please let me know.

Basically I use these parameters for MTP: --spec-draft-n-max 5 --spec-draft-p-min 0.8. Primary reason of poor results with MTP is ignoring --spec-draft-p-min. Don't put obvious crap in your drafts. But let drafter do more if it is sure enough. MTP performance speed-up is highly dependable on hardware, configuration and specific context. So to decide what is best for your case you should test yourself.

Also don't use other llama.cpp drafters like ngram-mod with MTP. MTP wastes time even if ngram-mod already done draft. That is how llama.cpp is programmed. Not obvious. I have created experimental fork to overcome this issue (and added much better ngram-mod-v2 + minor fixes): https://github.com/NikiKrutan/niki-llama.cpp. I use it myself on a daily basis, but it is more like crude draft than real working fork. It breaks some llama.cpp behavior. But it gives another ~1.5x speed-up on top of MTP for my use cases.

Chat template

Chat template included with gguf's is chat template from original model. No changes.

Multimodality

Tested and confirmed with this mmproj: https://huggingface.co/DAXZEIT/Qwen3.6-27B-mmproj-hybrid-Q8_0-F16-gguf

This one is smaller than F16, but quality stays high, recommended.

Any standard Qwen3.6-27B mmproj should work as well.

Acknowledgments

• DavidAU - great source model (not so great quants, sorry).
• nightmedia - big contribution to the source model. Very interesting creator.
• Qwen - great base model which we all are tinkering with.
• mradermacher - quants for comparison.
• llama.cpp - well, it is nice, but shouldn't we RIIR already? 😉
• michaelw9999 - some ideas to start with.