Prhub

#38086 [ROCm] Enable VLLM triton FP8 moe for gfx1201, tuned for Qwen3-30B-A3B-FP8 tp=2 and Qwen/Qwen3.5-35B-A3B-FP8 tp=2

原始 PR 作者 vllmellm 合并时间 2026-04-02 16:13 文件变更 4 提交数 3 评论 4 代码增减 +343 / -4

performance rocm qwen v1 feature

执行摘要

为 ROCm gfx12x 架构启用 Triton FP8 MoE 后端并添加 R9700 调优配置。

解决Issue #36105中报告的问题：在ROCm v0.16.0上，Qwen3-VL-30B-A3B-Instruct-FP8等模型启动时抛出NotImplementedError: No FP8 MoE backend supports the deployment configuration错误。PR正文明确指出其目的是“Enable Triton FP8 MoE for RDNA4 (gfx12xx) in vLLM so FP8 MoE models can run on ROCm with these GPUs”，以扩展vLLM在ROCm平台上对FP8 MoE模型的支持范围。

该PR清晰地解决了一个具体的平台支持缺口，并附带了详实的性能测试数据，值得负责ROCm支持、MoE模块或性能优化的工程师精读。关注点应包括：1) on_gfx12x检测逻辑的实现；2) 调优配置文件的参数模式，以了解如何为特定硬件定制Triton内核；3) 性能测试方法（TTFT、TPOT、E2E Latency）和精度验证方式，可作为类似工作的范本。

讨论亮点

Review讨论非常简短，仅有一条实质性评论。审核者tjtanaa在新增的调优配置文件上询问：“Does this PR runs on vLLM docker image?”，这可能是在关心配置的生成环境或兼容性。此评论未得到公开回复，但tjtanaa随后批准了PR（“LGTM”）。此外，Issue评论中big-yellow-duck提到会将benchmark_moe.py的补丁移到另一个PR以保持本PR的简洁，但调优配置会保留在此PR中。

实现拆解

实现分为两个主要部分：

  1. 平台支持扩展：修改vllm/platforms/rocm.py，新增on_gfx12x()函数用于检测gfx12架构，并在设备映射表中添加AMD_Radeon_R9700条目。修改vllm/model_executor/layers/fused_moe/fused_moe.py中的_supports_quant_scheme函数，在判断设备是否支持FP8时，将is_rocm_on_gfx12x加入条件（原已支持is_rocm_on_gfx9和CUDA SM8/9等），从而为gfx12x架构开启FP8 MoE后端支持。
  2. 性能调优配置：新增两个JSON调优配置文件：vllm/model_executor/layers/fused_moe/configs/E=128,N=512,device_name=AMD_Radeon_R9700,dtype=fp8_w8a8,block_shape=[128,128].json 和 E=64,N=768,...。这些文件包含了针对不同num_vec（从1到4096）的Triton内核参数（如BLOCK_SIZE_M/N/K、num_warps等），专为AMD Radeon R9700 GPU（设备ID 0x7551）和FP8数据类型优化，旨在提升特定Qwen MoE模型的推理性能。
文件 模块 状态 重要度
vllm/model_executor/layers/fused_moe/fused_moe.py model_executor/layers/fused_moe modified 8.0
vllm/platforms/rocm.py platforms modified 7.0
vllm/model_executor/layers/fused_moe/configs/E=128,N=512,device_name=AMD_Radeon_R9700,dtype=fp8_w8a8,block_shape=[128,128].json model_executor/layers/fused_moe/configs added 6.0

分析完成后，这里会展示 LLM 生成的相对完整源码片段和详细注释。

关键符号

_supports_quant_scheme ( 在 fused_moe.py 中 ) on_gfx12x ( 在 rocm.py 中 )

评论区精华

调优配置的运行时环境验证 question

审核者 tjtanaa 在调优配置文件上评论：'Does this PR runs on vLLM docker image?'，询问配置是否在标准 vLLM Docker 镜像中测试过。

结论：评论未获公开回复，但提问者随后批准了 PR，暗示问题可能已私下解决或被认为不影响合并。 · 已解决

