Real throughput numbers from our own Strix Halo box, not a coding-task benchmark: what we run, on which backend, and how fast. The gfx1151 ROCm hang that pushed us to Vulkan was scoped to one model family and closed a month later — ROCm runs several of our profiles today.
A version of this post used to promise a coding-task benchmark — “six models, sixty tasks, methodology included” — that we never published anywhere checkable. We dropped that claim. What follows is what our own 128GB Strix Halo box actually measures, read straight off the public, open-source strix_halo_vllm collection that deploys and benchmarks it — the numbers below are the repo's own, not a fresh benchmark run for this post.
What we measured
Backend, build, quant and decode rate are noted per model below so they can be checked rather than believed; context and slot count are noted where the source configures a serving deployment for that profile, and left blank where it does not — a raw throughput run has neither. Full methodology is in the repo's PERFORMANCE.md, at the revision these figures come from — not a moving branch that could read differently by the time you click it.
| Model | Backend / build | Quant | Context (per req. → aggregate, if split) | Slots | Decode (tok/s) |
|---|---|---|---|---|---|
| Qwen3-Coder-30B-A3B (coder) | llama.cpp/Vulkan · build 10400 | Q4_K_XL | — | — | 96.6 fresh |
| Nemotron-3-Nano-30B-A3B (nemotron) | llama.cpp/Vulkan · build 10400 | Q4_K_XL | — | — | 71.1 fresh (re-benchmarked — an earlier ~95 estimate was never measured) |
| Nemotron-3.5-Lightning-30B-A3B (lightning) | llama.cpp/Vulkan · build 10400 | Q8_0 | 131,072 → 262,144 | 2 | 56.2 fresh † |
| Qwen3-Coder-Next-80B-A3B (coder-next) | llama.cpp/Vulkan · build 10400 | Q8_0 | 131,072 → 262,144 | 2 | 42.7 fresh / 38.1 at 32K |
| MiniMax-M2.7, 229B MoE (minimax) | llama.cpp/Vulkan · build 10400 | UD-IQ4_XS | 81,920 | 1 | 28.1 fresh / 17.9 at 32K |
| Qwen3.5-122B-A10B (big, default) | llama.cpp/Vulkan · build 10400 | Q4_K_XL | — | — | 23.3 fresh |
| DeepSeek-V4-Flash-0731, 284B MoE (deepseek-v4) | llama.cpp/ROCm/HIP · mainline build 10217 | 2.90bpw custom requant (90.8% token-identical to full precision, 240/240 paired QA parity) | 1,048,576 | — | 17.1 fresh / 15.0 at ~22K |
| Qwen3.8-27B, dense + vision (qwen38) | llama.cpp/Vulkan · build 10400 | UD-Q4_K_XL | 262,144 | — | 12.4 fresh / 11.8 at 32K (bandwidth-bound, ~216GB/s effective weight reads) |
| Qwen3.8-27B ROCmFP4 + MTP (qwen38-fp4) | llama.cpp/ROCm (ROCmFPX fork) | same UD-Q4_K_XL + MTP draft head, vision off | 262,144 | — | 29.1 on code / ~21–22 on prose |
| Qwen3.8-27B via a ROCm multi-model router | Lemonade 11.8–11.9 on llama.cpp/ROCm · TheRock 7.14.0 | same GGUF, MTP auto-enabled, vision intact | 262,144 | — | 18.5–27.0 (1.5–2.2x the Vulkan qwen38 profile on the identical GGUF) |
A blank Context and Slots cell together means a throughput-only run (llama-bench "tg128": a short, fresh-context generation pass with no serving deployment behind it) — coder, nemotron and big are measured that way, so there's no context or slot count to report. DeepSeek-V4, qwen38, qwen38-fp4 and the router entry do have a real serving context; their Slots cell is blank because the source doesn't state a slot count for those profiles, not because none exists. † Lightning's Context and Slots columns describe the profile's live serving configuration (-c 262144, 2 slots, 131,072 tokens per request), not the 56.2 figure itself — that's a fresh-context llama-bench number from the same fleet-wide re-baseline as the rows above it, which explicitly corrects Lightning from a previously published 51.4 tok/s to 56.2 and notes that some of the gain is the newer build. A separate, earlier test on that live serving configuration measured 51.43 tok/s at a ~23-token prompt, 51.13 at 8K, and 49.99 at 32K — none of it anywhere near the 262K configured context.
The gfx1151 hang, scoped
In March 2026 we hit a real ROCm/HIP hang on this hardware: Qwen 3.5 models locked the compute queue during tensor finalization on gfx1151, and only a full GPU reset recovered it. It is tracked publicly as ROCm/ROCm#6027, filed 10 March 2026 and closed 1 April 2026. llama.cpp's Vulkan backend does not hit it, so that model family runs there instead.
That is a narrower claim than “Vulkan is the path forward on gfx1151 this generation,” which is what we said before. ROCm runs several of our profiles today: DeepSeek-V4-Flash serves on ROCm/HIP at its full 1M-token context, a fast variant of our dense 27B model uses a ROCm speculative-decoding fork, and routing that same model through a ROCm backend with speculative decoding decodes 1.5–2.2x faster than the Vulkan profile serving the identical file. ROCm is not the backend we reach for a Qwen 3.5 model on this hardware — everything else is a question of which profile fits.
For how harness-go itself evaluates candidate changes — separate from this throughput work — see the harness-go case study.