五连开源后，DeepSeek还有One More Thing！

就在刚刚，DeepSeek官方亲自揭秘了DeepSeek-V3/R1推理系统。

重点包括，优化吞吐量和延迟的方法：

• 跨节点EP驱动的批量扩展

• 计算与通信重叠

• 负载均衡

还公布了DeepSeek的在线服务数据统计：

• 每个H800节点每秒有73.7k/14.8k个输入/输出token

• 成本利润率545%

更多细节，一起来看官方原文↓

更大的吞吐，更低的延迟

DeepSeek-V3/R1推理系统的优化目标是：更大的吞吐，更低的延迟。

为了实现这两个目标，我们的方案是使用大规模跨节点专家并行（ExpertParallelism/EP）。

首先EP使得batch size大大增加，从而提高GPU矩阵乘法的效率，提高吞吐。其次EP使得专家分散在不同的GPU上，每个GPU只需要计算很少的专家（因此更少的访存需求），从而降低延迟。

但EP同时也增加了系统的复杂性。复杂性主要体现在两个方面：

• EP引入跨节点的传输。为了优化吞吐，需要设计合适的计算流程使得传输和计算可以同步进行。

• EP涉及多个节点，因此天然需要Data Parallelism（DP），不同的DP之间需要进行负载均衡。

因此，本文的主要内容是如何使用EP增大batch size，如何隐藏传输的耗时，如何进行负载均衡。

大规模跨节点专家并行（Expert Parallelism/EP）

由于DeepSeek-V3/R1的专家数量众多，并且每层256个专家中仅激活其中8个。模型的高度稀疏性决定了我们必须采用很大的overall batch size，才能给每个专家提供足够的expert batch size，从而实现更大的吞吐、更低的延时。需要大规模跨节点专家并行（Expert Parallelism/EP）。

我们采用多机多卡间的专家并行策略来达到以下目的：

• Prefill：路由专家EP32、MLA和共享专家DP32，一个部署单元是4节点，32个冗余路由专家，每张卡9个路由专家和1个共享专家

• Decode：路由专家EP144、MLA和共享专家DP144，一个部署单元是18节点，32个冗余路由专家，每张卡2个路由专家和1个共享专家

计算通信重叠

多机多卡的专家并行会引入比较大的通信开销，所以我们使用了双batch重叠来掩盖通信开销，提高整体吞吐。

对于prefill阶段，两个batch的计算和通信交错进行，一个batch在进行计算的时候可以去掩盖另一个batch的通信开销；

△Prefill阶段的双batch重叠

对于decode阶段，不同阶段的执行时间有所差别，所以我们把attention部分拆成了两个stage，共计5个stage的流水线来实现计算和通信的重叠。

△Decode阶段的双batch重叠

关于更多双batch重叠的细节，可以参考我们的profiling数据的GitHub仓库：https://github.com/deepseek-ai/profile-data。

尽可能地负载均衡

由于采用了很大规模的并行（包括数据并行和专家并行），如果某个GPU的计算或通信负载过重，将成为性能瓶颈，拖慢整个系统；同时其他GPU因为等待而空转，造成整体利用率下降。因此我们需要尽可能地为每个GPU分配均衡的计算负载、通信负载。

• Prefill Load Balancer

• 核心问题：不同数据并行（DP）实例上的请求个数、长度不同，导致core-attention计算量、dispatch发送量也不同

• 优化目标：各GPU的计算量尽量相同（core-attention计算负载均衡）、输入的token数量也尽量相同（dispatch发送量负载均衡），避免部分GPU处理时间过长

• Decode Load Balancer

• 核心问题：不同数据并行（DP）实例上的请求数量、长度不同，导致core-attention计算量（与KVCache占用量相关）、dispatch发送量不同

• 优化目标：各GPU的KVCache占用量尽量相同（core-attention计算负载均衡）、请求数量尽量相同（dispatch发送量负载均衡）

• Expert-Parallel Load Balancer

• 核心问题：对于给定MoE模型，存在一些天然的高负载专家（expert），导致不同GPU的专家计算负载不均衡