过去一周，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%。
还没有评论，来说两句吧...