五连开源后，DeepSeek 还有 One More Thing！
就在刚刚，DeepSeek 官方躬行揭秘了DeepSeek-V3/R1 推理系统。
重心包括，优化费解量和延伸的顺次：
跨节点 EP 启动的批量膨胀
计算与通讯类似
负载平衡
还公布了 DeepSeek 的在线就业数据统计：
每个 H800 节点每秒有 73.7k/14.8k 个输入 / 输出 token
本钱利润率 545%
更多细节，沿途来看官方原文↓
更大的费解，更低的延伸
DeepSeek-V3/R1 推理系统的优化缠绵是：更大的费解，更低的延伸。
为了收场这两个缠绵，咱们的决策是使用大领域跨节点行家并行（ExpertParallelism/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，从而收场更大的费解、更低的延时。需要大领域跨节点行家并行（Expert Parallelism/EP）。
咱们采用多机多卡间的行家并行战术来达到以下主见：
Prefill：路由行家 EP32、MLA 和分享行家 DP32，一个部署单位是 4 节点，32 个冗余路由行家，每张卡 9 个路由行家和 1 个分享行家
Decode：路由行家 EP144、MLA 和分享行家 DP144，一个部署单位是 18 节点，32 个冗余路由行家，每张卡 2 个路由行家和 1 个分享行家
计算通讯类似
多机多卡的行家并行会引入相比大的通讯支拨，是以咱们使用了双 batch 类似来遮蔽通讯支拨，晋升举座费解。
对于 prefill 阶段，两个 batch 的计算和通讯交错进行，一个 batch 在进行计算的技能不错去遮蔽另一个 batch 的通讯支拨；
△Prefill 阶段的双 batch 类似
对于 decode 阶段，不同阶段的推行技能有所死别，是以咱们把 attention 部分拆成了两个 stage，测度 5 个 stage 的活水线来收场计算和通讯的类似。
△Decode 阶段的双 batch 类似
对于更多双 batch 类似的细节，不错参考咱们的 profiling 数据的 GitHub 仓库：https://github.com/deepseek-ai/profile-data。
尽可能地负载平衡
由于采用了很大领域的并行（包括数据并行和行家并行），要是某个 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 接纳量的最大值）
参考架构图
线上系统的实际统计数据
DeepSeekV3 和 R1 的通盘就业均使用 H800 GPU，使用和磨真金不怕火一致的精度，即矩阵计算和 dispatch 传输采用和磨真金不怕火一致的 FP8 体式，core-attention 计算和 combine 传输采用和磨真金不怕火一致的 BF16，最猛进程保证了就业适度。
另外，由于日间的就业负荷高，晚上的就业负荷低，因此咱们收场了一套机制，在日间负荷高的技能，用通盘节点部署推理就业。晚上负荷低的技能，减少推理节点，以用来作念经营和磨真金不怕火。在最近的 24 小时里（北京技能 2025/02/27 12:00 至 2025/02/28 12:00），DeepSeekV3 和 R1 推理就业占用节点总和，峰值占用为 278 个节点，平均占用 226.75 个节点（每个节点为 8 个 H800 GPU）。假设 GPU 租出本钱为 2 好意思金 / 小时，总本钱为 $87,072/ 天。
在 24 小时统计时段内，DeepSeekV3 和 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 的订价 * 计算，表面上一天的总收入为 $562,027，本钱利润率 545%。
*DeepSeek R1 的订价：$0.14/ 百万输入 tokens ( 缓存掷中 ) ，$0.55/ 百万输入 tokens ( 缓存未掷中 ) ，$2.19/ 百万输出 tokens。
固然咱们实际上莫得这样多收入，因为 V3 的订价更低，同期收费就业只占了一部分，另外夜间还会有扣头。
原文运动：
[ 1 ] https://zhuanlan.zhihu.com/p/27181462601
[ 2 ] https://github.com/deepseek-ai/open-infra-index/blob/main/202502OpenSourceWeek/day_6_one_more_thing_deepseekV3R1_inference_system_overview.md九游体育app(中国)官方网站