Validating the 35B Full Fine-tune of Qwen × Fable, "Qwable-3.6-35b", across 40 tasks [RTX5090]

Hello, this is CoolZero.

I found a model with a unique name: Qwable = Qwen + Fable. It is a model full fine-tuned on the Qwen3.6-35B base using Fable 5-style reasoning data. The fact that it uses full weight updates rather than LoRA is what first caught my eye.

I tested whether a 35B-class model could run locally and how quantization affects it using my usual coding benchmark. I am reporting the results of running three quantizations—Q4_K_M, Q5_K_M, and Q6_K—through 40 tasks.

Model Characteristics

Base: `unsloth/Qwen3.6-35b` (Qwen3.5 architecture, 35B parameter MoE)
Training Method: Full fine-tuning (no LoRA)
Training Data: Cleaned Fable 5-style reasoning and instruction dataset
License: MIT (check base model terms separately)
Author: Mia-AiLab

MTP (Multi-Token Prediction) is disabled, and it operates as a standard Qwen-style causal language model. The author's goal is to create a model capable of providing more thoughtful responses for code, structured answers, and technical assistance.

Importantly, Qwen3.6-35B is a MoE (Mixture of Experts) architecture. Even though it is labeled as 35B, only a portion of the parameters are actually activated during inference. This is the reason for the speed, which I will mention later, that is "fast for a 35B model."

GGUF size (nominal values):

Verification Environment

• Execution Environment: llama.cpp (CUDA build)

• Hardware: EVO-X2 + RTX5090 32GB

• Number of Tasks: 40 questions (easy 5 / medium 5 / hard 10 / expert 12 / frontier 8)

• Content: Python bug fixing and implementation tasks (function level, with deterministic tests)

• Evaluation criteria:

  • Resolved rate (did pytest pass all tests?)

  • Quality (code quality: ruff/cyclomatic complexity)

  • Combined (overall score of the above)

  • usability (🟢Autonomous / 🟡Assisted / 🔴Impossible)

The tests were run with identical prompts and identical tasks for each quantization.

Result Summary

Conclusion: Q6_K has the best balance. However, all quantizations were judged as "safe to use with assistance".

Please note the speed.A figure of around 250 tok/s is abnormally fast for the 35B class. Thanks to the MoE architecture, it achieves speeds comparable to a 12B dense model. Compared to the 133 tok/s of the gemma-4-12B-coder Q4, a reversal has occurred where the 35B model is nearly twice as fast.

usability (how much can you actually rely on it?)

The fact that 18% (7 tasks) were "impossible" for Q4 is a bit high. It drops to 10% for Q6, but considering that the gemma-4-12B-coder Q6 was at 8%, this is a lower figure than expected for a 35B full fine-tune.

Q4-specific behavior: leakage of training data paths

The most striking thing about Q4 was that 4 of the failed tasks were due to a specific reason: "parse failure".

patch parse failed: unknown/unsafe paths:
  ['home/lane/AIArchives/archives/neonix/00000001/palindrome.py']
  ['home/lane/MythosMini/intervals.py']
  ['home/lane/AIArchives/archives/neon/claude/20260611_174400_454/0002/task_output.txt']
  ['home/lane/AIArchives/archives/neon/2026-06-11_10-00-00/.../vm.py']

The model included file paths from the training data in its output. Instead of returning a diff-style correction for the target file, it returned non-existent paths like `home/lane/AIArchives/...`, which the parser rejected because it could not determine them to be safe.

This may indicate that the lower the quantization (Q4), the more likely the memory of the training data is to appear explicitly. In Q5 and Q6, the same tasks (t004, t022, t026, t040) were resolved normally, and this behavior disappeared as the quantization increased.

As a risk of full fine-tuning, there are cases where personal environment information from the training data is imprinted into the weights. In Qwable, this was mitigated by increasing the quantization, but if you use Q4, I recommend checking the path information in the output just in case.

Results by difficulty

Q4 has a strange distribution where it missed one question in easy (t004: parse failure) but got all questions correct in medium. This is also due to the specificity of the parse failure; it was a result of being rejected by the output format even though it was solved in terms of content.

For hard, Q6 was the best with 9/10. The quality score was also 89, the highest among all quantizations.

Tasks that failed across all quantizations

t010: Parsing CSV quoted fields

• A rare result where Q5❌ (test failure) and Q6❌ (timeout) failed, but Q4✅ succeeded.

• The possibility that Q6 failed due to timeout because the implementation was too complex to finish processing.

t020: Order of operations for arithmetic and parenthesis handling

• Failed in all 3 quantizations. A calculator implementation that correctly handles operator precedence is a weak task for Qwable.

t021: Banker's Rounding

• Failed in all 3 quantizations. It could not correctly implement the subtle specifications of Python's standard even-rounding.

t034: Event Bus (unsubscribe processing during dispatch)

• Q4✅ succeeded, Q5❌ and Q6❌ failed. A race-condition-like task involving behavior when a handler is unsubscribed during dispatch.

What is the speed of a 35B MoE?

Measured average generation speed:

The speed difference is small, with only an 8% drop from Q4 to Q6. This is likely because, due to the nature of MoE where 'the weights used are limited,' the impact of the quantization bit count is not as significant as it is in dense models.

For comparison, the gemma-4-12B-coder (no MoE) verified last time was 133–94 tok/s. It is counterintuitive that the 35B Qwable is nearly twice as fast, but the difference in architecture is reflected in the numbers.

Summary of the trade-off between accuracy and speed

Although Qwable is more than twice as fast, gemma-4-12B-coder has higher accuracy. This can be read as either the strength of gemma-4-12B-coder, which had strict quality gates applied during Fable 5's CoT distillation, or as an indication that Qwable's full fine-tuning is more geared toward general-purpose reasoning than coding optimization.

A division of roles is emerging: Qwable if you 'just want to run it fast and often,' and gemma-4-12B-coder if you 'want to prioritize coding accuracy.'

Summary

• Q4_K_M: Characterized by parsing failures (leakage of training data paths). It is the fastest, but the accuracy cost is high.

• Q5_K_M: Between Q4 and Q6. Parsing failures are resolved, and the speed is sufficient.

• Q6_K: Resolved rate of 90%, Combined 83.2, the best. Speed is also practical at 8% less than Q4.

The speed advantage of the 35B MoE is real, making it a strong candidate if you want to run it fast locally. However, if you specialize in coding, smaller models in the same score range are also options. Since the unique behavior of parsing failures can be avoided at Q5 or higher, I recommend starting with Q5 or Q6 if you want to try it.

The code and test results generated during verification have been archived. Please comment if you 'want to see details of a specific task' or 'want to try it in your own environment.'

Model Information

• Mia-AiLab/Qwable-3.6-35b (HuggingFace)

• Base: unsloth/Qwen3.6-35b (MoE architecture)

• License: MIT

• Recommended sampling (balanced): temp 0.6 / top_p 0.95 / min_p 0.02

• Recommended sampling (coding): temp 0.2–0.4 / top_p 0.9

#LocalLLM #Qwen #Fable5 #Quantization #MoE #llamacpp #Benchmark #GGUF #35B