过去一周，DeepSeek 依次开放了 5 个 Infra 项目的源代码。正当大家觉得这场开源盛宴已然结束之时，3 月 1 日，DeepSeek 的彩蛋出现了！在开源周的第 6 天，DeepSeek 官方团队于开发者社区 Github 和知乎给出了 DeepSeek - V3/R1 推理系统的技术解读。DeepSeek 通过优化吞吐和延迟，在理论上一天的总收入达到了 562027 美元，并且成本利润率为 545%。

敏锐的网友翻译了这意味着什么，比如 MenloVentures 投资人 Deedy 说：“理论上的年收入是 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；怎样隐藏传输所耗费的时间；怎样进行负载均衡。

大规模地进行跨节点的专家并行操作，即 Expert Parallelism / EP 这种方式。

DeepSeek-V3/R1 的专家数量较为众多，每层 256 个专家里仅会激活其中 8 个。因为模型具有高度稀疏性，所以我们必须使用很大的 overall batch size，这样才能给每个专家提供足够的 expert batch size，进而实现更大的吞吐以及更低的延时。需要实施大规模的跨节点专家并行举措。

我们采用多机多卡间的专家并行策略来达到以下目的：

路由专家有 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 仓库。

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 的计算负载均衡；同时，各 GPU 的请求数量也要尽量保持相同，即要达到 dispatch 的发送量负载均衡。

Expert-Parallel Load Balancer

给定 MoE 模型存在一些天然的高负载专家，这会使得不同 GPU 的专家计算负载不均衡，这是核心问题。

每个 GPU 上的专家计算量要达到均衡，也就是说要使所有 GPU 的 dispatch 接收量的最大值达到最小化。

4、参考架构图

5、线上系统的实际统计数据

DeepSeek V3 的所有服务使用 H800 GPU，其使用和训练的精度是一致的。在矩阵计算和 dispatch 传输方面采用与训练一致的 FP8 格式，在 core-attention 计算和 combine 传输方面采用与训练一致的 BF16，这样最大程度地保证了服务效果。R1 的所有服务也使用 H800 GPU，使用和训练的精度同样一致，矩阵计算和 dispatch 传输采用与训练一致的 FP8 格式，core-attention 计算和 combine 传输采用与训练一致的 BF16，从而最大程度保证了服务效果。

另外，因为白天的服务负荷比较高，而晚上的服务负荷比较低，所以我们构建了一套机制。在白天负荷高的时候，会使用所有节点来部署推理服务。在晚上负荷低的时候，会减少推理节点，以便用于做研究和训练。在最近的 24 小时时间段内（即北京时间 2025 年 2 月 27 日 12：00 至 2025 年 2 月 28 日 12：00），DeepSeek V3 的推理服务与 R1 的推理服务所占用的节点总和，其峰值时占用了 278 个节点，平均占用的节点数为 226.75 个（每个节点包含 8 个 H800 GPU）。假定 GPU 的租赁成本是每小时 2 美元，而总成本是每天 87072 美元。

在24小时统计时段内，DeepSeek V3和R1：

输入的 token 总数是 608B，其中有 342B 的 tokens，这些 tokens 占比 56.3%，并且命中了 KVCache 硬盘缓存。

输出的 token 总数是 168B。其平均输出速率在 20 到 22tps 之间。平均每输出一个 token 的 KVCache 长度为 4989。

对于 decode 任务，其输出吞吐约为 14.8k tokens/s。

以上统计包括了网页、APP 和 API 的所有负载。如果所有 tokens 都按照 DeepSeek R1 的定价来计算，DeepSeek R1 的定价是：$0.14 / 百万输入 tokens（缓存命中），$0.55 / 百万输入 tokens（缓存未命中），$2.19 / 百万输出 tokens。实际上我们没有这么多收入，因为 V3 的定价更低，而且收费服务只占一部分，另外夜间还有折扣。理论上一天的总收入为 562027 美元，成本利润率为 545%。