Ternary Bonsai on HRX: exact PTQ1_0 -> Q4_0 converter, prism.hadamard route, pin llama.cpp b8d587e

[bong-water-water-bong]

PrismML's Ternary-Bonsai-2-27B (Qwen3.8-27B trained to weights of -1/0/+1) now runs on HRX0.

What's in it

• tools/ternary_to_q4_0.py writes PrismML's PTQ1_0 weights as Q4_0, bit for bit: q = trit + 8, with the group's own fp16 scale in each of its four blocks. It decodes every group back before keeping the file, and stamps onebit.ternary_q4_0 = 128. The decoder matched PrismML's own libggml to_float on 210 M real Bonsai weights with 0 mismatches; tests/ternary_to_q4_0_test.py checks the tool against PrismML's encoder in CI.
• 1bit serve sends a prism.hadamard file to --device hrx (auto picks it) and refuses every other device, since upstream llama.cpp would ignore the rotation and answer garbage. It refuses PrismML's own ternary types with the converter's name. Covered by tests/prism_route.sh.
• Pin: llama.cpp acf9c74 -> b8d587e, which is only llama.cpp site: GoatCounter visitor counts #34 (the prism.hadamard loader).
• docs/hrx.md: how to run it, and what was checked.

Checked on strixhalo (gfx1151)

• Perplexity against PrismML's F16 on CPU: wikitext-2 running PPL on HRX0 is 7.962 / 10.408 / 10.171 at chunks 5 / 10 / 15, against 7.958 / 10.382 / 10.142 for PrismML's F16 on CPU. The gap is Q4_0's 8-bit activations.
• Same KLD as PrismML's own stack: KLD against Qwen3.8-27B BF16 (40 × 512) is 0.3607 on HRX0; PrismML's own PTQ1_0 / PQ2_0 on its Vulkan fork give 0.3588. This is distance from Qwen3.8, not quality loss: Bonsai is a separately trained model.
• Serving works: 1bit serve --device hrx gives 14.3 / 14.9 / 13.9 tok/s on the code / prose / short prompts, and answers "Paris". PrismML's PTQ1_0 on Vulkan decodes 27.8 tok/s, which is what a native ternary HRX kernel would win back.
• Route tests: prism_route, hadamard_route and long_route pass. ternary_to_q4_0_test.py passes, and fails when the trit order is broken on purpose.

🤖 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 0559725

[bong-water-water-bong]

Pushed afbfaa8: registry regenerated for b8d587e. registry_pins failed because the registry still recorded acf9c74. Holding the merge for the HRX0 perplexity check of the new pin (ZAYA1-8B and Qwen3-0.6B against acf9c74), which is queued behind the box lock.

[bong-water-water-bong]

Review (standing in for PR-Agent while coder-llm is paused for the leaderboard sweep)

Read the full diff: converter, serve route, tests, docs, pin and registry.

tools/ternary_to_q4_0.py: correct.

• Trit order matches PTQ1_0's layout:
  • bytes 0-15 give value 16n + m (trit n of byte m);
  • bytes 16-23 give 80 + 8n + m;
  • the two qh bytes give 120 + 2n + h, as 4 trits plus a padding trit.
• q = t + 8 with the group's fp16 d repeated into all four Q4_0 blocks reproduces t * d exactly.
• The byte arithmetic cannot overflow: at most 255 * 81 fits in uint16.
• The tool writes to a .part file, reads everything back, then renames. It also stays bounded in memory: 64K groups per step, through memmap.
• The test encodes with PrismML's own encoder, not the tool's decoder, so it is independent of the code under test.
• Nit (no change needed): any tensor type outside F32/F16/BF16/Q4_0/PTQ1_0 stops with an error rather than being copied. That's the safe choice; if a later Bonsai file carries e.g. a Q8_0 output head, SIZES needs its block size.

serve: routing is right.

• A prism.hadamard file with --device auto goes to hrx; every other device is refused, and --laya is refused too.
• A file still in PrismML's own ternary types is refused with the converter's name.
• On HRX, qwen35 already gets one slot (serve: one slot for Qwen3.5/3.8 on HRX when --parallel is not given #244) and refuses --parallel (serve --parallel on HRX: shared KV cache, no qwen.attention (Qwen3-4B 4 slots 39 -> 153 tok/s) #240), so Bonsai (qwen35 arch) is covered for multi-sequence.
• prism_route.sh covers all four routes.

CI: the one change adds a test step; permissions are untouched.

Pin and registry:

• b8d587e is fork site: GoatCounter visitor counts #34 on top of acf9c74 (which contains blog: HRX answers long prompts correctly, and where Unsloth quants pay #47/Docs chat on 1bit.gg: Context7 widget + context7.json #48).
• The registry now records b8d587e (afbfaa8), so registry_pins passes.

HRX0 check of the pin against acf9c74, wikitext c512 x4:

• Qwen3-0.6B Q4_K_M: 20.0214 on both.
• ZAYA1-8B: the run on the new pin tripped the 93 C guard twice while compiling kernels on a fresh build. A retry on 8 cores is queued behind the box lock. Merge after it matches 33.4549.

[bong-water-water-bong]

HRX0 check of b8d587e against acf9c74 (wikitext, c512 b512):

• Qwen3-0.6B Q4_K_M, 4 chunks: 20.0214 on both pins.
• ZAYA1-8B Q4_K_M, running PPL at chunks 1 / 2 / 3: 22.5570 / 35.6413 / 32.8290 on both pins, identical to the last digit. On the new pin the 4th chunk was cut three times by the 93 C thermal guard: prefill is 0.72 s per pass and spikes the CPU temperature. The acf9c74 run finished at 33.4549.

Files without prism.hadamard keys build the same graph, as the PR says. Merging.