风险与影响

  1. 平台检测风险：on_gfx12x()检测逻辑依赖于GPU架构名称包含“gfx12”。若未来ROCm设备命名规则变化或存在特例，可能导致检测不准确，进而影响FP8支持的启用。
  2. 配置泛化风险：新增的两个调优配置文件（E=128/N=512和E=64/N=768）是针对AMD_Radeon_R9700（gfx1201）和特定模型维度（Qwen3-30B/Qwen3.5-35B）进行优化的。这些配置可能不适用于其他gfx12x GPU（如gfx1200）或其他FP8 MoE模型，存在性能未达最优或兼容性问题。
  3. 维护风险：调优配置文件数量随硬件和模型组合增长，可能增加配置管理的复杂性。
  4. 回归风险：对_supports_quant_scheme的修改是增量式的，仅增加了一个条件，理论上不影响原有CUDA、gfx9或xpu路径，回归风险较低。
  1. 用户影响：解决了使用RDNA4（gfx12x）系列AMD GPU的用户无法运行FP8 MoE模型的问题，扩大了vLLM在ROCm生态的可用模型范围。对于使用指定Qwen模型的用户，能获得显著的性能提升（根据PR中数据，TPOT平均提升约8-13%，端到端延迟平均提升约6-8%）。
  2. 系统影响：扩展了vLLM的硬件支持矩阵，增强了在AMD最新GPU上的竞争力。新增的调优配置仅为特定硬件/模型组合提供，不会改变系统默认行为，对其他部署配置无影响。
  3. 团队影响：提供了针对AMD GPU的MoE内核调优实践案例，可作为后续为其他AMD GPU或模型进行性能优化的参考。
新增平台支持路径 设备特定调优配置 配置泛化性待验证

关联 Issue

#36105 [ROCm][v0.16.0] Qwen3-VL-30B-A3B-Instruct-FP8 fails to start with NotImplementedError: No FP8 MoE backend supports the deployment configuration

完整报告

Markdown PDF

执行摘要

  • 一句话：为ROCm gfx12x架构启用Triton FP8 MoE后端并添加R9700调优配置。
  • 推荐动作：该PR清晰地解决了一个具体的平台支持缺口，并附带了详实的性能测试数据，值得负责ROCm支持、MoE模块或性能优化的工程师精读。关注点应包括：1) on_gfx12x检测逻辑的实现；2) 调优配置文件的参数模式，以了解如何为特定硬件定制Triton内核；3) 性能测试方法（TTFT、TPOT、E2E Latency）和精度验证方式，可作为类似工作的范本。

功能与动机

解决Issue #36105中报告的问题：在ROCm v0.16.0上，Qwen3-VL-30B-A3B-Instruct-FP8等模型启动时抛出NotImplementedError: No FP8 MoE backend supports the deployment configuration错误。PR正文明确指出其目的是“Enable Triton FP8 MoE for RDNA4 (gfx12xx) in vLLM so FP8 MoE models can run on ROCm with these GPUs”，以扩展vLLM在ROCm平台上对FP8 MoE模型的支持范围。

实现拆解

实现分为两个主要部分：

  1. 平台支持扩展：修改vllm/platforms/rocm.py，新增on_gfx12x()函数用于检测gfx12架构，并在设备映射表中添加AMD_Radeon_R9700条目。修改vllm/model_executor/layers/fused_moe/fused_moe.py中的_supports_quant_scheme函数，在判断设备是否支持FP8时，将is_rocm_on_gfx12x加入条件（原已支持is_rocm_on_gfx9和CUDA SM8/9等），从而为gfx12x架构开启FP8 MoE后端支持。
  2. 性能调优配置：新增两个JSON调优配置文件：vllm/model_executor/layers/fused_moe/configs/E=128,N=512,device_name=AMD_Radeon_R9700,dtype=fp8_w8a8,block_shape=[128,128].json 和 E=64,N=768,...。这些文件包含了针对不同num_vec（从1到4096）的Triton内核参数（如BLOCK_SIZE_M/N/K、num_warps等），专为AMD Radeon R9700 GPU（设备ID 0x7551）和FP8数据类型优化，旨在提升特定Qwen MoE模型的推理性能。

