DeepSeek突袭公布成本利润率:545%

人工智能 新闻
DeepSeek官方亲自揭秘了DeepSeek-V3/R1推理系统。

五连开源后,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

a.核心问题:不同数据并行(DP)实例上的请求个数、长度不同,导致core-attention计算量、dispatch发送量也不同

b.优化目标:各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的专家计算负载不均衡
  • 优化目标:每个GPU上的专家计算量均衡(即最小化所有GPU的dispatch接收量的最大值)

参考架构图

图片

线上系统的实际统计数据

DeepSeekV3和R1的所有服务均使用H800 GPU,使用和训练一致的精度,即矩阵计算和dispatch传输采用和训练一致的FP8格式,core-attention计算和combine传输采用和训练一致的BF16,最大程度保证了服务效果。

另外,由于白天的服务负荷高,晚上的服务负荷低,因此我们实现了一套机制,在白天负荷高的时候,用所有节点部署推理服务。晚上负荷低的时候,减少推理节点,以用来做研究和训练。在最近的24小时里(北京时间2025/02/27 12:00至2025/02/28 12:00),DeepSeekV3和R1推理服务占用节点总和,峰值占用为278个节点,平均占用226.75个节点(每个节点为8个H800 GPU)。假定GPU租赁成本为2美金/小时,总成本为$87,072/天。

图片

在24小时统计时段内,DeepSeekV3和R1:

输入token总数为608B,其中342B tokens(56.3%)命中KVCache硬盘缓存。

输出token总数为168B。平均输出速率为20~22tps,平均每输出一个token的KVCache长度是4989。

平均每台H800的吞吐量为:对于prefill任务,输入吞吐约73.7k tokens/s(含缓存命中);对于decode任务,输出吞吐约14.8k tokens/s。

以上统计包括了网页、APP和API的所有负载。如果所有tokens全部按照DeepSeek R1的定价*计算,理论上一天的总收入为$562,027,成本利润率545%。

*DeepSeek R1的定价:$0.14/百万输入tokens(缓存命中),$0.55/百万输入tokens(缓存未命中),$2.19/百万输出tokens。

当然我们实际上没有这么多收入,因为V3的定价更低,同时收费服务只占了一部分,另外夜间还会有折扣。

责任编辑:张燕妮 来源: 量子位
相关推荐

2009-05-26 09:26:13

2012-07-05 15:39:28

互联网手机小米

2012-08-16 10:07:05

思科

2015-04-14 11:50:10

Info仓库管理

2015-06-11 09:57:06

2013-12-24 09:22:17

甲骨文商品云

2012-04-13 13:24:36

2022-02-16 16:40:36

AI人工智能通信服务

2011-11-25 10:20:50

云计算服务器

2015-12-22 12:00:05

SDN云服务

2023-03-30 14:22:41

2009-02-26 16:56:07

虚拟化ITVMware

2014-01-23 18:36:16

联想IBM低端服务器

2015-12-31 15:29:56

苹果2015

2015-07-29 20:21:58

IT世界网

2012-07-25 09:49:17

华为

2021-07-02 15:50:17

物联网

2012-04-02 20:24:53

苹果

2009-06-17 10:39:01

互联网
点赞
收藏

51CTO技术栈公众号