DeepSeek 开源了引擎，没开源它的低价

DeepSeek 线上服务用的推理引擎第一次公开了，它省算力的办法从今天起可以逐行核对。

10 月 20 日中午 12 点 09 分，GitHub 上的 DeepInfer 仓库 出现了第一个提交，提交说明只有两个词：initial commit。下午 5 点整，在 DeepSeek 产品部门工作的 Tianyi Cui 在 X 上发帖（8 分钟后又编辑过一次），说 DeepSeek 以 Apache-2.0 许可证开源了「高性能、大规模推理框架」，后面列了八项功能，从优化算子、注意力数据并行、专家并行负载均衡，一直到确定性采样和结构化输出。这份清单和 DeepInfer 仓库 README 的功能列表几乎逐字相同。5 点 06 分，仓库的提交者又补传了一份中文 PDF，题为《DeepSeek V4.1 Flash 推理部署 Q&A》。

我们的看法是：这次交出来的是一台引擎，不是一套推理服务。DeepInfer 把单个推理实例怎么少花算力写得很透；而 DeepSeek 自己在部署问答里讲的那些决定线上成本的部件，包括能把缓存保留三天以上的存储集群、预填与解码分开部署、跨实例的负载均衡，这次都没有放出来。对想复刻 DeepSeek 低价的人来说，拿到的是一半。

仓库里有什么

我们把仓库克隆下来读了一遍。截至北京时间 10 月 20 日 17 时半，它只有两个提交，约 2100 个星标；主包 deepinfer 约 4.6 万行 Python，csrc 目录约 5900 行 C++，另有 16 个测试文件；算子库 FlashMLA、DeepGEMM、DeepEP、DeepSelect 以子模块形式引入，昇腾版本的 DeepEP 和 DeepGEMM 单独列出。

DeepInfer 仓库 README 写得很克制：这次开源的是离线推理，只支持一个模型 DeepSeek-V4.1-Flash，硬件只支持英伟达 SM100 架构的 GPU 和华为昇腾 950。README 还专门列了一段「完整推理服务需要、但本次不包含」的部件：KV 缓存系统、视觉编码与预填、解码的分离部署（括号里说其中多数引擎功能已经实现）、数据并行副本之间的负载均衡。代码印证了这一点，deepinfer/entrypoints 目录下只有一个 llm.py，提供的是一次性喂入一批提示词、拿回结果的 LLM 类，没有对外的 HTTP 服务。这个类的文件头写着「Derived from vLLM; modified by DeepSeek」，README 的致谢里也说，DeepInfer 最初主要建在 vLLM 之上，并参考了 SGLang 和 TensorRT-LLM。

引擎里真正新的几样东西

读下来，有四处机制值得单独说，因为它们回答的都是同一个问题：一张卡在一秒里能多吐出几个词元。

第一处是投机解码的「按置信度验证」，帖子里叫 DSpark。草稿模型一次猜 5 个词元，主模型再逐个验证；以往的做法是 5 个全验。DeepInfer 给草稿模型加了一个置信度输出，预测每个草稿词元被接受的概率，再由 GPU 上的一个 TileLang 算子把这一步的验证预算按累乘概率分给各个请求（见 schedule_mtp_varlen.py 里的 compute_seqlens_q_by_confidence_rates）。据 DeepInfer 部署问答，这样每步要验证的草稿词元从 5 个降到 3.2 到 4.4 个，平均被接受的长度几乎不变（3.29 对 3.20），在每个计算分片约 60 个并发的生产运行点，吞吐多出 4% 到 7%（企业宣称）。值得注意的是，按 DeepInfer 环境变量定义，这个功能的开关 DEEPINFER_ENABLE_MTP_VARLEN 默认是关的，要手动打开。

第二处是 README 里的「SWA bounded replay」。V4.1 Flash 的结构是编码器加解码器，解码器层有一段滑动窗口注意力的缓存需要自己算。部署问答说，精确重建要在 20 个解码器层上把最后 2560 个词元都跑一遍，DeepInfer 改成只重算提示词末尾的 128 个词元，代价由此变成与上下文长度无关的常数，「总 prefill 计算量近乎减半」（企业宣称）。这个开关在 DeepInfer 环境变量定义里同样默认关闭，README 给了推荐值：模式设为 compact，保留 140 个词元。