关键文件：

  • vllm/model_executor/layers/fused_moe/fused_moe.py（模块 model_executor/layers/fused_moe）: 核心修改文件，在此处扩展了FP8量化方案对ROCm gfx12x架构的支持条件，是解决Issue中“No FP8 MoE backend supports”错误的关键。
  • vllm/platforms/rocm.py（模块 platforms）: 新增on_gfx12x()平台检测函数和R9700设备映射，为上层判断提供基础支持。
  • vllm/model_executor/layers/fused_moe/configs/E=128,N=512,device_name=AMD_Radeon_R9700,dtype=fp8_w8a8,block_shape=[128,128].json（模块 model_executor/layers/fused_moe/configs）: 新增的性能调优配置文件之一，针对特定专家数(E=128)和隐藏层大小(N=512)的模型进行优化，包含大量Triton内核参数，直接影响目标模型在R9700上的性能。

关键符号：_supports_quant_scheme (在fused_moe.py中), on_gfx12x (在rocm.py中)

评论区精华

Review讨论非常简短，仅有一条实质性评论。审核者tjtanaa在新增的调优配置文件上询问：“Does this PR runs on vLLM docker image?”，这可能是在关心配置的生成环境或兼容性。此评论未得到公开回复，但tjtanaa随后批准了PR（“LGTM”）。此外，Issue评论中big-yellow-duck提到会将benchmark_moe.py的补丁移到另一个PR以保持本PR的简洁，但调优配置会保留在此PR中。

  • 调优配置的运行时环境验证 (question): 评论未获公开回复，但提问者随后批准了PR，暗示问题可能已私下解决或被认为不影响合并。

风险与影响

  • 风险：1. 平台检测风险：on_gfx12x()检测逻辑依赖于GPU架构名称包含“gfx12”。若未来ROCm设备命名规则变化或存在特例，可能导致检测不准确，进而影响FP8支持的启用。
    2. 配置泛化风险：新增的两个调优配置文件（E=128/N=512和E=64/N=768）是针对AMD_Radeon_R9700（gfx1201）和特定模型维度（Qwen3-30B/Qwen3.5-35B）进行优化的。这些配置可能不适用于其他gfx12x GPU（如gfx1200）或其他FP8 MoE模型，存在性能未达最优或兼容性问题。
    3. 维护风险：调优配置文件数量随硬件和模型组合增长，可能增加配置管理的复杂性。
    4. 回归风险：对_supports_quant_scheme的修改是增量式的，仅增加了一个条件，理论上不影响原有CUDA、gfx9或xpu路径，回归风险较低。
  • 影响：1. 用户影响：解决了使用RDNA4（gfx12x）系列AMD GPU的用户无法运行FP8 MoE模型的问题，扩大了vLLM在ROCm生态的可用模型范围。对于使用指定Qwen模型的用户，能获得显著的性能提升（根据PR中数据，TPOT平均提升约8-13%，端到端延迟平均提升约6-8%）。
    2. 系统影响：扩展了vLLM的硬件支持矩阵，增强了在AMD最新GPU上的竞争力。新增的调优配置仅为特定硬件/模型组合提供，不会改变系统默认行为，对其他部署配置无影响。
    3. 团队影响：提供了针对AMD GPU的MoE内核调优实践案例，可作为后续为其他AMD GPU或模型进行性能优化的参考。
  • 风险标记：新增平台支持路径, 设备特定调优配置, 配置泛化性待验证

关联脉络

  • PR #38750 [ROCm][Bugfix] Fix ROCm runtime failure due to missing symbol: 同为ROCm相关的PR，涉及修复ROCm运行时问题。本PR是扩展ROCm平台的功能支持，可视为对ROCm生态支持的持续投入。
  • PR #38545 [Bugfix] Use dedicated MM processor cache in /tokenize to prevent sender-cache pollution: 涉及多模态模型支持。本PR中解决的Issue #36105最初由多模态模型Qwen3-VL触发，两者在问题根源（模型支持）上有关联。

参与讨论