DeepSeek 开源推理框架 DeepInfer：KVCache 存三天、投机解码少验 30% 是怎么做到的

10 月 20 日，DeepSeek 把线上跑 V4.1 Flash 的推理框架 DeepInfer 开源了，同时放出 Token 编解码组件 deepseek-recipe 和一份推理部署 Q&A。媒体标题多是「大模型普惠」，我更关心的是那份 Q&A：官方称单个集群每天服务 155 万亿 token，并把 Prefill / Decode 怎么分、KVCache 怎么存三天、投机解码怎么省验证算力都写了出来。这是继 2025 年 2 月开源周之后，DeepSeek 又一次把自己的推理系统讲得这么细。

数据以 2026 年 10 月 20 日 GitHub 仓库和官方 Q&A 为准，性能数字均为官方称，本文未实测。

一、这次开源了什么

项目	内容
发布	2026-10-20，GitHub `deepseek-ai/DeepInfer`（Apache-2.0）
一起开源	`deepseek-recipe`（MIT，Rust + Python 绑定）：API 请求与 token 之间的编解码
支持模型	目前只有 DeepSeek-V4.1-Flash（默认权重 `DeepSeek-V4.1-Flash-1017`，MIT 协议，Hugging Face 显示 763B 参数）
支持硬件	NVIDIA SM100 GPU、华为昇腾 950 NPU
环境	Linux、Python 3.12、GCC ≥ 13，CUDA 13 或 CANN 9.2
来历	README 写明最初主要基于 vLLM 构建，也参考了 SGLang、TensorRT-LLM
没开源	KVCache 系统、VE/Prefill/Decode 分离、数据并行副本间的负载均衡

最后一行很关键。官方 Q&A 原话是这两部分「因与内部基础设施耦合较深，相关代码目前尚未完整开源」。所以这次拿到的是引擎，不是整套服务系统：README 说当前版本提供的是离线推理。

二、系统长什么样

官方给推理系统定了三个目标：兼容多家芯片；用常见的 8 卡机做 Prefill、64～128 卡超节点做 Decode；KVCache 保留 72 小时以上。整体是 E/P/D 分离加独立存储：

text 复制代码

请求 ─▶ deepseek-recipe（协议 → token）
          │
          ▼
   Prefill 池  EP2~8 / DP2~8      ◀──▶  3FS 存储集群（Block KVCache，约 100 PiB SSD）
          │  KVCache 传输
          ▼
   Decode 池   EP64~128 / DP64~128（Wide-EP）
          │
          ▼
   deepseek-recipe（token → Chat Completions / Responses / Messages 流式响应）

   Vision Encoder：单卡部署，官方建议用便宜的卡

1. Prefill 小 EP，Decode 大 EP

Prefill 是算力密集型，序列长、batch 天然大，官方的原则是「显存够就用尽可能小的 EP/DP」。Decode 每步只出一个 token，瓶颈在访存，把 MoE 专家摊到 64 张以上的卡（Wide-EP），每张卡只放少量专家，单步要读的专家权重就少了。Decode 的冗余专家从每卡 1 个起步，EP64 取整后每卡共 7 个专家（不含共享专家），官方实测负载不均衡度 moe_lb（最慢 rank / 均值）= 1.090。

对比 2025 年 2 月公开的 V3/R1 推理系统：当时在 H800 上，Prefill 用 EP32（4 节点）、Decode 用 EP144（18 节点）。这次 Prefill 缩到单机 8 卡以内，Decode 也比当年的 18 节点小。模型和硬件都换了代，规模不能直接比，但方向很明显。Q&A 还提到，V4.1 大幅压缩了 KVCache，让 P、D 跨机房部署在技术上可行，大约每 8 张卡配 400Gbps 互联。

2. KVCache 放独立集群，存 3～7 天

多数推理框架把前缀缓存放在本机显存或内存里，路由时要做「前缀亲和」，把同一前缀的请求送到同一台机器，这和负载均衡天然冲突。DeepSeek 的做法是把 Block KVCache 全部放进独立的 3FS 集群：

