DeepSeek开源周:V3/R1推理系统揭秘,成本与性能深度解析

DeepSeek 公布 V3/R1 推理系统细节,H800 节点吞吐量达 73.7k 输入 token/s 和 14.8k 输出 token/s,理论成本利润率 545%。

原文标题:DeepSeek一天能赚多少钱?官方突然揭秘V3/R1推理系统,成本全透明

原文作者:机器之心

冷月清谈:

DeepSeek在其开源周的第六天,意外地公布了其V3/R1推理系统的细节。该系统采用跨节点专家并行策略(EP),结合计算-通信重叠和负载均衡技术,实现了高吞吐量和低延迟。官方数据显示,每个H800 GPU节点实现了每秒73.7k输入token和14.8k输出token的处理速度。DeepSeek还公布了其在线服务的统计数据,并透露如果所有token都按照R1的定价收费,理论日收入可达56.2万美元,成本利润率高达545%。但由于V3定价更低,部分服务免费,以及夜间折扣等因素,实际收入远低于理论值。值得注意的是,DeepSeek 的预填充阶段和解码阶段采用了不同程度的并行策略,以优化性能。他们还详细解释了如何通过预填充负载均衡器、解码负载均衡器以及专家并行负载均衡器来实现计算和通信负载的平衡,从而避免单点瓶颈,最大化资源利用率。

怜星夜思:

1、DeepSeek 提到的 EP 策略和计算 - 通信重叠技术,具体是如何在实际系统中实现的?有没有其他大模型也采用了类似的技术?
2、DeepSeek 的理论成本利润率高达 545%,这是否意味着大模型推理业务的利润空间非常大?实际应用中,有哪些因素会影响这个利润率?
3、DeepSeek 将部分资源用于夜间的研究和训练,这种策略有什么优势?其他大模型厂商是否也有类似的做法?

原文内容

机器之心报道
机器之心编辑部
DeepSeek 官方:如果所有 tokens 全部按照 DeepSeek R1 的定价计算,理论上一天的总收入为 $562,027,成本利润率 545%。但实际上没有这么多收入,因为 V3 的定价更低,同时收费服务只占了一部分,另外夜间还会有折扣。

太突然了!原来 DeepSeek 也有 One More Thing。

就在所有人以为 DeepSeek 预告的 5 天开源告一段落时,今天中午 12 点 11 分,官方 𝕏 帐号再次更新,宣告「开源周」还在继续。不过这第六天 DeepSeek 并没有开源新的软件库,而是介绍了 DeepSeek-V3/R1 的推理系统。


概述地址:https://github.com/deepseek-ai/open-infra-index/blob/main/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md

DeepSeek 的推文中写到,DeepSeek-V3/R1 的推理系统采用了跨节点 EP 驱动的批量扩展、计算 - 通信重叠、负载平衡来实现对吞吐量和延迟的优化。同时,DeepSeek 还给出了其在线服务的统计数据:

  • 每个 H800 节点实现了 73.7k/14.8k 个每秒输入 / 输出 token;
  • (理论)成本利润率高达 545%

DeepSeek 还表示:「我们希望本周的洞见能够为社区带来价值,并为我们共同的 AGI 目标做出贡献。」

一时之间,社区再次沸腾,不仅仅是因为明明说的 5 天开源却来到了第 6 天以及 73.7k、14.8k、545% 这三个惊人的数字,大家尤其期待明天 —— 开源周的最后一天,DeepSeek 将用什么来压轴。



系统设计原则

为了实现更高的吞吐量和更低的延迟,DeepSeek 采用了跨节点专家并行(EP,Expert Parallelism)策略。

首先,EP 显著扩展了 batch 大小,提高了 GPU 矩阵计算效率并增加了吞吐量。

其次,EP 将专家分布到各个 GPU 上,每个 GPU 只处理一小部分专家(减少内存访问需求),从而降低延迟。

然而 EP 增加了系统的复杂性,主要表现在两个方面:

  • EP 引入了跨节点通信。为了优化吞吐量,必须设计适当的计算工作流,shi 通信与计算重叠。

  • EP 涉及多个节点,因此本质上需要数据并行 (DP),并且需要在不同的 DP 实例之间进行负载平衡。


