快速结论:在 ROCm 环境(AMD Instinct、Qwen3.8-27B-FP8、TP4)开启 VLLM_ROCM_USE_AITER=1 后,高并发(如 256)下精度骤降、出现大量 ≤5 token 的截断回答和无法解析的答案,而关闭 AITER 就正常,这类情况优先排查 vLLM/AITER 镜像版本,而不是先怀疑模型或硬件。
适用环境(Issue 已确认):Ubuntu 22.04.5 LTS、Python 3.12.14、PyTorch 2.12.0+rocm10.0.0、ROCm 7.15.26333、HIP runtime 7.16.26361、MIOpen 3.6.0、AMD Instinct gfx950(Issue 标题写 MI355X,环境 dump 为 MI350X)、4 卡 TP4。复测在最新 nightly-rocm100 镜像(0.32.1rc1.dev361+g83c078d95)上通过。
最快修复方案:升级到最新的 nightly-rocm100 镜像后重新评测。Issue 中已确认:旧镜像 36768d1 仍能复现(65.88% 精度),新镜像在 VLLM_ROCM_USE_AITER=1、并发 256 下恢复到 96.74%,与 VLLM_ROCM_USE_AITER=0 + TRITON_ATTN(97.35%)基本持平。
注意事项:具体是哪个提交修复的尚未确认,维护者只列出了可能候选:AITER 版本更新(#59794、#62486)、CUDA graph capture 下的 AITER custom all-reduce(#57481)、Qwen3.8-27B 的 Gated RMSNorm 自定义算子(#60250),以及新版 AITER FlyDSL GDN prefill kernel(#57560)。升级前建议先用旧镜像做对照,确认差异来自镜像而非评测环境。
问题场景
在 4 卡 AMD Instinct(TP4)上,用 vLLM 加载 Qwen3.8-27B-FP8,并设置 VLLM_ROCM_USE_AITER=1 运行 GSM8K 评测。低并发时基本正常,但并发升到 256 时精度从约 97% 跌到约 66%。主要表现为回答在 5 个 token 以内就结束、出现大量无法解析的答案,以及长回答和截断回答变多。同一套启动命令下,把 VLLM_ROCM_USE_AITER=0 配合 TRITON_ATTN 就恢复正常,说明问题集中在 AITER 路径上。
报错原文
[Bug][ROCm] Qwen3.8-27B-FP8 (TP4, MI355X) accuracy collapses at high concurrency with `VLLM_ROCM_USE_AITER=1`; fine with AITER off
Issue 中没有崩溃堆栈,主要现象是高并发下精度坍塌,并伴随大量 ≤5 token 的响应(原文描述为 responses stop after ≤5 tokens)。
原因分析
问题确实出在 VLLM_ROCM_USE_AITER=1 所启用的 AITER 代码路径上。复测时同一台硬件、同一条启动命令,仅换镜像就恢复了精度,旧镜像至今仍能复现,因此可排除环境漂移。至于具体是哪个组件引入的回归,目前没有给出单点结论,可能原因包括:
- AITER 版本更新中已修复的回归(候选 #59794、#62486);
- CUDA graph capture 下 AITER custom all-reduce 的行为问题(候选 #57481);
- Qwen3.8-27B 的 Gated RMSNorm 自定义算子(候选 #60250);
- 新版镜像启用了此前不存在的 AITER FlyDSL GDN prefill kernel(#57560),影响 prefill 阶段的数值行为。
以上均为维护者列出的疑似方向,未在 Issue 中被逐一验证。
环境排查
- 确认镜像版本:旧镜像
36768d1会复现,最新nightly-rocm100(0.32.1rc1.dev361+g83c078d95)不复现。 - 确认
VLLM_ROCM_USE_AITER的取值,并做 1 与 0 的对照实验。 - 确认关闭 AITER 时注意力后端(
TRITON_ATTN)是否按 Issue 中的方式设置。 - 确认 GPU 型号:Issue 标题写 MI355X,而 collect_env 输出为 gfx950(MI350X),复测前应向维护者确认硬件身份。
- 确认 Python 3.12.14、PyTorch 2.12.0+rocm10.0.0、ROCm 7.15.26333 / HIP 7.16.26361、MIOpen 3.6.0 是否与复测环境一致。
- 确认评测使用单次全新启动的 server、完整 1319 道 GSM8K 题目,避免上一次运行的缓存状态污染结果。
解决步骤
- 先用旧镜像(如
36768d1)按 Issue 中的原始启动命令,在VLLM_ROCM_USE_AITER=1、TP4、并发 256 下跑一遍完整 GSM8K,留存精度、截断数、平均输出 token 数、≤5 token 响应数作为对照。 - 切换到最新
nightly-rocm100镜像,启动全新的 server,使用完全相同的启动命令与评测脚本复跑。 - 同时跑一组
VLLM_ROCM_USE_AITER=0+TRITON_ATTN作为参考基线。 - 比对三组结果:新镜像开启 AITER 的精度应与关闭 AITER 基本持平(Issue 中为 96.74% 对 97.35%),且 ≤5 token 响应数应为 0。
- 若仍能复现,附上客户端脚本与 server 日志,重新开启排查;若对齐,按 Issue 结论视为已修复。
验证方法
以完整 GSM8K(1319 题)为准,比较以下指标:
- 精度:并发 256 下应恢复到约 97%(Issue 复测 96.74%),而不是 65%~67%;
- ≤5 token 的响应数应为 0;
- 截断数(8192)应回落到与 AITER 关闭时同量级(Issue 中 18 对 13);
- 平均输出 token 数应从约 721~780 回落到约 454~474;
- 错误率后半段(除前 256 请求外)应从约 40% 降到约 3%。
只要新镜像下 AITER 开启与关闭的结果基本一致,且旧镜像仍能稳定复现,即可确认修复来自镜像,而非环境变化。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。
![[Bug] dify-agent: plugin tool observations repeat JSON output that already arrived as text](https://www.chat-gpts.plus/wp-content/uploads/2026/11/45296-2b8ad6b6-768x403.jpg)

