方正证券在报告中重点分析了DeepSeek开源周中DeepEP对MoE架构通信的优化。MoE（混合专家模型）架构下，Dispatch和Combine过程中需要在不同GPU之间进行频繁的小批量All-to-All通信，传统基于CUDA的NCCL专为单次启动、大批量连续传输设计，在小数据量下固定开销无法被充分摊薄。DeepEP使用NVSHMEM替代NCCL，允许GPU直接访问另一GPU内存，无需复杂启动和同步过程，在H800上实现153-158GB/s带宽，解码延迟压缩40%以上。
MoE架构的通信瓶颈——NCCL在小批量场景下的效率困境
MoE架构将传统Dense网络拆成了多个专家子网，每个Token只激活与其最相关的Top K个专家（Dispatch），再将这K个专家的输出组合到一起（Combine）。在Dispatch和Combine的过程中，需要在不同专家（或不同GPU之间）进行All-to-All通信。传统GPU间通信通常依赖基于CUDA的NCCL，专为单次启动、大批量且连续的数据传输场景设计，因此在通信模式相对简单和连续的Dense架构中表现很好。
然而在MoE架构下，由于Dispatch和Combine过程中需要频繁进行小批量数据交换，每调用一次NCCL都需要一定的固定时间用于初始化、数据准备与同步，而这些固定开销在小数据量下无法被充分摊薄，影响带宽的利用率。随着模型规模的扩大和专家数量的增加，通信开销在总计算时间中的占比越来越高，成为MoE扩展到超大参数规模的关键瓶颈。
DeepEP的解决方案——NVSHMEM的单边通信优势
DeepEP使用NVSHMEM（NVIDIA Shared Memory）优化MoE架构下的GPU通信。NVSHMEM允许一个GPU直接访问另一个GPU的内存，无需经过复杂的启动和同步过程，在处理小批量数据和不规则交换的场景下能够实现更高的带宽利用率和通信效率，更加适配MoE架构的需求。
与NCCL的“双边通信”模式（发送方发起请求，接收方确认后才能传输数据）不同，NVSHMEM采用“单边通信”模式（发送方直接写入接收方的内存，接收方无需提前准备），大幅减少了通信的启动和同步开销。DeepEP能在H800上通过NVLink实现153-158 GB/s带宽，相比传统方案的解码延迟压缩40%以上。
MoE架构的开源生态影响——Day2到Day6的完整闭环
DeepEP并非孤立的技术组件，而是与开源周其他项目形成完整的技术闭环。DAY6推理系统概览中，DeepEP与DualPipe、EPLB、FlashMLA、DeepGEMM、3FS等组件被整合到完整的推理流水线中。在MoE场景下，推理系统继续运用EPLB做热门专家的复制与迁移，结合DualPipe的双向并行调度减少GPU空转，通信层面依托DeepEP优化多机多卡的All-to-All数据交换，算子级运算由FlashMLA与DeepGEMM提供高效低精度支持。
DS开源的技术完全针对NV Hopper架构进行深度优化，DeepEP同样基于NVSHMEM和NVLink等NV特有技术栈优化。这也意味着技术迁移/国产适配需芯片厂商完善对类似特性的支持并相应优化推理侧解决方案。
MoE通信优化的产业意义——大模型规模扩展的关键突破
MoE架构是大模型实现更大参数规模的关键技术路径之一，其核心思想是在不显著增加计算成本的前提下扩大模型容量。然而通信瓶颈一直是限制MoE架构扩展到更大规模的关键因素。DeepEP通过将GPU间通信延迟压缩40%以上，显著降低了MoE架构中通信开销对整体计算效率的拖累。
随着模型参数规模从千亿向万亿级别迈进，MoE架构的采用将更加普遍。DeepEP的开源为整个AI社区提供了MoE通信优化的参考实现，有望推动更多大模型采用MoE架构实现参数规模的跨越式增长。DeepSeek正在推动大模型算法向开源、低精度（FP8）、MoE三个方向演进，DeepEP是MoE方向的关键技术突破。
表：DeepEP核心性能指标与对比| 指标 | 传统NCCL方案 | DeepEP方案 | 提升幅度 |
|---|
| 通信库 | NCCL（双边通信） | NVSHMEM（单边通信） | — |
| NVLink带宽 | — | 153-158 GB/s | — |
| 解码延迟 | 基准 | 压缩40%+ | 延迟-40%+ |
| 适用场景 | 大批量连续传输 | 小批量不规则交换 | — |