为此,该项目重点介绍如何通过以下方式应对这些挑战:

  • 利用 EP 扩展 batch 大小;

  • 隐藏计算背后的通信延迟;

  • 执行负载平衡。


大规模跨节点专家并行(EP)

由于 DeepSeek-V3/R1 中专家数量庞大 —— 每层 256 个专家中只有 8 个被激活 —— 模型的高度稀疏性导致需要极大的总 batch 大小。这样才能确保每个专家有足够的 batch 大小,从而实现更高的吞吐量和更低的延迟。大规模跨节点 EP(专家并行)是至关重要的。

由于 DeepSeek 采用了预填充 - 解码分解架构,因此他们在预填充和解码阶段采用不同程度的并行性:

  • 预填充阶段 [路由专家 EP32、MLA / 共享专家 DP32]:每个部署单元跨越 4 个节点,拥有 32 个冗余路由专家,其中每个 GPU 处理 9 个路由专家和 1 个共享专家。

  • 解码阶段 [路由专家 EP144、MLA / 共享专家 DP144]:每个部署单元跨越 18 个节点,拥有 32 个冗余路由专家,其中每个 GPU 管理 2 个路由专家和 1 个共享专家。


计算 - 通信重叠

大规模跨节点 EP 会引入显著的通信开销。为了缓解这一问题,DeepSeek 采用了「dual-batch」重叠策略,通过将一个 batch 请求拆分为两个 microbatch 来隐藏通信成本并提高整体吞吐量。在预填充阶段,这两个 microbatch 交替执行,一个 microbatch 的通信成本被隐藏在另一个 microbatch 的计算过程中。

预填充阶段通信 - 计算重叠

在解码阶段,不同阶段的执行时间是不平衡的。因此,DeepSeek 将注意力层细分为两个 step,并使用一个 5 阶段的 pipeline 来实现无缝的通信 - 计算重叠。
解码阶段的通信 - 计算重叠

关于通信 - 计算重叠机制的更多细节可以参考:https://github.com/deepseek-ai/profile-data

实现最优负载平衡

大规模并行化(包括 DP 和 EP)存在一个关键难题:如果单台 GPU 的计算或通信负荷过重,它就会成为性能瓶颈,导致整个系统变慢,同时还让其他 GPU 处于闲置状态。为了最大限度地提高资源利用率,DeepSeek 努力实现了所有 GPU 上的计算和通信负载平衡。

1. 预填充负载平衡器

关键问题:DP 实例之间的请求数量和序列长度不同,导致核心注意力(core-attention)计算和调度发送负载不平衡。

优化目标:

  • 平衡 GPU 之间的核心注意力计算(核心注意力计算负载平衡)。

  • 均衡每个 GPU 的输入 token 数量(调度发送负载平衡),防止特定 GPU 上的处理时间过长。


2. 解码负载平衡器

关键问题:DP 实例之间的请求数量和序列长度不均匀导致核心注意力计算(与 KV 缓存使用量相关)和调度发送负载不均。

优化目标:

  • 平衡 GPU 之间的 KV 缓存使用率(核心注意力计算负载平衡)。

  • 均衡每个 GPU 的请求数(调度发送负载平衡)。


3. 专家并行负载平衡器

关键问题:对于给定的 MoE 模型,存在固有的高负载专家,导致不同 GPU 之间的专家计算工作负载不平衡。

优化目标:平衡每个 GPU 上的专家计算(即,最小化所有 GPU 上的最大调度接收负载)。

DeepSeek 在线推理系统示意图 

DeepSeek 在线推理系统示意图

DeepSeek 在线服务统计 

所有 DeepSeek-V3/R1 推理服务均在 H800 GPU 上运行,精度与训练一致。具体而言,矩阵乘法和分发传输采用与训练一致的 FP8 格式,而核心 MLA 计算和组合传输使用 BF16 格式,确保最佳服务性能。 

