DeepSeek开源周第二天：DeepEP深度分析
带你深入分析DeepSeek DeepEP
开源周第二天，deepseek官方X 在10:24分发了一个文，带来了开源周的第二个开源项目DeepEP。
deepseek X文介绍说：
DeepEP —— 第一个用于 MoE 训练和推理的开源 EP 通信库。
-
✅ 高效且优化的全互联（all-to-all）通信
-
✅ 支持节点内和节点间通信，兼容 NVLink 和 RDMA
-
✅ 面向训练和推理预填充的高吞吐量内核
-
✅ 面向推理解码的低延迟内核
-
✅ 原生支持 FP8 数据类型分发
-
✅ 灵活的 GPU 资源控制，实现计算与通信的重叠
代码发布之后，目前已经4.3K Star。
很多人对MoE模型不是很熟悉，本文先简单介绍一个MoE和deepseek 在MoE上的一些工作。
MoE介绍
专家混合模型（Mixture-of-Experts，简称 MoE）是 transformer架构的一种简单扩展，它正迅速成为中到大型语言模型（20亿到6000亿参数）的首选架构。
主要优点：
-
与稠密模型相比， 预训练速度更快
-
与具有相同参数数量的模型相比，具有更快的推理速度
** **
存在的问题：需要大量内存，因为所有专家系统都需要加载到内存中，并且通常用于中到大型模型，所以往往需要在多个 GPU 上并行处理，而且通信必须非常高效。
MoE模型主要由两个关键部分组成:
- 稀疏 MoE 层
这些层代替了传统 Transformer 模型中的前馈网络 (FFN) 层。MoE 层包含若干“专家”(例如 8 个)，每个专家本身是一个独立的神经网络。
2.门控网络或路由
这个部分用于决定哪些令牌 (token) 被发送到哪个专家。有时，一个令牌甚至可以被发送到多个专家。
总结：混合专家模型 (MoE) 的一个显著优势是它们能够在远少于稠密模型所需的计算资源下进行有效的预训练。这意味着在相同的计算预算条件下，你可以显著扩大模型或数据集的规模。特别是在预训练阶段，与稠密模型相比，混合专家模型通常能够更快地达到相同的质量水平。
DeepSeek MoE
deepseek在2024年1月11日发布了DeepSeekMoE: Towards Ultimate Expert Specialization in Mixture-of-Experts Language Models 论文，算是非常早研究MoE模型的公司。
在DeepSeekMoE论文中，主要提出了Router Expert 和Shared Expert概念，并且实验了增加细粒度专家的效果。
论文中，DeepSeekMoE 16B拥有每层包含2个共享专家和64个路由专家，每个token激活2个共享专家和6个路由专家，而145B版本则有4个共享专家和128个路由专家，每个token激活4个共享专家和12个路由专家。
在DeepSeekMoE论文中也提到了今天要讲的主题：Expert Parallelism(专家并行)
在DeepSeek V3论文中，则有两段文字描述，给出了更详细的数据。DeepSeek R1 是基于V3来训练的，虽然没有提到更多的信息，基本上也与V3保持一致。
DeepEP介绍
DeepEP 是一个MoE模型和专家并行（Expert Parallelism, EP）设计的通信库。它提供了高吞吐量和低延迟的全互联 GPU 内核，这些内核也被称为 MoE 数据分发（dispatch）和合并（combine）。此外，该库还支持低精度操作，包括 FP8。
为了与 DeepSeek-V3 论文中提出的分组限制门控算法（group-limited gating algorithm）相匹配，DeepEP 提供了一组针对非对称域带宽转发优化的内核，例如从 NVLink 域向 RDMA 域转发数据。这些内核具有高吞吐量，非常适合用于训练和推理预填充任务。此外，它们还支持流式多处理器（Streaming Multiprocessors, SM）数量控制。
针对对延迟敏感的推理解码任务，DeepEP 包含了一组使用纯 RDMA 的低延迟内核，以最大限度地减少延迟。该库还引入了一种基于钩子（hook）的通信与计算重叠方法，不占用任何 SM 资源。
注意：该库的实现可能与 DeepSeek-V3 论文存在一些细微差异。
性能
普通内核的 NVLink 和 RDMA 转发测试
我们在 H800 上测试了普通内核（NVLink 最大带宽约为 160 GB/s），每个设备连接到一张 CX7 InfiniBand 400 Gb/s 的 RDMA 网卡（最大带宽约为 50 GB/s）。测试遵循 DeepSeek-V3/R1 的预训练设置：每批次 4096 个 token，隐藏层维度为 7168，top-4 分组，top-8 专家，FP8 分发与 BF16 合并。
类型
Dispatch #EP
瓶颈带宽
Combine #EP
瓶颈带宽
节点内
8
153 GB/s (NVLink)
8
158 GB/s (NVLink)
节点间
16
43 GB/s (RDMA)
16
43 GB/s (RDMA)
节点间
32
44 GB/s (RDMA)
32
47 GB/s (RDMA)
节点间
64
46 GB/s (RDMA)
64
45 GB/s (RDMA)
纯 RDMA 的低延迟内核测试
我们在 H800 上测试了低延迟内核，每个设备连接到一张 CX7 InfiniBand 400 Gb/s 的 RDMA 网卡（最大带宽约为 50 GB/s）。测试遵循典型的 DeepSeek-V3/R1 生产环境设置：每批次 128 个 token，隐藏层维度为 7168，top-8 专家，FP8 分发与 BF16 合并。
Dispatch #EP
延迟 (Latency)
RDMA 带宽
Combine #EP
延迟 (Latency)
RDMA 带宽
8
163 us
46 GB/s
8
318 us
46 GB/s
16
173 us
43 GB/s
16
329 us
44 GB/s
32
182 us
41 GB/s
32
350 us
41 GB/s
64
186 us
40 GB/s
64
353 us
41 GB/s
128
192 us
39 GB/s
128
369 us
39 GB/s
256
194 us
39 GB/s
256
360 us
40 GB/s
代码解读
优化思路中，最重要的还是低延迟通信优化，这里主要提一下。其他的比如动态调度和异步通信，流管理可以去看相关的文档和代码。
双缓冲区
auto buffer = layout.buffers[low_latency_buffer_idx]; auto next_buffer = layout.buffers[low_latency_buffer_idx ^= 1];
- 交替使用两个缓冲区，一个用于当前操作，另一个用于下一次操作
- 通过位运算^= 1高效切换缓冲区索引
**TMA (Tensor Memory Access) 优化**
- 利用Hopper架构的TMA指令加速数据传输
- 支持FP8等低精度数据格式，减少通信带宽需求
**IBGDA直接通信**
- - ```
// Initialize recv queues for low-latency mode ARibgda_initialize_recv_queue>>(rank);-
使用NVSHMEM的IBGDA技术实现GPU直接处理RDMA通信
-
完全绕过CPU参与，降低延迟
专家级QP分配
_buffer = Buffer(group, 0, num_rdma_bytes, low_latency_mode=True,num_qps_per_rank=num_experts // group.size())
- 为每个本地专家分配独立的QP，消除资源竞争
### DeepEP**适用场景：**
- 大规模MoE模型训练（如千亿参数级别）
- 高并发低延迟的实时推理服务
- 多模态、科学计算等异构计算任务
特别的，在repo最后，deepseek还说明，用了一个没有在英伟达文档里面的指令用来做优化，真是拥有探索精神的黑客，值得学习！
往期文章：
- [DeepSeek开源周第一天：FlashMLA 深度分析](https://mp.weixin.qq.com/s?__biz=MzAwNzc4MDgwNQ==&mid=2653126513&idx=1&sn=325c82d7c75a8ceb3f7bcfd63280d72e&scene=21#wechat_redirect)
- [开源周来袭：DeepSeek有哪些神秘技术即将公开？](https://mp.weixin.qq.com/s?__biz=MzAwNzc4MDgwNQ==&mid=2653126493&idx=1&sn=e0082b3ac23090cf9a363209f887c4e4&scene=21#wechat_redirect)
参考链接：
- https://github.com/deepseek-ai/DeepEP
- https://arxiv.org/pdf/2401.06066
- https://github.com/deepseek-ai/DeepSeek-MoE