DeepSeek 开源 DeepInfer：155 万亿 Token 吞吐与 82% 利润估算怎么理解

DeepSeek DeepInfer 开源推理框架与算力效率

DeepSeek 将支撑其模型推理的框架 DeepInfer 和消息编解码组件 deepseek-recipe 开源了。对开发者来说，这次值得看的，是模型上线之后，如何把昂贵的 GPU 用得更充分。

官方披露，单个推理集群每天处理 155 万亿 Token；按谷价 API 定价口径核算，收入约为 每 GPU 小时 38 美元。这些数字见 DeepSeek 官方部署问答。

随之流传的“82% 毛利率”，则是第三方在假定 GPU 租金基础上的估算。理解这次开源，先把吞吐、收入和成本这三件事分开看。

DeepInfer 和 deepseek-recipe 分别做什么

可以把模型服务想成一家餐厅：模型权重是厨师，推理框架负责安排订单、调度工位，让设备尽量少空转。

DeepInfer 负责推理执行，目前支持 DeepSeek V4.1 Flash。它将算子、并行策略、调度和推测解码等工程能力组合起来。对普通用户，这些名字有些远；对运营大规模模型服务的团队，每少一次等待、少一段通信，都可能影响整套服务的成本。

另一个组件 deepseek-recipe 负责消息格式、提示词与 Token 之间的转换，并提供输出解析能力。它采用 Rust 实现，带有 Python 绑定，方便服务接入不同接口格式。

例如，一个工具调用请求需要先转换成模型能处理的输入，模型生成结果后，再还原成调用方能理解的消息。编解码组件就负责这段衔接。推理、工具执行和 HTTP 服务仍要由调用方提供。

两者可以分别使用：DeepInfer 采用 Apache 2.0 许可，deepseek-recipe 采用 MIT 许可。具体能力和接口见 DeepInfer 仓库与 deepseek-recipe 仓库。

从用户请求到模型推理与输出解析的处理流程示意

处理流程示意，帮助理解组件分工；不代表完整的生产部署拓扑。

155 万亿 Token 是官方披露的单集群日处理量。只知道总量，还不能计算单卡吞吐：需要同时知道 GPU 数量、请求长度、输入输出比例、缓存命中和服务延迟要求。

38 美元则是按谷价 API 定价口径计算的每 GPU 小时收入。它不能直接等同于利润，也不应解读成“只有非高峰时段才能达到的收入”。

“82%”的算法更容易说明。Yuchen Jin 的讨论以租用 B300 每 GPU 小时 7 美元为假设，对照上述 38 美元收入：

（38 − 7）÷ 38 ≈ 81.6%。

这说明在这组假设下，收入减去 GPU 租金后，还有约 82% 的差额比例。

但实际用卡、采购或租赁方式，以及网络、存储、人员等费用，都影响完整成本。它也没有给出整个公司收支。因此，不能把这个估算写成 DeepSeek 官方披露的公司毛利率，更不能写成净利率。

即便如此，这组数据仍然有讨论价值：同样一小时的算力，能完成多少有收入的请求，比单纯比较买了多少卡更接近推理服务的经济账。

DeepInfer 使用的 FlashMLA、DeepGEMM、DeepEP 等组件，解决的是推理执行中的具体效率问题。算子再快，如果请求分配不均，或者 CPU 和 GPU 相互等待，系统仍会浪费时间。

MoE 模型还会遇到专家负载不均：部分专家繁忙，其他专家空闲，整体速度却要受最慢的一环影响。DeepInfer 的专家并行与 EPLB 就涉及这类调配问题。

异步调度的目标，是让 CPU 侧的批次准备与设备执行尽量重叠。DSpark 推测解码则尝试提高生成效率。它们的实际收益，需要放在具体硬件和请求负载下测量，不能由组件名单直接推导出某个固定加速倍数。

我的理解是，这次开源提供了一组可研究的工程实现。对有集群的团队，价值在于找出自己的瓶颈，再判断哪些设计能迁移到现有系统。

按当前仓库说明，DeepInfer 支持 NVIDIA SM100 系列和华为昇腾 950。运行环境要求包括 Linux、GCC 13 或以上、Python 3.12；对应后端分别需要 CUDA 13 或 CANN 9.2。

这些要求意味着，它面向的是配备相应硬件的团队。普通笔记本用户不适合把它当作下载即用的本地聊天工具。

同时，“支持两种硬件平台”不等于两种平台已经公布了相同的吞吐、延迟或成本。部署决策仍需要针对目标硬件进行验证。

更关键的是，当前开源版本提供核心能力的离线推理，并未开放完整的线上服务基础设施。 官方列出的未完整开放部分包括 KV 缓存管理系统，以及与内部基础设施紧密耦合的服务调度能力。具体边界以 README 的开源范围说明为准。

所以，能跑通模型和能稳定对外提供 API，是两段工作。准备接入的团队还需要评估缓存、限流、监控、故障恢复和服务负载，而不是只看一次离线测试结果。

对研究推理系统的人，DeepInfer 提供了观察大规模模型执行方式的窗口。对自建服务的团队，可以从具体模块入手，对照现有系统找改进机会。

对主要调用 API 的开发者，短期内仍应以实际价格、延迟、稳定性和任务成功率选型。底层效率改善有机会传导到产品成本，但什么时候降价、降多少，需要看服务方的正式政策。

我更期待它对 Agent 类应用的影响。一次任务可能包含很多轮生成和工具调用，单轮开销的小幅下降，累积起来就可能改变产品能否负担持续运行的成本。

不过，这仍是对未来的判断。这次可以确认的进展，是 DeepSeek 开放了推理框架和编解码组件，也披露了一组值得进一步检验的运行数据。