在大规模 MoE（Mixture-of-Experts）模型训练与推理场景中，专家并行（Expert Parallelism，EP）通信是决定系统吞吐量的关键瓶颈。DeepSeek 开源的 DeepEP 库正是为解决这一挑战而设计，它提供了面向 MoE 场景的高效 all-to-all 通信内核，同时支持训练与推理两种不同延迟需求的工作负载。本文将从内核分类、SM 资源控制、跨域带宽转发三个维度，梳理工程落地的关键参数与配置策略。
一、两种内核设计：适配训练与推理的差异化通信
DeepEP 将通信内核划分为两大类别，分别对应不同的业务场景与性能需求。深入理解这两类内核的适用条件，是正确选型与调优的前提。
Normal Kernels（常规内核） 面向模型训练和推理预填充阶段，特点是高吞吐量、强吞吐能力，专注于批量处理大规模 token 序列。在 DeepSeek 官方测试中，基于 H800 GPU（NVLink 带宽约 160 GB/s）和 CX7 InfiniBand 400 Gb/s RDMA 网卡（带宽约 50 GB/s），采用 4096 tokens/batch、7168 hidden、top-4 groups、top-8 experts 的配置，8 路专家并行下 NVLink 域内可达到 158 GB/s 的实际带宽，跨节点 32 路 EP 时 RDMA 带宽达到 58 GB/s。这表明常规内核在跨节点扩展性上表现优异，能够有效利用 RDMA 的高带宽特性。
Low-latency Kernels（低延迟内核） 则专为推理解码阶段设计，聚焦单批次延迟最小化。典型配置为 128 tokens/batch、7168 hidden、top-8 experts，采用纯 RDMA 路径以最小化延迟。测试结果显示，8 路 EP 下 dispatch 延迟仅为 77 微秒，combine 延迟为 114 微秒；即使扩展到 256 路 EP，dispatch 延迟也能控制在 194 微秒左右。值得注意的是，2025 年 6 月的更新（PR #173）进一步优化了低延迟内核，现在能够尽可能利用 NVLink 进行节点内通信，进一步降低了端到端延迟。
工程选型建议如下：训练场景与推理预填充阶段优先采用 Normal Kernels；推理解码阶段（尤其是延迟敏感的业务）切换至 Low-latency Kernels。二者在 API 层面通过 Buffer 对象的初始化参数进行区分，Low-latency 模式需指定 low_latency_mode=True 并配置 num_qps_per_rank 参数（建议值等于本地专家数）。
二、SM 资源控制：训练阶段的计算通信重叠策略
DeepEP 的核心技术亮点之一是提供了 SM（Streaming Multiprocessors）资源控制能力，允许开发者精确指定通信内核占用的 GPU 计算单元数量，从而为计算核保留充足的 SM 资源。这一设计在训练场景中尤为重要，因为 MoE 层的 FFN 计算需要大量的矩阵运算资源。
通过 Buffer.set_num_sms(N) 接口可静态设置 Normal Kernels 使用的 SM 数量。DeepSeek 官方推荐值为 24，这一数值在 H800 平台上经过了充分验证。实际使用时，开发者应根据本地的计算负载进行微调：如果 MoE 层之前的 Attention 计算是瓶颈，可适当降低 SM 数量（如 16 或 20）以释放更多资源给前向计算；反之如果通信带宽是主要瓶颈，则可尝试提高 SM 数量（如 28 或 32）以加速通信内核的执行。
更进一步的优化手段是使用 Hook 机制实现通信与计算的重叠。DeepEP 提供了 return_recv_hook=True 选项，使接收操作返回一个可延迟执行的 hook 函数。以低延迟模式的双微批重叠为例，第一微批的 dispatch 接收 hook 可以在第二微批的 Attention 计算期间异步执行，从而实现计算与 RDMA 通信的并行。更关键的是，这个 hook 机制不占用任何 SM 资源—— 通信数据的传输完全在 NIC（网络接口卡）层面完成，GPU 仅在需要访问数据时才参与拷贝。这意味着在理想情况下，通信可以做到对计算吞吐量的零侵入。
对于使用 CUDA Graph 的推理场景，低延迟内核也提供了良好的兼容性支持。开发者需要注意在 CUDA Graph replay 时恢复缓冲区状态，具体可参考官方示例代码中的 num_max_dispatch_tokens_per_rank 参数配置，该参数建议控制在 256 以内以获得最佳性能。
三、NVLink-RDMA 跨域转发：非对称带宽的利用策略
DeepEP 针对性优化了 DeepSeek-V3 论文中提出的分组限制门控算法（Group-limited Gating）。在该算法中，专家被划分为多个组，每个 token 只能在特定组内选择 top-k 专家。这种路由模式导致了天然的非对称通信模式：部分流量在 NVLink 域内（节点内部 GPU 间）即可完成，另一部分则需要跨 RDMA 域（跨节点）转发。
针对这一场景，DeepEP 提供了专门优化的 asymmetric-domain forwarding 内核，其核心思想是将 NVLink 域内无法直接送达的跨节点流量，通过 NVLink 转发至具有更好 RDMA 带宽的 GPU，再由该 GPU 统一对外发起 RDMA 通信。这种设计在物理拓扑上具有重要意义：在典型的 8-GPU 节点中，NVLink 互联带宽约为 160 GB/s，远高于单卡 RDMA 带宽（约 50 GB/s），因此将跨节点流量汇聚到少数几张网卡上，可以更充分地利用 RDMA 带宽资源。
工程实践中，跨域转发的配置是透明的，DeepEP 在内部自动处理转发逻辑。但开发者需要关注以下网络调优参数以获得最佳性能：
-
Virtual Lanes（VL）虚拟通道隔离：通过
NVSHMEM_IB_SL环境变量控制。建议将不同类型的工作负载（Normal kernels、Low-latency kernels、其他任务）分配到不同的虚拟通道，以避免网络流量的相互干扰。InfiniBand 的 Virtual Lanes 机制能够在硬件层面实现流量的 QoS 保障。 -
自适应路由（Adaptive Routing）：在网络负载较重的生产环境中，启用自适应路由可以有效消除路由冲突导致的网络拥塞；但在轻负载场景下，自适应路由引入的额外跳数会增加延迟，因此建议根据实际网络状况动态选择。DeepSeek 在其生产环境中默认禁用了拥塞控制机制，因为尚未观察到明显的网络拥塞现象。
-
缓冲区配置：对于 Normal 模式，需要分别估算 NVLink 和 RDMA 缓冲区的大小。官方提供了
get_dispatch_config()和get_combine_config()接口自动计算缓冲区大小提示（buffer size hint），开发者应基于本地的 hidden size 和 EP 并行度进行配置。DeepSeek 明确建议在生产环境中运行完整的自动调优（auto-tuning）测试，以获取针对特定集群的最优配置。
四、部署依赖与环境配置要点
DeepEP 的部署涉及多项依赖的正确配置，以下是生产部署的关键检查清单：
硬件与驱动层面，需要 Ampere（SM80）或 Hopper（SM90）架构的 GPU，以及支持 NVLink 的节点内互联和 RDMA 能力的跨节点网络（InfiniBand CX7 400Gb/s 为推荐配置）。软件依赖包括 CUDA 11.0+（SM80）或 CUDA 12.3+（SM90）、PyTorch 2.1+，以及 NVSHMEM（必须单独安装）。NVSHMEM 是 DeepEP 的核心依赖库，提供了共享内存风格的跨节点通信抽象，安装过程需参考官方提供的第三方库安装指南。
编译安装时的环境变量配置同样关键：NVSHMEM_DIR 指定 NVSHMEM 安装路径，若不设置则仅启用节点内通信功能；DISABLE_SM90_FEATURES 用于在 SM90 设备或 CUDA 11 环境下禁用相关特性；DISABLE_AGGRESSIVE_PTX_INSTRS 可禁用极端性能优化的 PTX 指令（使用非标准行为指令以换取更高性能），如果在某些平台上出现内核运行异常，可将此变量设为 1。
五、实践建议：工程落地的关键阈值
综合上述分析，给出以下可直接落地执行的参数建议：
在 SM 资源分配方面，训练阶段 Normal 模式建议 Buffer.set_num_sms(24)，推理阶段低延迟模式不提供 SM 控制 API；如遇性能异常可逐步调整至 16-32 范围。
缓冲区配置方面，建议在框架初始化时调用 get_dispatch_config() 和 get_combine_config() 获取自动计算的缓冲区大小提示，并在生产环境运行完整的 auto-tuning 测试。
网络配置方面，推理延迟敏感场景使用 Low-latency 模式并将 batch size 控制在 256 tokens 以内；多租户环境下通过 NVSHMEM_IB_SL 实现不同工作负载的虚拟通道隔离；高负载网络启用自适应路由，轻负载网络使用静态路由以降低延迟。
精度选择方面，训练推荐 FP8 dispatch + BF16 combine 的混合精度组合，这正是 DeepSeek-V3 论文中验证的标准配置，能够在保证计算精度的同时显著降低通信带宽需求。
资料来源：本文技术细节主要参考 DeepEP 官方 GitHub 仓库（https://github.com/deepseek-ai/DeepEP）。