Add Strix Halo/GFX1151 Support

[hstolte11-collab]

Summary

Add first-class Radeon 8060S / Strix Halo (gfx1151, RDNA 3.5) benchmark runners derived from the current MI355X lifecycle scripts.

• add vllm_radeon8060s.sh and sglang_radeon8060s.sh
• preserve Magpie's server/client/all phases, persistent server lifecycle, remote endpoint mode and persisted evaluation contract
• remove MI355X MEC firmware and scratch-reclaim assumptions
• use native gfx1151 without HSA_OVERRIDE_GFX_VERSION
• register both scripts as built-ins for persistent server reuse
• extend eval-concurrency tests and compatibility documentation

Qualified routes

Physical Radeon 8060S qualification used ROCm 10, Torch 2.13.0+rocm10.0.0, vLLM 0.27.0+hyperloom.gfx1151.rocm10, and SGLang 0.5.15.

• vLLM: AITER off; 2/2 measured fixed 64 -> 16 requests; 131.03 output tok/s
• SGLang: Triton attention, CUDA graphs disabled, AITER off; 2/2 measured fixed 64 -> 16 requests; 82.19 output tok/s

Current upstream AITER attention is not claimed for the tested BF16 Qwen3 GQA2/head-size-128 geometry: CK prefill compilation failed and paged decode device-asserted.

Original submission tests

• bash -n on both new runners
• 16 focused runner/eval/registry tests passed
• 404 root Magpie tests passed
• embedded kernel-finder tests: 5 passed, 16 skipped
• import and CLI help smoke passed
• introduced-line Ruff findings: 0

Review follow-up

• Commit: ebcbed02f8717848a9ba3adc93f3177b63f9152b.
• Map vllm.gfx1151 to the published vllm/vllm-openai-rocm:v0.23.0 image.
• Accept and preserve semicolon-delimited build architecture lists containing gfx1151 in both runners; this is build metadata, not runtime GPU dispatch.
• Keep SGLang on an explicit compatible image/local install, and distinguish the original custom-build qualification from the collaborator's published-image test.
• Local verification: 470 tests passed, including 63 new container-compatibility cases; coverage gate passed at 90.06%; shell syntax, new-file Ruff, CLI help, and independent review passed. Existing tests unchanged.
• This follow-up ran CPU-only tests and anonymous registry metadata checks, not a new GPU benchmark.

[haofrank]

Overall LGTM, Do you have validated, up-to-date Docker images for the new gfx1151 vLLM and SGLang runners? there is a mapping in benchmark_images.yaml.

[mgehre-amd]

You can use gfx1151: "vllm/vllm-openai-rocm:v0.23.0" as docker image (

Magpie/Magpie/benchmark_images.yaml

Line 16 in 3aba836

gfx1151: "vllm/vllm-openai-rocm:v0.23.0"

). sglang currently doesn't have docker images that support gfx1151, afaik.

[mgehre-amd]

Nice work! I've been looking at gfx1151 support from the same angle and wanted to offer one small addition rather than duplicate the effort.
After adding the vllm docker images to benchmark_images.yaml,
I have hit a second issue.

Adding the image on its own isn't enough. I checked out this branch and ran
vllm_radeon8060s.sh against that image on a real Radeon 8060S, and it exits before
launching:

Status: FAILED
Errors:
  - Docker command failed with code 2
  - stderr: ERROR: vllm_radeon8060s requires PYTORCH_ROCM_ARCH=gfx1151.

The cause is that PYTORCH_ROCM_ARCH is a build-time variable holding the list of
architectures the image was compiled for, and every ROCm vLLM image sets it:

$ docker run --rm --entrypoint /bin/bash vllm/vllm-openai-rocm:v0.23.0 \
    -c 'echo "PYTORCH_ROCM_ARCH=[$PYTORCH_ROCM_ARCH]"'
PYTORCH_ROCM_ARCH=[gfx90a;gfx942;gfx950;gfx1100;gfx1101;gfx1200;gfx1201;gfx1150;gfx1151]

gfx1151 is in that list, but the guard demands the exact string gfx1151, so it fails:

if [[ -n "${PYTORCH_ROCM_ARCH:-}" && "$PYTORCH_ROCM_ARCH" != "gfx1151" ]]; then
  echo "ERROR: vllm_radeon8060s requires PYTORCH_ROCM_ARCH=gfx1151." >&2
  exit 2
fi
export PYTORCH_ROCM_ARCH=gfx1151

This means the runner can only start where PYTORCH_ROCM_ARCH is unset or exactly
gfx1151 and refuses every published ROCm vLLM container. It's
also worth noting the export on the last line is inert at runtime: nothing dispatches
kernels off this variable after the build, so neither the check nor the export affects
which kernels vLLM actually uses.

A membership test would fix it, e.g. [[ ";$PYTORCH_ROCM_ARCH;" == *";gfx1151;"* ]], or
the guard could simply be dropped.

With the guard satisfied, your runner works.:

Selected benchmark script: benchmarks/vllm_radeon8060s.sh
Status: SUCCESS
Request throughput: 19.41 req/s | Output throughput: 621.07 tok/s
accuracy_report.json: {"status": "COMPLETED", "task": "gsm8k", "samples": 5, "error": null}

[hstolte11-collab]

Thanks @haofrank and @mgehre-amd — the multi-architecture diagnosis was correct, and thanks for testing the runner on a real 8060S.

Addressed in ebcbed0:

• Added vllm.gfx1151: "vllm/vllm-openai-rocm:v0.23.0" to benchmark_images.yaml.
• Changed both Radeon runners to the suggested exact semicolon-delimited membership check. They now accept and preserve the published image's complete architecture list rather than rejecting or overwriting it. The existing default when the variable is empty/unset remains only a build hint; comments now explicitly distinguish this from runtime GPU selection.
• Added separate regression tests exercising server/client/all phases for both runners, including the exact published list, first/middle/last entries, empty/unset values, and near-match rejection. Existing tests were left unchanged.

On the SGLang image question: our original PR results used a custom ROCm 10 / SGLang 0.5.15 build, not an official upstream image. We now also publish a community image, ghcr.io/hawgauto/haloloom-sglang-full-gfx1151:v0.1.1, pinned as:

ghcr.io/hawgauto/haloloom-sglang-full-gfx1151@sha256:5f46740ad763e8c174df5c693616ea6da824ee5db341a42bec72eed0562597c2

Its published manifest and runtime receipt bind five text-only Qwen3.5-0.8B serving checks on a physical gfx1151 to that image. It uses ROCm 10 / SGLang 0.5.19.dev0, Triton attention, CUDA graphs off, and AITER off. Those are bounded serving checks, not a full Magpie benchmark/eval rerun or broad model/precision coverage. I left SGLang as an explicit --docker-image/local-install option rather than silently making our community build the upstream default, and documented that boundary.

[mgehre-amd]

Sorry, I merged the wrong PR (#91). I wanted to get this PR merged instead. Don't know how you feel about it, but I'm fine to revert (#94) and then merge this one.