feat(backend/python): AMD multi-arch ROCm torch for transformers/diffusers/kokoro (consumer/RDNA GPUs)

[walcz-de]

What

The community whl/rocm7.0 torch wheel that the transformers, diffusers and kokoro backends install does not enumerate consumer/RDNA AMD GPUs — torch.cuda.device_count() == 0 on e.g. Strix Halo / gfx1151 — so those backends silently fall back to CPU or fail to load.

AMD publishes a stable ROCm 7.14 torch for essentially every AMD arch on its multi-arch index (repo.amd.com/rocm/whl-multi-arch/), selected per GPU via the torch[device-gfx<arch>] extra. This switches the three backends to it.

How

• New AMDGPU_TARGETS ARG/ENV on backend/Dockerfile.python, so install.sh can pick the GPU arch.
• Each backend installs torch from AMD's index in an isolated step: that index returns 403 (not 404) for packages it doesn't serve (accelerate/transformers/…), which uv treats as fatal — so only the torch family is pulled there, everything else resolves from PyPI.
• AMDGPU_TARGETS is the repo-wide comma-separated gfx list, and the device extras compose: torch[device-gfx942,device-gfx1151] resolves and installs both device packages side by side. The whole list is mapped, not its first entry.

Which arches an image carries

That is now a matrix decision, stated explicitly instead of inherited. The three hipblas entries set amdgpu-targets: 'gfx942,gfx950,gfx1151' — both CDNA data-center arches plus Strix Halo.

The reason is size: one rocm-sdk-device-gfx* package is ~1.6 GB installed (measured). The repo-wide 11-arch default would add ~17 GB per image. Adding a further arch is one matrix entry at ~1.6 GB, so the trade-off sits where it is made.

Testing

Hardware-validated on gfx1151 (Strix Halo, ROCm 7.14): transformers generates text, diffusers runs SD-1.5, kokoro runs TTS — all on the GPU. Only gfx1151 was tested on real hardware; the mechanism is arch-generic for any AMD GPU AMD ships a device wheel for.

Dependency

Stacks on #10978 (ROCm 7.14 base). The reviewable change is the top commit — the rest is #10978.

[localai-org-maint-bot]

The ROCm work is substantial, but the stacked commit fix(rocm): update Go backend Dockerfile for TheRock packaging contains Co-authored-by: localai-org-maint-bot .... LocalAI policy explicitly forbids AI/bot Co-Authored-By trailers; AI assistance must be recorded with Assisted-by: AGENT_NAME:MODEL_VERSION [TOOLS] instead (see .agents/ai-coding-assistants.md). Please rewrite that commit trailer before merge.

@mudler tagging you because this is a repository-policy blocker on the otherwise valuable ROCm series.

[localai-org-maint-bot]

DCO passes. Two blocking issues:

1. gfx1151 default breaks CDNA builds — AMDGPU_TARGETS is never set in any of the 36 hipblas matrix entries (verified: grep finds nothing in .github/backend-matrix.yml). The install.sh blocks default to gfx1151 (Strix Halo / consumer RDNA). The old wheel (download.pytorch.org/whl/rocm7.0) served CDNA (gfx942 MI300X / gfx950) too. So every hipblas transformers/diffusers/kokoro build — including datacenter CDNA — would get a gfx1151 torch that won't enumerate a MI300X. Fix: set AMDGPU_TARGETS per matrix entry (gfx942/950 for CDNA, gfx1151 for consumer), or gate the AMD-index install on an RDNA flag.

2. Rebase onto #10978 — This PR's Dockerfile.golang is the simpler version (no amdrocm-blas-dev fallback). It lacks #10978's commit-4 fix, so merging as-is would re-break qwen3-tts hipblas. Rebase onto a merged #10978 and adopt its Dockerfile.golang.

The multi-arch ROCm torch approach is sound — just needs per-entry GPU targeting and the rebase.