昨天我们还在深入探讨DeepSeek的FlashMLA技术，仅仅一天之后，他们又发布了另一项重大成果——DeepEP，这是一款专为MoE（混合专家）模型训练与推理量身打造的高效专家并行通信库。如果说FlashMLA聚焦于解码内核的加速优化，那么DeepEP则直接回应了MoE架构在高效通信与并行处理方面的核心挑战。上线短短24小时内，GitHub上的Star数已突破1000，社区对该项目的关注程度可见一斑。

在MoE模型中，不同“专家”之间需要频繁进行数据交换，如何在众多GPU之间实现高速、稳定的数据传输成为关键所在。同时，专家并行场景下的负载不均衡问题由来已久，容易造成算力分配不均，进而拖累整体性能。DeepEP正是为了攻克这些长期存在的痛点而生。

我们一起看看它究竟带来了哪些突破：

• 高度优化的全对全通信机制
• 同时支持NVLink与RDMA的节点内及跨节点通信能力
• 为训练与推理预填充阶段提供高吞吐量计算核心
• 为推理解码阶段提供极低延迟的计算核心
• 原生支持FP8数据分发格式
• 灵活调控GPU资源，实现计算与通信的高效重叠

将这些特性归纳起来，核心无非三件事：高效通信大幅削减了数据传输瓶颈，计算核心的精心优化显著提升了处理速度，而灵活的资源调度则让计算与通信不再相互等待。从架构层面审视，MLA与MoE本就是DeepSeek的两张王牌，昨天亮出第一张，今天再亮第二张，确实无愧于“Open”之名。

有评论指出，DeepSeek针对MoE模型所做的优化达到了令人惊叹的水平，尤其是能够充分利用NVLink与RDMA这类尖端硬件技术，同时支持FP8精度，这几乎是一项具有突破意义的成就。还有人直言，NVLink与RDMA的支持对于大规模MoE模型堪称革命性突破，DeepSeek再次推动了AI基础设施的可能边界。

此前外界对DeepSeek-R1存在一些质疑，例如有人认为它仅靠模型蒸馏获取性能，而并非真正的技术创新；还有人怀疑它低报了训练过程中实际使用的GPU数量。通过开源周的这一系列发布，至少从侧面有力证明：DeepSeek确实是通过扎实的技术创新实现了真实的训练效率提升与成本降低。

DeepEP 是什么？

简单来说，DeepEP是专门为MoE模型和专家并行场景量身定制的通信库。它提供了兼具高吞吐量与低延迟的全对全GPU内核，这些内核本质上是MoE分发与合并操作的具体实现。该库还原生支持低精度运算，包括FP8格式。

为了与DeepSeek-V3论文中提出的group-limited gating算法保持一致，DeepEP还额外提供了一套针对非对称域带宽转发进行优化的内核——例如从NVLink域向RDMA域进行数据转发。这些内核吞吐量极高，适用于训练与推理预填充任务，并且支持SM（流式多处理器）数量动态控制。

对于延迟敏感的推理解码场景，DeepEP包含了一套基于纯RDMA的低延迟内核，核心目标就是尽可能降低延迟。此外，它还引入了一种基于hook的通信-计算重叠方法，关键是不占用任何SM资源。

DeepEP 性能如何？

官方在H800平台上进行了性能测试。常规内核部分，H800的NVLink最大带宽约为160 GB/s，每个H800连接到一个CX7 InfiniBand 400 Gb/s RDMA网卡（约50 GB/s）。测试遵循DeepSeek-V3/R1预训练设置：每批次4096个token，隐藏维度7168，top-4组，top-8专家，FP8分发，BF16合并。低延迟内核部分，测试采用典型生产设置：每批次128个token，隐藏维度7168，top-8专家，FP8分发，BF16合并。

还有几个值得关注的细节：

• 为了追求极致性能，DeepSeek发现并启用了一条未记录在文档中的PTX指令：ld.global.nc.L1::no_allocate.L2::256B。该指令会引发一个未定义行为——使用非一致性只读修饰符“.nc”访问易变的GPU内存。但在Hopper架构上，通过“.L1::no_allocate”已测试确保正确性，且性能提升极为显著。如果你在其他平台上遇到问题，可以在setup.py中添加DISABLE_AGGRESSIVE_PTX_INSTRS=1来禁用，或提交GitHub issue寻求帮助。
• 为了在你的集群上获得更佳性能，建议运行所有测试并使用最佳的自动调优配置。官方提供的默认配置是针对其内部集群优化得出的。

更多技术细节可前往GitHub代码仓库查阅。最后再强调一次：Real OPENAI has born!

那么，你猜第三天会发布什么？24小时后答案便会揭晓。