license: mit
base_model:

• huihui-ai/Huihui-Ornith-1.0-35B-abliterated-GGUF
  base_model_relation: quantized
  pipeline_tag: image-text-to-text
  library_name: gguf
  tags:
• gguf
• mtp
• speculative-decoding
• apex
• v2d-lite
• moe
• vlm
• abliterated
• uncensored
• qwen3_5_moe

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

huihui-ai's abliterated Ornith-1.0-35B
with an MTP head grafted in, the vision projector, and eight tiers.

Measured MTP draft acceptance: 86.4% (748/866), 44.1 t/s, --mmproj loaded.

This build is deliberately a one-variable change from the faithful
gbuzhf/Ornith-1.0-35B-MTP-UD-APEX-GGUF:
identical MTP head, identical tensor maps, identical imatrix. Only the trunk is
abliterated. That is what makes the two comparable at all.

Same harness, same prompt mix, so this comparison is like-for-like. Abliteration
cost about one point of draft acceptance — the un-abliterated head still fits the
abliterated trunk nearly as well.

Tiers

Ranked by active bpw — routed experts weighted 8/256 because that is what
actually fires per token, token_embd excluded (it is a get_rows, not a matmul).
It is a measure of where the bits go, not a measured quality score.
Every file size matched its pre-build prediction to 0.01 GB.

The MTP head is pinned Q8_0 in every tier (8.515 bpw measured). 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.

Note the two inversions against file size. UD-IQ4_XS (18.68 GB) scores above
APEX-I-Quality-v2D-lite (23.85 GB) on the active path, and UD-Q4_K_XL (23.22 GB)
above APEX-I-Balanced-v2D-lite (26.30 GB). The UD maps pin attention, shared
experts and token_embd at Q8_0 at every tier, and roughly 55% of active
parameters are non-routed — attention, the shared expert and the 508 M-param output
head all run on every token, while routed experts contribute 8/256. If you are
choosing on quality per GB, start from the top of this table, not from file size.

How the MTP head got here

huihui-ai publishes the abliterated model as bf16 GGUF only — there are no
abliterated safetensors on the Hub. The usual path grafts 19 mtp.* tensors into
safetensors and then converts, which was impossible, so the graft was done one
stage later, directly at GGUF level:

+ 20 blk.40.* tensors, copied byte-for-byte from the faithful build's bf16 master
~ qwen35moe.block_count            40 -> 41
+ qwen35moe.nextn_predict_layers   (absent) -> 1

The donor head is Qwen3.6-35B-A3B's original MTP head (844.6 M params), which
passed a byte-identity HEAD GATE in the faithful build —
sha256 faac91f15cbe54475faa2578bedc46a7c29a947b8a3e7ef3ecd376ae079826ab. So this
repo provably carries the same head as the faithful one.

Verified before building: huihui's 733 tensor names are identical to the
reference, and all shapes agree once trailing 1s are normalised (huihui writes
ffn_gate_inp_shexp as [2048, 1], convert_hf_to_gguf.py writes [2048] — the
same 2048 values). A grafted-master gate then asserted 753 tensors, 20 in blk.40,
block_count=41, nextn_predict_layers=1.

Vision

Huihui-Ornith-1.0-35B-abliterated-mmproj-F16.gguf (0.90 GB) is required —
without it you have a blind model. It is huihui-ai's own projector, kept separate
so one copy serves all eight tiers.

llama-server -m Huihui-Ornith-1.0-35B-abliterated-MTP-UD-Q5_K_S.gguf \
  --mmproj Huihui-Ornith-1.0-35B-abliterated-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

--mmproj silently force-disables ctx_shift and cache_reuse.

Honest limits — read these

• The imatrix was computed on the UN-abliterated model. It is the same 2-way
  Ornith-native merge (bartowski calibration_datav5 + unsloth, 2463 chunks,
  1.26 M tokens) used by the faithful build. Abliteration changes activation
  statistics, so a base imatrix will misallocate precision to some degree, and on a
  256-expert MoE it can misdescribe routing too. This was a deliberate trade to
  keep the build on a CPU box and to hold every variable except the trunk constant.
  It is the one known-suboptimal ingredient here.
• Acceptance is one gate run, 866 draft tokens, on a code-novel + copy-edit
  prompt mix. Comparable to the faithful build's 87.4% because it is the identical
  harness — not comparable to acceptance figures quoted from other harnesses.
• Abliteration is not free. It moves weights off the trained optimum by design,
  and that cost is separate from and additional to quantization error. If you do not
  need refusal removal, use the faithful build.

Also included

• BF16/ — the abliterated bf16 + MTP master (71.07 GB, 753 tensors), so any
  future tier rebuilds from it with no graft and no conversion.
• sha256sums.txt