enginetown/Qwen3.8-27B-Calibrated

Qwen3.8-27B - GGUF (Bedrock / Tightrope / Gambit)

Three GGUF builds of Qwen/Qwen3.8-27B, all quantized starting from Unsloth's Q8_0 release.

What I did

I used the same harness I'd been running for my Qwen3.6-27B projects, just adapted it over to Qwen3.8's architecture. The method is the same: quantize one tensor category at a time, measure KL-divergence against the source across general, code, math, and tool-calling prompts, and find where the real safe floor actually sits rather than just guessing. I built a fresh imatrix specifically for this model and used it for every pass.

This time I went beyond isolated testing. After building each combined model, I validated it as a whole. And when the combined results came back worse than what the isolated tests had predicted, I didn't just shrug and move on. I ran targeted probes to figure out which specific tensors were actually responsible, one at a time, until I could account for every single number in the results.

What the testing showed

Isolated per-tensor safe floors don't predict how the combined model will behave. All 14 tensor categories passed their own isolated test on the first combined build. The combined model still came back worse than any of them predicted individually. Compression errors compound when enough components get touched at once, even when nothing on its own looks bad.

Isolated fragility is not the same thing as combined-model importance, and this goes in both directions. ssm_alpha broke earliest of anything in isolation, and protecting it in the combined model made results worse, not better. attn_v had the single worst isolated result in the whole sweep, and turned out to do nothing measurable when protected in the combined model. Zero effect, identical numbers to leaving it unprotected. Meanwhile attn_qkv and ffn_down, both unremarkable in isolation, turned out to be the two strongest individual levers I found anywhere in this project.

Some components only do anything as a pair. Protecting output_weight/token_embd helps general, code, and math, but on its own it makes tool-calling measurably worse. Protecting attn_gate alongside it does basically nothing by itself, but it specifically cancels out that tool-calling regression when the two are combined. Neither one works alone. Together, they're necessary.

Tool-calling was the first and most volatile category to break across every single test I ran, whether isolated or combined. It also has the widest, spikiest error distribution of the four. A small number of individual tokens carry most of the measured divergence, not a uniform drift across all of them. If tool-calling precision matters for what you're doing, weigh it more heavily than a flat average across the four categories.

Measured KL-divergence, combined model (all components applied together)

Bedrock

general: 0.0177 code: 0.0034 math: 0.0048 toolcalling: 0.0200

Tightrope

general: 0.0252 code: 0.0040 math: 0.0067 toolcalling: 0.0404

Gambit

general: 0.0455 code: 0.0064 math: 0.0112 toolcalling: 0.0542

These are combined-model numbers, the full quantized file tested as one, not per-component isolated results. Nothing crossed into red (≥0.1) anywhere. Code was green on every build at every tier, including the most aggressive. General and toolcalling never hit green on any build. Those are the two categories worth weighing most if you're picking between tiers.

The builds

File	Size	True BPW
Bedrock	13.91 GiB	4.37
Tightrope	13.14 GiB	4.13
Gambit	12.54 GiB	3.94

Bedrock is the two proven levers (attn_qkv, ffn_down) fully protected, everything else at its individually-tested safe floor. It's the closest to the source and the largest of the three.

Tightrope takes those same two proven levers, plus the output_weight/token_embd + attn_gate pair protected as a unit, and pushes everything else more aggressive. I decomposed this build's protected components one at a time specifically to check whether they were all earning their size cost. One (attn_v) wasn't. It could be dropped with no measurable quality loss. The rest are genuinely load-bearing, including one pairing that only works when both halves are present.

Gambit pushes nearly everything to an aggressive IQ-family tier. It's the smallest of the three, and the only build where math slipped into yellow.

Testing

Nothing in this project has been tested by hand against real tasks yet. Every number above is a KL-divergence measurement against the Q8_0 baseline, not a qualitative read. I'd trust these for picking a tier based on size and quality tradeoff. I wouldn't treat them as a stand-in for actually running the build against whatever you're planning to use it for.

Scope

Combined-model validation was done for all three builds, but against the same four-category battery as before, and those battery files are small. We're talking 2 to 3 chunks per category. Good enough for a working baseline, thinner than I'd like. Worth keeping in mind on any close call between tiers.

Qwen3.8 has an MTP/speculative-decoding head block that isn't exercised during normal calibration, so it ends up with little to no imatrix coverage. Mid-tier quant levels fall back to non-imatrix quantization for that block's tensors with a warning, nothing more. The most aggressive tiers refuse outright unless that block is pinned to a safer level, which I did where it came up. Quality on that one block is a little less informed than the rest of the model, not fatally so.

The output_weight/token_embd + attn_gate finding came from testing each piece alone against the full pair, not a from-scratch ablation across every possible sub-combination. I can speak to what I actually tested, the pair together and each half alone, not to every combination I didn't try.

All comparisons are against the source's own Q8_0 release, not the original FP16/BF16 weights. Same baseline caveat as my earlier projects. Whatever loss Unsloth's own quantization introduced is already baked into what I'm calling "source" here.

Usage

Standard GGUF. Works with llama.cpp, LM Studio, koboldcpp, and other GGUF-compatible runtimes.

./build/bin/llama-cli \
    -m Qwen3.8-27B-Bedrock-v4.gguf \
    -p "Explain quantum computing in simple terms." \
    -n 256 \
    --temp 0.7 --top-p 0.95 --top-k 20 \
    -ngl 99

If you try one of these and something breaks or feels off, I want to hear about it. Specifics help most: what task, what you expected, what you got.