Prhub

#7039 [Optimization] merge_allreduce

PaddlePaddle/FastDeploy · 作者 fxyfxy777 · 合并时间 2026-04-02 19:52

分析状态 已生成
文件变更 3提交数 3 · 评论 4
代码增减 +17 / -6
Optimization Models MoE

执行摘要

优化 GLM4-MoE 模型在纯 TP 并行模式下的 AllReduce 通信,合并两个 FFN 分支的归约操作。

根据PR描述中的"Modifications"部分,优化动机是"将普通专家和共享专家在计算ffn后各自的allreduce合并为一个allreduce"。代码注释进一步说明:在纯TP模式下(tp>1, ep=1),两个分支都返回部分和,因此推迟AllReduce到合并之后可以节省一次集体通信。

该PR值得精读,特别是对于关注分布式优化和MoE模型性能的工程师。核心设计决策在于如何根据并行模式动态调整归约策略,这种条件化通信优化模式值得借鉴。建议重点关注merge_ffn_tp的判断逻辑和reduce_results的参数传递一致性。

讨论亮点

review讨论非常简短,仅有一次命名建议:zhoutianzi666建议将变量名改为self.merge_ffn_tp以更易理解,作者fxyfxy777立即采纳并修改。没有出现设计争议或未解决的疑虑。

实现拆解

实现主要分为三个部分:1) 在glm4_moe.py的__init__中新增merge_ffn_tp标志,判断是否为纯TP模式(use_tp且非use_ep)。2) 修改FusedMoE和SharedExperts初始化参数,根据merge_ffn_tp设置reduce_results(为True时内部执行归约,为False时返回部分和)。3) 在forward方法中,如果merge_ffn_tp为True,则在合并两个专家输出后执行一次tensor_model_parallel_all_reduce。此外,更新了两个测试文件中的基线路径和预期输出。

文件 模块 状态 重要度
fastdeploy/model_executor/models/glm4_moe.py model_executor/models modified 9.0
tests/e2e/4cards_cases/test_GLM_45_AIR_mtp_tp4.py tests/e2e modified 4.0
tests/e2e/utils/rollout_routing_replay_test_utils.py tests/e2e/utils modified 3.0

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

关键符号

__init__ forward

评论区精华

变量命名优化 style

zhoutianzi666 建议将变量名改为 self.merge_ffn_tp 以提升可读性

结论:作者 fxyfxy777 采纳建议并修改 · 已解决

风险与影响

主要风险包括:1) 条件逻辑风险:merge_ffn_tp的判断条件(self.use_tp and not self.use_ep)需要确保在所有并行配置下正确,错误判断可能导致归约缺失或重复。2) 通信模式一致性:需确保FusedMoE和SharedExperts的reduce_results参数与merge_ffn_tp逻辑完全匹配,否则可能破坏分布式计算语义。3) 测试覆盖不足:Codecov报告显示patch覆盖率仅20%,有4行代码缺少测试覆盖,可能影响变更的可靠性验证。

对系统性能有积极影响:在纯TP并行场景下减少一次AllReduce通信,可提升MoE模型推理吞吐量,尤其在大规模分布式训练/推理中效果显著。对用户透明,不影响API接口。对团队开发影响较小,但需要确保相关测试充分覆盖变更逻辑。

条件逻辑风险 测试覆盖不足

关联 Issue

未识别关联 Issue

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

完整报告

执行摘要

  • 一句话:优化GLM4-MoE模型在纯TP并行模式下的AllReduce通信,合并两个FFN分支的归约操作。
  • 推荐动作:该PR值得精读,特别是对于关注分布式优化和MoE模型性能的工程师。核心设计决策在于如何根据并行模式动态调整归约策略,这种条件化通信优化模式值得借鉴。建议重点关注merge_ffn_tp的判断逻辑和reduce_results的参数传递一致性。

功能与动机

根据PR描述中的"Modifications"部分,优化动机是"将普通专家和共享专家在计算ffn后各自的allreduce合并为一个allreduce"。代码注释进一步说明:在纯TP模式下(tp>1, ep=1),两个分支都返回部分和,因此推迟AllReduce到合并之后可以节省一次集体通信。

实现拆解

实现主要分为三个部分:1) 在glm4_moe.py的__init__中新增merge_ffn_tp标志,判断是否为纯TP模式(use_tp且非use_ep)。2) 修改FusedMoE和SharedExperts初始化参数,根据merge_ffn_tp设置reduce_results(为True时内部执行归约,为False时返回部分和)。3) 在forward方法中,如果merge_ffn_tp为True,则在合并两个专家输出后执行一次tensor_model_parallel_all_reduce。此外,更新了两个测试文件中的基线路径和预期输出。

关键文件:

  • fastdeploy/model_executor/models/glm4_moe.py(模块 model_executor/models): 核心优化逻辑所在,实现了AllReduce合并的条件判断和前向计算修改。
  • tests/e2e/4cards_cases/test_GLM_45_AIR_mtp_tp4.py(模块 tests/e2e): 更新了端到端测试的预期输出,反映优化后模型输出的变化。
  • tests/e2e/utils/rollout_routing_replay_test_utils.py(模块 tests/e2e/utils): 更新了测试基线路径,确保测试环境一致性。

关键符号:init, forward

评论区精华

review讨论非常简短,仅有一次命名建议:zhoutianzi666建议将变量名改为self.merge_ffn_tp以更易理解,作者fxyfxy777立即采纳并修改。没有出现设计争议或未解决的疑虑。

  • 变量命名优化 (style): 作者fxyfxy777采纳建议并修改

风险与影响

  • 风险:主要风险包括:1) 条件逻辑风险:merge_ffn_tp的判断条件(self.use_tp and not self.use_ep)需要确保在所有并行配置下正确,错误判断可能导致归约缺失或重复。2) 通信模式一致性:需确保FusedMoE和SharedExperts的reduce_results参数与merge_ffn_tp逻辑完全匹配,否则可能破坏分布式计算语义。3) 测试覆盖不足:Codecov报告显示patch覆盖率仅20%,有4行代码缺少测试覆盖,可能影响变更的可靠性验证。
  • 影响:对系统性能有积极影响:在纯TP并行场景下减少一次AllReduce通信,可提升MoE模型推理吞吐量,尤其在大规模分布式训练/推理中效果显著。对用户透明,不影响API接口。对团队开发影响较小,但需要确保相关测试充分覆盖变更逻辑。
  • 风险标记:条件逻辑风险, 测试覆盖不足

关联脉络

  • PR #7073 [OP] support deepgeem for sm103: 同属Optimization标签的PR,涉及模型执行层的性能优化。
  • PR #7001 [Feature] Support mtp overlap schedule: 同属性能优化相关PR,关注调度和通信优化。
  • PR #6993 [XPU] Refactor pre process: 同属模型执行层优化,涉及前处理逻辑重构。

参与讨论