跳到主要内容

DeepEP

两套 kernel 分别针对 prefill 和 decode 优化 AllToAll，IBGDA 怎么让 GPU 直接发 RDMA

核心要点：

  • DeepEP 解决传统 NCCL AllToAll 在 MoE 场景的三个具体问题
  • Normal kernel：训练 / prefill, NVLink + RDMA 非对称转发
  • Low-latency kernel: decode，纯 RDMA + IBGDA + Hook overlap
  • IBGDA 让 GPU 在 kernel 内直接发起 RDMA，绕开 CPU
  • 公开实测：EP=8 ~ 256 的延迟与带宽数据

DeepEP 是 DeepSeek 在 2025 年 2 月开源的 MoE 专家并行通信库，针对 Dispatch / Combine 两步 AllToAll 提供两套 kernel: normal （训练/prefill 用） 和 low-latency （decode 用）。EP 与 AllToAll 基本机制详见 8.1 总览，名词 (EP / Dispatch / Combine) 详见 8.1 总览 Glossary。

为什么需要 DeepEP，不用 NCCL?​

MoE 推理对 AllToAll 的需求与训练通用通信不同，传统 NCCL AllToAll 在 EP 场景有三个具体问题：

  • 延迟受 CPU 路径限制：NCCL 依赖 CPU 提交 work request，单次小消息端到端延迟约为微秒级 CPU+RDMA 路径。decode 阶段每个 token 都要触发完整通信，CPU 开销不可忽视
  • SM 占用与计算抢资源：NCCL 通信 kernel 长期占用大量 SM 拷贝数据。MoE 推理本身计算量小，通信 kernel 直接挤掉了 Expert FFN 可用算力
  • NVLink 和 RDMA 不分层：训练时一个 EP 组通常跨 NVLink 域 （节点内） 和 RDMA 域 （节点间），NCCL 标准 AllToAll 不感知非对称带宽，让 NVLink 闲置而 RDMA 过载

DeepEP 重新设计了两套 kernel，并在 Hopper (SM90) 上用 NVSHMEM + IBGDA 实现 kernel 内 RDMA 直接发起[1]。

Normal 与 Low-Latency，各解决什么场景？​

两套 kernel 面向不同阶段，优化目标完全不同：

维度Normal kernelLow-latency kernel
目标阶段训练 / 推理 prefill推理 decode
主要优化目标吞吐 (GB/s)延迟 (μs)
通信路径NVLink 域内 + RDMA 跨节点，非对称转发纯 RDMA
RDMA 发起方式NVSHMEM 标准路径IBGDA, GPU kernel 内直接发起
CUDA Graph 兼容否 （输出 shape 动态）是 （需预分配固定 buffer）
典型 SM 占用24 ~ 64 SM （可调）0 SM （hook overlap 模式）
Overlap 方式显式双 streamhook 回调，不占 SM

@tbl-deepep-01 Normal vs Low-Latency kernel 对比

LMSYS 96 H100 部署验证了 "prefill 用 normal, decode 用 low-latency" 的部署惯例[2]。

Normal kernel：非对称带宽转发​

Normal kernel 显式区分 NVLink 域和 RDMA 域，跨节点流量先 RDMA 到目标节点的"代理 GPU"，再由代理 GPU 通过 NVLink 转发到目标 GPU。这样跨节点 RDMA 只承载节点间唯一链路流量，避免每对源-目标 GPU 各占一份 RDMA 带宽。

Low-latency kernel：纯 RDMA + Hook overlap​

Low-latency kernel 放弃两段转发，直接用 IBGDA 在 source GPU 上发起 RDMA Put 写到目标 GPU 的接收 buffer，路径只有 RDMA 一跳。

Hook 机制让 overlap 不消耗 SM：调用 dispatch 后立即返回一个 hook 闭包，实际的 RDMA 接收和搬运动作要等用户在合适位置显式 hook() 才被驱动。这是 DeepEP 与传统 NCCL AllToAll 在 decode 场景的核心差异[1]。

IBGDA 是什么？为什么对延迟关键？​

IBGDA (InfiniBand GPU Direct Async) 让 GPU 线程在 CUDA kernel 内部直接构造 RDMA WQE 并通过 doorbell 触发 NIC，不需要 CPU 参与[3]。

