[Bug]: ROCm tuned-config lookup keys off an unstable device name — shipped gfx1151 configs are unreachable

### Your current environment

The output of python collect_env.py

```text
Collecting environment information...
==============================
System Info
==============================
OS : Ubuntu 24.04.4 LTS (x86_64)
GCC version : (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0
Clang version : Could not collect
CMake version : version 4.4.0
Libc version : glibc-2.39

==============================
PyTorch Info
==============================
PyTorch version : 2.11.0+rocm7.14.0
Is debug build : False
CUDA used to build PyTorch : N/A
ROCM used to build PyTorch : 7.14.60850
XPU used to build PyTorch : N/A

==============================
Python Environment
==============================
Python version : 3.12.3 (main, Jun 19 2026, 12:46:00) [GCC 13.3.0] (64-bit runtime)
Python platform : Linux-7.1.1-070101-generic-x86_64-with-glibc2.39

==============================
CUDA / GPU Info
==============================
Is CUDA available : True
CUDA runtime version : Could not collect
CUDA_MODULE_LOADING set to :
GPU models and configuration : AMD Radeon 8060S Graphics (gfx1151)
Nvidia driver version : Could not collect
cuDNN version : Could not collect
HIP runtime version : 7.14.60850
MIOpen runtime version : 3.5.2
Is XNNPACK available : True

==============================
CPU Info
==============================
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 32
On-line CPU(s) list: 0-31
Vendor ID: AuthenticAMD
Model name: AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
CPU family: 26
Model: 112
Thread(s) per core: 2
Core(s) per socket: 16
Socket(s): 1
Stepping: 0
Frequency boost: enabled
CPU(s) scaling MHz: 44%
CPU max MHz: 5187.5000
CPU min MHz: 625.0000
BogoMIPS: 5988.81
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect movdiri movdir64b overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d amd_lbr_pmc_freeze
Virtualization: AMD-V
L1d cache: 768 KiB (16 instances)
L1i cache: 512 KiB (16 instances)
L2 cache: 16 MiB (16 instances)
L3 cache: 64 MiB (2 instances)
NUMA node(s): 1
NUMA node0 CPU(s): 0-31
Vulnerability Gather data sampling: Not affected
Vulnerability Ghostwrite: Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Old microcode: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Mitigation; IBPB on VMEXIT only
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; STIBP always-on; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsa: Not affected
Vulnerability Tsx async abort: Not affected
Vulnerability Vmscape: Mitigation; IBPB on VMEXIT

==============================
Versions of relevant libraries
==============================
[pip3] amd-torch-device-gfx1151==2.11.0+rocm7.14.0
[pip3] conch-triton-kernels==1.2.1
[pip3] numpy==2.3.5
[pip3] onnx==1.22.0
[pip3] onnx-ir==0.2.1
[pip3] onnxscript==0.7.1
[pip3] onnxslim==0.1.94
[pip3] pyzmq==27.1.0
[pip3] torch==2.11.0+rocm7.14.0
[pip3] torch_c_dlpack_ext==0.1.5
[pip3] torchaudio==2.11.0+rocm7.14.0
[pip3] torchvision==0.26.0+rocm7.14.0
[pip3] transformers==5.14.1
[pip3] triton==3.7.1+git0263a6a6.rocm7.14.0
[conda] Could not collect

==============================
vLLM Info
==============================
ROCM Version : 7.14.60850-0000000
vLLM Version : 0.26.1.dev0+g568afb3a1.d20260728 (git sha: 568afb3a1, date: 20260728)
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; XPU: Disabled
GPU Topology:
============================ ROCm System Management Interface ============================
================================ Weight between two GPUs =================================
GPU0
GPU0 0

================================= Hops between two GPUs ==================================
GPU0
GPU0 0

=============================== Link Type between two GPUs ===============================
GPU0
GPU0 0

======================================= Numa Nodes =======================================
GPU[0] : (Topology) Numa Node: 0
GPU[0] : (Topology) Numa Affinity: -1
================================== End of ROCm SMI Log ===================================

==============================
Environment Variables
==============================
PYTORCH_ROCM_ARCH=gfx1151
LD_LIBRARY_PATH=/opt/venv/lib/python3.12/site-packages/_rocm_sdk_core/lib:/opt/venv/lib/python3.12/site-packages/_rocm_sdk_libraries/lib
VLLM_USE_TRITON_AWQ=1
PYTORCH_NVML_BASED_CUDA_CHECK=1
TORCHINDUCTOR_COMPILE_THREADS=1
TORCHINDUCTOR_CACHE_DIR=/tmp/torchinductor_root

```

### 🐛 Describe the bug

Tuned-config filenames are built from `current_platform.get_device_name()`. On ROCm that string is **not stable across ROCm releases or container builds**, so a config tuned on one stack cannot be found on another for the *same* GPU. Today every shipped Radeon 8060S (gfx1151) config is unreachable on a stock ROCm 7.14 build.

## Three names, one GPU

All measured on a single machine (AMD Ryzen AI MAX+ 395 / Radeon 8060S, gfx1151):

| source | value |
|---|---|
| HSA marketing name, host **ROCm 7.2.2** (`rocminfo 7.1.1`) | `Radeon 8060S Graphics` |
| `amdsmi_get_gpu_asic_info()['market_name']`, **ROCm 7.14** | `AMD Radeon 8060S Graphics` |
| `torch.cuda.get_device_name()`, ROCm 7.14 | `AMD Radeon 8060S Graphics` |
| `current_platform.get_device_name()` (device-ID map) | `AMD_Radeon_8060S` |

