---

license: apache-2.0

library_name: llama.cpp

base_model:

• bottlecapai/ThinkingCap-Qwen3.6-27B

base_model_relation: quantized

pipeline_tag: text-generation

quantized_by: ROCmFPX

language:

• en

tags:

• gguf
• rocm
• amd
• strix-halo
• gfx1151
• rocmfpx
• quantized
• magicquant

---

ThinkingCap-Qwen3.6-27B-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/ThinkingCap-Qwen3.6-27B-MagicQuant-GGUF.

Derivative of ThinkingCap-Qwen3.6-27B, 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 ThinkingCap-Qwen3.6-27B.

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

• Q5 was not published. ROCmFPX trades some quality for throughput, but this build measured 9.5 tok/s against the MagicQuant Q5's 9.6 -- 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 Q5 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

• Q4 -- rendering MagicQuant's Q4 config into ROCmFPX types predicts 17.09 GiB against a 50.89 GiB BF16 baseline (ratio 0.3358), which is the Q5 band, not Q4. The ROCmFPX family has no type between 4.5 and 6.5 bpw, so schemes round to the nearest available and a tier can render outside its own band.

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. Any file for them currently in this repo therefore comes from an earlier run -- see below.

Files from an earlier build

These files were produced by a previous quantization run, not the one this card describes:

• ThinkingCap-Qwen3.6-27B-ROCMFPX-MQ-Q4.gguf (14.64 GiB) -- size verified as Q4 band

They are kept because they are correctly sized for their tier and remain usable. But they were selected by an earlier version of the search, so their quality was not measured on the same footing as the other files here, and the per-group scheme breakdown above does not describe them.

If you are comparing tiers against each other, prefer the files from the current run -- the comparison is only apples-to-apples within a single search.

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

| File | Size | Quant | Perplexity vs BF16 | Speed |

|------|------|-------|--------------------|-------|

| ThinkingCap-Qwen3.6-27B-ROCMFPX-MQ-Q4.gguf | 15.7 GB | MagicQuant Q4 layout in ROCmFPX types (hybrid, fork-only) | earlier build, not measured here | |

| ThinkingCap-Qwen3.6-27B-ROCMFPX-MQ-Q6.gguf | 22.2 GB | MagicQuant Q6 layout in ROCmFPX types (hybrid, fork-only) | 6.8232 (+0.63%) | 9.2 tok/s |

| mmproj-ThinkingCap-Qwen3.6-27B-f16.gguf | 0.9 GB | F16 (unquantized) | not measured | |

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

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 ThinkingCap-Qwen3.6-27B-ROCMFPX-MQ-Q4.gguf -c 8192 --jinja -cnv

# Server mode
llama-server -m ThinkingCap-Qwen3.6-27B-ROCMFPX-MQ-Q4.gguf -c 8192 --port 8080 -ngl 99 -fa on --jinja

Vision (image input)

llama-server -m ThinkingCap-Qwen3.6-27B-ROCMFPX-MQ-Q4.gguf --mmproj mmproj-ThinkingCap-Qwen3.6-27B-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