Qwen3.6-27B-A3B-CoderX — long-horizon code prune, hybrid redistribution

~27B params · 184 experts (72 dropped/layer) · A3B active · top-8 routing · MTP head + vision tower

A second, harder-targeted code prune of Qwen3.6-35B-A3B. Same 256 → 184 expert budget as the Qwen3.6-27B-A3B-Coder sibling, but a different selection and an added redistribution step: our saliency map picks the keep-set, a REAP-style per-layer floor (p=24) protects the tail, and the evicted experts are folded DERN-style into the survivors instead of being discarded. Same router, attention, norms, MTP head and vision tower as the base — no fine-tuning, no distillation.

CoderX is not a strict upgrade over Coder. It is the long-horizon sibling: much stronger on multi-step competitive-programming work, a tie on short multi-language completion. Pick by workload — see the table.

Full model card & methodology: ManniX-ITA/Qwen3.6-27B-A3B-CoderX-MTP-GGUF on Hugging Face.

How it works

The 256-expert teacher is profiled per-expert on a balanced corpus plus targeted LiveCodeBench and MultiPL-E/HumanEval pass-response classes. That saliency ranking chooses which 184 experts survive; a REAP-style floor (p=24) keeps each layer from being stripped below a minimum, which is what the plain saliency cut over-prunes. The 72 evicted experts per layer are then folded into the survivors (DERN-style, survivor-anchored) rather than dropped, so their weight is redistributed instead of lost.

Serving is top-8 — the base model’s native routing, no override needed.

Evaluation (Q6_K + imatrix, llama.cpp b9700, greedy)

▲ = beats both the 256e teacher and the Coder sibling. Every cell is greedy (temperature 0.0 / top_p 1.0 / top_k 0), one serving geometry per bench, pinned in the eval template and read back out of the server log — not chosen at launch time. All three models were run on the same binary, the same quant recipe and the same basis.

Read the MultiPL-E row carefully. A same-basis repeat of that bench — identical weights, quant, sampler and geometry — moved 1.0 pp on batch-scheduling nondeterminism alone. The 0.33 pp CoderX↔Coder gap sits inside that band and should be read as a tie; the 2.33 pp gap to the teacher sits outside it and is real. Per language (CoderX / Coder / 256e): Rust 0.85 / 0.81 / 0.84 · Java 0.89 / 0.90 / 0.93 · JS 0.92 / 0.96 / 0.96. CoderX takes Rust and gives up JavaScript.

Routing ships top-8, and that was measured, not assumed: MBPP-full 0.784 / 0.790 at top-8 against 0.732 / 0.730 at top-10, with repeat spreads ≤ 0.3 pp on both arms. MultiPL-E was inside noise either way. This is the opposite call from the Coder sibling, which bakes top-10.

Non-code axes (GPQA, MATH-500, IFEval, ARC) were not re-measured on this greedy basis and are deliberately not tabled here. A separate sampled cohort put CoderX ahead of the published Coder on IFEval, but that gap decomposed into thinking-termination, not instruction-following — different sampler, different basis, so it does not belong in the table above.

Which one do I want?

• CoderX — long, multi-step, test-driven problem solving; LiveCodeBench-shaped work; Rust.
• Coder — short single-function completion across many languages, and the broader non-code profile (it has a published 9-bench table; this one does not).
• Base 256e — you want maximum MultiPL-E and don’t care about the 8 GB.

Which tier to pull

One ladder, 19 tiers. Every K- and I-quant here is built with an importance matrix (calibration_datav5.txt, 510 entries, 128 chunks — the same recipe as the Coder GGUFs); Q8_0 carries none by rule. Append vision- to any tag for the multimodal tower (e.g. :vision-Q4_K_M).

Sizes are the actual on-disk GGUF bytes, so the ladder is ordered by size rather than by name — Q3_K_L really is larger than Q3_K_XL on this architecture.

Pull

ollama run mannix/qwen3.6-27b-a3b-coderx                  # :latest = Q4_K_M, 16.1 GB
ollama run mannix/qwen3.6-27b-a3b-coderx:Q6_K             # the tier every number above was measured on
ollama run mannix/qwen3.6-27b-a3b-coderx:vision-Q4_K_M    # + vision tower (multimodal)

Every tag ships these sampling defaults baked in, matching the Coder release: temperature 1, top_p 0.95, top_k 20, min_p 0, repeat_penalty 1, presence_penalty 1.5, num_ctx 32768, with RENDERER qwen3.5 / PARSER qwen3.5.

Speculative decoding — MTP is on by default

The MTP block ships inside every GGUF, and every tag carries PARAMETER draft_num_predict 3, so ollama runs --spec-type draft-mtp --spec-draft-n-max 3 --spec-draft-backend-sampling without you configuring anything.

n=3 is a deliberate choice, not a default. On an RTX 5080 (Blackwell): 189.65 tok/s baseline → 251.94 at n=3 (+33%), falling to 145.37 at n=8 — worse than not speculating at all. On a 3090 the same grid peaks at n=8 instead. The optimum is hardware-dependent; n=3 is near-peak on both, so it is the safe shipped default. Raise it yourself if you’re on Ampere and measuring. Acceptance at n=3: mean accepted length 3.16, per-position (0.841, 0.730, 0.587).

Good to know

• CoderX thinks long. On LiveCodeBench its median completion is ~15.8k tokens against ~2.2k for the published Coder, and 60 of 77 completions trip a repetition heuristic — but 42 of those 60 still pass. The length is where the LCB win comes from, not a defect. If your work is LCB-shaped, raise num_ctx above the baked-in 32768.
• The vision tower is the released Qwen3.6-27B-A3B-Coder mmproj (clip projector, projection_dim 2048, matching this model’s embedding_length 2048).
• imatrix.dat is archived in the GGUF repo — every tier is reproducible and auditable.
• Built with omnimergekit.

Apache-2.0 · research checkpoint.