任何 Prefill 机器都能命中任何前缀，路由只看负载，不做前缀亲和；
计算节点挂了缓存不丢（官方说计算节点故障率比存储高一个数量级以上）；
容量约 100 PiB SSD，Agent 流量 TTL 3 天，chatbot 流量 7 天，数据用 10+2 纠删码存放。

为什么 chatbot 反而存得更久？Q&A 的解释是 chatbot 的长尾命中更严重，少量 KVCache 会被读极多次，TTL 只给 3 天时命中率会掉 0.5%～1%。我猜这也是 DeepSeek API 缓存命中价能压得很低的原因之一：缓存在它这里是用 SSD 集群兜底的长期资产，不是显存里随时会被挤掉的临时数据（这是推测，官方没有把两者直接挂钩）。

3. SWA Bounded Replay：缓存缺一点，只补 128 个 token

V4.1 有滑动窗口注意力（SWA）层。SWA 的 KVCache 不进分页存储，单独存在机器内存里，只在 128 的整数倍位置落盘。如果 SWA 这部分没命中，按常规就要从头重算整段前缀。

DeepInfer 的办法是只重算最近 128 个 token，并把注意力窗口截断在重算段内，得到近似的 SWA KVCache。重算代价因此变成和上下文长度、层数都无关的常数。用在 decoder 层时，原本精确重建要 20 层跑最后 2560 个 token，现在每次 prefill 只重算 prompt 末尾 128 个，官方称总 prefill 计算量近乎减半。

这是拿一点精确度换算力：窗口内的 KV 是近似值，不是逐位一致。README 里对应的配置是 DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140。

4. 投机解码：不再固定验 5 个

DeepInfer 的投机解码叫 DSpark。草稿一次出 5 个 token，常规做法是 5 个全部送去验证。DSpark 加了一个 Confidence Head 预测每个草稿 token 被接受的概率，按硬件吞吐曲线只验「有效吞吐最大」的前缀。

官方给的数据：每步验证的草稿数从 5.00 降到 3.2～4.4，减少约 30%，平均接受长度基本不变（3.29 vs 3.20），在生产运行点（每 rank 约 60 并发）折合吞吐 +4%～7%。提升不大，但放到每天 155 万亿 token 的规模上，几个百分点也是不少卡时。

5. 其他细节

FP4：Main KV 用 per-16 e4m3，Indexer KV 和 MoE 路由专家权重用 MXFP4。
异步调度：CPU 准备第 N+1 步时 GPU 跑第 N 步，参考了 SGLang 和 Nanoflow 的做法，消掉 GPU 空等。
确定性 ：DEEPINFER_BATCH_INVARIANT=1 让结果不受同批其他请求影响，配合固定 seq_seed 可以做到同输入同输出（仅 NVIDIA）。做评测复现和回归测试的团队会需要这个。

三、官方给的性能数字

README 附了两张 Pareto 图（DeepSeek V4.1 Flash，上下文 131,072）：

阶段	配置	官方图上的读数（近似）
Prefill	4 卡 SM100，EP4DP4	每卡每秒约 6 万～9 万个未命中输入 token，单步延迟约 70～730 ms
Decode	64 卡 SM100，EP64DP64	每 rank 64 并发时约 1.57 万 token/s/卡、单用户约 246 token/s；256 并发时约 2.6 万 token/s/卡、单用户约 103 token/s

两点要打折看：

图上数字是我从官方图里读的近似值，不是表格原值。
Decode 图标注了 nextn=3、接受率 75%；但 README 说明 benchmark 脚本的 decode 吞吐按「草稿全部接受」口径计算。图用的是哪个口径没有写明，以官方后续说明为准。

Q&A 里另一个数字是「单一集群服务吞吐 155 万亿 Tokens/天，整体收入每卡每小时 38 美金（按谷价）」，也就是按非高峰价折算的收入，不是成本。卡型和卡数没有公开，目前没法据此反推单 token 成本。

