Ornith-1.5-35B-ROCmFPX-GGUF

Ornith-1.5-35B-A3B — ROCmFPX builds for Strix Halo

ROCmFPX quantisations of Ornith-1.5-35B-A3B for AMD Strix Halo (gfx1151), with the MTP head kept live for speculative decoding.

More variants may be added later.

HYBRID: class-aware assignment

Every stock ROCmFP4 preset leaves the obvious lever unused on a 256-expert MoE: they apply one type to every tensor. The hybrid splits them:

4.41 bpw · 18.21 GiB. Routed experts are sparse (8 of 256 fire per token) and tolerate 4-bit; attention and the shared expert are on every token's critical path and get 6-bit.

Perplexity

wikitext-2, 145 chunks @ ctx 2048, identical corpus, Vulkan, all measured here:

The three stock presets cluster within 0.8% of each other — preset choice barely matters on this architecture, because none of them differentiate by tensor class. Class-aware assignment moves 4.8% for +0.14 bpw.

Perplexity measures prose next-token prediction, not agentic capability. Use it to compare quantisations of the same weights, not to rank models.

Speed (Radeon 8060S, gfx1151, Vulkan, MTP n4, -ub 2048)

Prefill is identical (within 0.5%) — it is compute-bound, so the FP6 weights cost nothing there. Decode pays the whole price: −28%, because FP6 attention means more bytes per generated token.

⇒ Pick HYBRID for prefill-dominated work (digesting repos/documents, long context, short answers). Pick FAST for generation-dominated work. The recipe is a quality/decode dial, not a free win.

Needle-in-a-haystack retrieval passes at 8.5K, 34.5K and 69.5K on both.

Backend: use Vulkan

Same build, same model, same flags — only -dev changes:

The ROCm nightly is a prefill-for-decode trade: +12% prefill over HIP 7.2 but −20% decode, and −34% decode against Vulkan. Vulkan wins overall and needs no container.

MTP head at FP4 is safe here

The nextn.eh_proj head is often kept at Q8_0 on the theory that it determines draft acceptance. Measured on this model, dropping it to FP4 did not hurt — identical perplexity to 4 decimals (7.7749 both) and slightly better acceptance:

Usage

llama-server -m Ornith-1.5-35B-HYBRID-fp6.gguf \
  -ngl 99 -c 131072 -dev Vulkan0 --jinja -fa on -b 2048 -ub 2048 \
  --spec-type draft-mtp --spec-draft-n-max 4 --spec-draft-p-min 0.6

Requires a ROCmFPX build — mainline llama.cpp does not know the Q4_0_ROCMFP4_* / Q6_0_ROCMFPX tensor types. The MTP head is native to Ornith 1.5 (blk.40.nextn.*, nextn_predict_layers=1); no graft is needed, unlike 1.0.

Reproduce the recipe with:

attn_.*=q6_0_rocmfpx
ffn_(gate|up|down)_shexp=q6_0_rocmfpx
token_embd.weight=q6_0_rocmfpx
output.weight=q6_0_rocmfpx
nextn.*=q4_0_rocmfp4_fast

llama-quantize --tensor-type-file <rules> Ornith-1.5-35B-BF16.gguf out.gguf Q4_0_ROCMFP4_FAST

Honest caveat

On wikitext perplexity, Ornith 1.0 scores far better — 6.19 (ROCmFP4-COHERENT) against 7.40 here, and the gap is present at BF16, so it is a property of the 1.5 weights and not of this quantisation. 1.0 also decodes faster (86.7 t/s) with higher draft acceptance (0.88).

Ornith 1.5 is chosen here for its reported agentic/SWE gains, which wikitext does not measure. If your workload is prose modelling rather than agentic coding, 1.0 may serve you better.