Quality-first GGUF quants of Kiwen1.1-27B

❗NEW VERSION 1.2 here

❗Use original chat template instead of embedded one❗

Why these quants? First of all they are properly measured by meaningful metrics and compared to other popular quants (most other providers don't do this). You can see which quant is better and why.

My quants were produced by my quality-first experimental tool, niki-allocator. The main difference of my method is per-tensor type allocation (not by community lore). Each tensor gets what is estimated to be best for it. Estimation is tuned by KLD runs, not just theory. After that best candidate allocations are tested with KLD runs to choose the winners.

Source model

Quantization quality comparison

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

bartowski, mradermacher

Lower is better

Main metrics

Tail metrics

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

Same top probability

Useful for temperature 0 only, otherwise RMS Δp should be considered.

Note that graphs show 1 - same top p, so lower is better.

Perplexity (PPL)

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

Notes

TL;DR difference of corpora for end user: niki-eval-4 - coding, agentic, reasoning, hard logic prompts, English, Russian; indep-v3 - multilingual, web texts, English science papers, no reasoning or agentic traces, almost no code.

bartowski and mradermacher quants for comparison were downloaded on September 1, 2026. I've deliberately dropped some known bad quants (legacy quant types, Q2*, Q3*, IQ4_NL) to save my time on downloading and measuring.

See the tables below for exact numbers for all quants and metrics

Sizes

I've chosen 15 sizes to fill 8500-23000 MiB with geometric progression and rounded to 100 MiB

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.

About speed

I haven't measured speed since it is highly hardware and configuration dependable. What is faster for me may be slower for you. If the 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 the 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

What is 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 tuned by some KLD runs. 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, it takes days of GPU time on my consumer setup.

Corpora

Corpora choice, differences, details

All corpora is chunk aligned by model's tokenizer. 1 chunk = 1 turn/document exactly. I've found that standard workflow with simply concatenated documents gives high tail metrics where context suddenly changes. Most calibration decisions are made to overcome these corpora concatenation artifacts instead of real hard parts of documents. So I believe that chunk alignment is a must for any calibration or evaluation corpora measured by llama-perplexity.

• imatrix: niki-imatrix-4 corpus - 96 chunks of 6144 tokens. ~590K tokens from my own agentic sessions (English, Russian, design docs with hard logic, code, reasoning) + multilingual block with top 32 languages. Deduped, cleaned, filtered by simhash similarity to include only really different turns. Used for imatrix only.
• Evaluation 1: niki-eval-4 corpus - 64 chunks of 6144 tokens. ~390K tokens from my own agentic sessions (English, Russian, design docs with hard logic, code, reasoning). Deduped, cleaned, filtered by simhash similarity to include only really different turns. Does not include any exact or similar (by simhash) agentic turns from niki-imatrix-4 or niki-calib-4. Never seen during calibration.
• Evaluation 2: indep-v3 corpus - 64 chunks of 6144 tokens, ~390 K tokens. This corpus is random compilation of top-32 languages web text prose (HuggingFaceFW/fineweb-2) excluding English (it is in science papers), English science papers (recursal/arXiv-CC0-v0.5). Never seen during calibration.
• Calibration of niki-allocator: niki-calib-4 corpus - for this corpus I've made another different seed "copies" of evaluation corpora (checked by simhash not to contain similar turns/docs) and took 12 hardest chunks of both. Here chunk alignment is most critical. Without chunk alignment calibration is done for concatenation artifacts and not for natural hard content.

Notes:

• indep-v3 corpus will be published here. Note that you can't redistribute it without proper attributions due to license of some included papers.
• niki-* corpora are not published. There is nothing really special actually. They just contain my private information. Sorry for inconvenience.
• Why not wikitext-2 test? While wiki 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. Also wiki is mostly homogenous (not very easy, but there are very few hard tokens and chunks). My corpora is everything from "walk in the park" to "high mountain climbing". Tail metrics are much higher. It is actually more representative for the real model work (if crawling English wiki is not your main use case of course).

Metrics

All metrics were evaluated with llama-perplexity against Q8_0 standard quant (due to hardware constraints). Note that against BF_16 metrics would be little higher.

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.

same top p (top-1) is only good for temperature = 0. Since most models are used with much higher temperatures (~0.6-1.2) it shows nothing really meaningful for real use cases. RMS Δp is what should be measured and compared instead.

p99 KLD, p99.9 KLD, max KLD. With such a small corpora 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). So I don't tune to these. And anybody who does with less than several M tokens corpus just over-fits to their exact corpus and concatenation artifacts. Please correct me if I am wrong.

Evaluation results

niki-eval-4 corpus

Warning! Huge table inside!

Lower is better except same top p

Kiwen1.1-27B — niki-eval-4 corpus

indep-v3 corpus

Warning! Huge table inside!

Lower is better except same top p

Kiwen1.1-27B — indep-v3 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 model size and VRAM.

For numbers check my GRM-2.6-Plus-0628 quant's MTP section (same model architecture).

I've done fast tests on other models (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 my gguf's is v20 from Moore2877.

But it turned out that froggeric's chat template and its forks doesn't work well for this model.

❗Use original chat template instead❗

Sorry for inconvenience!

Multimodality

Any standard Qwen3.8-27B mmproj should work.

I include quantized mmproj following DAXZEIT's receipt for Qwen3.6 that I used in Qwen3.6 era. It is lighter with no noticeable degradation (but it wasn't anyhow measured, so it is just "take my word on this").

Acknowledgments

• beyoru - awesome fine-tuned model.
• Qwen - great base model.
• llama.cpp - quantization and evaluation framework.
• bartowski - quants for comparison.
• mradermacher - quants for comparison.
• Moore2877 - chat template.
• FineWeb - data for evaluation dataset.
• recursal - data for evaluation dataset.
• DAXZEIT - mmproj receipt.
• michaelw9999 - some ideas to start with.
• Required attributions for exact science papers used for evaluation dataset are on dataset page.