在大规模语言模型训练与推理场景中，混合专家模型（Mixture-of-Experts，MoE）已成为突破算力瓶颈的关键架构。然而，MoE 模型中专家并行（Expert Parallelism，EP）带来的跨节点 All-to-All 通信开销，往往成为系统性能的致命瓶颈。DeepSeek 团队开源的 DeepEP 库，正是为解决这一核心挑战而设计的底层通信基础设施。本文将深入剖析 DeepEP 的技术实现细节与工程化参数，为需要在生产环境中部署 MoE 模型的团队提供可落地的技术参考。
MoE 通信的核心理论挑战
理解 DeepEP 的设计初衷，需要先把握 MoE 模型带来的通信复杂性。在典型的 MoE 架构中，每个输入 token 需要根据门控机制被路由到 top-k 个专家进行计算。以 DeepSeek-V3 为例，其配置为 4096 个 tokens per batch、7168 隐藏维度、top-4 groups 且 top-8 experts，这意味着每个 token 的计算请求会被分发到 8 个不同的专家节点。当模型规模扩展到数百个专家、跨数十个 GPU 节点时，All-to-All 通信的数据量与延迟就变得不可忽视。
传统分布式训练框架中的 All-to-All 实现通常假设对称的网络拓扑与均等的带宽资源。然而在真实数据中心环境中，节点内部的 NVLink 互联与节点间的 RDMA 网络存在显著的带宽不对称性 ——NVLink 理论带宽可达 160 GB/s（以 H800 为例），而 InfiniBand 400Gb/s RDMA 的理论带宽仅约 50 GB/s。这种非对称特性使得简单的通信调度策略无法充分利用硬件能力，造成网络资源的浪费与端到端延迟的增加。
DeepEP 的核心创新在于其针对非对称域带宽的专项优化。库中实现的 normal kernels 支持从 NVLink 域到 RDMA 域的数据转发功能，使得节点内部已经聚合的 token 可以高效地跨节点分发，避免了传统方案中需要先将数据下放至 CPU 再转发的低效路径。这一设计使得 8 个 EP 下的节点内部 dispatch 带宽达到 153 GB/s，接近 NVLink 的理论极限；跨节点 16 EP 场景下也能达到 43 GB/s 的 RDMA 带宽利用率。
两套内核体系的场景适配
DeepEP 在架构设计上明确区分了两种不同定位的内核类型，以适配 MoE 模型在不同推理阶段的需求差异。这种设计理念体现了对实际部署场景的深刻理解 —— 训练阶段与推理 prefilling 阶段的吞吐量需求，与推理 decoding 阶段的延迟需求存在本质矛盾。
Normal kernels 面向训练和推理 prefilling 场景进行了深度优化。这类场景的特点是 batch size 较大（通常为数千 tokens），对吞吐量（throughput）的敏感度高于单次延迟。Normal kernels 充分利用 NVLink 进行节点内转发，并通过 RDMA 实现跨节点通信。值得注意的是，该内核族支持 SM（Streaming Multiprocessors）数量控制功能，允许开发者精确指定用于通信内核的 SM 比例。在 DeepEP 的示例代码中，默认配置为 24 个 SM 专用于通信，这一参数可根据实际计算密度进行调整。当模型计算部分较轻时，可以将更多 SM 分配给通信以提升吞吐；反之则需保留足够 SM 给计算内核。
低延迟内核（low-latency kernels）则专门为推理 decoding 阶段设计。这类场景的典型特征是 batch size 极小（通常为 128 tokens 甚至更少），但对单次推理延迟有严格要求。DeepEP 的低延迟内核采用纯 RDMA 路径，避免了 NVLink 转发的额外开销。实测数据显示，在 8 个 EP 配置下，dispatch 延迟仅为 77 微秒，combine 延迟为 114 微秒；即使扩展到 256 个 EP，dispatch 延迟也仅增至 194 微秒。这一延迟水平对于需要实时响应的推理服务而言至关重要。
低延迟内核的另一项关键技术是其 hook-based 通信计算重叠机制。与传统方案需要占用 SM 资源进行通信调度不同，DeepEP 的 hook 机制允许 RDMA 网络传输在后台完成，完全不占用任何 SM 资源。开发者可以通过 return_recv_hook 接口获取一个回调钩子，在实际需要数据时触发接收完成等待。这一设计使得双微批重叠（two-micro-batch overlapping）成为可能 —— 在执行当前批次计算的同时，后台已经开始了下一批次的通信，实现了计算与通信的完美流水线。
通信缓冲区的工程实践
在生产环境中部署 DeepEP，通信缓冲区的配置直接决定了内存占用与性能表现。DeepEP 采用队列式的缓冲区设计以节省内存，但这也引入了额外的复杂度与潜在的死锁风险。官方文档明确建议，若追求极致简单性，可以考虑使用固定大小的缓冲区分配至最大容量，这在内存充足且追求稳定性的场景下是更优选择。
缓冲区大小的配置需要根据 hidden_bytes、group.size () 以及运行模式进行计算。DeepEP 提供了 get_dispatch_config 和 get_combine_config 两个接口用于获取推荐配置，同时提供了 get_nvl_buffer_size_hint 与 get_rdma_buffer_size_hint 用于精确计算。对于低延迟模式，由于其内存消耗远高于普通模式，官方强烈建议实际的 decoding batch size（num_max_dispatch_tokens_per_rank）应控制在 256 以下。超出此范围不仅内存占用急剧增加，RDMA 的 QP（Queue Pair）资源也可能成为瓶颈。
在 QP 配置方面，低延迟模式有一个硬性要求：QP 数量必须等于本地专家数量。这一约束体现在 get_buffer 函数的 assert 断言中：assert num_experts % group.size() == 0。这是因为 RDMA 的 QP 是有限的稀缺资源，而每个 QP 在建立连接时需要消耗可观的内存与计算资源。合理配置 QP 数量是确保低延迟内核稳定运行的关键。
网络配置与性能调优
DeepEP 的网络配置直接影响了跨节点通信的最终性能。库文档详细描述了与 InfiniBand 网络相关的三项关键配置：流量隔离（Traffic Isolation）、自适应路由（Adaptive Routing）与拥塞控制（Congestion Control）。
流量隔离通过 InfiniBand 的 Virtual Lanes（VL）实现。建议将使用 normal kernels 的工作负载、使用 low-latency kernels 的工作负载以及其他类型的工作负载分别部署在不同的虚拟通道上，以避免相互干扰。配置方式极为简单，只需设置 NVSHMEM_IB_SL 环境变量即可。在多租户或混合负载的生产环境中，这一配置对保障服务质量至关重要。
自适应路由是 InfiniBand 交换机提供的高级路由特性，能够将流量均匀分布到多条物理路径上，从而消除路由冲突导致的网络拥塞。然而，该特性也会引入额外的延迟开销。DeepEP 建议在网络负载较重的环境中启用自适应路由，而在负载较轻的环境中使用静态路由以获得更低延迟。这一建议体现了性能调优中经典的吞吐 - 延迟权衡。
关于拥塞控制，DeepEP 在生产环境中未观察到显著的拥塞现象，因此默认禁用了该特性。这一保守选择意味着在网络条件复杂的共享集群中，可能需要额外的监控与调优手段。
此外，Auto-tuning 机制是获取最优性能的重要途径。DeepEP 提供了完整的测试套件（test_intranode.py、test_internode.py、test_low_latency.py），开发者应在目标集群上运行这些测试并使用自动调优的结果作为配置参数。官方强调默认配置针对 DeepSeek 内部集群进行了优化，在其他硬件环境（如不同的 NVSwitch 配置、不同的 RDMA 网卡型号）下可能并非最优。
面向未来的技术演进
DeepEP 的 Roadmap 揭示了多项值得关注的技术方向。TMA（Tensor Memory Access）指令支持是其中最引人注目的特性之一 ——TMA 能够实现更高效的显存访问模式，预计可将 SM 占用进一步降低。AR（Asymmetric Routing）支持的加入将使得跨域通信的路径选择更加灵活。A100 支持（尽管仅限节点内）将扩大库的适用范围。
社区贡献者也在积极推动技术边界。Tencent Network Platform Department 贡献的 Zero-copy 优化通过消除 PyTorch 张量与通信缓冲区之间的数据拷贝，显著降低了 SM 占用。AntGroup 的 Normal-SMFree 优化通过解耦通信内核执行与 NIC 令牌传输，实现了 RDMA 路径的 SM 零占用。腾讯的优化甚至带来了高达 30% 的性能提升。这些来自大规模生产环境的优化经验，对其他部署团队具有重要参考价值。
在生产环境中落地 DeepEP，建议遵循以下实施路径：首先在测试集群完成 Auto-tuning 以获取最优配置；其次根据业务场景选择合适的内核类型（训练 / 推理 prefilling 选 normal，实时推理选 low-latency）；第三配置 Virtual Lanes 实现流量隔离；最后建立延迟与带宽的监控告警机制。DeepEP 作为 MoE 模型通信基础设施的核心组件，为大规模语言模型的高效部署提供了坚实的技术基座。
参考资料
- DeepEP GitHub 仓库：https://github.com/deepseek-ai/DeepEP
- DeepSeek-V3 论文：https://github.com/deepseek-ai/DeepSeek-V3