clm-0052 — claim — HALOBENCH

On gfx1151, stock ROCm 3653e6d's own BF16 KV decode is SLOWER than its own F16 KV decode: 29.26 t/s vs 42.35 t/s at 32,768 depth (Qwen3.6-35B-A3B, fa on) — a 31% penalty for switching to the KV type the community recommends for its quality, with prefill roughly unchanged (587.4 vs 595.0). stew675's rdna-boosts branch (commit ed89854) fixes it with a native BF16 flash-attention tile kernel: 47.31 t/s BF16 decode, +61.7% over stock's own BF16 and stock's best config on this chip. Upstream commit a94d563 — six days ahead of 3653e6d and the exact base ed89854 is rebased on — reproduces the same BF16 penalty (29.12 t/s), so the fix is stew675's kernel work, not upstream drift absorbing it for free.

METHOD — same rdna-boosts-challenger matrix as the anchor-pair calibration in bench/protocol.json: Qwen3.6-35B-A3B UD-Q4_K_XL, ROCm, fa on, pp1024/tg256, llama-bench defaults otherwise (-b 2048 / -ub 512), median of 3 fresh-process reps with page cache dropped between reps, 45/45 reps rc=0. Four arms at d32768: | build | KV | pp1024 | tg256 | |---|---|---|---| | 3653e6d (stock baseline) | f16 | 595.0 | 42.35 | | 3653e6d (stock baseline) | bf16 | 587.4 | 29.26 | | a94d563 (upstream, 6 days ahead) | f16 | 593.7 | 42.12 | | a94d563 (upstream, 6 days ahead) | bf16 | 588.3 | 29.12 | | ed89854 (stew675/rdna-boosts) | f16 | 607.3 | 44.96 | | ed89854 (stew675/rdna-boosts) | bf16 | 651.4 | 47.31 | BUILDS — 3653e6d: fleet stock baseline, all pre-Aug-10 runs (bench/protocol.json). a94d563: upstream llama.cpp a94d563ed801d1da1b8c2432946de07d0231bb3d (2026-08-13, PR #27026), built on-box 2026-08-14 with the same ROCm flags as every other arm; exists solely to de-confound stew675's branch from ordinary upstream drift — it is the exact commit rdna-boosts is rebased on. ed89854: stew675/llama.cpp branch rdna-boosts, head ed89854b2aeb0e333dd61424f14af2aedaca126e (2026-08-13T21:09Z), built on-box 2026-08-14 with the stock ROCm flags, like-for-like with 3653e6d except the branch's kernel-fusion changes (see clm-0044's "what it does to clm-0031" thread — this is the consolidated branch that PR-26856's BF16 flash-attention tile path became part of). THE TRAP — a94d563 is proof the bf16 penalty is not something upstream fixed in the six days between it and 3653e6d: its own bf16 decode (29.12 t/s) matches stock's (29.26 t/s) within reps. The fix lives ENTIRELY in stew675's fork, which is unmerged and carries a divergence disclosure the moment any config depends on it (src/content.config.ts `runtime.divergence`) — this is a CARRIED FORK, not something a fresh `git pull` on 3653e6d or on any near-future upstream commit will give you. PR-26856, the BF16 flash-attention tile path this branch builds on, is itself still unmerged and unreviewed upstream (clm-0044, clm-0046) — adopt-watch policy applies to any production use of ed89854, not just the PR. CROSS-REFERENCE TO clm-0046 — that claim measured BF16 KV as a near-free QUALITY upgrade over F16 (+0.04% PPL vs F16's +5.8%, PR-26856 author's numbers on a 4B model). The quality case for adopting BF16 KV is sound and this claim does not contest it. What this claim adds is the throughput side the community advice usually omits: on a STOCK build, taking that quality upgrade silently costs roughly a third of your decode speed. "BF16 KV is a free quality win" is only true once ed89854's kernel (or PR-26856's, once/if it lands) is actually in your binary — on stock ROCm it is a real trade, not a free lunch. CAVEAT — single model tested (Qwen3.6-35B-A3B, an hd256 MoE), matching clm-0050/ 0051's own scope caveat; this is the same matrix and the same fleet-wide-vs- per-model lesson clm-0050 was just corrected on, so this claim is deliberately NOT generalised past this one model until a second one fills the matrix. ed89854 also lifts f16 decode over stock (44.96 vs 42.35, +6.2%) and f16/bf16 prefill modestly (607.3/651.4 vs stock's 595.0/587.4) — the bf16 fix is the standout result, not the only one, and it is what makes bf16 ed89854's best ROCm configuration on this chip rather than merely a repaired one.

Note — the record's own working