DeepSeek 开源 DeepInfer：一天 155 兆 token 的推理生意经

事件时间：2026-10-20（PyTorch Conf 首日官宣）｜本文解读基于 10-20 ~ 10-21 的官方披露与三方工程分析

这不是一篇"发布了什么"的快讯。它值得读，是因为 DeepSeek 把自家生产推理栈的"省钱方法"摊开成了一份可核对的工程报告：155 兆 token/天的服务量、96% 的输入缓存命中率、每加速卡小时 38 美元的营收——以及，这些大数字背后有哪些会计口径与未交出的部分。推理成本的军备竞赛，第一次被写成了一张能对账的账本。

一、交出来的，和没交出来的：开源范围的边界

10 月 20 日，DeepSeek 在 GitHub 留下 DeepInfer 的初始提交，以 Apache-2.0 协议开源了自家的生产推理框架。它支撑着 DeepSeek-V4.1-Flash 的大规模在线服务，现阶段明确支持的模型只有 V4.1-Flash，硬件目标写明两条路：NVIDIA SM100 GPU 与华为 Ascend 950 NPU。

开源包里含金量最高的，是它承认的技术脉络：DeepInfer 最初主要建立在 vLLM 之上，并致谢了 SGLang 与 TensorRT-LLM。换句话说，这不是一套从石头里蹦出来的系统，而是一次"我们拿开源社区的框架，加上自家模型和硬件配置，改造成了生产形态"的回赠。底层的 FlashMLA、DeepGEMM、DeepEP、TileKernels 等加速组件（此前已陆续开源）与上层的调度引擎拼到一起，第一次让外界能完整研究"能力如何被送到用户手上"。

但"完全开源"不等于"完整服务可复现"。README 白纸黑字列出三项未随本次发布提供的部分：完整的 KV 缓存系统、视觉编码 / Prefill / Decode 的分离部署，以及 Prefill、Decode 跨数据并行副本的负载均衡。需要注意两个易读错的细节：第一，缺的是"完整 KV 缓存系统"，不是引擎完全不用缓存；第二，缺的是服务副本层面的路由，模型内部的专家平行负载均衡（EPLB）已经在公开功能清单里。两者管的是不同层次。

二、155 兆 token/天、96% 缓存命中：大数字的账本读法

DeepSeek 随开源同步披露的运营数据相当抓眼：单一集群每天服务约 155 兆（155 trillion）token；输入缓存命中率 96%；平均首 token 时间 400 毫秒；生成速度 230 token/秒，代码场景达 300 token/秒；按离峰 API 价格折算，每加速卡小时营收约 38 美元。

海外工程圈有人顺手算了一笔账：卡的全部成本按每小时 5~8 美元计，这意味着超过 80% 的推理毛利，投资回收期约 81 天——而 DeepSeek 自己历来规划的硬件回本周期是 10 个月。这个"155 兆 token/天"的 headline 也被换算成每 GW 约 1660 亿美元的年营收当量。标题党式的《一天赚 2200 万美元》就这么来的。

但读账本要先看分母。155 兆"服务 token"不等于 155 兆"新产生 token"：96% 的缓存命中意味着绝大多数输入 token 只是命中了缓存前缀，而非重新计算。缓存命中的 token 与新算的 prefill、新生成的 decode，在成本上是完全不同的东西。营收也不等于利润——推算利润还需要硬件折旧、电力、网络、存储与运维支出。这些是官方自述的运营指标，没有独立审计，引用时必须标明来源与语境。

三、缓存才是主角：100 PiB 的 SSD 与"只重播 128 个 token"

把账本拆开看，DeepInfer 的全部设计几乎都围绕一件事：让 agent 时代重复发送的上下文不再重复付费。agent 会把不断增长的指令、仓库内容、工具输出和历史回复反复发给模型，这正是缓存最能发挥的地方。

持久化的块级 KV 缓存住在一个独立的 3FS 存储集群里，约 100 PiB 的 SSD 容量。保留策略是：agent 流量保留 3 天，聊天流量保留 7 天。任何 prefill 工作节点都能从共享存储取回缓存前缀——缓存局部性与计算位置解耦，存储和计算可以独立扩缩容。代价是显式的：有工程分析指出，把保留期拉长，换来的额外缓存命中只有约 0.5~1 个百分点，是典型的存储容量 vs 重算成本的权衡。

