DeepSeek公布成本、收入和利润率！最高可日赚346万
作者 | 程茜
编辑 | 心缘
智东西 3 月 1 日消息，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/deepseek-ai/open-infra-index/blob/main/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md
一、每日总成本为 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 美元。
▲推理服务的 H800 节点计数
在 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；网页端和应用程序免费，所有只有一部分服务被货币化；夜间折扣在非高峰时段自动适用。
▲成本和理论收入
二、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 接收量的最大值）。
▲ DeepSeek 在线推理系统图
