clm-0050

METHOD — three arms, one model, matched flags. A = stock llama.cpp 3653e6d ROCm, B = stock 3653e6d Vulkan, C = fork v0.6.1 commit 3be50ccc2 with its bundled RADV 26.3.0-devel. Qwen3.6-35B-A3B UD-Q4_K_XL, fa on, pp1024/tg256, llama-bench defaults otherwise (-b 2048 / -ub 512), median of 3 fresh-process reps with page cache dropped between reps; 72/72 reps rc=0 across both KV matrices. One benign outlier rep in the matrix (median absorbs it). f16 KV, pp/tg by depth: | depth | A ROCm | B Vulkan | C fork | |---|---|---|---| | 0 | 1068.1 / 51.1 | 1110.5 / 61.6 | 1251.5 / 61.8 | | 4,096 | 962.6 / 49.7 | 1020.0 / 59.3 | 1149.5 / 59.9 | | 32,768 | 595.8 / 42.3 | 697.7 / 50.4 | 705.4 / 51.0 | | 65,536 | 412.5 / 36.4 | 495.1 / 43.5 | 507.3 / 43.9 | | 131,072 | 253.6 / 28.5 | 278.3 / 34.2 | 321.6 / 34.5 | The counter-claim this answers: a r/LocalLLaMA report of ROCm leading 3.5x at 65k depth was measured on a V620 (RDNA2 — a different GPU family). At 65k on gfx1151 the same comparison reads Vulkan +20% prefill / +19.5% decode. Backend verdicts do not transfer across GPU families; this claim is scoped to gfx1151. FORK ATTRIBUTION CAVEAT: arm C differs from arm B in two ways at once — the fork's kernels AND the newer bundled Mesa (RADV 26.3.0-devel vs system RADV). The d0/d4096 prefill edge is plausibly part-Mesa; the cells are not single-variable the way clm-0022's cherry-pick was. Decode being flat (±1%) at f16 is expected per the fork docs for an hd256 MoE — hd128 models are documented to gain more, so these fork deltas are a FLOOR, not the fork's headline. Single model tested; medium confidence until a second model (ideally hd128 dense) fills the matrix. Stride-bug check: v0.6.1 shows no stride bug — 41/41 layers verified on GPU, CPU% identical to stock during runs. RELIABILITY COUNTERWEIGHT (2026-08-13): llama.cpp issue 25664 (open, field reports incl. Strix Halo) documents Vulkan/RADV DeviceLostError at ~80k context on this hardware class - our matrix ran clean to 131k, but a naive "switch to Vulkan" operational conclusion should carry this open issue until it resolves. CHALLENGER ON RECORD (2026-08-13): stew675's public rdna-boosts branch (kernel-fusion campaign, see clm-0044) claims to cut stock ROCm's decode deficit to ~3-5% and take prefill +36.5% past Vulkan with BF16 KV. Untested here; a rdna-boosts-vs-stock-Vulkan rerun of this matrix is queued. AMENDMENT 2026-08-14 — the fleet-wide reading of this claim was wrong; the per-model reading above (everything through "rerun of this matrix is queued") was and remains correct. The 2026-08-14 perf-matrix sweep ran the same fa-on, pp1024/ tg256, 3-fresh-process-rep methodology against two more models, ROCm vs Vulkan, stock 3653e6d, f16 KV: gpt-oss-120b, pp1024/tg256 by depth: | depth | ROCm | Vulkan | Vulkan delta | |---|---|---|---| | 32,768 | 308.2 / 39.0 | 294.8 / 45.1 | pp −4.3% / tg +15.7% | | 65,536 | 226.7 / 33.0 | 108.8 / 36.6 | pp −52.0% / tg +10.7% | | 131,072 | 144.3 / 24.0 | 23.1 / 26.3 | pp −84.0% / tg +9.8% | gpt-oss-120b's prefill does the OPPOSITE of Qwen3.6-35B's as depth grows: ROCm pulls further ahead at every depth measured, reaching a 6.2x lead at 131,072 (144.3 vs 23.1 t/s, medians of 3 reps each, tight — samples in run-0162/run-0180). Decode keeps the Qwen3.6-35B direction (Vulkan ahead, +10 to +16%), so the per-model reversal is prefill-specific, not a wholesale gpt-oss-120b exception — which is exactly why the rule has to be stated per-phase as well as per-model. Nemotron-3-Super, stock ROCm f16 and q8_0, d32768: both OOM before producing a number (run-0234, run-0235; "HSA exception: BadAlloc" x93/x5 in the process stderr, but the kernel-level cause captured via journalctl -k at the same timestamps is "amdgpu: SVM mapping failed, exceeds resident system memory limit" — a host-RAM residency ceiling, not a GTT-window one: re-running at an expanded 122 GiB GTT ceiling did not rescue either cell). Vulkan completed both KV variants cleanly (matrix-medians.json on aihydra). Nemotron "favours Vulkan" only in the degenerate sense that ROCm could not run at all — this is a reliability finding, not a throughput comparison, and should not be read as a third data point for the fleet-wide direction either way. CORRECTED RULE: backend advantage on gfx1151 is per-model AND per-phase. Qwen3.6- 35B's "Vulkan wins everywhere" result was real and is now the exception the rule has to explain, not the rule itself. A fleet verdict needs the phase named and the model named; "Vulkan is faster on this chip" is not a sentence this lab can stand behind without both. SECOND AMENDMENT 2026-08-14 — the Nemotron paragraph directly above ("should not be read as a third data point... either way") is superseded. That OOM was traced to a benchmarking-harness defect, not the hardware: the perf-matrix and perf-matrix- gtt120 llama-bench queues never carried --load-mode none, so stock ROCm was benchmarked under mmap on a model (~82 GB of weights) within ~40 GiB of the box's full 122 GiB. Full mechanism, detection-lag numbers, and the mmap-vs-no-mmap throughput control on a model that fits are in clm-0053; the summary needed here is the corrected cell. Nemotron-3-Super UD-Q4_K_M, stock ROCm 3653e6d, --load-mode none, d32768: | rep | pp1024 | tg256 | |---|---|---| | single (pre-reboot check, run-0243/run-0244) | 248.788416 | 16.390674 | | median of 3 (post-reboot, run-0236/run-0237) | 244.051835 | 16.434903 | The two checks agree within 2%. run-0236/run-0237 is the fully-backed N=3 record (stddev 3.76 pp / 0.03 tg across the 3 post-reboot reps) and is the one this claim quotes. Against Vulkan's own run-0190/run-0191 at the same cell (139.810384 pp / 17.559139 tg, median of 3, stock 3653e6d, mmap default — mmap is not a throughput confound for Vulkan or for any model that fits, per clm-0053's control pair), the ROCm figures read: pp +74.6%, tg −6.4%. (The single pre-reboot check alone would read +77.9%/−6.7% — the same conclusion, slightly noisier.) ROCm's prefill lead and Vulkan's decode lead put Nemotron-3-Super in the SAME prefill-favours-ROCm/decode-favours-Vulkan pattern as gpt-oss-120b, not the degenerate no-data case the first amendment recorded. CORRECTED RULE, restated: the per-model, per-phase rule from the first amendment stands unchanged. What moves is Nemotron-3-Super's place in it — from "no data, reliability finding only" to a third model confirming the same phase split gpt-oss-120b showed. Three of three multi-model cells measured on gfx1151 now show prefill and decode capable of favouring opposite backends on the same model; no cell measured here has shown a backend win both phases at once except Qwen3.6-35B at f16 KV, which remains the outlier the rule exists to explain.