路径对比​

传统 GPUDirect RDMA:

GPU kernel → CPU 通信库 (NCCL/MPI) → CPU 提交 WQE 到 NIC → NIC 从 GPU 显存 DMA → 对端 NIC → 对端 GPU 显存

IBGDA:

GPU kernel → GPU 线程直接写 WQE 到 NIC 提交队列 → 敲 doorbell → NIC 从 GPU 显存 DMA → 对端 NIC → 对端 GPU 显存

两点收益​

  • 延迟：去掉 GPU → CPU → NIC 的同步往返，对小消息特别有利。GPU 线程能在 kernel 内连续发起多次远端写入，不需要等 host 调用返回
  • 带宽利用：IBGDA 配合 warp 协作把多个小消息合并提交，维持 NIC 队列深度，避免短消息打不满 RDMA 带宽

DeepEP 在 low-latency kernel 中用 IBGDA 实现 warp 级 RDMA Put，用 RDMA 原子操作维护跨 GPU 的 token 到达计数。每个 local Expert 对应一个独立的 InfiniBand Queue Pair，支持多 Expert 并发收发[4]。

SM 占用对 MoE 推理意味着什么？​

SM 占用直接决定通信 kernel 与 Expert FFN 共享 GPU 算力的代价。DeepEP 的两种 kernel 占用差别巨大：

  • Normal kernel：通过 num_sms 参数控制上限，实测档位 24 （最小） 到 64 （最大）[1]
  • Low-latency kernel + hook: 0 SM 占用 — RDMA 由 NIC 异步完成，数据接收阶段在主 stream 外驱动

V2 进一步压缩 SM 用量：V1 在 24 SM, V2 在 4-6 SM，性能提升 1.3× 同时节省 4× SM[5]。

公开实测数据是什么量级？​

测试场景 （来自 DeepEP README）：8K tokens/batch, 7168 hidden dim, top-8 experts, FP8 dispatching, BF16 combining。硬件：H800 + CX7 InfiniBand （节点内 NVLink ~160 GB/s 单向，节点间 RDMA ~50 GB/s 单向）[1]。

Normal kernel 瓶颈带宽​

类型EP 规模DispatchCombine
节点内 (Intranode)8153 GB/s (NVLink)158 GB/s (NVLink)
跨节点 (Internode)1643 GB/s (RDMA)43 GB/s (RDMA)
跨节点 (Internode)3258 GB/s (RDMA)57 GB/s (RDMA)
跨节点 (Internode)6451 GB/s (RDMA)50 GB/s (RDMA)

@tbl-deepep-02 Normal kernel 瓶颈带宽

Low-latency kernel 延迟与带宽​

EP 规模Dispatch 延迟Dispatch RDMA 带宽Combine 延迟Combine RDMA 带宽
877 μs98 GB/s114 μs127 GB/s
16118 μs63 GB/s195 μs74 GB/s
32155 μs48 GB/s273 μs53 GB/s
64173 μs43 GB/s314 μs46 GB/s
128192 μs39 GB/s369 μs39 GB/s
256194 μs39 GB/s360 μs40 GB/s

@tbl-deepep-03 Low-latency kernel 延迟与 RDMA 带宽

观察：

  • Combine 延迟约为 Dispatch 的 1.5~2 倍，原因是 Combine 需要在目标 GPU 上按 token 聚合写回
  • EP 从 8 扩到 256 单次延迟从 77 μs 增至 194 μs，亚线性增长，IBGDA 路径在大 EP 下没有线性同步代价
  • EP=8 单点 Dispatch 带宽 98 GB/s 超过单 CX7 端口典型 50 GB/s 单向上限 (400 Gb/s ÷ 8 ≈ 50 GB/s)，此档位每 GPU 占用了多块 NIC 通道

大规模端到端实测​

LMSYS 在 SGLang 用 96 张 H100 （12 节点 × 8 GPU） 部署 DeepSeek-V3, prefill 用 normal dispatch, decode 用 low-latency dispatch，实测吞吐：prefill 单节点 52.3k input tokens/s, decode 单节点 22.3k output tokens/s[2]。

