往时一周，DeepSeek 领路通达了 5 个 Infra 姿色的源代码，方正全球认为这场开源盛宴照旧收尾。
刚刚，DeepSeek 的彩蛋来了！开源周 Day6，DeepSeek 官方团队在 Github 和知乎给出了 DeepSeek-V3 / R1 推理系统的本事解读。
先说论断：通过优化模糊和延伸，DeepSeek「表面上一天的总收入为 $562,027，资本利润率 545%。」
骄慢的网友——如 MenloVentures 投资东谈主 Deedy 翻译了这意味着什么：「表面 ARR 2 亿好意思金、利润率超过 500%，这样的交易效用理当是一家值 100 亿好意思金的公司。」
从 2024 年 5 月发布 DeepSeekV2 以来，DeepSeek 模子处事就以「价钱屠户」示众，老是比行业其他模子低廉 1/10 傍边，质疑 DeepSeek 亏损打价钱战的声息也一直有。
通过这 5 天通达源代码以及今天的推理系统详细，这一疑虑也被拔除，不错预想，模子推理价钱越来越背负得起，且处事提供方也有得赚。这一事件的影响也不错通过 X 平台网友展现出刷屏的惊喜得以一窥，「资本利润率 545%，便是说你是在告诉我，我被 Open AI 劫掠了？开源周 Day7 的彩蛋是 AGI？」
但更大的信号指向生态伙伴，部署 DeepSeek 有得赚。
一位 AI 领域的投资东谈主向极客公园发扬，「官方本事解读标明，云平台和高低游通过部署 DeepSeek 的处事，表面上收益和利润率不错达到很高」。不论是对于提供在线推理、照旧专有化部署等处事的供应商，皆是利好。
在这波 DeepSeek 热中受益的云平台硅基流动首创东谈主袁进辉也在第一时分发表了我方的感受，「DeepSeek 官方线路大规模部署资本和收益，又一次颠覆了好多东谈主融会。」
但需要时分适配 DeepSeek V3/R1 模子架构，他示意「当今好多供应商还作念不到这个水平，主如若 V3/R1 架构和其它主流模子辞别太大了，由无数小 Expert 构成，导致对准其它主流模子结构开辟的系统皆不再有用，必须按照 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，怎样荫藏传输的耗时，怎样进行负载平衡。
01 大规模跨节点群众并行（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 个分享群众
02 筹备通讯类似
多机多卡的群众并行会引入比拟大的通讯支拨，是以咱们使用了双 batch 类似来掩饰通讯支拨，擢升合座模糊。
对于 prefill 阶段，两个 batch 的筹备和通讯交错进行，一个 batch 在进行筹备的时候不错去掩饰另一个 batch 的通讯支拨；
Prefill 阶段的双 batch 类似
对于 decode 阶段，不同阶段的实行时分有所辞别，是以咱们把 attention 部分拆成了两个 stage，测度 5 个 stage 的活水线来杀青筹备和通讯的类似。
Decode 阶段的双 batch 类似
对于更多双 batch 类似的细节，不错参考咱们的 profiling 数据的 GitHub 仓库：https://github.com/deepseek-ai/profile-data。
03 尽可能地负载平衡
由于选择了很大规模的并行（包括数据并行和群众并行），如果某个 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 禁受量的最大值）
04 参考架构图
05 线上系统的骨子统计数据
DeepSeek V3 和 R1 的通盘处事均使用 H800 GPU，使用和测验一致的精度，即矩阵筹备和 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 的订价 ( [ 1 ] ) 筹备，表面上一天的总收入为 $562,027，资本利润率 545%。
「虽然咱们骨子上莫得这样多收入，因为 V3 的订价更低，同期收费处事只占了一部分，另外夜间还会有扣头。」
参考
^DeepSeek R1 的订价：$0.14 / 百万输入 tokens ( 缓存射中 ) ，$0.55 / 百万输入 tokens ( 缓存未射中 ) 体育游戏app平台，$2.19 / 百万输出 tokens。