在大规模语言模型的实际部署中，MoE（Mixture-of-Experts，混合专家）架构已成为平衡模型容量与计算效率的核心选择。然而，MoE 模型引入的专家并行（Expert Parallelism，EP）机制对 GPU 间的 all-to-all 通信提出了极高要求 —— 每一次前向传播都需要将 token 动态路由到多个专家节点，这一通信开销往往成为整体吞吐量的瓶颈。DeepSeek 开源的 DeepEP 正是为解决这一痛点而设计的高效 CUDA 专家并行通信库，其在 H800 集群上实测的带宽可达 158 GB/s，延迟可低至 77 微秒，为 MoE 模型的训练与推理提供了可落地的工程化方案。
核心定位：面向 MoE 的 all-to-all 通信优化
DeepEP 的设计目标非常明确：为 MoE 模型的专家并行提供高吞吐量、低延迟的 all-to-all GPU 内核实现。该库的核心功能围绕 MoE 的两个关键操作展开 ——dispatch（将 token 分发到对应的专家）和 combine（将专家输出结果汇聚回原 token 位置）。与传统分布式通信库不同，DeepEP 针对 MoE 的稀疏激活特性进行了深度定制，能够根据不同的计算场景选择最优的内核实现。
从架构层面来看，DeepEP 支持两种内核模式，分别对应不同的应用场景。第一种是面向训练和推理预填充（prefilling）阶段的常规内核（Normal Kernels），这类场景的特点是批量较大、吞吐量优先，DeepEP 在此模式下提供了完整的 NVLink 域内通信和 RDMA 域间转发能力，能够充分利用 GPU 间的高速互联带宽。第二种是面向推理解码（decoding）阶段的低延迟内核（Low-latency Kernels），这类场景的特点是批量较小但对首字延迟（Time to First Token，TTFT）极为敏感，DeepEP 为此专门优化了纯 RDMA 路径，将通信延迟压缩到极致。
性能基准：实测数据与瓶颈分析
理解 DeepEP 的性能表现需要关注其官方披露的基准测试数据。测试环境采用 H800 GPU（NVLink 最大带宽约 160 GB/s）配合 CX7 InfiniBand 400 Gb/s RDMA 网卡（最大带宽约 50 GB/s），遵循 DeepSeek-V3/R1 的预训练配置：每批次 4096 个 token，隐藏层维度 7168，选择 top-4 组、top-8 专家，dispatch 阶段使用 FP8、combine 阶段使用 BF16。
对于常规内核，测试结果显示：NVLink 域内 8 路专家并行的 dispatch 和 combine 带宽分别达到 153 GB/s 和 158 GB/s，基本跑满了 NVLink 的物理带宽；跨节点场景下，16 路专家并行的 RDMA 带宽为 43 GB/s，32 路时提升至 58 GB/s，而 64 路时回落至 51 GB/s 左右。这一趋势表明，随着专家并行度的增加，RDMA 网络的聚合带宽经历了先增后降的过程，主要原因在于更多的并行度带来了更细粒度的流量划分，RDMA 队列对网络资源的竞争加剧。
对于低延迟内核，测试采用更贴近生产环境的配置：每批次 128 个 token，隐藏层维度 7168，top-8 专家。在 8 路专家并行下，dispatch 延迟为 77 微秒、RDMA 带宽为 98 GB/s，combine 延迟为 114 微秒、带宽为 127 GB/s；随着并行度提升到 256 路，dispatch 延迟稳定在 194 微秒左右，带宽维持在 39 GB/s。值得注意的是，低延迟内核在 128 路以上并行度时性能趋于平稳，说明单次 RDMA 传输的最小延迟成为了主要瓶颈。
关键技术实现：从 FP8 到 SM 资源管控
DeepEP 在工程实现上引入了一系列创新技术，以确保在各种场景下都能发挥最佳性能。
首先是低精度计算支持。DeepEP 原生支持 FP8 数据类型的 dispatch 操作，这对于大规模 MoE 训练尤为重要 ——FP8 不仅减少了通信数据量，还能通过张量核心（Tensor Core）实现更高效的矩阵运算。官方披露显示，FP8 dispatch 配合 BF16 combine 的组合在精度与性能之间取得了良好平衡。
其次是 SM 资源管控。常规内核提供了 Buffer.set_num_sms() 接口，允许开发者精确控制通信内核占用的流多处理器（Streaming Multiprocessors，SM）数量。这一设计使得通信与计算可以实现更细粒度的重叠 —— 当通信内核仅占用部分 SM 时，剩余的 SM 可用于执行注意力机制或前馈网络的计算，从而提高 GPU 利用率。DeepEP 官方建议将 SM 数量设置为 24，具体数值需根据实际工作负载进行调优。
第三是基于钩子的通信 - 计算重叠机制。DeepEP 提供了 EventOverlap 类和接收钩子（hook）接口，能够在不占用任何 SM 资源的前提下实现 RDMA 通信与计算的重叠。以低延迟模式为例，当调用 return_recv_hook=True 时，实际的接收操作被延迟到显式调用钩子函数时才执行，这意味着网络传输完全在后台完成，GPU 的计算资源可以全部用于处理上一个 micro-batch。这种双 micro-batch 重叠策略能够显著降低端到端推理延迟。
第四是对非对称域带宽的优化支持。DeepEP 针对 DeepSeek-V3 论文中提出的组限制门控算法（group-limited gating）提供了专门的内核变体，能够高效支持从 NVLink 域到 RDMA 域的非对称带宽转发场景。这类内核特别适合跨节点 MoE 部署，其中节点内的专家通信主要依赖 NVLink，节点间的专家通信则通过 RDMA 完成。
部署要求与网络配置指南
将 DeepEP 集成到实际项目中需要满足一定的软硬件环境要求。在硬件层面，需要支持 Ampere（SM80）或 Hopper（SM90）架构的 GPU，并配备 NVLink 用于节点内通信、RDMA 网络（如 InfiniBand）用于节点间通信。软件层面则需要 CUDA 11.0+（SM80）或 CUDA 12.3+（SM90），以及 PyTorch 2.1+。此外，DeepEP 依赖 NVSHMEM 库实现共享内存风格的通信优化，需要在构建时正确配置 NVSHMEM_DIR 环境变量。
网络配置方面，DeepEP 推荐进行流量隔离以避免不同类型 workload 之间的干扰。具体做法是通过 InfiniBand 的虚拟通道（Virtual Lane，VL）机制，将使用常规内核的 workload、使用低延迟内核的 workload 以及其他 workload 分配到不同的虚拟通道，通过设置 NVSHMEM_IB_SL 环境变量来控制。对于自适应路由（Adaptive Routing），DeepEP 建议在网络负载较重的环境中启用以消除路由冲突导致的拥塞，而在负载较轻的环境中使用静态路由以避免额外的延迟开销。官方表示在其生产环境中默认禁用了拥塞控制，因为尚未观察到显著的拥塞现象。
实践建议与调优策略
在实际部署 DeepEP 时，以下几点实践建议可以帮助获得更优性能。
第一，根据场景选择合适的内核类型。训练阶段和推理预填充阶段应使用常规内核，以最大化吞吐量为目标；推理解码阶段则应使用低延迟内核，将首字延迟置于首位。两种内核的 API 接口略有不同，低延迟模式需要额外指定 low_latency_mode=True 和 num_qps_per_rank 参数，且官方建议解码 batch size（num_max_dispatch_tokens_per_rank）应小于 256，以控制通信缓冲区的内存占用。
第二，充分利用自动调优功能。DeepEP 提供了 Buffer.get_dispatch_config() 和 Buffer.get_combine_config() 等接口获取默认配置，但这些配置针对 DeepSeek 内部集群进行了优化。在实际部署中，建议运行库提供的测试脚本进行自动调优，选择最适合当前网络拓扑和硬件配置的参数组合。
第三，关注未来的功能演进。DeepEP 的公开路线图显示，接下来将支持 A100（仅限节点内）、BF16 低延迟 dispatch、NVLink 低延迟内核、TMA 拷贝替代 LD/ST 指令，以及完全移除未定义行为的 PTX 指令。此外，社区还贡献了多个实验性分支，包括零拷贝（Zero-copy）优化、低延迟模式的 eager 协议、混合专家并行（Hybrid-EP）后端以及 AMD ROCm 支持等，这些功能在成熟后将进一步扩展 DeepEP 的适用场景。
资料来源：DeepEP 官方 GitHub 仓库（https://github.com/deepseek-ai/DeepEP）