feat(backend/python): build vllm from source for AMD consumer/RDNA GPUs

[walcz-de]

What

vllm's ROCm install pulls a prebuilt wheel from wheels.vllm.ai/rocm, but that wheel exists only for CDNA data-center arches (gfx942/gfx950) and is pinned to a rocm7.2.3 torch that can't enumerate consumer/RDNA GPUs (device_count == 0 on e.g. gfx1151). There is no prebuilt vllm wheel for these GPUs anywhere — which is why AMD ships a whole rocm/vllm:*_rdna_* container. This builds vllm from source against AMD's ROCm 7.14 torch, reproducing that container's recipe inside LocalAI's normal Dockerfile.python build (FROM-scratch, portable venv — no external gRPC / no 73 GB image).

How

• torch[device-gfx<arch>] + rocm-sdk-devel (hipcc + the HIP CMake packages the runtime _rocm_sdk_core lacks) from AMD's multi-arch index; ROCM_PATH/CMAKE_PREFIX_PATH resolved from the SDK's own rocm-sdk path CLI — self-contained, no system /opt/rocm needed.
• vLLM detects ROCm at runtime via import amdsmi; register the SDK's in-place amd_smi with a .pth. A pip copy breaks its relative libamd_smi.so lookup, and forcing the lib via LD_LIBRARY_PATH shadows torch's own ROCm runtime and zeroes device_count.
• run.sh exposes the bundled amdclang as CC/CXX: Triton JIT-compiles kernels at first inference and the runtime image ships hipcc but not cc/gcc, so without it inference dies with "Failed to find C compiler". Mirrors the CPU-toolchain block just above it.

The prebuilt path is kept, not replaced

install.sh picks between the two on the target arch: a target set covered entirely by gfx942/gfx950 installs the wheels.vllm.ai wheel exactly as before, anything else builds from source. So the published ROCm image stays what it is today, build time included — and its matrix entry pins amdgpu-targets: 'gfx942,gfx950' so the repo-wide default list (which contains consumer arches) cannot silently turn it into a multi-hour source build.

Consumer GPUs get their own image, because the two install paths cannot share one venv:

image	arch	vllm
-gpu-rocm-hipblas-vllm (rocm-vllm)	gfx942, gfx950	prebuilt wheel, unchanged
-gpu-rocm-hipblas-gfx1151-vllm (rocm-gfx1151-vllm)	gfx1151	built from source

The new backend is deliberately not in the amd: capability map: that map cannot know the caller's gfx arch, so rocm-vllm stays the automatic choice and the consumer image is installed by name. One arch per image because each AMD torch device package is ~1.6 GB installed (measured), so bundling arches is not free.

Testing

Hardware-validated on gfx1151: builds from a single make, is loaded natively by LocalAI from /backends/vllm (no external gRPC), and generates. Only gfx1151 was tested on real hardware; other AMD arches use the same mechanism but are unverified.

Dependency

Stacks on #10978 (ROCm 7.14 base) and #10997 (multi-arch torch / AMDGPU_TARGETS). Reviewable change is the top commit.

[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.

[walcz-de]

Addressed the policy blocker: removed the Co-authored-by: localai-org-maint-bot trailer from the Go-backend Dockerfile commit and added the required Assisted-by: AGENT:MODEL trailers across the whole ROCm series (#10978 / #10997 / #10998) per .agents/ai-coding-assistants.md. Only commit messages changed — trees are byte-identical (verified via git range-diff), each commit keeps its human Signed-off-by, DCO is green on all three. Force-pushed the stacked branches. Thanks for the catch.

[localai-org-maint-bot]

DCO passes. Two blocking issues:

1. Same gfx1151 CDNA regression as #10997 — vllm/install.sh defaults to gfx1151 with AMDGPU_TARGETS never set in the matrix. vLLM on AMD is primarily a CDNA (MI300X/MI356) workload — a gfx1151-default torch is wrong for the common case. Same fix needed (per-entry AMDGPU_TARGETS).

2. Source build CI unverified — Pinned to VLLM_REF=v0.23.0 built from source with MAX_JOBS=8 (hours-long build). The old path pulled a prebuilt wheel from wheels.vllm.ai/rocm; this PR drops that entirely, so there's no fallback if the source build fails. Need to confirm a green CI build before merge.

Also needs rebase onto a merged #10997 (which itself needs #10978 first).

The amdsmi.pth trick and amdclang PATH setup for Triton JIT are well-documented and handle non-obvious issues correctly.