kingjones777/Granite-4.2-30B-ROCmFP4-COHERENT-GGUF

Granite 4.2-30B (COHERENT) — ROCmFP4 for AMD Strix Halo (gfx1151)

I built this 4-bit ROCmFP4 quantization of ibm-granite/granite-4.2-30b on my Strix Halo box for the ROCmFPX runtime. Granite 4.2 landed this week; this is the 30B of my 3-tier publish set (3B / 8B / 30B).

The file

ftype	102 — Q4_0_ROCMFP4_COHERENT
size	16,685,527,744 bytes (15.54 GiB)
bpw	4.56
architecture	granite
tensors	579
context	131,072
token embedding	Q6_K
output.weight	Q6_K (protected)
sha256	21246dbb79981a56025cad3597ee8634f507a17331c5ea78ceebdb474a39b2f6

Type histogram, read from the finished file:

Q4_0_ROCMFP4 x448, F32 x129, Q6_K x2

What this build type is — and what it protects

Q4_0_ROCMFP4_COHERENT (ftype 102) quantizes the body to ROCmFP4 — my 4-bit UE4M3-scale layout — and deliberately protects the two tensors that hurt coherence most when crushed to 4-bit: the token embedding table and the LM head both stay at Q6_K. Because this model's head is untied, a 4-bit output.weight would degrade the logits of every single token; so I quantized with --output-tensor-type q6_K and confirmed the head landed at Q6_K by exact-name read-back.

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

1. Manifest gate: pulled ibm-granite/granite-4.2-30b file list from the HF API with ?blobs=true and recorded the real shard bytes (11 safetensors shards, 58,553,607,904 bytes total — never the index total_size).
2. Downloaded and byte-verified all 24 files against that manifest.
3. Converted with convert_hf_to_gguf.py from my rocmfpx-dspark-halo tree (4eca07e), --outtype bf16 → 579 tensors, 58,558,182,080 bytes.
4. Quantized with the same tree's llama-quantize at 16 threads and --output-tensor-type q6_K. Dry-run estimate 15,909.14 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	44 / 64 layers on ROCm0, rest CPU-mmap (-ngl 44 -c 4096)
generation (server-reported)	0.266 t/s over 128 tokens (480.5 s)
prompt processing	19 tokens in 5.93 s
MemAvailable	16.4 GiB before load → 3.5 GiB after

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. (then continued in its own answer/revise scaffold — real structured generation)

⚠️ Stock llama.cpp will not load this file

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

llama-server -m granite-4.2-30b-Q4_0_ROCMFP4_COHERENT.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.266 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:

13.03 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