Prhub

#39387 [ROCm] Disable fused_silu_mul_block_quant on ROCm

原始 PR 作者 micah-wil 合并时间 2026-04-10 01:59 文件变更 1 提交数 5 评论 6 代码增减 +1 / -1

rocm bugfix quantization compilation v1

执行摘要

临时禁用 ROCm 平台的特定量化融合，避免模型启动失败。

PR body中明确指出：'After https://github.com/vllm-project/vllm/pull/38817, some models are failing on ROCm.' 错误源于QuantKey(f8e4m3fnuz,scale(f32,dynamic,GroupShape(row=1, col=128)),symmetric)不被支持，因为'torch.ops._C.per_token_group_fp8_quant'在ROCm上尚未启用，需要临时禁用该路径以避免崩溃。

此PR变更简单但涉及平台兼容性设计，值得ROCm用户或关注量化编译的开发者精读，重点关注如何通过平台检查实现优雅降级，以及review中讨论的一致性考量。

讨论亮点

review中gemini-code-assist[bot]指出使用hasattr与QUANT_OPS填充逻辑不一致，可能导致未来ROCm支持时仍出错，建议使用current_platform.is_cuda()；tjtanaa同意此建议。最终结论是采纳is_cuda作为临时修复，并计划后续通过vLLM IR Ops启用内核支持。

实现拆解

仅修改了vllm/compilation/passes/fusion/act_quant_fusion.py文件的一行代码：将if current_platform.is_cuda_alike(): 改为 if current_platform.is_cuda():。这限制了SiluMulBlockQuantPattern模式仅对CUDA平台注册，从而在ROCm上跳过相关融合，避免因缺失量化操作而导致的断言错误。

文件 模块 状态 重要度
vllm/compilation/passes/fusion/act_quant_fusion.py compilation/fusion modified 7.0

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

关键符号

SiluMulBlockQuantPattern.__init__ current_platform.is_cuda

评论区精华

平台检查方法的选择 设计

gemini-code-assist[bot] 指出：'The use of `hasattr` here is inconsistent with the rest of the codebase...' 并建议使用 current_platform.is_cuda() 以确保与 QUANT_OPS 填充逻辑一致。

结论：采纳建议，改为使用 current_platform.is_cuda() 作为临时修复，避免未来 ROCm 支持时的潜在断言错误。 · 已解决

风险与影响

风险较低：变更仅影响条件检查，不会引入回归错误。但可能导致ROCm用户在特定FP8量化场景下性能下降，因为融合被禁用。兼容性依赖于平台检测的正确性，若is_cuda()在混合环境中误判，可能影响其他平台。

对ROCm用户：解决了Llama-3.1-70B-Instruct-FP8-KV等模型的启动失败问题，提升稳定性。系统层面：在ROCm上禁用了fused_silu_mul_block_quant融合，可能轻微影响FP8量化推理性能。团队影响：需跟踪ROCm内核开发进度，以在未来重新启用融合优化。

ROCm 功能降级 平台检测依赖

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接，后续同步到相关引用后会出现在这里。

完整报告

Markdown PDF

执行摘要

  • 一句话：临时禁用ROCm平台的特定量化融合，避免模型启动失败。
  • 推荐动作：此PR变更简单但涉及平台兼容性设计，值得ROCm用户或关注量化编译的开发者精读，重点关注如何通过平台检查实现优雅降级，以及review中讨论的一致性考量。

功能与动机

PR body中明确指出：'After https://github.com/vllm-project/vllm/pull/38817, some models are failing on ROCm.' 错误源于QuantKey(f8e4m3fnuz,scale(f32,dynamic,GroupShape(row=1, col=128)),symmetric)不被支持，因为'torch.ops._C.per_token_group_fp8_quant'在ROCm上尚未启用，需要临时禁用该路径以避免崩溃。

实现拆解

仅修改了vllm/compilation/passes/fusion/act_quant_fusion.py文件的一行代码：将if current_platform.is_cuda_alike(): 改为 if current_platform.is_cuda():。这限制了SiluMulBlockQuantPattern模式仅对CUDA平台注册，从而在ROCm上跳过相关融合，避免因缺失量化操作而导致的断言错误。

关键文件：

  • vllm/compilation/passes/fusion/act_quant_fusion.py（模块 compilation/fusion）: 包含平台检查逻辑，直接决定SiluMulBlockQuantPattern是否在ROCm上注册，是修复的核心文件。

关键符号：SiluMulBlockQuantPattern.init, current_platform.is_cuda

评论区精华

review中gemini-code-assist[bot]指出使用hasattr与QUANT_OPS填充逻辑不一致，可能导致未来ROCm支持时仍出错，建议使用current_platform.is_cuda()；tjtanaa同意此建议。最终结论是采纳is_cuda作为临时修复，并计划后续通过vLLM IR Ops启用内核支持。

  • 平台检查方法的选择 (design): 采纳建议，改为使用current_platform.is_cuda()作为临时修复，避免未来ROCm支持时的潜在断言错误。

风险与影响

  • 风险：风险较低：变更仅影响条件检查，不会引入回归错误。但可能导致ROCm用户在特定FP8量化场景下性能下降，因为融合被禁用。兼容性依赖于平台检测的正确性，若is_cuda()在混合环境中误判，可能影响其他平台。
  • 影响：对ROCm用户：解决了Llama-3.1-70B-Instruct-FP8-KV等模型的启动失败问题，提升稳定性。系统层面：在ROCm上禁用了fused_silu_mul_block_quant融合，可能轻微影响FP8量化推理性能。团队影响：需跟踪ROCm内核开发进度，以在未来重新启用融合优化。
  • 风险标记：ROCm功能降级, 平台检测依赖

关联脉络

  • PR #38817 未知: 从PR body提及，引入了fused_silu_mul_block_quant融合，导致ROCm失败，是本PR的直接触发原因。
  • PR #39122 [ROCm] Remove unnecessary fp8 roundtrip in gather cache NHD dequant: 同是ROCm平台上的FP8量化修复，涉及类似平台特定优化问题，可参考跨平台支持策略。

参与讨论