新闻动态

智东西3月1日音讯，DeepSeek的开源周确实还有彩蛋！开源第六天，DeepSeek不仅放出了DeepSeek-V3/R1推理系统时候诡秘，还公开了逐日资本和表面收入！

DeepSeek统计了2月27日24点到2月28日24点，假想出其逐日总资本为87072好意思元（折合东谈主民币约63万元）。要是统统Token皆以DeepSeek-R1的价钱计费，逐日总收入将为562027好意思元（折合东谈主民币约409万元），资本利润率达到545%。也便是说，表面上DeepSeek逐日净赚474955好意思元（折合东谈主民币约346万元）。

但本色情况是，DeepSeek的收入大幅着落。由于DeepSeek-V3订价低于R1；网页端和应用次第免费，惟有部分劳动有收入；非岑岭时段还有夜间扣头，使得其本色收入并莫得这样高。

此外，DeepSeek还公开了DeepSeek-V3/R1推理系统空洞：为了达到推理更高的蒙胧量和更低的蔓延，谈论东谈主员聘请了跨节点的内行谈论（EP），况兼诈欺EP增大batch size、将通讯蔓延荫藏在假想之后、引申负载平衡，应付EP的系统复杂性挑战。

发布一小时，GitHub Star数已进步5600。

驳倒区的网友经常cue OpenAI，直呼“被剥夺”了！

还有网友以OpenAI的订价帮DeepSeek算账：

GitHub地址：

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

一、逐日总资本为87072好意思元，利润率表面上最高545%

DeepSeek V3和R1的统统劳动均使用H800 GPU，使用和历练一致的精度，即矩阵假想和dispatch传输聘请和历练一致的FP8时局，core-attention假想和combine传输聘请和历练一致的BF16，最猛进程保证了劳动恶果。

此外，由于白昼的高劳动负载和晚上的低负载，DeepSeek在白昼岑岭时段跨统统节点部署推理劳动。在低负载的夜间时段减少了推理节点，并将资源分拨给谈论和历练。 在昔时的24小时内（2月27日24点到2月28日24点），V3和R1推理劳动的同一峰值节点占用率达到278，平均占用率为226.75个节点（每个节点包含8个H800 GPU）。假定一个H800 GPU的租借资本为每小时2好意思元，则逐日总资本为87072好意思元

▲推理劳动的H800节点计数

在24小时统计周期内（2月27日24点到2月28日24点），V3和R1：总输入Token 608B，其中342B Token（56.3%）射中KVCache硬盘缓存。总输出Token 168B，平均输出速率为每秒20-22 tps，每个输出Token的平均kvcache长度为4989个Token。每个H800节点在prefill时期提供约73.7k token/s输入（包括缓存射中）的平均蒙胧量，或在解码时期提供约14.8k token/s输出。以上统计数据包括统统来自web、APP、API的用户央求。 要是统统Token皆以DeepSeek-R1的价钱计费，逐日总收入将为562027好意思元，资本利润率为545%。*R1的订价：0.14好意思元输入Token（缓存射中），0.55好意思元输入令牌（缓存未射中），2.19好意思元输出令牌。 然则，DeepSeek的本色收入并莫得这样多，其原因是DeepSeek-V3的订价较着低于R1；网页端和应用次第免费，统统惟有一部分劳动被货币化；夜间扣头在非岑岭时段自动适用。

▲资本和表面收入

二、EP加多系统复杂性，三大计谋应付

DeepSeek的搞定有操办聘请了跨节点的内行并行（EP）。

领先，EP权臣扩张了批处理大小，增强了GPU矩阵假想效力并擢升了蒙胧量；其次，EP将内行散播在不同GPU上，每个GPU只处理内行的一小部分（减少内存造访需求），从而裁减蔓延。

然则，EP在两个方面加多了系统复杂性：EP引入跨节点的传输，为了优化蒙胧，需要假想允洽的假想历程使得传输和假想不错同步进行；EP触及多个节点，因此自然需要Data Parallelism（DP），不同的DP之间需要进行负载平衡。

DeepSeek通过三种相貌应付了这些挑战：

诈欺EP增大batch size、将通讯蔓延荫藏在假想之后、引申负载平衡。

1、大界限跨节点内行并行（EP）

由于DeepSeek-V3/R1的内行数目繁密，况兼每层256个内行中仅激活其中8个。模子的高度寥落性决定了其必须聘请很大的overall batch size，智力给每个内行提供有余的expert batch size，从而扫尾更大的蒙胧、更低的延时。需要大界限跨节点内行并行（Expert Parallelism/EP）。

DeepSeek聘请多机多卡间的内行并行计谋来达到以下主义：

Prefill：路由内行EP32、MLA和分享内行DP32，一个部署单位是4节点，32个冗余路由内行，每张卡9个路由内行和1个分享内行

Decode：路由内行EP144、MLA和分享内行DP144，一个部署单位是18节点，32个冗余路由内行，每张卡2个路由内行和1个分享内行

2、假想-通讯重复多机多卡的内行并行会引入比拟大的通讯支出，是以使用了双batch重复来障翳通讯支出，擢升全体蒙胧。 关于prefill阶段，两个batch的假想和通讯交错进行，一个batch在进行假想的时候不错去障翳另一个batch的通讯支出。

▲预充阶段的通讯-假想重复

关于decode阶段，不同阶段的引申时辰有所别离，是以DeepSeek把attention部分拆成了两个stage，揣测5个stage的活水线来扫尾假想和通讯的重复。

▲解码阶段的通讯-假想重复

3、扫尾最好负载平衡

由于聘请了很大界限的并行（包括数据并行和内行并行），要是某个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发送量负载平衡）。

内行并行负载平衡器的中枢问题：关于给定MoE模子，存在一些自然的高负载内行（expert），导致不同GPU的内行假想负载不平衡。

其优化操办是，每个GPU上的内行假想量平衡（即最小化统统GPU的dispatch接受量的最大值）。

▲DeepSeek在线推理系统图