DeepSeek一天的盈利揭秘：官方全面解析V3/R1推理系统成本透明化

DeepSeek 官方表示，如果所有tokens均按DeepSeek R1的定价计算，理论上一天的总收入可以达到$562,027，成本利润率为545%。然而，实际收入并未达到此金额，因为V3的定价较低，且收费服务只占一部分，此外，夜间也会提供折扣。

这一切来得异常突然！原来DeepSeek也有「One More Thing」。

就在许多人以为DeepSeek 预告的开源活动已经进行到第5天时，今日中午12点11分，官方的𝕏账号再次发文，宣布「开源周」依然持续。然而，在这第六天，DeepSeek并未推出新的软件库，而是介绍了DeepSeek-V3/R1的推理系统。

详细概述请访问：https://github.com/deepseek-ai/open-infra-index/blob/main/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md

DeepSeek的推文中指出，DeepSeek-V3/R1推理系统利用跨节点的专家并行（EP）策略实现批量扩展，并通过计算与通信的重叠和负载均衡来优化吞吐量和延迟。此外，DeepSeek还提供了其在线服务的统计数据：

• 每个H800节点实现了 73.7k/14.8k的每秒输入/输出token；
• （理论上）成本利润率高达545%。

DeepSeek表示：“我们希望本周的洞见能够为社区带来价值，并为我们共同的AGI目标贡献力量。”

一时间，社区的热议再度升温，这不仅因为原本承诺的5天开源活动延长至第6天，且还因为73.7k、14.8k、和545%这三个惊人数据，大家尤其期待明天——也就是开源周的最后一天，DeepSeek将以何种方式进行压轴表演。


系统设计原则

为实现更高的吞吐量和更低的延迟，DeepSeek采用了跨节点专家并行（EP）策略。

首先，EP显著提升了batch的大小，从而提高了GPU矩阵计算的效率并增加了系统的吞吐量。

其次，EP将专家分布到多个GPU上，每个GPU仅处理较小部分的专家，这一方式降低了内存访问需求，因此降低了延迟。

然而，EP的实施也增加了系统的复杂性，主要体现在以下两个方面：

• EP引入了跨节点通信。为了优化吞吐量，必须合理设计计算工作流，以便计算与通信能够重叠进行。
• EP涉及多个节点，因此本质上需要实现数据并行（DP），同时在不同的DP实例之间进行负载均衡。

为此，该项目重点开发了以下应对策略：

• 利用EP扩展batch的大小；
• 隐藏计算过程中的通信延迟；
• 实施负载均衡。

大规模跨节点专家并行（EP）

鉴于DeepSeek-V3/R1中专家数量庞大——每层256个专家中仅激活8个——模型呈现出高度稀疏性，这要求总batch大小极大，以确保每个专家都能优化其性能，进而实现较高的吞吐量和低延迟，因此大规模跨节点EP至关重要。

DeepSeek采用了一种预填充-解码分解架构，因此在预填充和解码阶段的并行性程度各不相同：

• 预填充阶段 [路由专家EP32、MLA/共享专家DP32]：每个单元跨越4个节点，具备32个冗余路由专家，每个GPU处理9个路由专家及1个共享专家。
• 解码阶段 [路由专家EP144、MLA/共享专家DP144]：每个单元跨越18个节点，具备32个冗余路由专家，每个GPU管理2个路由专家和1个共享专家。

计算 – 通信重叠

大规模跨节点EP会引发显著的通信开销。为应对这一难题，DeepSeek采用了“双批次”重叠策略，通过将单个batch请求拆分为两个微批次来隐藏通信成本并提升总体吞吐量。于预填充阶段，这两个微批次交替执行，使得一个微批次中的通信开销可以在另一个微批次的计算中得到弥补。

                                       ^{预填充阶段的通信-计算重叠}

在解码阶段，由于不同阶段的执行时间不均衡，DeepSeek将注意力层细分为两个步骤，并通过5阶段的管道实现无缝的通信-计算重叠。

                                      ^{解码阶段的通信-计算重叠}

有关通信-计算重叠机制的更多细节，可参考：https://github.com/deepseek-ai/profile-data

实现最优负载平衡

大规模并行化（包括DP和EP）面临一个关键难题：若单个GPU的计算或通信负载过重，便会成为性能瓶颈，导致整个系统的速度减缓，同时其他GPU处于闲置状态。为最大化资源利用率，DeepSeek致力于在所有GPU上实现计算与通信的负载平衡。tion>

• 实现 GPU 之间的核心注意力计算负载平衡。
• 确保每个 GPU 的输入 token 数量均衡（调度发送负载平衡），以防止单个 GPU 上处理时间过长。

2. 解码负载均衡器
核心问题：因 DP 实例间请求数量和序列长度分布不均，导致核心注意力计算（与 KV 缓存使用量相关）及调度发送负载的不平衡。
优化目标：

• 实现 GPU 之间 KV 缓存使用率的负载平衡。
• 确保每个 GPU 的请求数量均衡，以优化调度发送的负载。

3. 专家并行负载均衡器
核心问题：对于所选的 MoE 模型，存在某些高负载专家，导致不同 GPU 之间专家计算工作负载的不均衡。
优化目标：在每个 GPU 上实现专家计算的负载平衡，即最小化所有 GPU 上的最大调度接收负载。
DeepSeek 在线推理系统示意图 ^{DeepSeek 在线推理系统示意图}
DeepSeek 在线服务统计
所有 DeepSeek-V3/R1 推理服务均在 H800 GPU 上运行，确保精度与训练一致。在具体实施中，矩阵乘法和分发传输使用与训练相同的 FP8 格式，而核心 MLA 计算及组合传输则使用 BF16 格式，以优化服务性能。
鉴于白天服务负载较高，而夜间负载较低，DeepSeek 采取了一项机制，在高峰时段于所有节点上部署推理服务。在低负载的夜间，减少推理节点，并将资源重新分配到研究和训练中。在过去 24 小时内（北京时间 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00），V3 和 R1 推理业务的合并峰值节点数达 278，平均节点占用为 226.75（每个节点包含 8 个 H800 GPU）。假设每小时租赁一个 H800 GPU 的成本为 2 美元，则每日总成本预计为 87,072 美元（约合人民币 63.4 万）。  ^{H800 推理服务节点数量。}
在此24小时统计期间（北京时间 2025 年 2 月 27 日中午 12:00 至 2025 年 2 月 28 日中午 12:00），V3 和 R1 的表现如下：

• 总输入 token 数为 608B，其中 342B token（56.3%）命中磁盘 KV 缓存。
• 总输出 token 数为 168B，平均输出速度为每秒 20-22 个 token，每个输出 token 的平均 KV 缓存长度为 4,989 个 token。
• 每个 H800 节点在预填充阶段的平均吞吐量约为 73.7k tokens/s 输入（包括缓存命中），而在解码期间为约 14.8k tokens/s 输出。

以上统计数据涵盖来自网页、APP 和 API 的所有用户请求。如果所有 token 都按 DeepSeek-R1 的定价 (*) 收费，则每日总收入可达 562,027 美元，成本利润率为 545%。
(*) R1 定价：0.14 美元 / 百万输入 token（缓存命中），0.55 美元 / 百万输入 token（缓存未命中），2.19 美元 / 百万输出 token。
然而，DeepSeek 表示实际收入远低于此预期，原因如下：

• DeepSeek-V3 的定价较 R1 有显著降低；
• 仅部分服务实现了货币化（网页和 APP 访问仍然免费）；
• 在非高峰时段自动实施夜间折扣。

明天是本周的最后一天，期待 DeepSeek 是否会带来新的惊喜。