第三处是异步调度。解码的每一步，CPU 要排下一批请求、处理上一批的输出，过去这段时间 GPU 在空等。DeepInfer 让 CPU 在 GPU 跑第 N 步时就排好第 N+1 步，默认开启。代码里有一个细节能看出他们对「零开销」的认真程度：deepinfer/utils.py 的 forbid_cuda_sync 会在模型前向和采样启动期间，把 PyTorch 能察觉到的 CPU 与 GPU 同步直接变成报错，而且配了专门的测试。

第四处是「批次不变」和确定性采样：同样的输入，不管和哪些请求拼在一批，输出都一样。这对需要复现结果的评测和对账有用。但它只在英伟达上可用，runtime_config.py 里写着，在昇腾上打开就会直接断言失败，注释是「待完整支持后移除」。结构化输出则建在开源库 xgrammar 之上，不是自研。

官方性能图该怎么读

DeepInfer 仓库 README 放了两张图。预填阶段在 4 张卡上测，每批 65536 个词元时，每卡每秒处理约 8.9 万个未命中缓存的输入词元，一步耗时约 0.73 秒；解码阶段在 64 张卡上测，每个分片 256 个并发时每卡每秒输出约 2.6 万个词元，此时单个用户每秒约 100 个词元，并发降到 32 时单用户速度接近每秒 300 个，每卡吞吐降到约 9500。

这两张图是理想条件下的上限。DeepInfer 基准脚本在启动前写死了 DEEPINFER_FORCE_LOAD_BALANCE=1，让专家之间的负载强制均衡；DeepInfer 出图脚本则显示，解码图的纵轴是实测每秒步数乘以一个系数 τ，τ 等于 1 加上草稿长度乘以接受率，而这个接受率是出图时传进去的参数，图上写的是 75%，草稿长度固定为 3，按置信度验证没有打开。也就是说，图上的解码吞吐是实测步速乘以一个由假设接受率算出的 3.25 倍系数。

这些不是隐瞒，脚本里都写着，DeepInfer 部署问答也给了对照：做完负载均衡后的线上系统，「大概能达到完全均衡的离线 benchmark 的 80%」。75% 的接受率换算成平均每步接受 3.25 个词元，与问答给出的平均接受长度 3.2 到 3.3 接近，虽然那组数字是在草稿长度 5 的设置下得到的。对按卡时算账的人来说，结论很具体：拿这两张图估自家单卡产出，按 DeepSeek 自己给的比例，大约要打八折。

账本上的另一半

DeepSeek 自己把成本账的另一半写在了 DeepInfer 部署问答里。它说推理系统从设计之初定了三个目标，其中一条是 KV 缓存保留 72 小时以上，让重复的上下文不必重新预填。实现方式是独立的存储集群：KV 缓存以 10+2 纠删码存放在 3FS 分布式文件系统上，总共约 100 PiB 固态盘，智能体流量的缓存保留 3 天，聊天流量保留 7 天；推荐每台存储服务器配 20 块 30.73 TB 的固态盘。负载均衡分预填、解码、视觉编码三套，预填按上下文长度分四档派单。问答同时说明，KV 缓存管理与负载均衡因为与内部基础设施耦合较深，代码「目前尚未完整开源」。

缓存为什么是账本的另一半？DeepSeek 官网 9 月发布 V4.1 Flash 时写道，在智能体场景里，缓存命中的费用往往占比较高。我们此前在《DeepSeek 新 Flash：该记住的是每题 0.2 美元》里写过，每题成本取决于框架、推理档位、缓存命中和计费时段。缓存命中这一项，正是 DeepInfer 这次没有带上的部分：引擎能读入缓存，却不带那套让缓存保留三天的存储与调度。

