AI大模型DeepSeek日前在知乎贴文《DeepSeek-V3 / R1 推理系统概览》，DeepSeek称，在最近的 24 小时里（北京时间 2025/02/27 12:00 至 2025/02/28 12:00），DeepSeek V3 和 R1 推理服务占用节点总和，峰值占用为 278 个节点，平均占用 226.75 个节点（每个节点为 8 个 H800 GPU）。
“假定 GPU 租赁成本为 2 美金/小时，总成本为 $87,072/天。如果所有 tokens 全部按照 DeepSeek R1 的定价[1]计算，理论上一天的总收入为 $562,027（约409万元），成本利润率 545%。”
这意味着，DeepSeek理论上一天的利润为474,955美元（约350万元）。
据悉，DeepSeek R1 的定价：$0.14 / 百万输入 tokens (缓存命中)，$0.55 / 百万输入 tokens (缓存未命中)，$2.19 / 百万输出 tokens。
DeepSeek还指出，实际上没有这么多收入，因为 V3 的定价更低，同时收费服务只占了一部分，另外夜间还会有折扣。
硅基流动创始人、CEO袁进辉指出，“主要是V3/R1架构和其它主流模型差别太大了，由大量小Expert组成，导致瞄准其它主流模型结构开发的系统都不再有效，必须按照DeepSeek报告描述的方法才能达到最好的效率，而开发这样的系统难度很高，需要时间，幸好这周DeepSeek五连发已经把主要模块开源出来了，降低了社区复现的难度。”
“这些成果充分体现DeepSeek团队第一性原理思考方式和强悍的意志，他们应该是首先是基于某些原因想到了用这样的模型结构，然后发现这样的结构无论是训练还是推理，要做好都有非常大的工程挑战，这些问题在他们工程团队来说并不是搞不定的，关键是花那么大力气做完是否有大的收益呢，在最终结果出来前，谁也说不准，他们还是赌了，结果是赌对了。”
更有人评论称，怀疑DeepSeek的模型结构就是为了榨干系统和芯片的每一滴油水来设计的。
这可能让OpenAI CEO Altman（奥特曼）很不好想。外媒曾曝出，OpenAI在2024年可能面临惊人的50亿美元亏损，并可能在未来12个月内耗尽其现金储备。
DeepSeek也挑战了市场对AI、估值和高支出的叙述。
DeepSeek的高性能预算产品也“质疑未来在英伟达芯片和开发上花费数千亿美元的必要性”。
DeepSeek火爆以来，英伟达在2025年就失去了上涨的势头。
有行业人士评论称，DeepSeek这一波操作，英伟达等公司的股价可能又撑不住了。
以下是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，如何隐藏传输的耗时，如何进行负载均衡。
大规模跨节点专家并行（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 的通信开销；
对于 decode 阶段，不同阶段的执行时间有所差别，所以我们把 attention 部分拆成了两个 stage，共计 5 个 stage 的流水线来实现计算和通信的重叠。
尽可能地负载均衡
由于采用了很大规模的并行（包括数据并行和专家并行），如果某个 GPU 的计算或通信负载过重，将成为性能瓶颈，拖慢整个系统；同时其他 GPU 因为等待而空转，造成整体利用率下降。因此我们需要尽可能地为每个 GPU 分配均衡的计算负载、通信负载。
1,Prefill Load Balancer
核心问题：不同数据并行（DP）实例上的请求个数、长度不同，导致 core-attention 计算量、dispatch 发送量也不同优化目标：各 GPU 的计算量尽量相同（core-attention 计算负载均衡）、输入的 token 数量也尽量相同（dispatch 发送量负载均衡），避免部分 GPU 处理时间过长
2,Decode Load Balancer
核心问题：不同数据并行（DP）实例上的请求数量、长度不同，导致 core-attention 计算量（与 KVCache 占用量相关）、dispatch 发送量不同优化目标：各 GPU 的 KVCache 占用量尽量相同（core-attention 计算负载均衡）、请求数量尽量相同（dispatch 发送量负载均衡）
3,Expert-Parallel Load Balancer
核心问题：对于给定 MoE 模型，存在一些天然的高负载专家（expert），导致不同 GPU 的专家计算负载不均衡优化目标：每个 GPU 上的专家计算量均衡（即最小化所有 GPU 的 dispatch 接收量的最大值）
