大规模 EP 部署实测
LMSYS 96 H100 DeepSeek-V3 案例：五项调优怎么组合、三个瓶颈在哪
核心要点：
- LMSYS 96 H100 上 prefill 54.5k tokens/s/node, decode 22.3k tokens/s/node
- PD 分离：4 prefill 节点 (EP32) + 9 decode 节点 (EP72)
- 五项调优组合：DeepEP / EPLB / TBO / DeepGEMM / PD 分离
- 三个主要瓶颈：AllToAll 元数据同步 / KV 跨节点传输 / Expert 负载不均
- 用更少节点 (9 vs 18) 接近 DeepSeek H800 官方 profile 数字
LMSYS SGLang 团队在 96 H100 上把 DeepSeek-V3 推理吞吐做到接近 DeepSeek 官方 H800 profile，是首个公开的大规模开源复现。名词 （EP / Dispatch / Combine / PD 分离 / MTP） 详见 8.1 总览 Glossary; DeepEP kernel 细节见 8.2 DeepEP; PD 分离对带宽的具体需求见 9.3 推理部署模式。
96 H100 长什么样，怎么分？
Atlas Cloud 提供 12 节点 × 8 H100 集群，节点间 InfiniBand 互联，节点内 8 卡 NVLink 全互联[1][2]。每 GPU 单独绑定 400 Gb/s NDR HCA，节点级聚合 3.2 Tb/s 互联带宽 （与 NDv5-类 H100 配置一致）。
PD 分离节点划分：
| 角色 | 节点数 | GPU 数 | EP 度 | DP 度 (MLA + shared expert) |
|---|---|---|---|---|
| Prefill 服务器 | 4 | 32 | EP32 | DP32 |
| Decode 服务器 | 9 | 72 | EP72 | DP72 |
@tbl-large-ep-01 LMSYS 96 H100 PD 节点分配
PD 之间通过 RDMA 传输 KV cache，用 scatter-gather 后台线程做非阻塞传输，把 KV 写入与 decode 计算时间重叠[1]。
DeepSeek 官方 H800 部署作对照：prefill 4 节点 EP32 （与 LMSYS 一致）；decode 18 节点 EP144，比 LMSYS 多用一倍节点[3]。
各模块怎么并行？为什么这么选？
DeepSeek-V3 共 61 层 （前 3 层 dense FFN，后 58 层 MoE FFN, 256 routed expert + 1 shared, top-8 路由），LMSYS 对各层做差异化并行：
| 模块 | LMSYS 策略 | 关键参数 | 理由 |
|---|---|---|---|
| MLA Attention | DP | DP=32 (prefill) / DP=72 (decode) | 避免 TP 切分时 KV cache 在所有 TP rank 重复 |
| Dense FFN （前 3 层） | DP | --moe-dense-tp-size=1 | TP 在 H100 NVLink 域内带宽不够；intermediate dim 18432 用 TP 会 OOM |
| MoE FFN (routed expert) | EP | EP32 / EP72 | 把 256 expert 摊到 GPU，单 GPU 持 8 个 (EP32) 或约 4 个 (EP72) |
| MoE FFN (shared expert) | DP | DP=EP 度 | shared expert 每 token 都走，DP 不引入通信 |
@tbl-large-ep-02 LMSYS DeepSeek-V3 模块并行配置
Batch size:
| 阶段 | per-device batch | 触发约束 |
|---|---|---|
| Prefill | 16384 token | 受 dense FFN intermediate=18432 峰值显存限制；开 TBO 才能达 16k，关 TBO 时 8192 即 OOM |
| Decode | 128 ~ 256 sequence | 受 KV cache 显存与 DeepEP low-latency buffer 预分配限制 |
@tbl-large-ep-03 LMSYS per-device batch 与约束[1]
Dense FFN 显存最优 TP 度的经验公式：
$$\begin{equation} TP_{\mathrm{opt}} = \sqrt{\frac{N_{\mathrm{param}}}{(1+k) \cdot N_{\mathrm{hidden}}}} \label{eq:large-ep-tp-opt} \end{equation}$$- $N_{\mathrm{param}}$：单 dense FFN 参数量
- $N_{\mathrm{hidden}}$：该层激活元素数
- $k$：反向激活相对前向激活的倍率
对 DeepSeek-V3 dense FFN (intermediate=18432)，该式给出 TP=1 显存最优，与 LMSYS 实测一致[1]。
实测吞吐到底多少？
Prefill 吞吐 (per node, 16k batch)
| 输入长度 | LMSYS 实测 tokens/s | 备注 |
|---|---|---|
| 1k | 57,674 | 默认配置 |
| 2k | 54,543 | 默认配置 |
| 4k | 50,302 | 默认配置 （无 perfect EPLB） |
| 4k | 59,337 | 开 perfect EPLB （理论上限模拟） |
@tbl-large-ep-04 Prefill per-node 吞吐[1]
Decode 吞吐 (per node)
| 配置 | 输入长度 | per-device batch | tokens/s/node |
|---|---|---|---|
| 默认 （无 MTP） | 2k | 256 | 22,282 |
| 默认 （无 MTP） | 2k | 128 | 22,310 （开 TBO） |
| 模拟 MTP （多一次 attention） | 4k | 256 | 17,552 （开 TBO） |
| 模拟 MTP （多一次 attention） | 4k | 256 | 17,373 （关 TBO） |
@tbl-large-ep-05 Decode per-node 吞吐[1]
LMSYS 给出的是 per-node 吞吐：整个 96 H100 集群 (4 prefill + 9 decode) 在 2k 输入下达到 prefill 54.5k/4k 输入 50.3k 与 decode 22.3k tokens/s/node。这是首个大规模下接近 DeepSeek 官方博客报告吞吐的开源实现[1]。
主要瓶颈在哪三处？
AllToAll 元数据同步阻塞 CPU
DeepEP Normal Dispatch 在动态 shape 模式下需要先在 GPU 间交换路由元数据，CPU 拿到元数据前会被阻塞[1]。
- 单层 dispatch 实测约 0.17 ms
- Unit test 中纯 RDMA 路径理论下限 0.06 ms
- 差距来自元数据同步与 CPU 路径
Azure 独立测试[2] 给出带宽口径：H100 + 400 Gb/s NDR 双节点 16 GPU 场景，DeepEP RDMA 阶段算法带宽约 25 GB/s （dispatch / combine 单向）；同节点 NVLink 路径 79~84 GB/s。
KV cache 跨节点传输
PD 分离要求每条请求 prefill 结束后把全部 KV cache （DeepSeek-V3 MLA 后压缩到 latent） 通过 IB 传到 decode 节点。前台同步会成为关键路径，LMSYS 用后台非阻塞传输 + scatter-gather 把它隐藏在 decode 计算之下[1]。
Expert 负载不均
DeepSeek-V3 实际路由分布是"少数 expert 极热、多数冷"，且 prefill 与 decode 分布不一样。LMSYS 实测：
- 关 EPLB 在 EP72 大规模下出现 GPU 利用率劣化
- 开 EPLB （256 + 32 冗余 = 288 expert 实例） 后，prefill 提速 1.49 倍，decode 提速 2.54 倍
@tbl-large-ep-06 EPLB 收益[1]
EPLB 的另一好处：EP 度不再受限于 2 的幂，LMSYS 才能用 EP72 (72 = 8 × 9) 这种非 2 幂划分。
五项调优手段各自收益多少？
| 调优手段 | 适用阶段 | 量化收益 | 机制 |
|---|---|---|---|
| DeepEP Normal Dispatch | Prefill | 大批量 token / dynamic shape 友好 | NVLink + RDMA 非对称转发 |
| DeepEP Low-Latency Dispatch | Decode | 单步 dispatch ~0.17 ms | 纯 RDMA + IBGDA，预分配固定 buffer |
| EPLB | Prefill + Decode | Prefill ×1.49, Decode ×2.54 | 256 + 32 冗余 expert，按历史路由放置 |
| Two-Batch Overlap (TBO) | Prefill | +27% ~ +35% | 双 micro-batch 交错，AllToAll 与 Expert 并行 |
| TBO | Decode | +25.5% （无 MTP） / +35% （模拟 MTP） | 同上 |
| TBO + 峰值显存优化 | Prefill | per-device batch 8k → 16k | 双 micro-batch 拆掉单批中间张量峰值 |
| DeepGEMM contiguous-layout grouped GEMM | Prefill | 适配 Normal Dispatch 输出 | 配合 Triton permutation 重排 contiguous |
| DeepGEMM masked-layout grouped GEMM | Decode | 适配 Low-Latency 固定 shape | 支持 CUDA Graph, shape 静态 |
| PD 分离 | 全局 | 避免 prefill 打断 decode；解 DP attention 不平衡 | prefill 与 decode 独立 server，握手交付 KV |
@tbl-large-ep-07 调优手段与收益[1]
Azure 团队的 host 侧经验补充：显式把进程绑定到正确的 NUMA 节点、HCA 和 GPU 上，减少跨 NUMA 拷贝，DeepEP 在 ND_H100_v5 上能达到甚至超过 DeepEP README 报告的带宽[2]。
与 DeepSeek 官方数字比，差多少？
DeepSeek-V3 官方公开两组数字：技术报告 24h 生产服务平均，与开源周博客 profile。LMSYS 逐项对比：
| 指标 | DeepSeek 官博 (H800) | DeepSeek profile (H800) | LMSYS 默认 (H100) | LMSYS + perfect EPLB (H100) |
|---|---|---|---|---|
| Prefill, 4k 输入，16k batch (tokens/s/node) | 32,206 | 62,713 | 50,302 | 59,337 |
| Decode, 2k 输入，128 batch (tokens/s/node) | 14,800 | 18,598 | 22,282 | 17,373 （模拟 MTP） |
@tbl-large-ep-08 LMSYS vs DeepSeek 官方逐项对比[1]
观察：
- Prefill 默认比 DeepSeek profile 慢 20%；开 perfect EPLB 后只慢约 6%
- Decode 用了 DeepSeek 一半的节点数 (9 vs 18) 即接近 profile
- DeepSeek-V3 技术报告 73.7k tokens/s/node prefill 数字带了"含 KV cache 命中"统计口径，与 profile 纯计算口径不可直接比较[4][3]
硬件差异：H800 是 H100 的中国特供版，HBM 与 SM 数与 H100 一致，主要差在 NVLink 带宽 （H800 ~400 GB/s 双向，H100 ~900 GB/s）。LMSYS 用 H100 而 DeepSeek 用 H800，节点内带宽 LMSYS 占优，LMSYS 用更少节点匹配 profile 数字合理。
想复现需要什么？局限是什么？
复现关键条件：
- 硬件：12 节点 × 8 H100，节点间至少 400 Gb/s × 8 = 3.2 Tb/s IB 互联 （NDR / NDv5 量级）
- 软件：SGLang ≥ 当时博客版本，启用
--enable-deepep-moe --enable-dp-attention --moe-dense-tp-size=1 --enable-two-batch-overlap - 依赖：DeepEP 编译 IBGDA 支持，NVSHMEM ≥ 3.0
- 预热：EPLB 需要先用 warm-up batch 跑出 expert 路由统计，再做冗余 expert 放置
实验局限 （影响结论可信度）：
- per-node 口径：prefill 与 decode 节点数不同，整体集群单一 throughput 数字无法直接相加
- MTP 是模拟：decode 阶段的 MTP 收益不是真实 MTP 实现，而是用"多跑一次 attention"模拟其额外计算量
- EPLB 收益依赖 trace：1.49× / 2.54× 是博客 trace 上的数字，不同 prompt 分布下收益可能不同；"perfect EPLB" 是理论上限非可部署配置
- 未做长上下文压力：博客主要在 2k / 4k 输入，128k 长上下文场景的 KV 传输瓶颈未覆盖
- PD 节点比例固定：4 : 9 是手调而非动态调度，真实在线服务的流量比例可能漂移
还有哪些未解决？
- EP72 + EPLB 收益结构能否推广到 H100 之外的硬件 （B200 / MI300X / 国产卡）
- 真实 MTP （非模拟） 在 PD 分离 + DeepEP 路径下的端到端吞吐
- 长上下文 (≥ 32k) 下 KV cache 跨节点传输是否会从"可隐藏"变成关键路径
- EP72 这种非 2 幂划分对 routing collision / load imbalance 的长期稳定性
- 与 DeepSeek 官方 H800 EP144 decode 在相同 SLO 下的真实成本对比 （按 $/Mtoken）
Takeaway
| 知识点 | 核心结论 |
|---|---|
| 集群规模 | 12 节点 × 8 H100，节点级 3.2 Tb/s IB |
| PD 划分 | 4 prefill (EP32) + 9 decode (EP72) |
| 各模块策略 | MLA / dense FFN / shared expert 用 DP; routed expert 用 EP |
| Prefill 吞吐 | 50.3k ~ 57.7k tokens/s/node （随输入长度） |
| Decode 吞吐 | 22.3k tokens/s/node （无 MTP, 2k 输入） |
| 三大瓶颈 | AllToAll 元数据 + KV 传输 + Expert 负载不均 |
| 五项调优 | DeepEP / EPLB / TBO / DeepGEMM / PD 分离 |
| 关键 EPLB 收益 | Prefill ×1.49, Decode ×2.54 |
| 与官方对比 | 用 H800 一半节点接近 DeepSeek profile |
@tbl-large-ep-09 大规模 EP 实测核心知识点
参考资料
- LMSYS Org, Deploying DeepSeek with PD Disaggregation and Large-Scale Expert Parallelism on 96 H100 GPUs, 2025-05-05. https://www.lmsys.org/blog/2025-05-05-large-scale-ep/
- Microsoft Azure HPC Blog, Achieving Optimal Performance for DeepSeek Expert Parallelism (DeepEP) on Azure, 2025. https://techcommunity.microsoft.com/blog/azurehighperformancecomputingblog/achieving-optimal-performance-for-deepseek-expert-parallelism-deepep-on-azure/4414699
- Atlas Cloud, Cross-Node Expert Parallelism: DeepSeek's Leap in Throughput and Latency Efficiency, 2025. https://www.atlascloud.ai/blog/guides/cross-node-expert-parallelism-deepseeks-leap-in-throughput-and-latency-efficiency
- DeepSeek-AI, DeepSeek-V3 Technical Report, arXiv:2412.19437, 2024. https://arxiv.org/abs/2412.19437
延伸阅读
- Microsoft Learn, ND-H100-v5 size series. https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/gpu-accelerated/ndh100v5-series