Qwen3.8-27B-Omnimerge-v6 — the v4 merge, rebased on Qwen3.8

~27B dense hybrid · 64 layers (48 gated-SSM / 16 full-attention) · 256k native context · MTP head + vision tower

A three-source task-arithmetic merge on top of Qwen/Qwen3.8-27B — the same sources, weights and merge method as Omnimerge v4, which was built on Qwen3.6-27B. v6 moves that recipe onto the newer base generation. No fine-tuning and no distillation of its own: only weight-space arithmetic over published checkpoints.

Full model card & methodology: ManniX-ITA/Qwen3.8-27B-Omnimerge-v6-MTP-GGUF · bf16 weights on Hugging Face.

How it works

Three sources — rico03 Claude-Opus-Distill (0.40), ValiantLabs Esper 3.1 (0.35) and a kai-os LoRA anchor (0.25) — are merged with omnimerge_v2 at density 0.53, darex-q 0.75, seed 42. Attention, norms and embeddings take the merge; mlp.gate_proj / up_proj / down_proj are passed through from the base.

The load-bearing detail is the task base. Every source was fine-tuned from Qwen3.6-27B, so each delta is computed against 3.6, not against the 3.8 target. Skip that and delta = source − 3.8 silently embeds the inverse of the 3.6→3.8 generational upgrade and drags the merge backwards; on a sampled q_proj the built artifact sits at ‖out − 3.8‖ = 1.09 against ‖out − 3.6‖ = 67.78.

Two things were verified rather than assumed before the merge ran. Vocabulary: vocab.json and merges.txt are sha256-identical between Qwen3.6-27B and Qwen3.8-27B; 3.8 adds 7 tokens purely additively at ids 248070–248076 and reassigns none. Vision: all 333 model.visual.* tensors in the merge are bit-identical to the base, which is why the official Qwen3.8 projector is the correct mmproj for the vision- tags.

The MTP (next-token-prediction) head is deliberately not merged. All three sources carry the 15 mtp.* tensors, so the default would paste a 3.6-trained head's delta onto 3.8's head. MTP affects draft-acceptance rate only — it costs decode speed, and it costs it silently. 3.8's head is preserved verbatim and ships in every GGUF as blk.64.* (blocks 0..64, 866 tensors).

Evaluation — sampled cohort (Q6_K, llama.cpp b9700, temp 0.6 / top-p 0.95 / top-k 20)

These are sampled-cohort numbers (do_sample=true), run for both models on the same binary, the same benches and the same sampler. They are comparable to each other and not to greedy-decode numbers from anywhere else — including the greedy tables on other cards. Don't pool the two.

▲ beats v4 · = exact tie. One result here is real and the rest are noise, so read the table with that in mind. LiveCodeBench is the signal: 0.883 against v4’s 0.818, +6.5pp, 68 of 77 problems solved against 63. That is the only cell outside the measurement band. The ±1pp cells — IFEval and MultiPL-E — are not differences: a same-basis repeat of MultiPL-E-100 on this rig moved 1.0pp from batch scheduling alone, and a sampled cohort like this one is at least that noisy. HumanEval ties outright. GPQA’s −2pp is 4 questions of 198 — suggestive of a small real loss, not established by one run. The +1.3pp mean is carried almost entirely by LiveCodeBench.

