[Bug]: Abnormally bad performance on AMD ROCM gfx1030 (W6800, V620, 6900XT 6800XT)

快速结论：在 AMD ROCm gfx1030（RDNA 2 架构，如 Radeon PRO W6800、V620、6900XT、6800XT）上用 vLLM 加载 bf16 模型时，会出现吞吐异常低、但 GPU 利用率接近 99% 的情况。优先排查 dtype 是否被自动选成了 bfloat16，改为强制 float16。

适用环境：Ubuntu 24.04.4 LTS（x86_64）；Python 3.12.3；PyTorch 2.11.0+rocm7.2；ROCm/HIP 7.2.26015；MIOpen 3.5.1；GPU 为 AMD Radeon PRO V620（gfx1030），同类 RDNA 2 机型如 W6800、6900XT、6800XT 症状相同。

最快修复方案：在启动命令中显式加上 --dtype float16，不要依赖 auto 自动推断；同时建议去掉强制的 --attention-backend TRITON_ATTN，让 vLLM 自行选择 gfx1030 上 float16 可用的后端。

注意事项：Issue 中的反馈者确认加 float16 后能解释并缓解该现象，但该结论主要来自社区讨论，不是 vLLM 官方的一步修复补丁；float16 与 bf16 在推理精度上通常差异可忽略（logits/采样路径仍为 fp32），但极端精度要求的场景需自行验证。强制指定 attention backend 可能反而绕开更优路径，是否有必要保留需按实际模型测试。

问题场景

用户在 AMD RDNA 2（gfx1030）显卡上通过 vLLM 启动本地模型服务（Issue 中以 Qwen3-8B 为例，使用 vllm serve、TP=2 等参数），观察到吞吐异常低、GPU 利用率却接近 99%。相同硬件上 llama.cpp 运行正常，因此问题被定位到 vLLM 的 dtype 与后端路径选择上。

报错原文

[Bug]: Abnormally bad performance on AMD ROCM gfx1030 (W6800, V620, 6900XT 6800XT)

dtype=torch.bfloat16

原因分析

最可能的原因是数据类型回退：RDNA 2（gfx1030）没有 bf16 硬件数据类型（硬件 bf16 自 RDNA 3 才引入）。当模型以 bfloat16 运行时，每次矩阵乘都会走软件模拟路径，表现为 GPU 忙碌、利用率很高但有效吞吐只有个位数。Issue 中还提到高利用率是模拟路径占用，而非正常密集计算。此外，在 gfx1030 上强制 TRITON_ATTN 或使用 bf16 模拟相关 kernel 也可能引入额外回退或崩溃（如缺少 cutlass 的上游路径），这些属于可能原因。

环境排查

确认 GPU 架构：运行 rocminfo | grep gfx，gfx1030 即为 RDNA 2。
确认 PyTorch 与 ROCm/HIP 版本（Issue 中为 PyTorch 2.11.0+rocm7.2、HIP 7.2.26015）。
检查 vLLM 启动日志中的 dtype 字段，确认是否被自动设为 bfloat16。
确认是否手动指定了 --attention-backend TRITON_ATTN 等强制后端参数。
确认模型是否本身为 bf16 权重。

解决步骤

在启动命令中显式指定 --dtype float16，替代 auto 推断。Issue 中给出的示例为：vllm serve /home/arli/models/Qwen3-8B --dtype float16 --gpu-memory-utilization 0.9 --max-model-len 32768 --port 8000 --max-num-seqs 16 -tp 2。
暂时移除 --attention-backend TRITON_ATTN，让 vLLM 为 gfx1030 上的 float16 自动选择可用后端。
重新启动服务并观察日志中的 dtype 是否已变为 float16。
如仍异常，检查是否有 wNa16/compressed-tensors 或 AWQ 等量化路径在 gfx1030 上未正确路由；Issue 中提到经典 AWQ 容器未能路由 RDNA 2 kernel，吞吐明显偏低。

验证方法

用固定长度生成（如 256 token、ignore_eos）做单请求测试，对比切换前后的 tok/s。Issue 社区反馈者在 V620 上使用 4B 模型、float16、单卡测得约 49.9 tok/s（首次启动请求约 27.1），开启 CUDA graphs 后约 50.0 tok/s，接近带宽理论上限的约 78%；若结果回到该量级，说明 dtype 回退问题已排除。