---

license: mit

base_model:

• ornith-ai/Ornith-1.0-35B

base_model_relation: quantized

pipeline_tag: image-text-to-text

library_name: gguf

tags:

• gguf
• mtp
• speculative-decoding
• apex
• v2d-lite
• moe
• vlm
• qwen3_5_moe
• imatrix

---

Ornith-1.0-35B — MTP + UD + APEX-v2D-lite GGUF

Ornith-1.0-35B with its **native

MTP head restored**, the vision projector, and an Ornith-native blended imatrix.

Eight tiers, plus the bf16 master.

Measured MTP draft acceptance: 87.4% (764/874), 49.1 t/s, with --mmproj

loaded — the highest this pipeline has recorded, against Holo-3.1's 85.0% on the

same harness and prompt mix.

Read that number honestly: it is one gate run, 874 draft tokens, on a mix of

code-novel and copy-edit prompts (copy-edit alone scored 146/147, so the mix

flatters the average). It is not comparable to acceptance figures quoted from

agentic workloads elsewhere, including this project's own 73–76% for

KAT-Coder-V2.5 — different prompts, different number. Raw runs are in

gate_spec_bench.json; compare like with like.

Why the graft is a restoration, not a transplant

Ornith-1.0-35B declares mtp_num_hidden_layers: 1 and ships zero mtp.*

tensors. Settled structurally rather than from any model card:

Qwen3.6-35B-A3B index : 1045 = 333 visual + 19 mtp.* + 693 trunk
Ornith index          : 31,666 = 333 visual + 31,333 (experts stored UNFUSED)
Ornith unfused->fused : 31,333 - (40*256*3) + (40*2) = 693   <- exact match

Every structural config field matches too (hidden 2048, 40 layers, 256/8 experts,

moe_intermediate_size 512, head_dim 256, 16/2 heads, full_attention_interval 4,

attn_output_gate, vocab 248,320).

**Ornith-1.0-35B is the Qwen3.6-35B-A3B trunk with the MTP head deleted, then RL

post-trained.** So this graft restores the head that was cut out.

Note the structure above narrows the parent to a Qwen 35B-A3B — Qwen3.5-35B-A3B

has the same 40 layers / 256 experts / moe_intermediate_size 512 and the same

Qwen3_5MoeForConditionalGeneration arch string, which is a transformers class

name and not a version marker. Only weights discriminate, so here is the control:

| tensor | vs Qwen3.6 | vs Qwen3.5 |

|---|---:|---:|

| norm.weight | 5.857e-07 | 3.081e-02 |

| layers.0.input_layernorm.weight | 4.631e-03 | 7.509e-02 |

| layers.3.self_attn.k_proj.weight | 1.651e-02 | 2.243e-01 |

| layers.3.self_attn.v_proj.weight | 2.065e-02 | 2.289e-01 |

11–52,000x closer to Qwen3.6 on every probe. **Ornith's own model card says

"post-trained on top of Qwen3.5"; the weights say otherwise.** Never trust a card

for lineage — two ranged GETs settle it.

The same probes also prove Ornith is genuinely fine-tuned and not a relabelled

base: real attention matrices moved 1.6–3.5%, where a republished base would be

byte-identical everywhere.

For scale, against Kwaipilot/KAT-Coder-V2.5-Dev (also Qwen3.6-derived), sampled

across depth — L1rel vs Qwen3.6:

| tensor | Ornith | KAT | ratio |

|---|---:|---:|---:|

| layers.3.self_attn.k_proj | 1.651e-02 | 9.202e-03 | 1.79x |

| layers.19.self_attn.k_proj | 2.965e-02 | 1.374e-02 | 2.16x |

| layers.39.self_attn.k_proj | 3.490e-02 | 1.601e-02 | 2.18x |

| layers.39.self_attn.v_proj | 3.399e-02 | 1.763e-02 | 1.93x |

**Ornith sits ~1.8–2.2x further from the base than KAT, consistently at every

depth**, and both share the same profile of divergence growing with depth.

This is attention only. Experts — 97% of the parameters — are not sampled,

because Ornith and KAT store them unfused while Qwen3.6 stores them fused, so no

direct byte comparison exists without slice-offset math. And weight displacement

measures how far weights moved, not how much training was done, and certainly not

capability.

Donor head: Qwen3.6-35B-A3B's original 19 mtp.* tensors, 844.6 M params.

A HEAD GATE asserted byte-identity with the donor before conversion —

sha256 = faac91f15cbe54475faa2578bedc46a7c29a947b8a3e7ef3ecd376ae079826ab.

The head is not fine-tuned: measured across 79 live configs, the donor head

gives 73–76% acceptance while fine-tuned heads give 45–47%.

Tiers

Ranked by active bpw — routed experts weighted 8/256 because that is what

actually fires per token, token_embd excluded (a get_rows, not a matmul).

