Apodex-1.1-mini — ROCmFPX 8-bit reference layout for AMD Strix Halo (gfx1151)

I built this reference 8-bit ROCmFPX quantization of apodex/Apodex-1.1-mini (Qwen3.5- derived hybrid MoE, 262K context) on my Strix Halo box.

The file

ftype 111Q8_0_ROCMFPX
size 35,820,690,688 bytes (33.36 GiB)
bpw 8.27
architecture qwen3_5_moe (hybrid linear-attention + full-attention MoE)
tensors 733
context 262,144
experts 256 routed, 8 active per token + shared expert
token embedding Q8_0_ROCMFPX
output.weight Q8_0_ROCMFPX
sha256 575a3b0ec6b75df5ff30830a050ff0ef25d8cec6435d54973680ac729bdad590

Type histogram, read from the finished file:

Q8_0_ROCMFPX x432, F32 x301

What this build type is — and what it protects

Q8_0_ROCMFPX (ftype 111) is my reference 8-bit ROCmFPx layout: every weight tensor — including token_embd.weight and output.weight — goes into the ROCmFPX 8-bit UE4M3-scale reference format. Nothing is held back at plain Q8_0 (contrast with my _AGENT tier, which keeps the output-side tensors at plain Q8_0 for tool-call coherence). At 8 bits the quality gap between the two tiers is small; take this one for size/speed, take _AGENT if you serve tools.

tie_word_embeddings is false on Apodex, so output.weight is a real standalone tensor. I verified the head types by reading the finished file back by exact tensor name (token_embd.weight and output.weight — exact match, not substring).

Text-only, trunk-only — stated up front

  • No vision tower. The upstream repo is multimodal; this GGUF carries the language model only. No mmproj is included.
  • No MTP head. My converter's MTP merge path dies on this checkpoint's de-fused mtp.layers.0.mlp.experts.* tensors (KeyError: 'model.layers.0.mlp.experts.0.down_proj.weight' in the Qwen2Moe merge loop), so I converted with --no-mtp. The 40-layer trunk is complete (733 tensors); speculative MTP drafting is not available from this file. I do not publish what I have not verified.

How I built it

  1. Manifest gate: pulled apodex/Apodex-1.1-mini file list from the HF API with ?blobs=true and recorded the real shard bytes (15 safetensors shards, 71,903,869,048 bytes total — never the index total_size).
  2. Downloaded and byte-verified all 28 files against that manifest.
  3. Converted with convert_hf_to_gguf.py from my rocmfpx-dspark-halo tree (4eca07e), --outtype bf16 --no-mtp → 733 tensors, 69,376,638,528 bytes. The checkpoint ships fused expert tensors (mlp.experts.gate_up_proj / mlp.experts.down_proj); this converter's Qwen2Moe base ingests the fused layout directly.
  4. Quantized with the same tree's llama-quantize at 16 threads. Dry-run estimate 34,150.79 MiB; the real file landed within ~11 MiB of it.

Measured on my box — partial-offload functional check, stated plainly

amd-halo: AMD Ryzen AI Max+ 395 (Strix Halo, gfx1151), ROCm 7.13.0, 125 GiB unified memory. At test time this box was serving 8 live llama-server seats holding ~107 GiB of unified memory, leaving me ~16 GiB. A full -ngl 999 --no-mmap load does not fit in that headroom, so I functionally checked with partial offload instead:

offload 9 / 40 layers on ROCm0, rest CPU-mmap (-ngl 9 -c 2048)
generation (server-reported) 0.292 t/s over 48 tokens (164.6 s)
prompt processing 19 tokens in 33.7 s
MemAvailable 16.5 GiB before load → 8.0 GiB after

Greedy, port 8497, -t 16, --jinja. These t/s numbers are limited by streaming the CPU-resident layers, not by the ROCm path — treat them as load-and-generate proof with the server's own timing, not as the speed you will get on an idle box. Full-offload throughput: not measured (would require freeing the seats — I don't touch my live seats).

Sample output (greedy, prompt "Explain in one clear sentence what granite rock is primarily made of."):

<think> Thinking Process: 1. Analyze the Request: … (native thinking-mode generation)

⚠️ Stock llama.cpp will not load this file

Q8_0_ROCMFPX is a custom tensor format that exists only in the ROCmFPX fork of llama.cpp.

llama-server -m apodex-1.1-mini-Q8_0_ROCMFPX.gguf -dev ROCm0 -fa on -ngl 999 -c 8192   # on a box with the memory for it

Not measured

No benchmark sweeps, no context sweeps, no perplexity, no full-offload throughput — per my build discipline this is the 3-tier publish set and one functional check per tier.

Provenance & license

Converted and quantized from apodex/Apodex-1.1-mini (Apache 2.0). This quantized build is released under the same Apache 2.0 license. The ROCmFPX runtime is a third-party fork; its own terms apply to the runtime, not to these weights.

Downloads last month
-
GGUF
Model size
35B params
Architecture
qwen35moe
Hardware compatibility
Log In to add your hardware

8-bit

Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Model tree for kingjones777/Apodex-1.1-mini-ROCmFPX-Q8_0-GGUF

Quantized
(13)
this model