更巧的是滑动窗口注意力的处理：它的状态生命周期短，只放主机内存而不进 SSD；缺失的那部分短命状态，用 SWA Bounded Replay 从最近的 128 个 token 重建——只对这段做注意力、复用持久块缓存，DeepSeek 称这几乎把总 prefill 计算量砍掉一半。当然，这是一个近似，不是把完整历史重建一遍；它在别的模型架构上是否成立，还要单独验证。

四、调度的手术刀：分离部署、专家平行与自适应推测解码

DeepInfer 的部署设计把视觉编码、Prefill、Decode 拆成三个阶段各自扩缩：prefill 推荐用普通的 8 卡机器，decode 则用 64~128 卡的超级节点并拉宽专家平行。理由很直白——读长输入和接续吐字是两种完全不同的工作，前者瓶颈在计算，后者瓶颈在显存访问，分开配置才能各自调优；但拆分之后，缓存传输、路由与故障恢复就成了新的工程负担，分离本身不是提速保证。

调度细节里有几处"生产味道"很浓的设计：prefill 按注意力计算成本的估算来分配工作，而不是只看请求长度；因为缓存前缀放在共享存储里，prefill 路由不需要缓存亲和性——请求可以去任何空闲节点。decode 路由则同时看运行请求数和 KV 缓存总长度：前者近似调度压力，后者捕捉请求数看不见的内存压力。热门专家会被复制分摊（定期重分布），代价是多占 HBM，收益递减，复制因子因负载而异。

推测解码用的是自适应版本 DSpark：它预测草稿 token 的接受概率，动态调整验证长度，官方称比"永远验证 5 个草稿 token"的固定策略再提升 6% 吞吐——注意，这是相对一个特定的推测解码基线，不是相对不做推测解码。还有一个耐人寻味的观察：披露的 Blackwell 配置里似乎没有用张量并行，有评论者认为这可以追溯到 DeepSeek V3 时代 H800 互联受限的遗产，但这只是对配置的解读，不是"张量并行不行"的证据。

五、行业回声：vLLM 的 6%、OpenAI 的 12 小时，与三张成绩单

开源 48 小时内，行业给出了两种回应。vLLM 团队的回应最实在：承认 DeepInfer 起初主要基于 vLLM，然后在 GB200 上用匹配配置复现，decode 吞吐与 DeepInfer 公布结果差距在 6% 以内，并公开了复现配方。这实质上限定了一个争论——“DeepSeek 的效率是不是开源引擎够不到的”，现在有了可比的基准证据。

另一个巧合是时机：OpenAI 几乎同时把 API prompt 缓存从默认 30 分钟延长到 12 小时（含混合保留时长）。两家产品架构不同，但目标一致——服务那些隔很久还会复用上下文的持久 agent。“缓存军备赛"已经开哨。

那么这份开源到底该怎么验收？中文技术分析给出了一个干净的框架：第一张是"范围单”——固定代码提交、模型版本、硬件与启用功能，逐一标明公开引擎提供什么、自己要补什么，尤其把引擎内部 EPLB 和服务副本路由分开；第二张是"品质与等待单"——用同一批代表性请求，记录答案是否合格、端到端首字等待、字间延迟，保留冷热缓存与失败重试；第三张是"完整成本单"——计入实际占用的计算、存储、网络与运维，再除以合格完成的工作。先留下一组可对照的基准，再谈要不要搬——这比替开源消息喊一个尚未量过的降本百分比有用得多。

一句话总结：DeepInfer 把一部分大型推理服务的方法变成了可检查、可重用的工程资产。它最值得期待的成果，不是今天的热搜，而是别的团队能在自己的服务门槛内，交付同样可靠、成本更清楚的工作。

原文与延伸阅读

说明：155 兆 token/天、96% 缓存命中、每卡小时 38 美元等运营数据为 DeepSeek 官方自述，尚未经独立审计；文中引用分析观点已注明为第三方解读。

每日科技要文 · 2026-10-22