此外,由于白天服务负载高而夜间负载低,DeepSeek 实施了一种机制,于白天高峰时段在所有节点上部署推理服务。在夜间低负载期间,他们减少推理节点并将资源分配给研究和训练。在过去 24 小时内(北京时间 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00),V3 和 R1 推理业务的合并峰值节点占用达到 278,平均占用 226.75 个节点(每个节点包含 8 个 H800 GPU)。假设租赁一个 H800 GPU 的成本为每小时 2 美元,每日总成本为 87,072 美元(约合人民币 63.4 万)。 

H800 推理服务节点数量。

在 24 小时统计期间(北京时间 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00),V3 和 R1: 

  • 总输入 token:608B,其中 342B token(56.3%)命中磁盘 KV 缓存。

  • 总输出 token:168B。平均输出速度为每秒 20-22 个 token,每个输出 token 的平均 kvcache 长度为 4,989 个 token。

  • 每个 H800 节点在预填充期间平均吞吐量约为 73.7k tokens/s 输入(包括缓存命中)或在解码期间约为 14.8k tokens/s 输出。


以上统计数据包括来自网页、APP 和 API 的所有用户请求。如果所有 token 都按照 DeepSeek-R1 的定价 (*) 计费,每日总收入将为 562,027 美元,成本利润率为 545%。 

(*) R1 定价:0.14 美元 / 百万输入 token(缓存命中),0.55 美元 / 百万输入 token(缓存未命中),2.19 美元 / 百万输出 token。 

然而,DeepSeek 表示实际收入大幅低于此数字,原因如下:

  • DeepSeek-V3 的定价显著低于 R1,

  • 只有部分服务实现货币化(网页和 APP 访问仍然免费),

  • 在非高峰时段自动应用夜间折扣。



明天是这周的最后一天,不知道 DeepSeek 还有没有新的惊喜。

相关阅读:

  •  
© THE END 
转载请联系本公众号获得授权
投稿或寻求报道:[email protected]

关于 EP 策略和计算-通信重叠,DeepSeek 的文章里提到了 dual-batch 和 pipeline 技术,但细节不多。我理解 dual-batch 是指将一个 batch 拆成两个小的,交替执行来隐藏通信延迟。pipeline 应该是在解码阶段,把注意力层分成多个步骤,让计算和通信并行进行。至于其他大模型,我感觉应该也有类似的优化,但公开资料不多,得深入研究一下论文和代码。

这种 “削峰填谷” 的做法在云计算领域很常见,可以最大限度地利用资源。对于 DeepSeek 来说,夜间训练还可以加速模型迭代,保持竞争力。

545% 的利润率看着诱人,但这是理论值,而且是基于 R1 的定价。实际情况复杂得多,V3 定价、免费服务、夜间折扣都会影响收入。此外,硬件成本、维护成本、研发成本等等都会压缩利润空间。

感觉这个策略很聪明,既能省钱,又能提升技术水平。不过具体怎么调度资源,怎么平衡推理和训练的需求,估计也是个技术活。

DeepSeek这波操作确实有点东西,感觉是把高性能计算的经验用在了大模型上。不过具体实现细节还得等他们开源更多代码才能知道。估计现在很多大模型都在搞类似的优化,毕竟推理成本太高了。

我觉得 DeepSeek 公布这个数据是想展示其技术的先进性和效率,但这并不代表所有大模型都能达到这么高的利润率。市场竞争、用户需求、技术迭代都会影响最终的盈利水平。想躺着赚钱,没那么容易。

夜间推理负载低,把空闲资源用于研究和训练,可以提高资源利用率,降低成本。我觉得这是一种很合理的策略,其他厂商应该也有类似的做法,毕竟 H800 不是白菜价。

计算-通信重叠在高性能计算领域很常见,像一些MPI的实现就会用到。感觉DeepSeek这里也是类似的思路,只不过应用在了大模型推理上。至于EP,文中提到了跨节点,那网络拓扑结构就很关键了,不知道他们用的是什么互联技术,Infiniband?RoCE?

利润率高不高,最终还是得看市场。DeepSeek 如果能持续提供高质量的服务,吸引更多用户,那盈利前景肯定不错。但如果技术更新换代太快,或者竞争对手太强,那也可能赚不到什么钱。