MoE 模型跑分布式推理时最慢的不是 Expert 计算——是 Token 分发。每个 Token 要路由到不同的 Expert，这步 AllToAll 通信的延迟在 8 卡上能占到总推理时间的 40-55%。DeepEP 不是减少通信量，而是让通信和计算重叠。

AllToAll 为什么成为瓶颈

传统 Dense 模型分布式推理的主要通信是 AllReduce（梯度/激活的归约）。每个 rank 往所有 rank 发一份数据，但所有人发的数据最后加总到一起——通信量跟数据量成正比。

MoE 的 AllToAll 完全不同。每个 Token 通过 Gate 网络选出 Top-K 个 Expert，然后被 Dispatch 到 Expert 所在的 rank。8 个 rank，每个 rank 要向 7 个其余 rank 发数据——N² 条通信链路。一轮 Decode 的 Token 数是 Batch × Top-K，8 卡 Top-K=2 时通信量约等于 Token 数据量的 1.75 倍。

MoE 推理的关键步骤：

1. Gate 计算：gate_logits = router(x)，选 Top-K Expert
2. Token Dispatch：按 Expert→Rank 映射，做 AllToAll 分发 Token
3. Expert 计算：每个 Rank 独立算自己存的那几个 Expert
4. Token Combine：AllToAll 把 Expert 输出收集回来

步骤 2 和 4 的 AllToAll 是双向通信
→ 一次 MoE 层推理 = 2 次 AllToAll + N 个 Expert 计算
→ AllToAll 通信时间占总延迟 40-55%

昇腾集群的 AllToAll 优化

8 张 Ascend 910 通过 HCCS 全互联，单链路带宽 56GB/s。HCCL 的 hcclAlltoAll 在 8 卡全互联下走直连——每个 rank 到每个其他 rank 都是 1 跳。理论峰值带宽：7 × 56 = 392 GB/s。实测约 340 GB/s，HCCL 效率约 87%。

DeepEP 在这个基础上加了两层优化：

第一层：Token 重排。 Dispatch 前在 NPU 显存上按目标 Rank 重新排列 Token——把去往同一 Rank 的 Token 聚集到连续地址。AllToAll 发送时一次 DMA 搬一片连续数据，避免离散 Gather。

第二层：通信-计算 Overlap。 最核心的优化。当前批次 Token 在做 AllToAll Dispatch 时，上一批次的 Expert 计算还在跑。两个操作走不同 Stream——通信 Stream 和计算 Stream 并行。

DeepEP 的通信-计算 Overlap：

Timeline（三条 Stream）：
Stream 0（通信）：[AllToAll Batch 1]        [AllToAll Batch 2]
Stream 1（计算）：          [Expert Batch 1]                [Expert Batch 2]
Stream 2（通信）：        [Combine Batch 1]               [Combine Batch 2]

关键：Dispatch Batch 2 和 Expert Batch 1 同时跑
      Combine Batch 1 和 Expert Batch 1 的尾段同时跑

吞吐对比

Mixtral 8×7B，8 卡 Ascend 910，SeqLen=4096，FP16：

DeepEP 把通信占比从 45% 降到 18%，多出的 240 tok/s 全来自通信和计算的重叠。

分布式通信的挑战

AllToAll 跟 AllReduce 的硬件需求也不一样。AllReduce 在最慢的链路上做加法后继续传——对单链路延迟不敏感。AllToAll 每对 rank 之间的链路都要用——一条慢链路拖慢所有。8 卡 HCCS 全互联的优势就在这：没有中转跳，没有共享链路，每对 rank 都是独立 56GB/s。

参考仓库

HCCL 集合通信库

hcomm 通信算子库

ops-transformer MoE 算子

CANN 学习中心