迪士尼乐园时时彩 545%！DeepSeek公布表面老本利润率

发布日期：2024-10-19 19:53    点击次数：183

曩昔一周，DeepSeek贯穿盛开了5个Infra名倡导源代码，正直民众合计这场开源盛宴照旧收尾。3月1日，DeepSeek的彩蛋来了！开源周Day6，DeepSeek官方团队在斥地者社区Github和给出了DeepSeek-V3/R1推理系统的时间解读。通过优化婉曲和延长，DeepSeek表面上一天的总收入达到了562027好意思元，老本利润率为545%。

历害的网友——如MenloVentures投资东说念主Deedy翻译了这意味着什么：“表面ARR（年收入）2亿好意思元、利润率进步500%，这样的买卖效劳理当是一家值100亿好意思元的公司。”

从2024年5月发布DeepSeekV2以来，DeepSeek模子劳动就以“价钱屠户”示众，老是比行业其他模子低廉1/10傍边，质疑DeepSeek耗费打价钱战的声息也一直有。

通过这5天盛开源代码以及今天的推理系统概括，这一疑虑也被铲除，不错预料，模子推理价钱越来越职守得起，且劳动提供方也有的赚。这一事件的影响也不错通过应对平台网友展现出刷屏的惊喜得以一窥，“老本利润率545%，便是说你是在告诉我，我被Open AI洗劫了？开源周Day7的彩蛋是 AGI？”

但更大的信号指向生态伙伴，部署DeepSeek有的赚。

一位AI范围的投资东说念主示意，“官方时间解读标明，云平台和高下贱通过部署DeepSeek的劳动，表面上收益和利润率不错达到很高”。不管是对于提供在线推理、如故独有化部署等劳动的供应商，王人是利好。

在这波DeepSeek热中受益的云平台硅基流动独创东说念主袁进辉也在第一时期发表了我方的感受，“DeepSeek官方清晰大限度部署老本和收益，又一次颠覆了许多东说念主领略。”但需要时期适配DeepSeek V3/R1模子架构，他示意“当今许多供应商还作念不到这个水平，主如果V3/R1架构和其它主流模子判袂太大了，由大量小众人构成，导致对准其它主流模子结构斥地的系统王人不再有用，必须按照DeepSeek证据边幅的法子能力达到最佳的效劳，而斥地这样的系统难度很高，需要时期”。

袁进辉进一步指出当今复现这样的推理劳动的难度以及DeepSeek可能的计谋念念考，“幸好这周DeepSeek五连发照旧把主要模块开源出来了，镌汰了社区复现的难度。这些效果充分体现了DeepSeek团队第一性旨趣的念念考方式和强悍的相识，他们应该是当先是基于某些原因猜想了用这样的模子结构，然后发现这样的结构不管是检会如故推理，要作念好王人有至极大的工程挑战，不外这些问题在他们工程团队来说并不是搞不定的，要害是花那么自便气作念完是否有大的收益呢，在最终收尾出来前，谁也说不准，他们如故赌了，收尾是赌对了。也可能是反过来的，基于系统的起点瞎想了这样一个全新的模子结构。”

在DeepSeek官方证据中也提醒了DeepSeek-V3/R1推理系统的优化筹备是：更大的婉曲，更低的延长。合营时间解读，DeepSeek开源周放出的5个代码库带来的影响力才刚刚驱动。

《DeepSeek-V3 / R1 推理系统概览全文

DeepSeek-V3/R1推理系统的优化筹备是：更大的婉曲，更低的延长。

为了兑现这两个筹备，咱们的有筹备是使用大限度跨节点众人并行（Expert Parallelism / EP）。当先EP使得batch size大大加多，从而升迁GPU矩阵乘法的效劳，升迁婉曲。其次EP使得众人漫衍在不同的 GPU上，每个GPU只需要盘算很少的众人（因此更少的访存需求），从而镌汰延长。

但EP同期也加多了系统的复杂性。复杂性主要体当今两个方面：

EP引入跨节点的传输。为了优化婉曲，需要瞎想恰当的盘算进程使得传输和盘算不错同步进行。

EP波及多个节点，因此自然需要Data Parallelism（DP），不同的DP之间需要进行负载平衡。

因此，本文的主要内容是奈何使用EP增大batch size，奈何避讳传输的耗时，奈何进行负载平衡。

1、大限度跨节点众人并行（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个分享众人

2、盘算通讯重复

多机多卡的众人并行会引入相比大的通讯支出，是以咱们使用了双 batch重复来遮掩通讯支出，升迁全体婉曲。

对于prefill阶段，两个batch的盘算和通讯交错进行，一个batch在进行盘算的时候不错去遮掩另一个batch的通讯支出；

对于decode阶段，不同阶段的实验时期有所判袂，是以咱们把attention部分拆成了两个stage，推测 5 个stage的活水线来兑现盘算和通讯的重复。

对于更多双batch重复的细节，不错参考咱们的profiling数据的 GitHub仓库：https://github.com/deepseek-ai/profile-data。

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 发送量负载平衡）

Expert-Parallel Load Balancer

中枢问题：对于给定 、MoE模子，存在一些自然的高负载众人（expert），导致不同GPU的众人盘算负载不平衡

优化筹备：每个GPU上的众人盘算量平衡（即最小化悉数 GPU 的dispatch接管量的最大值）

4、参考架构图

5、线上系统的骨子统计数据

DeepSeek V3和R1的悉数劳动均使用H800 GPU，使用和检会一致的精度，即矩阵盘算和dispatch传输收受和检会一致的FP8花式，core-attention盘算和combine传输收受和检会一致的BF16，最猛进程保证了劳动效果。

今年以来，版号的稳定核发，稳步增长让广大游戏企业吃了“定心丸”。随着《黑神话》的现象级爆火，游戏企业更多地将精力放在市场探索、模式创新、自研创新和科技创新等方面，并积极开拓海外市场。

另外，由于白昼的劳动负荷高，晚上的劳动负荷低，因此咱们兑现了一套机制，在白昼负荷高的时候，用悉数节点部署推理劳动。晚上负荷低的时候，减少推理节点，以用来作念筹议和检会。在最近的24小时里（北京时期 2025/02/27 12:00 至 2025/02/28 12:00），DeepSeek V3和R1推理劳动占用节点总和，峰值占用为278个节点，平均占用226.75个节点（每个节点为8个H800 GPU）。假设GPU租出老本为2好意思元/小时，总老本为 $87072/天。

在24小时统计时段内，DeepSeek V3和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的订价 (注：DeepSeek R1 的订价：$0.14 / 百万输入tokens (缓存掷中)，$0.55 / 百万输入tokens (缓存未掷中)，$2.19 / 百万输出 tokens；虽然咱们骨子上莫得这样多收入，因为V3的订价更低，同期收费劳动只占了一部分，另外夜间还会有扣头)盘算，表面上一天的总收入为562027好意思元，老本利润率545%。

起头：段宛辰/极客公园微信公众号

• DeepSeek
• 迪士尼乐园时时彩
• 公布
• 545%
• 表面