智东西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在线推理系统图