详情

　　开首 TechWire开云体育

　　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

　　01

　　逐日总资本为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好意思元。

　　在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；网页端和应用瑕玷免费，扫数唯有一部分就业被货币化；夜间扣头在非岑岭时段自动适用。

　　02

　　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收受量的最大值）。

　　开首：智东西

海量资讯、精确解读，尽在新浪财经APP

包袱剪辑：王其霖 开云体育