`RocmPlatform.get_device_name()` returns `_ROCM_DEVICE_ID_NAME_MAP[device_id]` when the PCI ID is known, else `asic_info["market_name"]`. Which value the lookup sees therefore depends on the ROCm version **and** on whether `amdsmi` is importable.

## Effect

```python
>>> from vllm.model_executor.layers.fused_moe.fused_moe import get_moe_configs
>>> get_moe_configs(128, 768, "int4_w4a16") # shipped config from #34130
None
>>> get_moe_configs(256, 512, "int4_w4a16") # file named Radeon_8060S_Graphics
None
>>> get_moe_configs(256, 512, "int4_w4a16") # same file renamed AMD_Radeon_8060S
<18 entries>
```

The miss is silent — there is no log when nothing matches and the default heuristic is used instead, so the only symptom is unexplained performance. The same helper (`get_device_name_as_file_name()`) also keys the SSM and fp8 block-quant config lookups, which carry the same exposure.

## Root cause: adding a device to the map is a silent breaking change

`E=128,N=768,device_name=Radeon_8060S_Graphics,dtype=int4_w4a16.json` was added in #34130 (2026-02-13), correctly named for the marketing string of the day. #38455 (2026-04-10) then added `"0x1586": "AMD_Radeon_8060S"` to the device-ID map, which changed what `get_device_name()` returns for that GPU and orphaned the file. Nothing detects this.

**Why `AMD_Radeon_R9700` is unaffected:** its map entry and its config files landed in the *same commit* (#38086, `551b3fb39f`) — the author added the device to the map and named the configs after the map value, so the two were consistent by construction. That is the right convention, but it holds by author discipline rather than by any check.

**This is not a one-off.** Config names currently split into two groups:

- resolved via the map: `AMD_Instinct_MI300X`, `MI308X`, `MI325X`, `AMD_Radeon_R9700`
- resolved via `market_name` (absent from the map): `AMD_Instinct_MI350X`, `MI355X`, `MI325_OAM`, `MI350_OAM`, `MI355_OAM`

Those five work today only because they are *absent* from the map. The moment anyone adds them — exactly the well-intentioned change #38455 made — their configs orphan the same way, silently.

## Why a plain rename is not a fix

Builds that stub `amdsmi` (TheRock images use `unittest.mock.MagicMock` — see #44332) never reach the map and fall back to `torch.cuda.get_device_name()`, where the marketing string is correct. Renaming the shipped files to the map value fixes stock builds and breaks those. #44331 is currently adding a config under the marketing name, which will be unreachable on stock builds on arrival. Both are correct for their own environment; the mechanism is what is unsound.

## Possible paths

**A — Normalize both sides of the comparison.** Rather than requiring the filename to equal the reported name, apply the same normalization to the computed name and to the candidate filenames: lowercase, drop non-alphanumerics, strip a leading `amd`, strip a trailing `graphics`. All four spellings then collapse to one key:

```text
AMD_Radeon_8060S -> radeon8060s (map value)
AMD Radeon 8060S Graphics -> radeon8060s (ROCm 7.14 market_name)
Radeon 8060S Graphics -> radeon8060s (ROCm 7.2 market_name)
Radeon_8060S_Graphics -> radeon8060s (shipped filename)
```

Checked against every ROCm config device name plus every `_ROCM_DEVICE_ID_NAME_MAP` value (33 names): the only collision is the intended one above — no false merges. This makes existing files resolvable without renaming anything, and is robust to both the ROCm-version and the stubbed-`amdsmi` cases. The marketing string is supplied by ROCm and may change again, so normalization is a heuristic; the device-ID key in D is the version-proof alternative.

*Narrower variant:* change the map value to `AMD_Radeon_8060S_Graphics` so it matches the current market string. That aligns the map with ROCm 7.14 but does not by itself rescue the shipped file, which lacks the `AMD` prefix — so the prefix still needs handling.

**B — Lookup fallback chain.** Try the canonical name, then the gfx arch, then give up — logging which tier matched. Backwards compatible with every existing config, and gives untuned devices an arch-level net.

**C — Add a regression test.** A unit test asserting that every shipped ROCm config filename resolves for some known device would have failed on #38455 at the time, and would catch the five latent cases above. Cheap, runs in the existing suite, and is the only option here that prevents recurrence rather than fixing the instance.

**D — Key by PCI device ID** (`0x1586`). Maximally stable and per-device, and immune to both failure modes, but filenames become opaque.

One option deliberately not listed is keying purely by gfx arch: it is stable, but too coarse to be the primary key, since MI300X, MI308X and MI325X are all `gfx942` and today ship *different* tunings for the same shapes (`E=8,N=14336` and `E=8,N=16384` differ between MI300X and MI325X). It only works as the fallback tier in B.

I have not picked a direction — happy to prepare a PR for whichever approach maintainers prefer, and to test it on gfx1151 hardware. Input welcome on whether the normalization in A is acceptable as a heuristic over a vendor-supplied string, or whether the stable key in D is the better long-term answer.

Start at RocmPlatform.get_device_name() and get_device_name_as_file_name(), then trace the tuned-config, SSM, and fp8 block-quant lookup callers. Compare the device-ID and market-name paths with the shipped Radeon_8060S_Graphics and AMD_Radeon_8060S filenames. Done means equivalent ROCm names resolve the existing configs without collisions, with coverage for mapped and amdsmi-fallback cases.

Written by the indexing model from the issue text.