DeepSeek开源周第六天：DeepSeek-V3 / R1 推理系统概览深度分析
deepseek的One More Thing来了
今天十二点，deepseek 带来了一个开源周的One More Thing，介绍了DeepSeek-V3 / R1 推理系统的一些信息和成本计算，你一定感兴趣。
推理系统设计原则
deepseek先介绍了推理系统的设计原则，推理系统的优化目标：更大的吞吐，更低的延迟。
参考的架构图
deepseek目前采用的方案：大规模节点专家并行
-
EP 使得 batch size 大大增加，从而提高 GPU 矩阵乘法的效率，提高吞吐。
-
EP 使得专家分散在不同的 GPU 上，每个 GPU 只需要计算很少的专家（因此更少的访存需求），从而降低延迟。
引入的复杂性：
-
EP 引入跨节点的传输。为了优化吞吐，需要设计合适的计算流程使得传输和计算可以同步进行。
-
EP 涉及多个节点，因此天然需要 Data Parallelism（DP），不同的 DP 之间需要进行负载均衡。
大规模跨节点专家并行
deepseek采用的是多机多卡的专家并行策略：
- Prefill：路由专家 EP32、MLA 和共享专家 DP32，一个部署单元是 4 节点，32 个冗余路由专家，每张卡 9 个路由专家和 1 个共享专家
- **Decode：路由专家 EP144、MLA 和共享专家 DP144，一个部署单元是 18 节点，32 个冗余路由专家，每张卡 2 个路由专家和 1 个共享专家
**
多机多卡的专家并行引入比较大的通信开销，所以使用了双 batch 重叠来掩盖通信开销，提高整体吞吐。
prefill 阶段，两个 batch 的计算和通信交错进行，一个 batch 在进行计算的时候可以去掩盖另一个 batch 的通信开销；
decode 阶段，不同阶段的执行时间有所差别，所以我们把 attention 部分拆成了两个 stage，共计 5 个 stage 的流水线来实现计算和通信的重叠。
因为使用了大规模并行（包括专家并行/数据并行）时，就存在某些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 接收量的最大值）
线上推理系统的实际统计数据
DeepSeek R1/V3所有服务都使用H800，矩阵计算和 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 美金/小时，总成本为 $87,072/天。
在 24 小时统计时段内，DeepSeek V3 和 R1：
-
输入 token 总数为 608B，其中 342B tokens（56.3%）命中 KVCache 硬盘缓存。
-
输出 token 总数为 168B。平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度是 4989。
-
平均每台 H800 的吞吐量为：对于 prefill 任务，输入吞吐约 73.7k tokens/s（含缓存命中）；对于 decode 任务，输出吞吐约 14.8k tokens/s。
以上统计包括了网页、APP 和 API 的所有负载。如果所有 tokens 全部按照 DeepSeek R1 的定价计算，理论上一天的总收入为 $562,027，成本利润率 545%。
实际上deepseek 是没有这么多收入，因为 V3 的定价更低，同时收费服务只占了一部分，另外夜间还会有折扣。
我们能得到什么信息
**
**
前段时间传的，deepseek官方部署的是320张H800的一个推理集群，目前看来应该278个节点，2224张H800的集群，官方承认至少拥有一万张H800，用来做推理的GPU真不算多。
成本： 平均226.75节点，1814张，一张卡2刀/h， 一天成本$87,072
收入: 输入：608B 输出：168B， 算下来一天收入 $562,027
那么一天毛收入：$474,955 = 日入 3457672.4 RMB
其实上面的算法是很有问题的，即使6倍利润算变成3倍，那利润率也是非常高的，国内很多厂商部署deepseek还因为亏钱关闭API服务，是时候想想问题出在哪里了。
梁文锋在接受采访的时候说过：我们只是按照自己的步调来做事，然后核算成本定价。我们的原则是不贴钱。
这其实说明deepseek目前应该是赚钱的， 而且赚的钱应该都用到继续投入研发了，期待R2尽快出来。
关注我，我们一起猛学。
往期分析文章：
参考链接：