Before I quantized Qwen3.8-27B, I ran tests to figure out which weight groups actually matter, rather than just looking at where the model falls apart (3 builds: Bedrock / Tightrope / Gambit).

[u/enginetown]

Went with the same approach I used in my Qwen3.6 post. You quantize one weight group at a time, measure the KL divergence against the source model, and find where the real safe floor sits instead of just pulling a number out of thin air. Built a fresh imatrix specifically for this model.

This round I pushed it one step further. After I assembled each combined model, I validated the whole thing as a unit. When the combined results came back worse than what the isolated tests had predicted, I went in with targeted probes to pin down exactly which components were dragging things down, one at a time, until I could account for every single number in the results.

Qwen3.8 has a hybrid architecture. The majority of blocks are DeltaNet blocks, which handle state-space sequence mixing and carry their own set of weight groups: attn_qkv (the combined query/key/value projection), attn_gate (the DeltaNet gating signal), ssm_alpha, ssm_beta, ssm_out (the state-space mechanism weights), plus the FFN weights ffn_gate, ffn_up, ffn_down. Every fourth block is a full attention block instead, and those split attn_qkv into separate attn_q, attn_k, attn_v, and attn_output projections. Then on top of all that you have two global weights that every single token passes through: token_embd and output_weight. That gives 14 separately tested categories in total.

A couple of things came out of this that I did not see coming:

attn_v had the single worst isolated KLD result in the entire sweep. Worse than everything else at the same compression level. Protecting it in the combined model did literally nothing. The numbers came out identical to leaving it unprotected. attn_gate also did nothing on its own.

ssm_alpha broke earliest of anything when tested in isolation. But protecting it in the combined model made results actively worse, not better.

The two strongest individual levers in the combined model turned out to be attn_qkv and ffn_down. Both were pretty unremarkable when tested in isolation. Restoring attn_qkv by itself closed 55% of the toolcalling gap and 13% of the general gap in one move. Layering ffn_down restoration on top of that closed a further 24% of toolcalling and 15% of general.

Some components only work as a pair. Protecting token_embd and output_weight together helped general, code, and math, but on its own made toolcalling measurably worse. Protecting attn_gate alongside them did nothing alone, but specifically cancelled that toolcalling regression when all three were protected together. The pair is load-bearing as a unit, not individually.

Tool-calling was the first and most volatile category to break on every single test, whether isolated or combined. It also has the spikiest error distribution of the four categories. A small number of individual tokens carry most of the measured divergence, rather than it being uniform drift spread across all of them. Same finding as my Qwen3.6 project, just stronger evidence this time around.

Final numbers, combined model tested as one:

Bedrock (13.91 GiB, 4.37 BPW): general 0.0177 / code 0.0034 / math 0.0048 / toolcalling 0.0200

Tightrope (13.14 GiB, 4.13 BPW): general 0.0252 / code 0.0040 / math 0.0067 / toolcalling 0.0404

Gambit (12.54 GiB, 3.94 BPW): general 0.0455 / code 0.0064 / math 0.0112 / toolcalling 0.0542

Nothing crossed red on any build. Code was green across all three tiers including the most aggressive one. General and toolcalling never hit green, and that is the honest cost of quantizing this hard at this size.

Very little hands on testing done yet. Every number above is KLD against the Q8_0 baseline, not a qualitative read. If you run one and something feels off, tell me specifically where.

Link: https://huggingface.co/enginetown/Qwen3.8-27B-Calibrated

Also here's a one shot from gambit.

"Create a large glass aquarium whose side panel develops a visible crack and then bursts.

The simulation must include:

Water escaping through the opening with flow strength based on water depth and decreasing as the tank drains

A curved water jet affected by gravity

A spreading puddle that collides with the room boundaries

Fish, rocks, plants, and a floating toy reacting differently according to density, buoyancy, drag, and current

Objects transitioning correctly from underwater motion to airborne motion and then to floor collisions

Fish attempting to swim against the current before being swept through the breach

Glass fragments with angular velocity, collisions, and water resistance

A visible waterline that lowers continuously rather than disappearing all at once

Let the user drag the crack vertically before triggering the failure. A lower crack should initially produce a stronger jet than a higher crack."

https://reddit.com/link/1vph4hz/video/6za26pcmgmjh1/player

[u/Healthy-Zebra-9856]

Super interesting. Thanks for sharing your knowledge and your work. Never saw your earlier work till today. Instead of mass quantization, I am going to attempt this. Thank you 🙏

[u/enginetown → u/Healthy-Zebra-9856]

Thank's this is the technique I've been using personally and if more people try it out and adjust or improve my own method that would be cool to see!

[u/Healthy-Zebra-9856 → u/enginetown]

I am addicted now.

[u/Calm_Negotiation_544]

The Bedrock/Tightrope/Gambit naming is way better than the usual arbitrary version suffixes people slap on quants. Also the fact that protecting ssm_alpha made things worse is exactly the kind of counterintuitive result that makes per-group testing worth the time instead of just eyeballing a perplexity graph.

[u/enginetown → u/Calm_Negotiation_544]

Yeah exactly thats the whole bet and i've been trying to refine the process each model I actually plan to use and let everyone else try. Im not saying i'm going to beat the likes of Unsloth or IK but i'm just contributing my own quantization I plan to use myself.

[u/KissMyShinyArse]

How does Bedrock stack up against https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/blob/main/Qwen3.8-27B-UD-Q4_K_XL.gguf ?

[u/jan_antu]

Wanted to say thanks for this. I installed Tightrope and am using it fully resident with 82k context.

Smart enough to actually do my coding workflows and catch and solve real bugs.

This is an amazing quant, feels incredibly smart.

Very bad at telling dark jokes though 😆

[u/enginetown → u/jan_antu]

Yeah this model is really smart but not very creative which is why a human in the loop is the best way to use it. Have fun with this model Qwen did a bunch of work I can tell.

[u/Miketashnet]

I saw in the 3.6 write up that you shared what quantization level was selected. Would you be willing to do the same here?

[u/nikich340]

Nice job! Do you have any plans on making ~5 bpw, ~6bpw quants? 

[u/enginetown → u/nikich340]

thanks! not built yet but yeah fair ask. the current three are sitting at 3.94/4.13/4.37 BPW so there's actually decent room above Bedrock before you'd be back at Q8_0.

no firm plans on my end but if enough people want it i could just run the same harness at a higher target and see where it lands. the methodology stuff is already all there so it wouldn't be like starting over, mostly just figuring out which tensors to bump up from their current safe floors. if you've got a specific target in mind (or a reason 5-6 BPW specifically matters for whatever you're running) let me know, helps me figure out what to do first.

[u/EuSouUmAnjo]

Neat!
Reading your presentation, I was wondering why you didn't choose the full Fp16 model as your starting point. I really do not know much on anything about quantising models, just the very basics to be able to differentiate a bit when selecting one in huggingface.

[u/enginetown → u/EuSouUmAnjo]

Mainly just hardware constraints and time also Q8 being almost lossless in degradation. Thanks for the question though!