317 1 month ago

Code-targeted 184-expert prune of Ornith-1.5-35B-A3B (256e→184e, ~27B, A3B active, top-8). Beats the 256-expert teacher on LiveCodeBench v6 (+6.5pp) and HumanEval+ (+2.4pp) at ~28% fewer experts. Native MTP head + vision tower

vision tools thinking
ollama run mannix/ornith-1.5-27b-a3b-coder:Q4_K_L

Details

1 month ago

62c4488c3f40 · 16GB

qwen35moe
·
26.2B
·
Q4_K_M
{ "draft_num_predict": 3, "min_p": 0, "num_ctx": 32768, "presence_penalty": 1.5,
{{ .Prompt }}

Readme

Ornith-1.5-27B-A3B-Coder — competence-map expert prune

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

A code-targeted expert prune of Ornith-1.5-35B-A3B: the mixture is reduced from 256 experts to 184 per layer (72 dropped, ~35B→27B, still A3B active), keeping the code-competent experts. Same router, attention, norms, MTP head and vision tower as the base — only the expert keep-set changes. No fine-tuning, no distillation — pure expert selection.

Full model card & methodology: ManniX-ITA/Ornith-1.5-27B-A3B-Coder (weights) · GGUF repo on Hugging Face.

Its sibling CoderX uses the same map with a REAP stability floor — the pair differs by exactly 6 experts per layer — and measures better on almost every code and reasoning axis at the same expert budget and the same file size. Start there unless you specifically want this arm.

How it works

The 256-expert teacher is profiled per-expert on a balanced corpus to build a competence map, and the 72 lowest-value experts per layer are evicted, protecting the code-competent ones. This arm is the pure competence-map cut: no stability floor is applied. Routing stays at the native top-8 (expert_used_count = 8) — no routing-recovery dial is baked in.

The -MTP- claim is verified from the shipped file's own metadata, not asserted: block_count = 41 (40 trunk + 1 MTP), nextn_predict_layers = 1, and block 40 is actually present in the tensor list.

Evaluation (Q6_K + imatrix, llama.cpp, sampler recommended — temp 0.6 / top-p 0.95 / top-k 20)

Benchmarkbase 35B (256e)This model (184e)CoderX (184e)
GPQA-Diamond (198)0.82830.76770.8131
AIME (30)0.90000.90000.9667
LiveCodeBench v6 (77 hard)0.66230.7273 ▲0.7662
HumanEval+ (164)0.80490.8293 ▲0.8110
MultiPL-E (300)0.85330.83000.8367
Mean (11 benches)0.82520.8292 ▲0.8386

▲ = beats the full 256-expert teacher. LiveCodeBench +6.5pp and HumanEval+ +2.4pp over the teacher at ~28% fewer experts, and the 11-bench mean edges it out. The trade is graduate science (GPQA −6.1pp) and a small MultiPL-E give-back — not code. This arm tops CoderX on HumanEval+ only; CoderX wins the rest.

Tool-calling — tool-eval-bench hardmode (88 scenarios, 176 pts)

Benchmarked file is IQ4_XS, served on llama.cpp with MTP speculative decoding. 136.8 ±4.8 of 176, eighth of ten — statistically indistinguishable from Qwen3.6-27B-A3B-CoderX (137.4) and from its own CoderX sibling (134.0); the CIs overlap almost completely. The A3B rows it is compared against are Q4_K_M, so part of any gap is quantisation, not architecture.

Perfect (100%) on Tool Selection, Restraint & Refusal, Structured Reasoning, Toolset Scale and Creative Composition; Structured Output 96.7%. The weaknesses are agentic: Autonomous Planning 46.7%, Context & State 62.0%, Hard Mode 64.7% — plus Parameter Precision 66.7%, markedly worse than the rest of the cohort and worth knowing before wiring it to strict-schema tools. 12 safety-critical failures across five seeds; it does not share the A3B models' TC-31/TC-34 weakness.

Which tier to pull

Every tier is built with an importance matrix, including Q6_K, from this arm's own imatrix — an imatrix cannot be shared between two different expert cuts. Append vision- to any tag for the multimodal tower (e.g. :vision-Q4_K_M). Sizes are GB (bytes ÷ 1e9).

TierSizeNotes
Q8_027.91 GBnear-lossless reference
Q6_K21.57 GBrecommended — this is the eval tier
Q5_K_M18.73 GB—
Q4_K_M ⭐16.06 GBthe :latest default — fits 24 GB VRAM with context
IQ4_XS14.22 GBbest size/quality under 15 GB; the tool-calling tier
Q3_K_M12.72 GB—
Q2_K_L10.36 GB—
IQ2_XS8.20 GBsmallest; expect real degradation

Pull

ollama run mannix/ornith-1.5-27b-a3b-coder                # :latest = Q4_K_M, 16.06 GB
ollama run mannix/ornith-1.5-27b-a3b-coder:Q6_K           # eval tier
ollama run mannix/ornith-1.5-27b-a3b-coder:vision-Q4_K_M  # + vision tower (multimodal)

Every tag ships these defaults baked in: temperature 1, top_p 0.95, top_k 20, min_p 0, repeat_penalty 1, presence_penalty 1.5, num_ctx 32768, draft_num_predict 3. The published evaluation above used temperature 0.6 with the same top-p/top-k; set temperature 0.6 if you want to reproduce those numbers. Greedy is not viable on this family.

Budget the tail, not the median

ollama has no reasoning-budget flag, so num_ctx is what bounds the thinking phase there — keep it well above your prompt+output budget. On LiveCodeBench the median generation is ~12.7k tokens but 5 of 77 problems run to a 32,768-token ceiling. If you care about worst-case latency, bound it at serve time rather than hoping for a short draw.

Good to know

  • Native MTP head ships in the GGUFs for speculative decoding (draft_num_predict 3 is baked in), alongside the vision- mmproj tower.
  • Vision is verified, not assumed — the projector was shown a synthetic 5-band image in a non-obvious colour order and named all five correctly, while the same prompt with no image attached correctly reported it could not see one.
  • Calibrated on a published corpus — AtomicChat/calib-corpora build builds/ornith-1.5-9b (3,079 docs · 4,958,490 tokens · all 9,686 chunks · --parse-special on), with the tokenizer hash gated against the build manifest.
  • imatrix.dat is archived in the GGUF repo — quants are reproducible and auditable.

Links: HF · weights + full card · HF · GGUF · CoderX sibling

Apache-2.0 · research checkpoint.