与 NCCL AllToAll 的根本差异在哪？​

维度NCCL AllToAllDeepEP normalDeepEP low-latency
RDMA 发起方CPUCPU + GPU (NVSHMEM)GPU (IBGDA)
NVLink + RDMA 非对称感知否是 （节点内 NVLink，节点间 RDMA 分层）不适用 （纯 RDMA）
小消息延迟受 CPU 提交路径限制中等低 （kernel 内发起）
SM 占用高且不易裁剪可调 (24~64)0 （hook 模式）
CUDA Graph支持有限不支持 （动态 shape）支持 （需预分配）
适用阶段通用训练 / prefilldecode

@tbl-deepep-04 DeepEP 与 NCCL AllToAll 对比

DeepEP 有哪些使用限制？​

  • 硬件强依赖：当前公开版本要求 Hopper (SM90) GPU, CUDA 12.3+, RDMA 网络 (InfiniBand / RoCE)。Ampere 部分功能可用但非主要支持目标
  • NVSHMEM 耦合：low-latency kernel 直接调用 NVSHMEM IBGDA 接口，部署需要正确配置 NVSHMEM_IBGDA_ENABLE、QP 数量、对称堆大小。没有 IBGDA 内核驱动的环境 （部分云虚拟化） 无法启用 low-latency 路径
  • MoE 专用：接口为 Dispatch / Combine 定制，token 索引 / top-K / FP8 量化 (UE8M0 / LogFMT) 是一等公民，不是通用 AllToAll 替代品
  • top-K 与 batch 影响：低延迟数据基于 8K tokens / top-8，其他配置 RDMA 包大小变化会改变带宽利用率，变更后需要重测

适用场景：

场景建议
训练大规模 MoE （DeepSeek-V3 / Kimi K2 类）normal kernel，节点内外混合 EP
推理 prefill （长 prompt）normal kernel
推理 decode （单 token 自回归，对 TPOT 敏感）low-latency kernel + hook overlap
非 MoE 模型 / 非 Hopper GPU / 无 RDMA不适用，回退 NCCL 或专用通信库

@tbl-deepep-05 DeepEP 适用场景

哪些问题仍未公开？​

  • V2 转 NCCL Gin 后端后，IBGDA 是否仍是 low-latency 唯一选择？官方文档未明确，DeepWiki 只说明 V1 依赖 NVSHMEM/IBGDA, V2 转 NCCL Gin[5]
  • Azure / AWS 等云厂商 IBGDA 启用所需的虚拟化配置只给了链接级提示，缺完整可复现的环境矩阵
  • 更大 EP 规模 (EP=512 / 1024) 下 low-latency 延迟是否仍亚线性？公开数据止于 EP=256

Takeaway​

知识点核心结论
DeepEP 解决问题NCCL 在 MoE: CPU 延迟 + SM 占用 + 非对称不感知
Normal kernel训练 / prefill, NVLink + RDMA 非对称转发，高吞吐
Low-latency kerneldecode，纯 RDMA + IBGDA, hook 0-SM overlap
IBGDA 核心GPU kernel 内直发 RDMA，绕开 CPU，小消息延迟低
SM 占用 V24-6 SM，比 V1 节省 4×，性能提升 1.3×
延迟扩展EP 8→256 延迟亚线性，77 → 194 μs
局限Hopper + RDMA + NVSHMEM 强依赖，MoE 专用

@tbl-deepep-06 DeepEP 核心知识点

参考资料​

  1. DeepSeek-AI, DeepEP: an efficient expert-parallel communication library, GitHub README. https://github.com/deepseek-ai/DeepEP
  2. LMSYS Org, Large-Scale Expert Parallelism on 96 H100 GPUs with SGLang, 2025-05-05. https://www.lmsys.org/blog/2025-05-05-large-scale-ep/
  3. NVIDIA, NVSHMEM Documentation. https://docs.nvidia.com/nvshmem/api/
  4. DeepWiki, IBGDA Technology — ROCm/DeepEP. https://deepwiki.com/ROCm/DeepEP/7.1-ibgda-technology
  5. DeepWiki, deepseek-ai/DeepEP. https://deepwiki.com/deepseek-ai/DeepEP

延伸阅读​