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

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

I built this STRIX_LEAN quantization of ibm-granite/granite-4.2-30b on my Strix Halo box for the ROCmFPX runtime. This is the 4th tier of my Granite 4.2 set — the lean 4-bit one people normally want.

The file

ftype	106 — Q4_0_ROCMFP4_STRIX_LEAN
size	15,758,521,024 bytes (14.68 GiB)
bpw	4.31
architecture	granite
tensors	579
context	131,072
token embedding	Q5_K (the LEAN part)
output.weight	Q6_K (protected)
sha256	7655ed029c1eeeee0624a49413d648020cedec8277e64be235a36a50486b9573

Type histogram, read from the finished file:

Q4_0_ROCMFP4_FAST x320, F32 x129, Q4_0_ROCMFP4 x128, Q6_K x1, Q5_K x1

What STRIX_LEAN is — and what it protects

STRIX_LEAN is my lean 4-bit tier. The body is ROCmFP4 with the Strix Halo attention K/V quality recipe (that is what the STRIX part buys you), and the token embedding table is trimmed to Q5_K — that is the LEAN part, the size saving versus my COHERENT tier, which keeps the embeddings at Q6_K.

What never gets trimmed is the head. Every STRIX_LEAN I publish carries the protected Q6_K LM head. This model has tie_word_embeddings: false, so output.weight is a real standalone tensor, and a 4-bit head would degrade the logits of every single token. I quantized with --output-tensor-type q6_K and confirmed the head landed at Q6_K by exact-name read-back on the finished file (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 (sizes + LFS sha256).
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 with --output-tensor-type q6_K. Dry-run estimate 15,025.08 MiB (4.31 bpw); the real file landed within ~3.4 MiB of it.

Speed — full offload

generation (server-reported)	—

Full-offload speed being measured on an idle box, card will be updated.

My build box currently serves 8 live llama-server seats that hold the unified memory a full -ngl 999 --no-mmap load of a 14.7 GiB file would need, and I do not publish partial-offload numbers — a partial-offload t/s measures CPU weight streaming, not the ROCm path, and publishing one would misrepresent this build. So: no number yet, and no made-up number either.

⚠️ Stock llama.cpp will not load this file

Q4_0_ROCMFP4_STRIX_LEAN 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_STRIX_LEAN.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 — and no partial-offload numbers, per my build discipline.

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.

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