#2883 [Feature]: gfx906 / MI50: reproducible Linux releases and community validation

本文

## What do you want to do?

I am planning a local API server with AMD Instinct MI50 (gfx906), primarily running Qwen3.8-Flash-Next. The application will extract GPU mining benchmark records into JSON from Discord message text and locally generated OCR text. Reliable repeated requests and correct extracted values matter more to this workload than peak token throughput.

Thank you for keeping the community gfx906 path available. I understand that it is an opt-in wave64 build, that setup does not install it automatically, and that the maintainers do not have a gfx906 card. I have not built or benchmarked v0.1.45 on this hardware yet.

Could we establish a small, reproducible Linux validation path for current releases?

1. **A pinned build recipe and a compile smoke check per release.** Pin the ROCm/gfx906 image or toolchain and llama.cpp revision, and build the actual `strata` serving executable. An optional community-maintained recipe or container would already help; automatic installation could follow later. This would make build regressions such as #2459 easier to catch.
2. **Documented starting configurations and support limits.** A tested baseline for one or two MI50 cards, distinguishing 16 GB and 32 GB boards, model/quantization, KV format, context, MTP and layer split. Please mark options measured only on RDNA/CUDA separately from those validated on gfx906, and state whether Qwen3.6 and CPU vision are supported on this path.
3. **A maintainer-agreed community test checklist.** We can contribute reports covering exact versions and configuration, self-tests, fresh-prompt processing, decode, first-token latency, long-context correctness, repeated API requests and one versus two clients. Results should include warm-up, repeated measurements, errors and answer correctness, not only tokens/s. What is the smallest useful test set for contributors without access to your other GPU backends?

Related work:

- #641: the original gfx906 port and the maintainers' preference for a separate opt-in build.
- #2459: the existing v0.1.44.1 build regression report. Any reproduced build failure should be followed up there rather than duplicated here.
- #1923: expert-cache policy experiments; the reported offline hit-rate improvement is not yet an end-to-end speed measurement.
- #2461: multi-GPU settings whose gains did not transfer to a fully resident gfx906 workload.

For v0.1.45, source inspection still shows the missing cuBLAS aliases discussed in #2459 in `include/strata/platform/hip_compat/cublas_v2.h`, while `src/qwen35/q36_engine.cu` uses those names. This is a static observation, not a claim that I reproduced a v0.1.45 build failure.

Would a community-maintained Linux recipe plus this validation checklist be a useful first contribution? Which of these steps would you prefer us to start with?