在大规模语言模型训练中，Mixture-of-Experts（MoE）架构通过稀疏激活机制实现了模型容量与计算成本的有效平衡。然而，MoE 的专家并行（Expert Parallelism，EP）策略带来了独特的通信挑战：每个 token 需要根据门控机制分发到不同的专家节点，随后又需要将各专家的输出结果汇总合并。这种一对多的 dispatch 操作与多对一的 combine 操作构成了 MoE 训练中最为关键的通信瓶颈。DeepEP 作为 DeepSeek 团队开源的高效专家并行通信库，正是为解决这一核心问题而设计的基础设施层方案。
MoE 通信的核心挑战与 DeepEP 的设计定位
传统分布式训练中，数据并行与模型并行的通信模式相对单一，而 MoE 的专家并行则呈现出高度非对称的通信模式。以一个包含八个专家的 MoE 层为例，假设模型分布在四台 GPU 节点上，每个 token 在 dispatch 阶段需要根据门控决策被发送到对应的专家副本，而在 combine 阶段则需要将从不同专家返回的结果进行聚合。这种 all-to-all 通信模式的规模直接取决于专家数量与分布策略，当专家数量达到数十乃至上百时，通信量与延迟会成为训练吞吐量的决定性因素。
DeepEP 的设计正是针对这一场景进行深度优化。库的核心目标是在保证专家并行正确性的前提下，最大化 all-to-all 通信的吞吐并降低端到端延迟。与通用的集合通信库（如 NCCL）不同，DeepEP 专门面向 MoE 的 dispatch 与 combine 操作进行了内核层面的定制优化，能够充分利用 GPU 内存层次结构并实现数据传输与计算的有效重叠。
高吞吐 all-to-all 内核的实现细节
DeepEP 提供的核心功能是高吞吐量的 all-to-all 通信内核，这一内核针对 MoE 的两个关键阶段进行了分别优化。在 dispatch 阶段，库需要将每个 token 的隐藏状态根据门控决策发送到对应的专家进程；在 combine 阶段，则需要将各专家计算后的结果汇总回原始 token 序列。这两个操作在通信模式上呈现出镜像对称的特点，但在实际实现中面临着不同的性能约束。
CUDA 实现层面，DeepEP 的内核设计充分利用了共享内存与全局内存的层次化特性。对于 intra-node 通信（即同一台机器内的多 GPU 通信），库优先使用 NVLink 提供的高带宽路径，其峰值带宽可达数百 GB/s，远超传统的 PCIe 方案。对于跨节点通信，DeepEP 支持 RDMA（Remote Direct Memory Access）技术，能够绕过 CPU 直接在 GPU 内存之间传输数据，显著降低了端到端延迟。这种针对不同物理链路的差异化优化策略，使得 DeepEP 能够在异构集群环境中最大化通信效率。
FP8 低精度支持与混合精度策略
降低通信数据量是提升 MoE 通信效率的另一关键路径，DeepEP 在这一方向上提供了 FP8 低精度格式的原生支持。FP8（8-bit Floating Point）是一种新兴的数值格式，能够在保持模型精度的同时将数据体积缩减为 FP32 的四分之一或 FP16 的二分之一。对于 MoE 通信而言，当 token 在 dispatch 阶段被发送到专家时，其隐藏状态可以先被量化为 FP8 格式再进行传输，随后在 combine 阶段再解码回高精度格式。
DeepSeek 团队在设计 FP8 支持时充分考虑了精度与性能的平衡点。实验数据表明，在 MoE 训练的大部分场景下，使用 FP8 进行中间激活的传输不会导致模型质量的显著下降，但能够将通信带宽需求大幅降低。这一特性对于配备有限高速网络带宽的集群尤为重要，因为它允许在相同硬件条件下训练更大规模的 MoE 模型，或者在保持模型规模的前提下提升训练吞吐量。
计算通信重叠与异步执行机制
将通信等待时间隐藏在计算执行背后是提升 GPU 利用率的经典策略，DeepEP 为此提供了完善的异步执行支持。与传统的同步通信模式不同，DeepEP 的内核设计允许在数据传输的同时启动下一轮计算，从而实现计算与通信的时间重叠。具体实现上，库使用了 CUDA Stream 机制来管理多个执行队列，使得开发者能够精细控制不同操作之间的依赖关系。
在实际的 MoE 训练流程中，这种重叠优化的效果取决于多个因素的平衡。一方面，通信量越大、计算相对轻量的情况下，重叠带来的收益越明显；另一方面，重叠策略的设计需要考虑专家计算的启动延迟与通信完成时间的匹配程度。DeepEP 提供了可配置的调度参数，允许用户根据自身的模型结构与硬件环境调整重叠策略，以达到最优的整体效率。
Prefill 与 Runtime 的差异化路径
MoE 模型在推理阶段存在两个本质不同的处理阶段：prefill 阶段处理完整的输入序列并生成第一批 token，而 runtime 阶段则逐个生成后续 token。DeepEP 针对这两个阶段提供了差异化的内核路径，因为它们的通信模式与性能需求存在显著差异。
在 prefill 阶段，输入序列长度通常较长，此时通信的吞吐量是首要优化目标。DeepEP 优化了大批次、长时间跨度的 all-to-all 操作，能够在一次通信中处理大量 token 的 dispatch 与 combine。相比之下，runtime 阶段的 token 生成是自回归的，每次仅处理极少数量的 token，此时延迟成为更关键的指标。DeepEP 提供了低延迟的微批次通信内核，能够在毫秒级时间内完成单批次 token 的专家分发与结果聚合，从而避免成为推理延迟的瓶颈。
集成实践中的关键考量
将 DeepEP 集成到现有训练框架时，有几个关键因素需要评估。首先是硬件拓扑的适配性：DeepEP 的性能优势在配备 NVLink 的多 GPU 节点上最为明显，对于仅使用 PCIe 互联的节点，通信带宽的提升幅度会相应减小。其次是专家数量与分布策略的配置，库的最佳性能通常出现在专家数量与 GPU 数量呈现特定比例关系时，过度稀疏或过度密集的分布都可能导致通信效率下降。
在软件集成层面，DeepEP 提供了轻量级的 API 设计，能够与 PyTorch 生态的训练循环无缝对接。开发者需要关注的是门控决策与专家分布的对应关系确保，以及混合精度策略在模型不同层之间的合理配置。对于生产环境部署，建议进行基准测试以验证在目标硬件配置下的实际加速比，并监控通信相关指标以识别潜在瓶颈。
小结
DeepEP 作为 MoE 基础设施层的关键组件，通过专门优化的 all-to-all 通信内核、FP8 低精度支持、计算通信重叠机制以及针对推理阶段的差异化路径设计，为大规模 MoE 模型的训练与推理提供了高效的通信底层支撑。在 MoE 架构日益成为大模型标配的趋势下，这类通信库的成熟与普及将直接影响到模型训练效率与推理服务成本的优化空间。
资料来源：DeepEP 官方 GitHub 仓库（https://github.com/deepseek-ai/DeepEP）。