如何重现 DeepSeek 推理性能突破

正文

请到「今天看啥」查看全文

测试中没有模拟 Cache 的影响，这是后续需完善的工作之一。

RTP-LLM 也支持 TP/DP/EP 混合部署，推荐在高算力卡上使用 TP=1；在 H20 等算力受限卡上，根据延迟约束选择 TP=2/4。

Decode

Decode 实例采用 144 EP 部署（128 + 16 冗余）。因实现差异，Host 用时快 2ms，Device 上则略慢，分析原因是 RoCE 与 IB 网络差异、未实现 CUDA Graph 优化以及部分 Kernel 实现较慢。这也是后续优化方向。

上图为 Decode 阶段压测曲线。在较低并发下，单用户可达 42 TPS。在 13200 并发时，达到单用户 20 TPS 的 SLA 界限，此时单卡吞吐为 1850 TPS。

在 DeepEP 开源之前，我们通过 All2All 实现了分布式 EP，对比单机也有非常好的吞吐提升，但延迟过高。除网络延迟高之外，All2All 带来了非常严重的 Host 同步开销，亦不利于重叠网络和计算时间。 建议不支持 DeepEP 机制的 GPU 可以等价地实现 Pure Device All2All，以达到接近的性能；而 ASIC 加速卡可更进一步，直接做 MoE/Dispatch/Combine 的 Overlap。

Implementation and Tricks

EPLB

下图为 EPLB 对延迟的影响测试。我们发现 EP 均衡状态受测试数据影响较大， 测试数据也并不能完全模拟真实应用的负载状态 。EP 负载策略仍然是未来要深入探索的一个方向。

MicroBatch & Overlapping

为使 GPU 计算和网络通信互相覆盖，我们完整实现了 Prefill/Decode Micro Batching 方案，并接入了 DeepEP 的 Overlap 机制。过程中，我们有以下发现：

• 无论是 Prefill 还是 Decode，由于 Dispatch 阶段传输的是 FP8 tensor 而 Combine 阶段传输的是 FP16 tensor，Combine 阶段的通信耗时会显著高于 Dispatch。因此， 在设计 Overlap 方案时，需要考虑用更大块的时间遮盖 Combine 部分通信。未来，在推理阶段引入量化通信，是一个可以考虑的改进方向。

• 对于 Prefill 来说，Attention 花费的时间占比相对较短，最终 Attention+MoE gate 部分和 MoE MLP 花费的时间相差不大，两部分都可以遮盖 Combine 阶段比较长的通信时间，只需要将请求切分后，两个 MicroBatch 的计算 / 通信互相穿插即可。值得注意的细节是 Shared Expert 计算总是被覆盖在了 Combine 的部分里，以保证覆盖 Combine 的计算时间比 Dispatch 更多 。

考虑 Qwen3 模型，虽然没有 Shared Expert，在 Decode 阶段仍然可以采用同样的 Overlap 方案，以 Attention 算子为界，在其中插入 MLP 计算，前后分别遮盖 Dispatch 和 Combine 的通信时间。框架层面，为兼容包括 DeepEP 的两种模式和 Vanilla All2All 通信的 Overlap 功能，并考虑扩展到多种不同硬件，我们开发了

请到「今天看啥」查看全文