# PR #37787 完整报告

- 仓库：`vllm-project/vllm`
- 标题：[Bugfix][ROCm][MoE] Fix mxfp4 oracle regressions from #37128
- 合并时间：2026-03-25 08:17
- 原文链接：http://prhub.com.cn/vllm-project/vllm/pull/37787

---

## 执行摘要
本 PR 修复了由 PR #37128 重构引入的多个回归问题，主要影响 ROCm 平台上使用 mxfp4 量化的 MoE 模型（如 gpt-oss）。通过恢复 gfx950 gate、对齐检查和 padding 字段，确保 CK backend 正确选择并回退到 Triton，从而恢复 CI 测试通过和模型功能。这是一个重要的 bugfix，但涉及临时性 padding hack，需后续优化。

## 功能与动机
动机是解决 #37128 导致的 gpt-oss 在 ROCm 上的崩溃问题。具体问题包括：CK backend 在非 gfx950 设备（如 gfx942）上错误选择导致崩溃；模型维度未对齐 256 时出现 reshape 错误；以及 hidden_pad 和 intermediate_pad 字段丢失影响 ROCm aiter 内核调用。PR body 中明确表述：“Fixes several issues introduced by #37128 that broke gpt-oss on ROCm。”

## 实现拆解
实现按模块拆解如下：
- **backend 选择逻辑**：在 `oracle/mxfp4.py` 的 `select_mxfp4_moe_backend` 中，恢复 `is_supported_config` 方法，添加对齐检查（CK_MXFP4_MOE_DIM_ALIGNMENT），使不满足条件的模型回退到 Triton。
- **ROCm 特定处理**：在 `rocm_aiter_fused_moe.py` 中，修改 `_supports_quant_scheme` 以包含 `on_gfx950()` 检查，限制 CK backend 仅用于 gfx950；同时传递 `hidden_pad` 和 `intermediate_pad` 字段到 `rocm_aiter_fused_experts`。
- **padding 字段传递**：在 `mxfp4.py` 的 `create_weights` 和 `get_fused_moe_quant_config` 中添加 padding 计算和字段，确保信息流向下游。
- **tensor API 兼容性**：将多个文件中的 `.size()` 和 `.dim()` 改为 `.shape` 和 `len(.shape)`，例如在 `fused_moe.py` 和 `gpt_oss_triton_kernels_moe.py` 中，以支持 `triton_kernels.tensor.Tensor` 类型。
- **测试和 CI 调整**：更新 `.buildkite/test-amd.yaml` 添加测试，并在 `test_gptoss_tp.py` 中添加平台检查跳过。

## 评论区精华
review 讨论中的精华点：
- **矛盾澄清**：gemini-code-assist[bot] 指出：“PR description states: 'Enable mxfp4 LoRA on ROCm' ... However, this change still raises a `NotImplementedError`”。最终，错误消息被改为平台无关，但功能未启用，揭示了 PR 描述与实现的不一致。
- **技术解释**：AndreasKaratzas 在回复 jeejeelee 时解释：“When mxfp4 quantization is active, w1/w2 can be triton_kernels.tensor.Tensor objects, not torch.Tensor. Calling .size(0) or .dim() on them would raise AttributeError。” 这突出了抽象层设计的重要性。
- **优化建议**：Rohan138 建议：“if you just need to check for the current device being gfx950, you should instead override `supports_current_device`”。但作者回应需在 `_supports_quant_scheme` 中处理，以保持逻辑一致性。
- **长期视角**：BowenBao 评论：“The size -> shape change and padding logic feel like quick(hacky) band-aids”，建议等待 PR #34285，但作者因 CI 压力推进，反映了工程权衡。

## 风险与影响
具体风险包括：padding 逻辑基于硬编码值，是临时方案，可能在未来引入维护负担；mxfp4 LoRA 在 ROCm 上仍不支持，限制功能扩展；tensor API 变更虽已修复，但需监控其他潜在影响。影响方面，本 PR 直接恢复 gpt-oss 模型在 ROCm 上的可用性，提升 CI 稳定性，但团队需跟进 #34285 以避免技术债务。

## 关联脉络
本 PR 与历史 PR 紧密关联：
- **PR #37128**：是问题的根源，其重构引入了 gfx950 gate 丢失、对齐检查移除和 padding 字段遗漏，本 PR 旨在修复这些回归。
- **其他相关 PR**：如 #37811、#37784、#37786 在 PR body 中被提及，可能涉及补充修复或 CI 调整，反映了跨 PR 的协作脉络。
- **演进趋势**：从讨论中可见，仓库在 MoE 量化后端选择上持续优化，但面临平台特定性（如 ROCm gfx950）和抽象兼容性挑战，提示未来需更统一的设计。