四、和现有方案比

	DeepInfer	vLLM / SGLang
定位	为 DeepSeek 自家模型做到极致	通用推理框架，支持大量模型
模型	目前只有 V4.1 Flash	主流开源模型都支持
硬件	SM100、昇腾 950	覆盖面广，从消费卡到数据中心卡
完整服务	缺 KVCache 系统和负载均衡	自带在线服务和前缀缓存
价值	官方生产配置、算子和调度细节	开箱可用、社区生态

DeepInfer 不是来替代 vLLM、SGLang 的，它本来就是从 vLLM 长出来的。更现实的路径是社区把 SWA Bounded Replay、DSpark 这些做法移植回通用框架。

deepseek-recipe 倒是可以单独用：它把 Messages、Chat Completions、Responses 三种协议统一转成对话格式，pip install deepseek-recipe 即可安装。有一处细节做得很扎实：用户输入、工具返回里出现的角色标记、图片标记这类特殊字符串，会被编码成普通 token；模型自己用普通 token 拼出 </think> 也不会触发结束思考。这等于在 tokenizer 层堵住了 special token 注入。

五、谁用得上，坑在哪

用得上的：

托管 DeepSeek 的云厂商和 API 平台 ：拿到官方生产配置、算子和协议层，第三方部署可以更接近官方 API 的行为（recipe 的处理逻辑官方称与官方 API 完整对齐，包括思考模式默认 max_tokens 这些细节）。
有大集群的企业私有化部署：官方给的「高效最小单元」是 64 卡 Prefill + 64 卡 Decode；官方说 1P+1D 也能部署，但没给这种规模下的性能数据。
做推理优化的工程师：Q&A 里的并行策略、负载均衡和缓存设计，可以直接拿来对照自己的系统。

基本用不上的：个人开发者和中小团队。硬件门槛是 SM100 或昇腾 950，H100、H800、A100 和消费卡都不在支持列表里；模型只有一个；最难的 KVCache 和负载均衡还要自己补。想本地跑 V4.1 Flash，现阶段还是等 vLLM、SGLang 的适配更实际。

六、我的判断

这次开源的价值，一半在代码，一半在那份 Q&A。

代码层面，DeepInfer 更像一份「参考实现」：引擎、算子、投机解码和确定性推理都是生产级的，但把它变成在线服务的关键部件没给。所谓「普惠」，短期内受益的是有大集群的厂商，不是普通开发者。

设计思路层面，有两点我认为会被行业跟进。一是把 KVCache 当成长期存储资产来经营（独立集群、3～7 天 TTL），从根上解决前缀亲和和负载均衡的冲突；二是在可接受的近似范围内换算力（Bounded Replay、动态验证长度）。这两件事都直接决定了缓存命中价和高并发下的单价能压到多低。

所以，如果你只是 DeepSeek API 的用户，这次开源对你最直接的影响可能是：更多第三方平台能以接近官方的质量提供 V4.1 Flash，价格竞争会更激烈。

参考资料

DeepInfer GitHub 仓库（README、benchmark 图、eval）：github.com/deepseek-ai...
DeepSeek V4.1 Flash 推理部署 Q&A（官方 PDF，仓库 doc/ 目录）：github.com/deepseek-ai...
deepseek-recipe GitHub 仓库：github.com/deepseek-ai...
DeepSeek-V4.1-Flash-1017 模型卡：huggingface.co/deepseek-ai...
DeepSeek V3/R1 推理系统概览（2025 年 2 月，开源周 Day 6）：github.com/deepseek-ai...
AIBase：DeepSeek 开源推理框架 DeepInfer（2026-10-20）：news.aibase.com/zh/news/317...
IT之家：DeepSeek 宣布将内部推理框架 DeepInfer 全面开源（2026-10-20）：www.ithome.com/1/015/429.h...
Hacker News 讨论「DeepSeek just open-sourced its inference engine」：news.ycombinator.com/item?id=501...