Where v6 differs is how it spends its thinking budget. On GPQA, v6's reasoning channel has a median of 19,488 characters against v4's 12,010 (+62%), while its answer channel is shorter — 1,192 against 2,237 (−47%). Total output rises only ~10%: v6 moves work out of the answer and into the reasoning. It is also more dispersed, not uniformly verbose (p10 reasoning 2,179 vs v4's 5,865). The practical consequence: 6 of 198 GPQA questions ran past an ~8192-token thinking budget and scored zero, where v4 had none. Give v6 headroom.

Agentic behaviour — v6 thinks about 3× longer for the same result

Ten paired runs of the same agentic fix harness (task TX-01), v6 against v4, identical Modelfile lineage so the comparison isn't confounded by config:

Both models solved the task every time, in statistically indistinguishable numbers of iterations. The whole gap is thinking volume. It is not a serving artifact — v6 generates faster (149 chars/s of thinking vs v4's 125), it simply generates far more.

The 3.8× decomposes into two independent factors: v6 emits 1.47× more reasoning blocks, and each block is roughly 2.6× longer. Neither alone accounts for the gap.

And a structural difference, not a quantitative one: v6 reasons on every single turn — 1.00 blocks per iteration, exactly. v4 runs at 0.81, meaning it acts without deliberating on roughly one turn in five. v4 is not merely thinking less when it thinks; it sometimes skips deliberation entirely and just acts. No v6 run ever does. If you want a model that always deliberates before acting, that is what you are buying; if you want one that can act directly on an easy step, v4 still does that and v6 does not.

Corrected 2026-09-03: an earlier revision of this card reported thinking volume at twice its true value (636 K / 168 K). Medians, ranges and the chars/s figures above are the corrected ones. The ratio (3.8×) and the Mann-Whitney statistics are unchanged — doubling every observation is monotone, so it cannot alter ranks.

Read this next to the LiveCodeBench row above rather than against it. The extra thinking is not free and it is not wasted either — it buys +5 solved LiveCodeBench problems where there is headroom to gain, and buys nothing on a task both models already close 10 times out of 10. What you are paying for is a better shot at the problems v4 misses.

Two caveats worth keeping on the record. The tails overlap: v6's fastest run (999 s) beats three v4 runs, and v4's slowest (1,988 s) beats six v6 runs — "v4 is typically ~3× faster" is supportable, "always faster" is not. v4 is also less predictable: its relative dispersion is wider, a 7.9× range against v6's 4.4×.

Which tier to pull

Nineteen tiers, same ladder as the v4 MTP repo. Everything at Q3 and below plus the IQ / IQ4 tiers is built with imatrix; Q4_K_M and up are not, which is a measured policy on this family rather than an omission — imatrix stops paying for itself above ~4 bits here. Append vision- to any tag for the multimodal tower, e.g. :vision-Q4_K_M.

Pull

ollama run mannix/omnimerge-v6                # :latest = Q4_K_M, ~16.8 GB
ollama run mannix/omnimerge-v6:Q6_K           # the tier every eval number above was measured on
ollama run mannix/omnimerge-v6:vision-Q4_K_M  # + vision tower (multimodal)
ollama run mannix/omnimerge-v6:IQ2_S          # smallest, fits 12 GB

What the tags ship — requires ollama 0.33+

Every tag carries the same serving identity as the official qwen3.8:27b, copied verbatim from its published manifest rather than guessed:

RENDERER  qwen3.8
PARSER    qwen3.5          # note: there is no "qwen3.8" parser in ollama
PARAMETER draft_num_predict 4
PARAMETER min_p 0
PARAMETER presence_penalty 0
PARAMETER repeat_penalty 1
PARAMETER temperature 1
PARAMETER top_k 20
PARAMETER top_p 0.95

Because the tags declare RENDERER qwen3.8, they need ollama >= 0.32.12 (0.33.x recommended). On an older build the model downloads, loads, and reports healthy VRAM in ollama ps — then fails at prompt-render time with unknown renderer "qwen3.8". If you see that, upgrade ollama; nothing is wrong with the model.

The one parameter deliberately not pinned is num_ctx, since the right value depends on your VRAM. It is the one to think about. The architecture is good for 256k natively, and only 16 of the 64 layers carry a KV cache (the other 48 are gated-SSM), so context is unusually cheap here — but ollama's default is far below what this model wants, and v6 in particular will happily spend tens of thousands of tokens thinking. Give it room, or you will truncate reasoning and score zeros the way the 6 capped GPQA questions did:

ollama run mannix/omnimerge-v6
>>> /set parameter num_ctx 65536

Good to know

• Native MTP head ships in every GGUF for speculative decoding, alongside the vision- mmproj tower. Measured on Q4_K_M under llama.cpp: 2.0× decode throughput (69.4 → 140.4 tok/s) at --spec-draft-n-max 3, 0.73 draft acceptance. ollama does not implement MTP, so the head is inert here — this speedup is a llama.cpp-only benefit.
• The one measured reason to prefer v6 is LiveCodeBench, +6.5pp. Everything else on the cohort is a tie or inside the noise band, and GPQA may be slightly worse. If you are pulling this for hard coding problems, that is the trade — paid for with markedly longer thinking. For GPQA-shaped reasoning on a tight budget, v4 is still the cheaper answer.
• imatrix.dat is archived in the GGUF repo — the imatrix tiers are reproducible and auditable.

Links: HF · GGUF + full card · HF · bf16 weights · base model · Omnimerge v4

Apache-2.0 · research checkpoint.