Qwen3.6-27B-Fable-Fusion-Calibrated - GGUF (Bedrock-Final / Tightrope / Gambit)
Three GGUF builds of DavidAU/Qwen3.6-27B-Fable-Fusion-711-Uncensored-Heretic-NM-DAU-NEO-MAX-MTP, a fine-tune of Qwen/Qwen3.6-27B, quantized starting from the source's Q8_0 release.
This is a companion project to my earlier Qwen3.6-27B-Calibrated repo. Same methodology, applied to a fine-tune of the same base architecture, with one real improvement this time: I actually closed the biggest gap the last project left open.
What I did
Same harness as last time. Quantize one tensor category at a time, measure KL-divergence against the unquantized source across general, code, math, and tool-calling prompts, and find the real safe floor for each category instead of guessing. I built a fresh imatrix specifically for this model rather than reusing the base project's or the source's own bundled one.
The part I'm actually proud of is this: last project's biggest unclosed gap was that I measured every tensor category in isolation and never checked whether the combined model, all floors applied at once, actually held up together. This time I did. I built the full combined model, tested it, found real degradation that no isolated test had shown, walked back the components responsible, and retested until the combined result was clean. Bedrock-Final is the validated result of that process, not an isolated-floor guess dressed up as a finished product.
What the testing showed
This fine-tune's weights tolerate compression noticeably more than base Qwen3.6-27B did on the identical test, and unevenly across components, not by a flat multiplier. attn_q, attn_output, attn_k, attn_v, attn_gate, ssm_beta, and ssm_alpha all survived every level I tested, down to the most aggressive setting on the ladder, with zero measurable break. The equivalent components in base Qwen broke several steps earlier. That's a real, structural difference in how these specific trained weights hold up under compression, not something you'd guess from architecture or tensor size alone.
The break pattern also flipped from the base model. Last time, tool-calling was consistently the first capability to crack. This time, general-purpose output broke first in most components that showed a clean single-capability break, with tool-calling holding up comparatively well. I didn't expect that going in.
To be clear about what this isn't: I'm not claiming this proves the fine-tune is smarter than base Qwen. That's a separate question tied to the source model's own self-reported ARC-C claims, and this project doesn't test it. What I'm testing is narrower, and it's something I can actually stand behind: does quantization preserve whatever this model already is.
Measured KL-divergence, combined model (all components applied together)
Bedrock-Final
- general: 0.0213
- code: 0.0041
- math: 0.0059
- toolcalling: 0.0104
Tightrope
- general: 0.0237
- code: 0.0047
- math: 0.0073
- toolcalling: 0.0127
Gambit
- general: 0.0460
- code: 0.0074
- math: 0.0156
- toolcalling: 0.0269
These are combined-model numbers, the full quantized file tested as one, not just per-component numbers from isolated testing. No category crossed into red (over 0.1) on any build. Toolcalling on Bedrock-Final sits right at the edge of the yellow line (0.0104 against a 0.01 threshold), so if tool-calling precision matters most for your use case, know that going in.
The builds
Bedrock-Final - 12.19 GiB, 3.90 true BPW
The fully validated build, every component at its combined-tested safe point. Closest to the source model.
Tightrope - 12.13 GiB, 3.88 true BPW
Protects the largest tensors (FFN) at Bedrock-Final's level while keeping Gambit's more aggressive attention cuts. It's barely smaller than Bedrock-Final, about 60MB. That's the most interesting result of the whole build set: it tells you the real quality cost in this model lives almost entirely in FFN precision, not attention. The aggressive attention cuts cost next to nothing. If you want meaningfully smaller than Bedrock-Final, Tightrope isn't the way to get there. If you want to understand where this model's size actually comes from, its numbers are the evidence.
Gambit - 10.43 GiB, 3.33 true BPW
This tier went through a few rounds of iteration rather than one clean cut past the measured floors. An early version pushed too hard on a handful of small attention and state tensors (attn_k, attn_v, and two SSM gating tensors) and measurably got worse, not better, as a result, a real tested case of a compression choice backfiring. The version shipped here reverts that specific cut and trades size for quality along a different axis instead (an uneven split between two adjacent FFN tensor types). It's the best-performing configuration out of five real variants I tested, on every one of the four battery categories, though I haven't isolated exactly which individual change is responsible for the improvement. Only that this combination beats the others tried.
BPW figures for all three builds come directly from each file's own tensor metadata (real parameter count, real file size), not estimates.
Testing
I ran Gambit, the most aggressive build, by hand against real coding tasks. A stress-tested LRU cache implementation, 20,000 randomized operations checked against an independent reference implementation, zero mismatches. A recursive-descent expression parser with 16 test cases, including deliberately adversarial ones like associativity and malformed input, all correct. A deliberately loosely specified, realistic prompt for a small Python application. All three produced working, logically sound code. A few small mistakes did show up: an unguarded edge case, and one instance of the model describing example output it hadn't actually generated. Nothing that read as a loss of reasoning, the kind of thing you'd catch on a close read or by running it.
This is manual, hands-on testing on one build, not a formal benchmark suite, and it doesn't specifically stress math or tool-calling, the two categories the KLD numbers above flag as most affected by compression. I haven't tested Bedrock-Final or Tightrope by hand yet, and I haven't tested any build against tool-calling-heavy or math-heavy real tasks specifically. Treat the hands-on result as showing that Gambit handles general coding well, not as proof about the other categories or the other builds.
Scope
- Combined-model KLD testing was done this round, closing the gap my last project left open, but only against the same four-category battery as before. A broader or more adversarial test could still surface something this battery doesn't.
- All comparisons are against the source's own Q8_0 release, not original FP16/BF16 weights. Same unclosed baseline-choice caveat as last time.
- This project does not evaluate the fine-tune's own capability claims. Its self-reported ARC-C benchmarks are the source model's claim, not mine, and I haven't independently verified them. This project only measures whether quantization preserves whatever the source model already is.
- Hands-on testing covers one of the three builds. Three general-coding tasks, no tool-calling or heavy math tasks yet.
- Gambit's final configuration came from iterative testing of different tensor-type combinations rather than a single-variable ablation. The specific contribution of each individual change, versus the combination as a whole, hasn't been fully isolated.
Usage
Standard GGUF, works with llama.cpp, LM Studio, koboldcpp, and other GGUF-compatible runtimes.
./build/bin/llama-cli
-m Qwen3.6-27B-711-Bedrock-Final.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.
