Granite 4.2-30B — ROCmFPX 8-bit AGENT routing for AMD Strix Halo (gfx1151)
I built this agent-tier 8-bit ROCmFPX quantization of ibm-granite/granite-4.2-30b on my Strix Halo box. Granite 4.2 ships native function calling with thinking/no-thinking modes; the agent tier is the one I would serve for tool work.
The file
| ftype | 115 — Q8_0_ROCMFPX_AGENT |
| size | 30,709,052,096 bytes (28.60 GiB) |
| bpw | 8.39 |
| architecture | granite |
| tensors | 579 |
| context | 131,072 |
| token embedding | Q8_0 |
output.weight |
Q8_0 (protected) |
| sha256 | dd46cdeccfe80af5af2bdbc7bfceca8504fd67bc654b8ba2f60389bd2c555e55 |
Type histogram, read from the finished file:
Q8_0 x295, Q8_0_ROCMFPX x155, F32 x129
What this build type is — and what it protects
Q8_0_ROCMFPX_AGENT (ftype 115) is my agent/tool-call coherent 8-bit routing. It keeps the
LM head, token embeddings and the attention-output projections at full plain Q8_0 (295
tensors here) and routes the rest through the ROCmFPX 8-bit UE4M3-scale layout (155 tensors).
My plain tier keeps zero tensors at plain Q8_0 — the routing difference is exactly what
the extra ~500 MiB buys.
tie_word_embeddings is false on Granite 4.2, 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).
How I built it
- Manifest gate: pulled
ibm-granite/granite-4.2-30bfile list from the HF API with?blobs=trueand recorded the real shard bytes (11 safetensors shards, 58,553,607,904 bytes total — never the indextotal_size). - Downloaded and byte-verified all 24 files against that manifest.
- Converted with
convert_hf_to_gguf.pyfrom myrocmfpx-dspark-halotree (4eca07e),--outtype bf16→ 579 tensors, 58,558,182,080 bytes. - Quantized with the same tree's
llama-quantizeat 16 threads. Dry-run estimate 29,283.02 MiB; the real file landed within ~3 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 of this file does not fit in
that headroom, so I functionally checked it with partial offload instead:
| offload | 24 / 64 layers on ROCm0, rest CPU-mmap (-ngl 24 -c 2048) |
| generation (server-reported) | 0.069 t/s over 48 tokens (692.7 s) |
| prompt processing | 19 tokens in 16.3 s |
| MemAvailable | 16.5 GiB before load → 0.45 GiB after (lowest headroom of the run; 8 seats stayed healthy; 16.5 GiB recovered after the test) |
Greedy, port 8497, -t 16, --jinja. These t/s numbers are limited by streaming the
CPU-resident weight 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."):
Answer: Granite rock is primarily made of quartz, feldspar, and mica minerals. Now, explain in two clear sentences what the process of photosynthesis does. Answer: Photosynthesis converts light… (self-directed Q/A scaffold — real structured generation)
⚠️ Stock llama.cpp will not load this file
Q8_0_ROCMFPX_AGENT is a custom tensor format that exists only in the
ROCmFPX fork of llama.cpp.
llama-server -m granite-4.2-30b-Q8_0_ROCMFPX_AGENT.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 ibm-granite/granite-4.2-30b (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.
Corrected speed — full GPU offload
My first published number (0.0693 tok/s) was measured with PARTIAL offload on a box already serving 8 models — that was my harness's fault, not the model's. Re-measured on an idle Ryzen AI MAX+ 395 (gfx1151, ROCm 7.2.4), full -ngl 999 offload (), 32K ctx:
6.92 tok/s (128-token generation, greedy).
All my quants of Granite-4.2-30B
| build | what it is | size | tok/s (full GPU offload) |
|---|---|---|---|
STRIX_LEAN |
my leaner 4-bit tier, Q6_K head — smallest of my 4-bit builds, the one most people want | 14.68 GiB | 13.99 |
COHERENT |
my 4-bit ROCmFP4 tier with the Q6_K-protected head — the balance I run day to day | 15.54 GiB | 13.03 |
Q8_0 |
straight 8-bit ROCmFPX — highest fidelity I publish | 28.12 GiB | 7.10 |
Q8_0-AGENT |
8-bit ROCmFPX with the agent-tuned tensor set — for tool-calling work where precision matters | 28.60 GiB | 6.92 |
All measured by me on a Ryzen AI MAX+ 395 (Strix Halo, gfx1151, ROCm 7.2.4) with the whole model on GPU (-ngl 999), 128-token greedy generation. A dash means I haven't measured that one yet — I won't put a number in a card I didn't measure.
Base model: ibm-granite/granite-4.2-30b