门槛也写在明处。部署问答说，预填和解码需要的卡大致 1:1，解码推荐专家并行 64 以上，所以「效率高的最小部署单元是 64 卡 P + 64 卡 D」。DeepSeek 官网在 V4.1 Flash 发布时的说法更直接：有大规模部署需求、具备 2000 张 GPU 和存储集群的，欢迎联系。

问答里最引人注意的一句是：单一集群的服务吞吐每天 155 万亿词元，整体收入是每卡每小时 38 美元，按「谷价」计。DeepSeek 官网写明 API 采用峰谷定价、闲时价格为高峰的一半，据此谷价应指闲时价。这是企业宣称，没有给出集群卡数、成本和利润率，所以无法由此倒推单词元成本，只能说明 DeepSeek 愿意把收入口径放在卡时上谈。

帖子说对了什么，没说什么

Tianyi Cui 帖子列的八项功能在代码里都找得到对应实现，Apache-2.0 许可证也属实。帖子没有提的是同一份 README 里的限定：这次是离线推理；完整服务所需的三块部件不在其中；只支持一个模型；硬件只有 SM100 和昇腾 950；按置信度验证和 bounded replay 默认关闭；批次不变与确定性采样只限英伟达。帖子和 README 标题都把它称作「大规模推理框架」，引擎本身确实是为大规模部署写的，但让它「大规模」运转的那部分没有随这次开源放出。另外，帖子作者的简介写明他在 DeepSeek 工作，这条帖子应按企业表述来读。

据 IT之家 报道，DeepSeek 同时开源了 Token 编解码组件 deepseek-recipe，称其处理逻辑与官方 API 完整对齐，并表示新模型的推理代码和后续优化会持续在 DeepInfer 更新。

最强反方

最有力的反驳是：缺的那一半并不神秘，也不难补。存储底座 3FS 文件系统 DeepSeek 早已开源（见 3FS 仓库），DeepInfer 部署问答又把存储配比、纠删码、保留时长、负载均衡的分档与派单规则写到了参数级；README 也说分离部署所需的引擎功能多数已经实现。真正难、只有 DeepSeek 能做的，是让新模型结构在 SM100 和昇腾上跑出这个效率的算子与运行时，而这部分已经基本公开。按这个逻辑，有能力部署 128 卡起步集群的团队，完全可以照着问答把另一半搭出来。

我们部分让步：对已经有存储集群和调度系统的大型云厂商，缺的确实是工程量而不是秘密，DeepInfer 加上问答已经足够起步。我们坚持的是成本这一层：三天保留期、八成均衡度、每卡每小时 38 美元，都是在 DeepSeek 自己的流量和调度上跑出来的数字，第三方用同一台引擎、不同的存储和派单，得到的会是另一条曲线。在有第三方用 DeepInfer 公布带卡数与缓存命中率口径的实测之前，「开源了就能做到 DeepSeek 的价格」不能当结论。何况就连引擎本身，问答也承认开源版与内部版不完全相同：开源的 FlashMLA 少了一处直接改写 SASS 汇编的优化，解码算子慢 5% 到 10%，端到端最多差 5%；草稿模型内部版本也更新一些，只是性能差别不大。

我们不知道什么

• 负载均衡和 KV 缓存管理还要多久完整开源，问答只说「目前尚未」，没有时间表。
• 155 万亿词元每天对应多少张卡、什么卡型，问答没有写，单词元成本因此算不出来。
• 线上实际的草稿接受率分布，以及按置信度验证在昇腾上的收益，公开材料没有数字。
• 除 DeepSeek 自己的基准外，目前还没有第三方在 SM100 或昇腾 950 上用 DeepInfer 跑出的公开结果。

接下来看什么

一是 DeepInfer 仓库里负载均衡或缓存相关代码是否陆续补上；二是有没有云厂商用它上线 V4.1 Flash，并给出每卡吞吐与缓存命中率；三是昇腾 950 上的批次不变是否补齐，这决定国产卡上的部署能否做到与英伟达一样可复现。

这次 DeepSeek 把引擎的图纸摊开了，读得懂的人会发现，便宜的秘密有一半在图纸之外：缓存在哪里放、放多久、请求派给谁。