作者​：昇腾实战派
​知识地图​：https://blog.csdn.net/Lumos_Lovegood/article/details/161601003

背景概述

在基于 vLLM 0.19.0 版本部署 Minimax M3 模型时，我们发现 Atlas 800I A2 机器在启用图模式后出现精度异常，而单算子模式及 Atlas 800I A3 机器均表现正常。经排查，该问题与 MoE 通信路径选择、TP/EP 多卡部署及 torch compile 图模式相关，最终定位为 ALLGATHER 通信方式下缺少 TP all-reduce 导致聚合结果不完整。本文详细记录了问题现象、根因分析及修复方案。

问题现象

使用 vLLM 0.19.0 版本时：

• Atlas 800I A3 机器：单算子和图模式下入图精度均正常。
• Atlas 800I A2 机器：单算子精度正常，但入图后精度异常（图模式下，简单的问题也会答错）。
  

根因

MoE 通信方式选择 ALLGATHER 时，PrepareAndFinalizeWithAllGather.finalize() 阶段缺少 TP all-reduce。ALLGATHER 仅负责收集 token/expert 分发数据，不会自动对 TP 各 rank 的 partial hidden output 求和。入图后 reduce 边界不稳定，导致首 token logits 使用不完整聚合结果。

关联因素

• Atlas 800I A2 双机部署
• MoE 通信路径选择 ALLGATHER
• 开启 torch compile 图模式（FULL_DECODE_ONLY）
• prefill 走 compiled forward
• TP/EP 多卡场景

修复方案

三个代码文件，共 12 行改动，修复思路是将 ALLGATHER 的 TP reduce 收回到明确边界：

1. ALLGATHER finalize 内补齐 TP all-reduce

文件：vllm_ascend/ops/fused_moe/prepare_finalize.py

在 _finalize_with_dp_group() 中，当满足以下条件时执行 TP all-reduce：

• reduce_results=True
• 未启用 shared expert DP
• 未启用 replace_allreduce
• tp_size > 1 或 ep_size > 1

2. ALLGATHER 标记为 fused output 已 reduced

文件：vllm_ascend/ops/fused_moe/fused_moe.py

在 AscendMoERunner._fused_output_is_reduced 中增加 MoECommType.ALLGATHER，避免外层重复 reduce。

3. shared expert 的 ALLGATHER 分支同步 TP all-reduce

文件：同上

shared expert 分支的 all-reduce 条件增加 MoECommType.ALLGATHER，保证 routed_out 与 shared_out 在相加前处于同一 reduce 语义层级。

4. runtime 声明 shared MoE custom op 会原地修改输入

文件：vllm/model_executor/layers/fused_moe/runner/moe_runner.py

给 moe_forward_shared 增加 mutates_args=["hidden_states"]，让 torch.compile 正确理解 custom op 的原地写行为。

验证结果

• 正常回答：“北京”
• 用户原始采样参数下未复现异常
• 双机重启后已通过接口验证，精度恢复正常
  

对其他模型的影响

• Atlas 800I A3 正常 expert parallel 路径（MC2/ALLTOALL）：无影响
• 非 MoE 模型：无影响
• MoE 不走 ALLGATHER 的模型：无影响
• 走 ALLGATHER 的 TP/EP 多卡模型：受本次修复影响，精度应更正确，但会承担对应 all-reduce 通信成本