面对MoE架构带来的算力工程问题，华为展示的核心方法是“从算子到框架逐一突破”。这不是笼统强调软硬件协同，而是先找到动态路由、专家负载、跨设备通信和框架调度中的真实瓶颈，再决定在哪一层处理。对技术团队而言，真正可复用的价值是一套诊断与优化顺序，而不是脱离模型、硬件和测试口径比较单个性能数字。
MoE为什么比普通稠密模型更考验系统协同
MoE会根据输入动态选择部分专家参与计算。模型不必让全部专家处理每个Token，但也由此带来新的工程问题：不同专家接收的Token数量可能不一致，数据需要在设备之间重新分发，专家完成计算后还要把结果合并回来。计算路径不断变化，局部的负载不均或通信等待都可能放大为端到端延迟。
在这条链路中，Dispatch负责把Token分发给被选中的专家，Combine负责汇总专家输出。二者不仅包含数据搬运，还涉及路由信息、设备通信、专家并行和同步关系。只提升某个矩阵计算的速度，如果分发与汇总仍然等待，整条链路的吞吐就未必同步提高。
算子层要减少搬运、同步和碎片化开销
算子是模型执行的基础单元。MoE场景下，输入长度、Top-K路由结果和各专家负载会随批次变化，算子既要完成计算，也要处理不规则的数据组织。优化重点因此不只是提高单次计算峰值，还包括减少主机与设备之间的同步、合并零散通信、降低重复搬运，并尽量让计算和通信形成流水。
昇腾技术文章披露，相关团队围绕MoeDistributeDispatch与MoeDistributeCombine融合算子持续迭代，把部分原本依赖Host的路由处理下沉到Device侧，并针对通信方式和组网特点优化数据分发。文章给出的50%吞吐提升属于特定DeepSeek V3推理场景和迭代结果，不能直接套用到其他模型、集群规模或业务负载，但它说明：当瓶颈确实位于分发、通信和同步环节时，融合算子能够产生端到端价值。
框架层决定局部优化能否转化为整体收益
框架掌握模型结构、批次、专家映射、并行方式和运行时调度，可以从全局决定任务怎样拆分、通信何时发起以及不同设备如何衔接。如果专家负载长期不均，或者计算结束后仍要等待其他节点，单个算子即使更快，也可能被全局调度中的空闲时间抵消。
因此，框架优化需要处理三个关系：一是路由策略与专家负载，避免少数专家成为持续热点；二是计算与通信的时序，让可并行的环节尽量重叠；三是软件策略与硬件拓扑匹配，避免在不同组网条件下机械复用同一方案。“从算子到框架”强调的正是这种跨层联动，而不是把所有问题归因于算力不足。
开源工具链降低了定位和定制门槛
2025年8月5日，华为宣布CANN全面开源开放，Mind系列应用使能套件及工具链也全面开源，支持用户进行深度挖潜和自定义开发。开放的意义不只是能够查看代码，更在于开发者可以结合自己的模型结构、算子组合和部署环境定位问题，并针对特定工作负载调整实现。
不过，开放工具链不等于自动获得性能提升。团队仍需要具备可复现的基准测试、性能分析和回归验证流程；修改算子或调度策略后，还要检查精度、稳定性、显存占用和不同负载下的一致性，避免只在单一测试样本上获得局部收益。
评价MoE优化应先固定完整测试口径
一项优化是否有效，至少要说明模型与版本、硬件数量和互联方式、并行策略、输入长度、批量大小、数据类型、Top-K设置，以及吞吐或时延的统计方法。平均性能改善之外，还应观察专家负载分布、通信占比、长尾时延、资源利用率和持续运行稳定性。
对准备部署MoE模型的团队，可以按“定位瓶颈—优化底层执行—调整全局调度—完成回归验证”的顺序推进。华为工程实践的启示，是先把动态计算链路拆开看清，再让算子、通信、框架和工具链共同解决问题。只有在测试条件一致、结果可复现时，性能数字才具有比较和决策价值。