| tier | GB | active bpw | file bpw |

|---|---:|---:|---:|

| MTP-UD-Q6_K | 30.21 | 8.063 | 6.804 |

| MTP-UD-Q5_K_S | 25.84 | 7.693 | 5.820 |

| MTP-UD-Q4_K_XL | 23.22 | 7.471 | 5.230 |

| MTP-APEX-I-Balanced-v2D-lite | 26.30 | 6.913 | 5.922 |

| MTP-UD-IQ4_XS | 18.68 | 6.762 | 4.209 |

| MTP-APEX-I-Quality-v2D-lite | 23.85 | 6.699 | 5.371 |

| MTP-APEX-I-Compact-v2D-lite | 17.57 | 5.228 | 3.956 |

| MTP-APEX-I-Mini-v2D-lite | 14.37 | 4.180 | 3.208 |

Note the two inversions against file size: **UD-IQ4_XS is 5.2 GB smaller than

APEX-I-Quality-v2D-lite at comparable active precision**, and UD-Q4_K_XL is 3.1 GB

smaller than APEX-I-Balanced-v2D-lite while scoring higher. The UD maps pin

attention, shared experts and token_embd at Q8_0 at every tier; roughly 55% of

active parameters are non-routed, so that allocation suits a sparse MoE better.

Active bpw measures where the bits go, not measured output quality.

Every tensor map was replayed from that tier's own published GGUF header by ranged

GET, never derived from parameters: Unsloth's expert bands are irregular

(ffn_down_exps = IQ4_XS ×37 on layers 0-33,35-37 / Q6_K ×3 on 34,38-39) and no

generator reproduces that. All eight predicted sizes matched the built files to

±0.01 GB.

v2D-lite = rules 2+3 (rule 4 dropped): attn_k/attn_v +1 step on the ten

full-attention layers (3,7,…,39), and output.weight +1 step. Strictly additive —

no tensor sits below its classic counterpart. Costs +128 MB/tier; Mini takes rule 2

only (+8 MB) since its output is already at the rule-3 target.

The MTP head is pinned Q8_0 in every tier (8.515 bpw measured, +204.78 MB over

letting it follow the tier). No imatrix can reach blk.40 — it is grafted after

calibration and never runs during an imatrix pass — so it is unguided RTN either

way, and draft acceptance converts directly into tokens/sec.

imatrix

ornith_imatrix_2way.gguf — a merge of the two published Ornith-native

imatrices, included so the build is reproducible.

| source | corpus | chunks | chunk_size | tokens |

|---|---|---:|---:|---:|

| bartowski | calibration_datav5.txt | 802 | 512 | 410,624 |

| unsloth | unsloth_calibration_Ornith-1.0-35B.txt | 46 | 18,432 | 847,872 |

| merged | both | 2463 | 512 | 1,261,056 |

Complementary rather than redundant: 512-token chunks capture short-context

statistics, 18k-token chunks capture long-context behaviour that 512 structurally

cannot see — worth having on a 262,144-context model. llama.cpp renormalises to a

common 512-token chunk and weights by tokens, so the effective blend is

bartowski 32.6% / unsloth 67.4%.

blk.40 is uncovered in any imatrix, by construction. That is expected, not a defect.

Vision

Ornith is a VLM (333 model.visual. tensors). *Ornith-1.0-35B-mmproj-F16.gguf

is required** — without it you have a blind model.

Speculative decoding and the projector coexist: llama.cpp only rejects

spec + batch.has_embd when draft and target differ in n_embd_inp, and a grafted

head shares the trunk. Verified live at 87.4% acceptance with the projector loaded.

Note --mmproj silently force-disables ctx_shift and cache_reuse.

Running it

llama-server -m Ornith-1.0-35B-MTP-UD-Q5_K_S.gguf \
  --mmproj Ornith-1.0-35B-mmproj-F16.gguf \
  -c 8192 -fa on --jinja \
  --spec-type draft-mtp,ngram-mod \
  --spec-draft-n-max 1 --spec-draft-n-min 0 --spec-draft-p-min 0.75 \
  --spec-ngram-mod-n-min 8 --spec-ngram-mod-n-max 24 --spec-ngram-mod-n-match 48

Also included

• BF16/ — the bf16+MTP master (71.07 GB, 753 tensors, 35.505 B params). Published

because it is expensive and immutable; any future tier rebuilds from it with no

safetensors pull, no graft and no conversion.

• original-MTP-head.safetensors — the donor head alone, for future re-grafts.
• gate_spec_bench.json — the raw acceptance measurement.
• sha256sums.txt, MANIFEST.txt.

Honest limits

• The imatrix is text-only. llama-imatrix does not accept --mmproj in any

current llama.cpp, so no visual grounding enters calibration — for anyone, not just

here. Do not read these as vision-aware imatrices.

• Acceptance was measured on one box, one gate run, 874 draft tokens.