serve: Hadamard-rotated Q4_0 files run on --device hrx too

[bong-water-water-bong]

Hadamard-rotated Q4_0 files (tools/hadamard_q4_0.py, stamped onebit.hadamard_q4_0 = 32) now run on --device hrx. Until now they ran on the lean ROCm route only.

Merge after the third_party/llama.cpp pin that includes fork #58: the bump to bd5b297 (fork #58-#61). Without #58 the HRX build doesn't rotate the activations, and output is garbage (PPL 550,134).

Changes

• serve: accepts --device hrx for a rotated file and runs it on HRX0, with neither GGML_W4A4_TENSORS nor a process-wide Hadamard variable. Our llama.cpp reads the stamp itself (llama-hadamard, fork Lean: ROCmI4 on Vulkan (our ROCmFPX fork); the bump rebases our commit #58).

• --device auto still picks ROCm for these files. No fast HRX prompt kernel decodes Q4_0 yet: the q8_1 x4 template covers Q4_K, Q5_K and IQ4_XS only, so H32 prompts take HRX's generic path.

• H32 vs the UD-Q4_K_XL file on HRX: H32 is both less accurate and slower.

  Qwen3.8-27B on HRX0	KLD vs BF16	pp512
  H32	0.029	63.5 tok/s
  UD-Q4_K_XL	0.007	335 tok/s

  This route keeps existing H32 files working on HRX; for new HRX use the UD file is the better choice. Making H32 fast would take a Q4_0 branch in the wmmai8 prompt template (exact in-kernel scale and min, same 144 bytes per 256 weights as Q4_K). Nobody is working on that now.

• Docs: docs/hrx.md gets a section and docs/lean.md a pointer.

HRX numbers

Qwen3.8-27B-Q4_0-H32 on HRX0, measured on fork #58:

PPL (wikitext-2, 40 × 512)	6.021
KLD vs BF16 logits	0.0292
Same top token	92.5%
pp512	63.5 tok/s
pp2048	62.4 tok/s
tg64	11.65 tok/s

The speed figures are from a build before #55.

Tests

• tests/hadamard_route.sh: --device hrx → HRX0, with neither variable.
• ctest -LE gpu: 19/19 pass.

🤖 Generated with Claude Code

[context7]

Docs7 for 1bit-monster/engine

Result	Status	Action
Deployment	➖ Not used	—
Content review	➖ Did not run. This site has no agent runs available this month. Wait for the monthly reset or check your Docs7 plan.	—

Commit 2eca400

[bong-water-water-bong]

Review (PR-Agent duty). Correct.

• --device hrx for a stamped file runs on HRX0 with neither GGML_W4A4_TENSORS nor a process-wide Hadamard variable, which is right since our llama.cpp reads the stamp itself (fork Lean: ROCmI4 on Vulkan (our ROCmFPX fork); the bump rebases our commit #58).
• The test covers it, and the PPL/KLD are from Lean: ROCmI4 on Vulkan (our ROCmFPX fork); the bump rebases our commit #58 (6.021 / 0.0292, against ROCm exact 6.008 / 0.0284).

Merge order: after bcloud-ae's third_party/llama.cpp bump to 68805cc (the one with #58). Without it, HRX output is garbage.

Direction note (owner, 2026-10-01: zero ROCm): auto keeping ROCm for these files is a temporary exception. Please list it in docs/hrx.md as debt, and move auto to HRX in the PR that routes Q4_0 prompt matmuls to the fast kernel.