读摩尔线程 Megatron-MUSA-Titan 的改动说明时，有个细节值得单独拆开：它用 DeepEP 优化 MoE 的 token dispatch 与 combine，并让通信跑在硬件的 Async Copy Engine 上。
MoE 的训练效率瓶颈在哪
稠密模型里每个 token 都过所有参数，计算量大但通信简单。MoE 相反：每个 token 只激活少数几个专家，计算量小，但必须先搞清楚这个 token 该去哪个专家——这就是 routing，然后要把它「送过去」，算完再「送回来」，分别是 dispatch 与 combine。
问题在于专家是分布在不同 GPU 上的。一次 dispatch 本质是一次 all-to-all 通信，数据量取决于 batch 大小与专家并行度。当专家并行度上去之后，通信时间会盖过计算时间，GPU 大量空转等数据。
DeepEP 的思路
DeepEP 是专门为 MoE 通信做的库，核心做法是按目标专家做分组打包，减少通信次数，并把通信与计算重叠起来——一边发下一批 token，一边算当前这批。这种 overlap 是 MoE 训练提速的关键，做不好就是通信完再计算，串行执行。
Async Copy Engine 是什么角色
它是硬件里专门负责异步数据搬运的单元，不占用计算核心。把 dispatch 的拷贝交给它，等于让计算单元专心算，搬运由另一条通道并行完成。这是硬件特性层面的优化，也是为什么这套栈与特定硬件绑得紧——换平台就没有这个引擎可用。
读代码时该关注什么
看它怎么处理「专家负载不均」：某些专家被路由到的 token 特别多，会造成等待。常见做法是 capacity factor 加 token 丢弃，或者用冗余专家。另外看它怎么处理跨节点通信与节点内通信的分层——节点内走 NVLink 一类高带宽链路，跨节点走 IB 或等效网络，两者的策略完全不同。
给自研团队的启示
MoE 的工程难度不在模型结构，在通信。评估一套 MoE 训练栈，别看它支持多少参数，看它在专家并行度 8、16、32 时的通信占比。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
