[Bug]:amd mi308x gpu, vllm 0.27.0~0.27.1, rocm 7.2.3, Kimi-K2.7-Coder start fails:AssertionError: mla_gluon requires gfx950 (CDNA4), got gfx

快速结论：该报错通常发生在使用 AMD MI308X（gfx942）等非 gfx950 架构 GPU 加载 Kimi-K2.7-Coder 等模型时，vLLM 0.27.0~0.27.1 的 ROCm 版本因模型代码中 mla_gluon 算子的架构检查失败而启动中止。优先排查方向是升级 vLLM 到最新 main（nightly）构建，该问题已在 #50578 修复。

适用环境：vLLM 0.27.0+rocm723（0.27.0~0.27.1）、ROCm 7.2.3、PyTorch 2.11.0+gitd0c8b1f（ROCm 7.2.53211 构建）、Python 3.12.13、Rocky Linux 10.2 (x86_64)、AMD Instinct MI308X（gfx942:sramecc+:xnack-）、8 卡环境，vLLM 通过 uv pip install 安装。

最快修复方案：升级到 vLLM 最新 main（nightly）构建。Issue 报告者确认使用 nightly 版本后问题已解决，修复由 #50578 引入。

注意事项：该修复方案来自 Issue 中维护者的回复和报告者的确认，但未提供具体 nightly 构建版本号；升级 nightly 可能引入其他不稳定因素，请在测试环境验证后再部署。

问题场景

用户使用 vLLM 0.27.0~0.27.1（ROCm 723 版本）的 vllm serve 命令加载 Kimi-K2.7-Coder（moonshotai/Kimi-K2.7）模型，配置了 8 卡张量并行（--tensor-parallel-size 8）、fp8 KV cache 等参数，启动后立即失败。同时设置了多个 ROCm 相关环境变量（如 VLLM_ROCM_USE_AITER=1、HIP_FORCE_DEV_KERNARG=1 等），并指定了 gfx942 架构。

报错原文

AssertionError: mla_gluon requires gfx950 (CDNA4), got gfx942

原因分析

该断言表明 vLLM 在加载模型时检测到 mla_gluon 算子仅支持 gfx950（CDNA4）架构，而当前运行环境为 gfx942（对应 AMD MI308X 显卡）。可能原因是：

vLLM 0.27.x 的 ROCm 版本对 gfx942 架构的 mla_gluon 算子支持不完整或存在环境变量未正确传递的校验逻辑；
Kimi-K2.7-Coder 模型代码在初始化时通过架构检查来确保算子可用性，但 gfx942 不在支持列表内；
该问题可能是 vLLM 0.27.0~0.27.1 的回归缺陷，已在后续 main 分支中被修复（#50578）。

环境排查

确认 vLLM 安装版本是否为 0.27.0 或 0.27.1 的 rocm723 构建。
检查 GPU 架构：rocminfo | grep gfx 应返回 gfx942。
确认 ROCm 版本为 7.2.3，PyTorch 为 ROCm 7.2.x 构建版本。
若设置了 VLLM_ROCM_USE_AITER 等环境变量，需确认这些变量在 vLLM 0.27.x 中是否被正确识别。

解决步骤

备份当前环境配置和启动命令，记录当前 vLLM 版本号。
获取 vLLM 最新 main（nightly）构建版本，可通过 vLLM 官方 nightly wheel 或源码安装方式获得。
在测试环境安装 nightly 版本的 vLLM，保持原有启动命令和环境变量不变。
重新执行 vllm serve 启动 Kimi-K2.7-Coder 模型，观察是否仍出现 mla_gluon 断言错误。
若 nightly 版本正常启动，确认问题已解决；若仍失败，提供完整日志至 vLLM GitHub Issue 继续排查——这可能说明问题仍存在于该构建中，需进一步检查环境变量或模型配置。

验证方法

成功启动 vLLM serve 并显示模型加载完成、监听端口正常；使用 curl 或其他客户端发送一次推理请求（如 curl http://localhost:8003/v1/models）确认服务可用。若启动过程不再出现 AssertionError: mla_gluon requires gfx950 (CDNA4) 且无其他报错，即表示问题已解决。