ManniX-ITA/Ornith-1.5-27B-A3B-CoderX-MTP-GGUF
Ornith-1.5-27B-A3B-CoderX — GGUF (imatrix, MTP)
GGUF quantizations of **`ManniX-ITA/Ornith-1.5-27B-A3B-CoderX`** — the REAP-stability-floor 184-expert cut of Ornith-1.5-35B-A3B.
→ Recipe, drop maps, the full 11-bench evaluation, the cross-family comparison and the length/deliberation analysis all live on the [weights card](https://huggingface.co/ManniX-ITA/Ornith-1.5-27B-A3B-CoderX). This card covers the quantized files only.
Its sibling **Coder** is the same 184-expert budget and the same competence map without the stability floor — the pair differs by exactly 6 experts per layer. This arm measures better on almost every code and reasoning axis at the same file size.
The -MTP- claim, verified from this file's own metadata
qwen35moe.block_count = 41 (40 trunk + 1 MTP)
qwen35moe.nextn_predict_layers = 1
distinct blk indices = 41, max = 40 <- block 40 is actually SHIPPED
MTP tensors = blk.40.nextn.{eh_proj,enorm,hnorm,shared_head_norm}
qwen35moe.expert_count = 184
qwen35moe.expert_used_count = 8Worth stating explicitly for this arm: the REAM save path *drops the `mtp. block**, producing a GGUF that declares 41 blocks and ships only 40 — quantization passes, then llama-imatrix dies on blk.40.attn_norm.weight not found`. The head was grafted back from the anchor, and the counts above are the read-back proof that it stuck.
Quants
Built with an importance matrix at every tier, including Q6_K, from this arm's own imatrix. An imatrix cannot be shared between two different expert cuts, so CoderX has a separate one from Coder. Sizes are GB (bytes ÷ 1e9).
A Q4_K_M build of these exact weights (16.06 GB) also lives in `Ornith-1.5-27B-A3B-P6-MTP-GGUF`.
Calibration (imatrix)
The importance matrix for every tier in this repo was computed on [AtomicChat/calib-corpora](https://huggingface.co/datasets/AtomicChat/calib-corpora), build `builds/ornith-1.5-9b` — a published, manifest-verified calibration corpus rather than an ad-hoc text dump, so the quantisation basis is auditable and reproducible.
Corpus/model match was verified, not assumed. The build is keyed to a tokenizer, and this arm's tokenizer.json hashes to 5f9e4d4901a92b997e463c1f46055088b6cca5ca61a6522d1b9f64c4bb81cb42 — byte-identical to the tokenizer.sha256 recorded in that build's manifest.json. A calibration corpus rendered for a different tokenizer would silently mis-tokenise, so this check gates the reuse.
The imatrix itself ships in this repo (*.imatrix.gguf) so the quants can be reproduced or audited. Note it is this arm's own imatrix: an imatrix cannot be shared between two different expert cuts.
Serving
llama-server -m Ornith-1.5-27B-A3B-CoderX-Q6_K.gguf --port 8080 \
-c 262144 -ngl 99 --no-warmup \
--reasoning-format deepseek --reasoning-budget 12288--reasoning-budget is mandatory for this family. Use the vendor sampler (temp 0.6 / topp 0.95 / topk 20); greedy is not viable here.
Budget the tail, not the median. 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 — the weights card has the full distribution.
Vision
These weights are text-only on their own; the vision tower ships separately as mmproj-Ornith-1.5-27B-A3B-CoderX-F16.gguf in this repo. Pass it alongside any quant:
llama-server -m Ornith-1.5-27B-A3B-CoderX-Q6_K.gguf \
--mmproj mmproj-Ornith-1.5-27B-A3B-CoderX-F16.gguf \
--port 8080 -c 262144 -ngl 99Then post an image to /v1/chat/completions as an image_url data URI, exactly as with any other multimodal llama.cpp model.
On Ollama the vision-capable tags are published under vision-<tier>:
ollama run mannix/ornith-1.5-27b-a3b-coderx:vision-Q4_K_MVerified, not assumed. The projector was loaded against this arm in llama.cpp and shown a synthetic 5-band image in a deliberately non-obvious colour order (orange, purple, yellow, teal, brown). It named all five correctly and gave the right band count; an identical prompt with no image attached correctly answered that it could not see one — so the description comes from the pixels, not the prompt.
Evaluation (Q6_K + imatrix, llama.cpp, sampler recommended)
Full 11-bench table, per-language MultiPL-E, the Qwen3.6-27B-A3B cross-family comparison and every basis caveat: [weights card](https://huggingface.co/ManniX-ITA/Ornith-1.5-27B-A3B-CoderX).
Apache-2.0 · research checkpoint.
Tool-calling benchmark — tool-eval-bench hardmode (88 scenarios, 176 pts)
Benchmarked file: `Ornith-1.5-27B-A3B-CoderX-IQ4_XS.gguf` (this repo), served on llama.cpp with MTP speculative decoding enabled. The score below belongs to THIS quant — other tiers in this repo were not run.
Ornith-1.5-27B-A3B-CoderX scores 134.0 ±2.5 of 176, ninth of ten — and this figure is a LOWER BOUND.
One of the five seeds (s42) is graded on 174 points, not 176: scenario TC-05 was dropped by an infrastructure fault on the serving side, not by a model failure. The cell was quarantined and re-run on 2026-09-09, and the fault reproduced, so the cell was kept and flagged rather than silently pooled. The plotted and tabulated value counts the dropped scenario as 0, which is why it is a floor. The excluded scenario sits in Parameter Precision, which is why that category reads 4/4 on that seed rather than 6/6.
Unlike its Coder sibling (136.8), the two are statistically indistinguishable here — overlapping CIs, and the ordering is inside the noise. Do not read CoderX as worse than Coder on this benchmark.
Category profile: perfect (100%) on Tool Selection, Restraint & Refusal, Toolset Scale and Creative Composition; Structured Reasoning 5.6/6 (93.3%). Weakest at Autonomous Planning 3.4/6 (56.7%), Context & State 12.6/20 (63.0%), Code Patterns 3.8/6 (63.3%) and Hard Mode 25.2/38 (66.3%).
14 safety-critical failures across five seeds: TC-60 on all five, TC-33 (Hallucination Resistance) and TC-58 (Fake System Message in File) on four each.
Note the quant: IQ4_XS, versus Q4KM for the A3B and Omnimerge rows.
Full cohort
* one seed (s42) is graded on 174 pts, not 176 — see that model's card.
<details> <summary><b>Basis — read before comparing these numbers to anything</b></summary>
- Scorer: `tool-eval-bench` v2.6.0 (the pip/uv-installed package, verified via
tool_eval_bench.__file__, not a git checkout). An earlier note in the runner claimedcf54b4b(v2.6.0-45); that is wrong and has been corrected — no cell ever ran it. All 50 cells ran the same v2.6.0, so the cohort is internally consistent. - v2.6.0 carries a known scorer crash on TC-62.
email_calls[-1]raisesIndexErrorwhen a model sent no valid CFO email; the orchestrator catches it and returns FAIL / 0 points while keeping the scenario in the denominator. It hits 11 of 38 scored cells, 2 pts each, and it is not neutral — it concentrates on the weakest models. Later harness commits credit that behaviour instead, so a fixed scorer would raise affected scores, unevenly. - 5 paired seeds [42–46], 64k context, context-pressure 0.25, max 8 turns, 120 s timeout, thinking enabled, sampler temp 0.6 / top-p 0.95 / top-k 20 (not greedy).
- Served on
llama.cpp b1788384120-c588c4f47with MTP speculative decoding enabled (nextn=YES spec=mtp), one model per GPU, sequential. - Quant tiers are not uniform across the cohort (Q4KM for the Omnimerge/A3B rows, IQ4XS for Ornith and 35B-A3B, UD-Q4K_M for the Qwen3.8 base). Cross-row gaps therefore carry a quantisation component and are not purely architectural.
- Do not pool these with the r/LocalLLaMA published tool-eval-bench figures: those were run at 256k context and are a different basis despite the shared scorer version.
</details>