在大规模语言模型的训练与推理场景中，混合专家（Mixture-of-Experts，MoE）架构通过稀疏激活机制显著提升了模型容量与计算效率。然而，MoE 的核心挑战在于如何高效地将 token 路由至对应的专家并进行跨 GPU 的数据聚合。这一通信瓶颈在专家并行（Expert Parallelism，EP）策略下尤为突出。DeepSeek 于近期开源的 DeepEP 库正是为解决这一问题而设计的专用通信库，其核心价值在于提供了面向 MoE 场景的高吞吐、低延迟 all-to-all 集合通信内核。本文将从专家路由、集合通信内核架构、跨节点负载均衡三个维度，系统解析 DeepEP 的工程实现与关键配置参数。
专家路由与分组门控的通信原语
MoE 层的核心逻辑包含两个关键操作：dispatch（将 token 发送至目标专家）和 combine（将各专家的输出聚合回原始顺序）。传统集合通信库（如 NCCL）虽能完成 all-to-all 通信，但难以针对 MoE 的非均衡流量模式进行优化。DeepEP 的设计理念在于将路由决策与通信调度深度耦合，使通信带宽利用率与路由策略紧密关联。
DeepEP 与 DeepSeek-V3 论文中提出的 ** 分组门控（Group-Limited Gating）** 算法高度协同。该门控机制将专家划分为多个组，每组内执行 top-k 选择以限制跨组通信量。在实际通信中，这意味着 dispatch 操作的发送目标具有显著的域局部性：同一 NVLink 域内的专家间流量远高于跨 RDMA 域的流量。DeepEP 正是利用这一非对称带宽特性，设计了专为跨域转发优化的内核。
在 API 层面，DeepEP 提供了 Buffer.get_dispatch_layout() 方法用于在正式 dispatch 前计算 token 分布。该方法返回每个 rank 应接收的 token 数量、RDMA 域内的 token 分布、以及每个专家的 token 数量等布局信息。这一预计算过程使得后续的 all-to-all 通信能够以最优的内存布局执行，避免了动态负载均衡带来的额外开销。值得注意的是，在 dispatch 函数内部可能无法预知当前 rank 将接收的 token 数量，因此涉及隐式的 CPU 等待 GPU 信号的过程，这一行为与 CUDA Graph 不兼容，除非指定 num_worst_tokens 参数（仅限节点内使用）。
All-to-All 通信内核的双路径设计
DeepEP 在内核设计上采取了双路径策略，分别针对训练与推理预填充阶段、推理解码阶段进行了深度优化。
Normal Kernel 面向训练和推理预填充场景，其设计目标是在高吞吐量与低延迟之间取得平衡。该内核支持 NVLink 节点内通信与 RDMA 节点间通信的协同转发，能够将数据从 NVLink 域无缝转发至 RDMA 域。内核支持 SM（Streaming Multiprocessors）数量控制，通过 Buffer.set_num_sms(N) 静态方法指定参与通信的 SM 数量，剩余 SM 可供计算核使用。在典型配置下（4096 tokens/batch，7168 隐藏维度，top-4 groups/top-8 experts，FP8 dispatch + BF16 combine），8 路专家并行时节点内带宽可达 153 GB/s（dispatch）和 158 GB/s（combine），逼近 H800 的 160 GB/s NVLink 理论带宽；16 路专家并行时跨节点 RDMA 带宽为 43 GB/s，32 路时提升至 58 GB/s。这一数据表明，随着专家并行度提升，RDMA 带宽利用率持续改善，但单 link 带宽仍受限于 InfiniBand 400 Gb/s（约 50 GB/s）的物理上限。
Low-Latency Kernel 专为推理解码阶段设计，其核心优化目标是最小化单次 token 的端到端延迟。该内核采用纯 RDMA 路径，完全绕过 NVLink 转发，以消除额外的跳数延迟。在 128 tokens/batch 的典型生产配置下，8 路专家并行的 dispatch 延迟仅为 77 μs，combine 延迟为 114 μs；即使扩展至 256 路专家并行，dispatch 延迟也仅增长至 194 μs。这一超低延迟特性使得 DeepEP 能够支持对延迟敏感的在线推理场景。Low-Latency Kernel 不提供 SM 控制接口，但支持一种无 SM 占用的通信 - 计算重叠机制：通过返回接收钩子（hook），RDMA 数据传输可在后台异步完成，不消耗任何 GPU SM 资源。该机制对于双微批重叠（two-micro-batch overlapping）场景尤为关键，可将 attention、dispatch、MoE、combine 四个阶段的执行时间有效对齐。
跨节点负载均衡的工程配置
DeepEP 的跨节点负载均衡涉及通信缓冲区配置与网络虚拟通道两个层面。
在缓冲区配置方面，DeepEP 提供了自动调优接口 Buffer.get_dispatch_config() 和 Buffer.get_combine_config()，可根据专家并行度和隐藏层大小返回推荐的 NVLink 和 RDMA 缓冲区大小。对于低延迟模式，缓冲区空间的消耗远高于普通模式，因此文档明确建议 num_max_dispatch_tokens_per_rank（解码引擎的实际 batch size）应控制在 256 以内。此外，QP（Queue Pair）数量的配置是低延迟模式的关键约束：文档强制要求 QP 数量必须等于本地专家数量（即 num_qps_per_rank = num_experts // group.size()），这一参数直接影响 RDMA 连接的并发能力和拥塞控制效果。
在网络配置层面，DeepEP 依赖 NVSHMEM 实现共享内存通信，并提供了 InfiniBand 虚拟通道（Virtual Lane）隔离机制。通过设置环境变量 NVSHMEM_IB_SL 可指定虚拟通道编号，建议将使用 normal kernel 的工作负载、使用 low-latency kernel 的工作负载、以及其他工作负载分别映射至不同的虚拟通道，以避免相互干扰。 Adaptive Routing（自适应路由）是另一个值得关注的选项：该功能可均衡分配至多条物理路径，完全消除路由冲突引发的网络拥塞，但会增加额外延迟。DeepEP 官方建议在网络负载较重的环境中启用自适应路由，而在负载较轻的环境中使用静态路由以降低延迟。值得注意的是，DeepEP 在生产环境中未观察到显著的拥塞现象，因此默认禁用拥塞控制。
关键工程参数速查清单
针对计划采用 DeepEP 的工程团队，以下是关键配置参数的实践建议。SM 控制方面，Normal Kernel 推荐设置 Buffer.set_num_sms(24)，具体数值可根据计算核的 SM 需求调整，保留足够 SM 给后续的 MoE FFN 计算。低延迟模式不支持 SM 控制，需依赖 hook 机制实现计算 - 通信重叠。缓冲区大小方面，应通过自动调优获取 num_nvl_bytes 和 num_rdma_bytes，并在框架初始化时一次性分配足够空间以避免运行时重新分配带来的抖动。网络通道方面，生产环境建议通过 NVSHMEM_IB_SL 隔离不同类型流量，Heavy-load 场景启用自适应路由，Light-load 场景使用静态路由。QP 配置方面，低延迟模式下必须确保 QP 数量等于本地专家数量，且 num_experts % group.size() == 0 约束必须满足。最后，FP8 精度方面，DeepEP 原生支持 FP8 dispatch 与 BF16 combine 的混合精度组合，这一配置在 DeepSeek-V3/R1 预训练中被验证为最优精度 - 性能平衡点。
小结
DeepEP 作为 MoE 专家并行的专用通信库，其核心创新在于将专家路由的语义信息嵌入通信调度过程，从而实现了 NVLink 域与 RDMA 域的非对称带宽优化。Normal Kernel 与 Low-Latency Kernel 的双路径设计，分别覆盖了训练 / 推理预填充与在线解码两类场景；Hook 机制的无 SM 占用通信 - 计算重叠，为低延迟推理提供了关键加速手段。在工程落地层面，SM 数量控制、缓冲区自动调优、QP 数量约束、以及 InfiniBand 虚拟通道配置构成了完整的效果调优空间。建议部署前在目标集群上运行完整测试套件，基于实际硬件拓扑进行参数微调，以获得最优的通信效率。
资料来源：DeepEP 官方 GitHub 仓库（https://github.com/deepseek-ai/DeepEP）