技术基础设施研究 · DeepSeek 开源系列

DeepInfer：DeepSeek 把「生产级推理引擎」开源了

从 E/P/D 三级分离、Wide-EP 到 SWA 有界回放——一次把推理成本曲线拆开给你看的开源，也是一次「只交发动机、不交全套服务」的半开放。

报告日期　2026-10-21 数据截止　2026-10-21 09:30 CST 研究对象　deepseek-ai/DeepInfer（Apache-2.0） 配套　deepseek-recipe（MIT）

SECTION 00核心判断

2026 年 10 月 20 日，DeepSeek 开源了内部大规模云服务推理框架 DeepInfer，以及生产级 Token 编解码组件 deepseek-recipe。官方口径很直接：这就是支撑 DeepSeek V4.1 Flash 高吞吐、低延迟线上服务的那套引擎，单个集群每天处理约 155 万亿 Token。

但把它读完之后，结论比标题复杂得多：这是一次含金量很高的开源，也是一次边界划得很清楚的半开放。以下六条是本报告的核心判断。

1. 这不是「又一个 vLLM」。官方承认「最初主要基于 vLLM 构建」，但代码是 5.7 万行的深度分叉：setup.py 首行写着「Derived from vLLM; modified by DeepSeek」。它承载的是 DeepSeek 自己的生产架构，而不是通用推理库。
2. 真正的技术增量集中在三处：Wide-EP + EPLB 的 MoE 扩展方式（解码用 64–128 卡专家并行）、SWA 有界回放（把解码器预填充从「2,560 Token × 20 层」压到 128 Token，官方称预填充总算力近乎减半）、以及 3FS 上的 KV 分层复用（前缀命中率约 96%）。
3. 开源是「半开放」。README 明确列出三项未包含：KV Cache 系统、VE/Prefill/Decode 分离编排、跨 DP 副本的请求级负载均衡。偏偏这三项才是把「推理引擎」变成「DeepSeek 成本曲线」的部件。
4. 硬件门槛极高。只支持 NVIDIA SM100（Blackwell）与华为昇腾 950，H100/H800/A100 直接出局；需要 CUDA 13 或 CANN 9.2、GCC 13、Python 3.12，且交付形态是离线推理，不含 HTTP 服务。
5. 战略信号大于工程可用性。这是头部模型厂第一次把国产 NPU 与 NVIDIA 并列为「一级支持目标」，且是同一棵代码树、一个环境变量切换。对昇腾生态的背书价值，短期高于引擎本身的可部署价值。
6. 数字必须带口径读。155 万亿/天与 38 美元/卡·时都是厂商自报，无第三方复现；「25 倍」是缓存命中与不命中的预填充对比，不是 DeepInfer 对比 vLLM；官方全程没有给出任何与 vLLM/SGLang 的正面对比数据。

SECTION 01事件：一次「补作业」式开源

先把时间钉死：GitHub 仓库创建于 2026-10-16，对外官宣与代码推送是 2026-10-20；三天前的 10 月 17 日，DeepSeek 刚上线 DeepSeek-V4.1-Flash-1017——正是 DeepInfer 默认加载的那个 checkpoint。模型先到、引擎后到，这个顺序本身就是一条信息：引擎的开源是围绕最新模型做的一次「Day-0 配套」。

1.1 这次发布的四件东西

表 1　2026-10-20 DeepSeek 一次性放出的四项内容

发布物	形态	内容与定位
DeepInfer	GitHub 仓库，Apache-2.0	生产推理框架的离线推理版本，含与生产一致的算子、模型运行时、调度与采样逻辑；只支持 V4.1-Flash
deepseek-recipe	GitHub 仓库，MIT，Rust	把 Chat Completions / Responses / Messages 三种 API 协议统一转成对话格式，再编码为 Token 序列；官方 API 语义对齐
知乎技术报告	官方长文	V4.1 Flash 推理系统的整体架构与关键实现，含未开源的 KV Cache 与负载均衡设计
部署 Q&A	仓库内 doc/，28 KB	312 行的一手问答，本报告最重要的技术事实来源

1.2 为什么说这是「补作业」

2025 年 4 月，DeepSeek 曾专门发文解释为什么不开源完整推理引擎：代码库是一年多前的 vLLM fork、已经严重分叉；与内部集群管理工具耦合太深；小团队维护带宽有限。当时的结论是「改为抽取独立组件回馈社区」。

但同一份文档里还留了一句承诺：会在新模型发布前主动同步推理相关工程，做到「SOTA 支持的 Day-0 就绪」。2026-10-20 的 DeepInfer，就是这句话的兑现——同时也说明当年那三条困难并没有全部消失：KV Cache 与负载均衡依旧被截留在内部。判断

“We're sharing our production stack to help the community lower compute costs, reduce energy use, and make AI more affordable.”

—— DeepSeek 官方 X 公告（2026-10-20）

这段表态把动机讲得很清楚：开源生产栈不是做慈善，而是把「单位 Token 成本」这条曲线公开，让整个生态的成本基准一起下移。配套的中文口径是「降低算力成本、减少能源消耗、推动大模型普惠」。

1.3 DeepSeek 开源版图：从「算子」到「引擎」

表 2　DeepSeek 开源路线关键节点（模型 + 基础设施）

时间	项目	意义
2024-12-26	DeepSeek-V3	MoE + MLA 架构基线，开源权重
2025-02	开源周：FlashMLA、DeepEP、DeepGEMM、3FS、DualPipe、EPLB、profile-data	把训练/推理的「零件」逐个开源，但不含整机
2025-09-29	DeepSeek-V3.2-Exp	引入 DSA 稀疏注意力，API 降价
2025-12-31	mHC 论文	流形约束超连接，进入 V4
2026-01-12	Engram	条件记忆模块，留给下一代
2026-04-24	DeepSeek-V4（Pro 1.6T / Flash 284B）	1M 上下文、CSA + HCA 混合注意力，权重开源
2026-08-13	DeepSeek Harness	Agent 运行时开源，模型与工具链开始合流
2026-09-08 ~ 09-10	DeepJIT、DeepSelect、deepseek-recipe；V4.1 Flash 发布	算子 JIT、TopK 内核、协议层组件密集补齐
2026-09-29 ~ 09-30	DeepGEMM-Ascend、DeepEP-Ascend	昇腾侧算子与通信库先行落地
2026-10-17	DeepSeek-V4.1-Flash-1017	Agent 与代码能力增强，输出更短
2026-10-20	DeepInfer + deepseek-recipe	补上「引擎」这一块拼图

如果给 DeepSeek 的开源分波，脉络会更清楚：① 权重波（V3、R1）→ ② 系统零件波（2025 开源周的 FlashMLA/DeepEP/DeepGEMM/3FS 等）→ ③ 编译语言与国产芯片波（TileLang、DSA 算子、昇腾组件）→ ④ 推理栈波（DeepJIT、DeepSelect、deepseek-recipe、DeepInfer）。DeepInfer 是第四波的收官之作。

它开得最晚、留白最多，原因也不难理解：前三波开源的是「零件」，DeepInfer 开源的是把这些零件组装成生意的那层胶水——商业敏感度最高，因此边界划得最细。

SECTION 02它是什么：单模型、双平台、只有发动机

2.1 「只交发动机」是什么意思

README 把这件事写得很坦白，列出三项「跑完整推理服务需要、但本次不包含」的能力：

• KV Cache 系统（3FS 上的分布式缓存与客户端）；
• VE / Prefill / Decode 分离部署（官方补了一句：引擎侧大部分功能其实已经实现）；
• 跨数据并行副本的负载均衡（预填充与解码两侧都缺）。

换句话说，仓库给你的是单实例引擎：能加载权重、能批处理、能跑投机解码与结构化输出、能做 EP/DP 并行；但把它变成「DeepSeek 那样的一套服务」，你还需要自己补上路由层、缓存层、服务层与运维层。一位独立开发者在克隆仓库后写下的评价被广泛引用：「让推理引擎变成 DeepSeek 成本曲线的两个组件，恰好就是留在家的那两个。开源的是发动机舱，不是整条船。」第三方

2.2 与 deepseek-recipe 的分工

DeepInfer 只吃「Token 序列」，不吃 JSON。协议转换由配套的 deepseek-recipe 承担：它把 Chat Completions、Responses、Messages 三种请求统一成对话格式，渲染成模型提示词，编码成 Token ID；输出再从 Token 流还原成各协议的流式响应。请求转换、编码、解析全部用 Rust 实现，附 Python 绑定。

官方承诺这套逻辑与 DeepSeek 官方 API 完全对齐，第三方部署可以获得与官方一致的 API 行为。但它也明确写了：「调用方必须自行提供模型推理、工具执行与 HTTP 传输。」仓库里给的两个示例 server（Axum / FastAPI）都是 mock 推理——是给你照抄的骨架，不是可用服务。

SECTION 03架构：E/P/D 分离与四类负载均衡

官方给出的参考架构不是常见的「PD 分离」，而是三级分离：视觉编码器（Vision Encoder）、预填充（Prefill）、解码（Decode）各自独立部署，再加一层独立的 KV 存储集群。中文媒体普遍写成「PD 分离」，这是一个需要纠正的口径。

3.1 并行策略：小 EP 做预填充，Wide-EP 做解码

表 3　各阶段的并行配置（官方 Q&A）

阶段	EP	DP	TP / CP	取值原则
Prefill	EP 2 – 8	DP 2 – 8	不用	「用 HBM 允许的最小 EP/DP」——普通 8 卡机即可
Decode	EP 64 – 128	DP 64 – 128	不用	「用可用 GPU 允许的最大 EP/DP」——64–128 卡超节点
Vision Encoder	—	单卡一实例	不用	建议用更便宜的卡

注意力侧沿用 V3/R1 推理系统的做法：DP 数等于 EP 数。官方明确「目前不用 TP、不用 CP」。这个选择的经济含义很直接：预填充是算力密集型，用小规模并行换高利用率；解码是内存带宽密集型，用 Wide-EP 摊薄每步的专家权重访存——官方原话是「Wide-EP 显著降低 MoE 专家部分的每步内存流量，配合良好的 EPLB 支持，有效提升 TPS」。

代价是部署下限被抬高：1P + 1D 可以跑，但生产建议 P:D 约为 1:1，而解码侧推荐 EP64 起步，所以最小高效单元是 64 卡预填充 + 64 卡解码 = 128 卡。这不是给单机玩家准备的。

3.2 四类负载均衡器

因为放弃了前缀亲和路由（KV 在共享存储里，任何预填充机都能命中任何前缀），路由必须自己解决均衡。官方建了四个均衡器，其中三个的开源状态值得注意：

表 4　四类负载均衡器及开源状态

均衡器	做法	开源状态
Prefill LB	按上下文长度分四档（<16K / 16–64K / 64–256K / ≥256K），按上一轮算力配额需求动态分配引擎数；每档独立配额上限；单卡内按时间预算反解 chunk 大小	未开源（Q&A 给设计）
Decode LB	全实例均匀路由，同时均衡「请求数」与「KV 总长度」两个维度；短请求给低并发高 KV 的卡，长请求反之（DualPath 组内调度）	未开源
Vision Encoder LB	按机器粒度随机选一台，再选当前处理图像 patch 最少的 GPU	未开源
EPLB	冗余专家 + 周期性重排；预填充 4 个冗余专家 / 100 步统计 / 1000 步重排；解码 1 个冗余专家 / 1000 步统计 / 10000 步重排	已开源（算子与超参）

这里最容易混淆的是两个「LB」：EPLB 是 EP 组内专家分配的均衡，已经开源，官方还给了完整的超参与实测指标 moe_lb（最慢 rank / 均值）——预填充 1.045（EP2DP2）~1.074（EP4DP4），解码 1.090。而跨 DP 副本的请求级负载均衡没有开源。把两者混为一谈，会得出自相矛盾的结论。

官方还给了整体效果：这套调度能达到「完全均衡的离线基准」的约 80%。这句话反过来读更有意思——它承认还有 20% 的浪费，来自长尾请求、桶间迁移与配额冗余。

SECTION 04七项关键技术逐条拆解

README 列了七组能力。下面按「它解决什么问题、怎么实现、代价是什么」逐个拆。

4.1 算子层：把自家内核全部塞进 vendor性能基础

DeepInfer 的算子层由六块组成：FlashMLA（MLA 注意力内核）、DeepGEMM（GEMM 内核库）、DeepEP（专家并行通信库）、TileKernels（TileLang 写的内核库）、DeepSelect（DSA 与采样器的 TopK 内核）、以及仓库内 tilelang_ops 里的自定义 TileLang 内核。前五个以 git submodule 形式挂在 vendor/ 下，昇腾侧另有 DeepEP-Ascend 与 DeepGEMM-Ascend 两个移植版本。

官方特别提了一个融合算子 Mega MoE：在 scale-up 域内，不论 EP 规模与 batch 大小，融合 MoE 都显著快于非融合实现。至于「开源版内核是否弱于内部版」，Q&A 的回答相当实在：大体相同，只是索引器与 mega 系列略有差异；FlashMLA 少了一处手工 SASS 优化，解码内核慢 5%–10%，端到端差距最多 5%。这是全篇少见的、带自我批评的数字。

4.2 Wide-EP + EPLB：解码侧的吞吐杠杆MoE 扩展

解码阶段每个 Token 只激活少量专家，但需要读的专家权重总量不变。EP 越大，单卡需要驻留的专家越少，每步访存越低，batch 就能开得更大。官方的对比曲线很直观：

读法：在 100 Token/s/user 附近，EP8 与 EP64 的峰值接近（约 2.5 万 vs 2.6 万 Token/s/卡）；但当用户要求 150 Token/s 时，EP8 掉到约 1.9 万，EP64 还有约 2.3 万。Wide-EP 买的不是峰值，是低延迟区间的吞吐保持能力——这恰好是交互式服务的日常工作点。

EPLB 则负责让这 64–128 张卡不出现「最慢的木桶板」。机制是：每张卡除负责的专家外多放几个冗余专家（热专家的副本），按最近 N 步的负载统计，每 M 步重排一次，权重在组内通过 NVLink 共享内存直接搬运。解码侧 moe_lb 实测 1.090，意味着最慢 rank 比均值慢 9%，已经相当紧。

4.3 DSpark：变长验证的投机解码延迟/吞吐

投机解码的经典做法是固定草稿长度（比如 5），一次验证 5 个 Token。问题是：不同请求、不同位置的接受率差异很大，固定长度会在低概率 Token 上浪费验证算力。

DSpark 的做法是给草稿模型配一个 Confidence Head，预测每个草稿位置的接受概率；调度时按「边际收益」排序，动态选择要验证的前缀长度。生产配置是草稿模型一次出 5 个 Token，实际验证长度在 3.2–4.4 之间浮动，而平均接受长度基本不变（3.29 vs 3.20）。

表 5　DSpark 变长验证 vs 固定验证 5（官方 EP64/DP64 基准数据）

并发（seq/rank）	固定 5 验证长度	变长验证长度	固定 5 接受长度	变长接受长度	吞吐增益
16	5	4.44	3.32	3.24	−1.5%
32	5	3.65	3.25	3.17	+1.6%
48	5	3.94	3.30	3.26	+3.6%
60（生产工作点）	5	3.58	3.30	3.21	+5.4%
72	5	3.24	3.29	3.12	+6.7%
96	5	3.24	3.30	3.15	+11.0%

两个细节值得注意：第一，低并发（16）时变长验证反而 −1.5%，说明这套机制是为高并发生产点设计的，不是万能加速器；第二，验证长度降了约 30%，接受长度几乎不变，省下的是纯验证算力。官方总结为生产点 +4%–7%。

4.4 SWA 有界回放：把预填充砍到近乎一半本报告认为最关键

要理解这项技术，得先看 V4.1 Flash 的模型结构。按官方技术报告与媒体解读：V4.1 Flash 是约 5,500 亿参数主干 + 约 1,960 亿参数 Engram 条件记忆模块的 MoE（技术报告口径；模型卡标称合计约 7,630 亿，统计口径略有差异），采用 Causal Encoder-Decoder（CED） 结构——40 层切成前 20 层「因果编码器」和后 20 层「解码器」，编码器激活约 8B 参数、解码器激活约 16B 参数。官方博客媒体

关键设计是：解码器的全局 KV Cache 不从各层自己的隐藏状态生成，而是从编码器最后一层（第 20 层）的隐藏状态用每层独立的投影权重投射得到。这样一来，绝大多数 prompt Token 只需走前 20 层，不必走完整 40 层；对长序列，预填充复杂度从 O(NL) 降到约 O(NL/2)。

但解码器每层仍有自己的滑动窗口注意力（SWA）KV 需要重建。精确重建要跑「2,560 Token × 20 层」——这是 128 × 20 的乘积。V4.1 改为只回放最近 128 个 Token，把注意力窗口截断在回放段内：从位置 s 回放时，位置 i 的 query 只与 [max(s, i−127), i] 的 key 计算，得到一个近似的 SWA KV。

效果是重算成本变成常数，与上下文长度、层数无关。官方说解码器侧这项让预填充总算力近乎减半（nearly halving）。代价是很明确的：它是近似，不是精确重建；官方称对响应质量影响可忽略，但这是「官方称」。

配套的命中策略也值得记：命中长度由块 KV 决定，最后一块是否需要重算由 SWA KV 决定。在输入长度 L 下，最大命中长度被限制在 L − 134（128 Token 窗口 + 6 Token 投机回溯余量）。先查块 KV 得到 L1，再查 [L1−128, L1] 区间的 SWA KV：有则命中 L1，没有则退回 L1−128。官方

4.5 异步调度：把 GPU 的空转填掉工程优化

解码一步是 schedule(N) → forward(N) → sample(N) → post-process(N)。其中调度和后处理都是纯 CPU 逻辑，但后处理前需要一次 GPU–CPU 同步拿采样结果，于是 GPU 在「后处理 + 下一步调度」期间空转。

DeepInfer 的做法（官方承认参考了 SGLang 与 NanoFlow）是把流水线错开：GPU 跑 forward(N) → sample(N) 的同时，CPU 并发跑 schedule(N+1) → launch_forward(N+1) → post-process(N−1) → launch_sample(N+1)。它在 README 里默认开启，官方称「零开销批调度」。

有个很能说明工程复杂度的细节：异步之后，schedule(N+1) 执行时第 N 步的置信度还没回来，CPU 无法决定每个请求的验证长度，只能先定总预算；具体长度改由一个 TileLang 内核在 GPU 上算（累积乘积、全局排序取 top-k、融合重映射写回 pinned buffer）。

4.6 批不变性与确定性采样可复现性

这两项都标注 仅 NVIDIA，但对企业部署其实很重要：

• 批不变推理（DEEPINFER_BATCH_INVARIANT=1）：同一请求在不同 batch 组成下结果完全一致。MoE 专家路由与归约顺序会随 batch 变化，通常导致数值漂移；这项能力把它锁死，对 A/B 测试、回归测试、计费一致性都有价值。
• 确定性采样：相同输入 Token 与采样参数产生相同输出，需要固定 seq_seed 并关闭变长验证。

4.7 结构化输出：把约束编译成自动机Agent 场景

支持正则、JSON Schema、EBNF 三种约束。设计上把「编译」和「推理」解耦：编译在专用机器上异步完成，把格式约束编译成语法自动机；运行时每步推进自动机，确定合法 Token 集合，生成 mask 施加到采样逻辑上。

这个「编译与推理分离」的选择，说明 DeepSeek 在线上把结构化输出当成一个独立服务来跑——编译开销不进请求关键路径。对 Agent 场景（工具调用参数必须是合法 JSON）这是刚需，也是 README 里唯一单独列出的「应用层」特性。

SECTION 05KV Cache：把重复 prefill 变成一次计算

DeepSeek 的成本优势，一半来自模型（KV 小），一半来自「算过的不再算」。DeepInfer 的 KV 体系分三层，介质、生命周期、管理方都不同：

表 6　三层 KV Cache（官方 Q&A 原文整理）

内容	介质	副本	管理方 / 生命周期
在途块 KV + 状态 KV	推理 GPU 显存	—	Prefill / Decode 实例，请求级
SWA KV	本机主机内存（分布式内存池）	单副本，不落 3FS	实例自管，TTL 约 180 秒；跨机命中走 400G VLAN 拉取
块 KV（主 KV + 索引器 K）	专用 3FS 存储集群	无应用层副本，靠 3FS 自身冗余	kvcache-store；TTL 3 天（Agent）/ 7 天（聊天）

5.1 为什么用独立存储集群，而不是本机内存

官方给了四条理由，本质上都在回答「为什么值得多花一次网络往返」：

1. 任意预填充机都能命中任意前缀，不必为了前缀亲和性牺牲负载均衡（这也是前文「放弃前缀亲和路由」的前提）；
2. 存储节点的扩缩容与计算节点解耦；
3. 计算节点故障率比存储节点高一个数量级以上，KV 放在存储侧不被计算节点故障牵连；
4. 配合 3FS 的纠删码（10+2），一个组可同时容忍两个节点故障。

规模上的数字：约 100 PiB SSD、读约 10 TiB/s、写约 850 GiB/s，面向约 112 KiB 的块粒度随机读写；每张 GPU 折算约 14.4 TB 逻辑容量（物理容量更大）。单台标准存储服务器建议 20 块 30.73 TB SSD，读不低于 40 GB/s、写不低于 5 GB/s，容量按 24 小时数据留存规划。

5.2 命中率与「25 倍」的真实含义

官方博客给出的线上数据：平均请求输入约 77K Token，前缀缓存命中率约 96%；命中后单卡预填充从约 6 万 Token/s 提升到约 150 万 Token/s，约 25 倍。平均首 Token 延迟（TTFT）约 400 ms，生成速度约 230 Token/s（写代码约 300）。官方博客媒体转述

另外两个数字值得记住：SWA KV 只在内存里活约 180 秒，但命中率仍有 98% 以上——说明它服务的请求间隔普遍很短；块 KV 的 TTL 是 3 天/7 天，官方实测把聊天流量的 TTL 从 7 天缩到 3 天，只会损失 0.5%–1% 的命中率。

还有一个容易被忽略的工程细节：从共享内存换入 HBM（swap-in）没有用 CUDA copy engine，因为它在细粒度 KV 块拷贝上表现很差；DeepInfer 改用 GDR（GPU Direct RDMA），让 RDMA 网卡在不占用 SM 的情况下打满 PCIe 带宽，同时与逐层前向计算重叠。

SECTION 06性能：三条曲线与数字口径

官方只给了一组可复现的基准：预填充 4 张 SM100、解码 64 张 SM100，各自在同一个 scale-up 域内；仓库提供 examples/sweep/run_sweep.sh 与绘图脚本。下面三张图来自官方，数字是本报告从图上读出的近似值。

表 7　官方基准读数（SM100，图 3 / 图 4 近似值）

阶段	配置	关键读数
Prefill	EP4DP4，chunk 4,096 → 65,536	吞吐 6.0 万 → 8.9 万 Token/s/卡；单步延迟 68 ms → 740 ms；曲线在 32K 后基本走平，说明吞吐已接近饱和
Decode	EP64DP64，并发 8 → 256	单用户 325 Token/s 时约 2.6 千 Token/s/卡；单用户 105 Token/s 时约 2.6 万 Token/s/卡；生产工作点（约 60 并发）约 1.37 万 Token/s/卡
Wide-EP 增益	EP8 vs EP64	峰值接近；高交互区间（150 Token/s/user）EP64 约 2.3 万 vs EP8 约 1.9 万，差距约 20%

还有一组模型能力参考值，来自仓库的评测脚本说明：在默认配置下，V4.1 模型 AIME 2026 Pass@1 为 99.9%、GPQA Diamond 93.4%、HLE-Full 42.6%。官方这些数字是「部署配置是否正确」的 sanity check，不是模型榜单结论。

SECTION 07开源边界与工程成熟度

判断一个开源项目，看它「给了什么」不如看它「没给什么」。DeepInfer 的边界相当清晰：

表 8　开源 / 未开源清单

已开源	未开源（官方明确列出）
模型运行时、采样器、批调度（异步）	KV Cache 系统（kvcache-store、3FS 客户端）
并行：Attention DP / 均衡 CP、MoE EP + EPLB	VE / Prefill / Decode 分离编排（引擎侧功能大部分已实现）
DSpark 投机解码 + 置信度调度验证	跨 DP 副本的预填充/解码负载均衡
SWA 有界回放、结构化输出、批不变、确定性采样	HTTP 服务、鉴权、限流、监控（需自建）
算子层：FlashMLA / DeepGEMM / DeepEP / TileKernels / DeepSelect / TileLang 内核	官方 benchmark 数据集与原始 CSV（只有 PNG 曲线）
离线评测脚本（AIME / HLE / GPQA）	昇腾侧性能数据（完全空白）

7.1 工程成熟度：Beta，且是「毛坯交付」

• 版本 0.1.0，分类 Development Status :: 4 - Beta；无 release tag、无 CI、无 Dockerfile，必须源码编译。
• 六个 vendor/ 子模块默认是空的，要手动 git submodule update --init。
• 仓库没有开 issue 区（has_issues=false），只能提 PR；上线一天就有 119 个待合并 PR。
• 社区以 PR 形式「补文档」：修 pyproject.toml 里的 404 链接、补参数下界校验、把一半中文 docstring 国际化、清理泄漏到公开 API 的内部注释（"HACK token id"）。
• 默认 checkpoint 约 510 GB（48 个分片），首次运行自动下载。

公平地说，doc/inference_deployment_qa.md 的质量相当高——312 行、覆盖并行、存储、负载均衡、容错、低精度、内核、投机解码、异步调度、结构化输出、Recipe 十个主题，还给了失败场景的数字。这是「官方认真写了一份部署手册」，与「工程化包装粗糙」并存，并不矛盾。第三方

SECTION 08横向对比：它到底替代谁

表 9　主流推理框架定位对比

维度	DeepInfer	vLLM	SGLang	TensorRT-LLM	MindIE
出品方	DeepSeek（模型厂）	社区（Berkeley 起源）	社区（LMSYS 系）	NVIDIA	华为
定位	自家单模型的官方调优参考实现	通用推理/服务库	高性能服务 + 结构化生成	NVIDIA 硬件极致性能	昇腾官方推理套件
模型数量	1 个	200+ 架构	多模型族	多模型	昇腾生态模型
硬件	SM100 / 昇腾 950	多厂商 + 插件	NVIDIA 为主	NVIDIA	昇腾
HTTP 服务	不含（离线）	含，OpenAI 兼容	含	含（Triton 等）	含
PD 分离	设计有、开源版未交付	支持	支持	支持	视版本
许可	Apache-2.0	Apache-2.0	Apache-2.0	Apache-2.0	需查华为许可

结论是：它不是用来「替换 vLLM」的。vLLM 的护城河是模型覆盖广度与硬件广度，DeepInfer 恰好相反——一个模型、两种芯片、把每一层都针对自家模型拧到最紧。两者的关系更像「厂商参考实现」与「通用基础设施」：短期内不会正面竞争，长期看 DeepInfer 里的工程手法（Wide-EP 调度、SWA 回放、KV 分层）会以补丁或论文形式外溢到 vLLM / SGLang。

血缘上也不用回避：官方致谢写得很清楚，「最初主要基于 vLLM 构建，并受到 SGLang 与 TensorRT-LLM 启发」。第三方核查显示 vllm 字样只残留在大约 23 个 Python 文件里、代码量 5.7 万行，说明这是深度分叉后的自研替换，不是薄封装。但「是否/如何向上游同步」官方没有给出计划。第三方

SECTION 09影响与判断

9.1 对国产算力：一次公开背书，但还不是可用的生产力

把昇腾 950 与 NVIDIA SM100 并列为 README 的第一级支持对象，这件事的信号价值很高：这是头部模型厂第一次把「官方生产引擎」同时押注国产 NPU，而且不是维护一个独立分支，而是同一棵代码树、构建时一个环境变量（DEEPINFER_ACCELERATOR）切换。仓库里能看到真实的工程投入：vendor/DeepEP-Ascend、vendor/DeepGEMM-Ascend、csrc/asc_utils.cpp、graph_timer_asc.cpp。

但要克制：官方没有给任何昇腾侧的性能或精度数据；只支持 950 一个型号；CANN 9.2 是硬门槛；两项能力（批不变、确定性采样）明确只支持 NVIDIA。所以准确的说法是——这是路线图信号，不是可评估的生产方案。判断

9.2 对推理成本：一台「五层乘法」的成本机器

要理解 DeepSeek 为什么能把价格压到那个位置，先写一个最朴素的成本恒等式：

把 DeepInfer 与 V4.1 Flash 的公开信息按层拆开，会看到五层相互咬合的杠杆。它们不是相加，而是相乘——任何一层掉链子，整体成本就会回到行业平均：

表 10　五层成本杠杆

层级	关键做法	作用机制	公开量级
模型层	CED 非对称编解码、CSA2 三维压缩、FP4	prompt 只走 20/40 层；KV 的条目、序列、层三个维度同时压；权重与 KV 位宽减半	预填充约 O(NL/2)；KV 对 HBM 需求降到 1/4
复用层	96% 前缀命中、3FS 持久缓存、SWA 有界回放	命中部分不再重算；未命中只回放最近 128 Token	预填充 6 万 → 150 万 Token/s（约 25×）
调度层	E/P/D 分离、Wide-EP、分桶配额、异步调度	阶段解耦、解码批处理做大、消除 GPU 空转	解码约 60 并发/卡；DSpark +4–7%；达到理想均衡的 80%
系统层	3FS 存算分离、GDR 换入、异步编译	把匹配、拉取、换入、语法编译挪出关键路径	TTFT 约 400 ms；生成约 230 Token/s
硬件层	8 卡机做预填充、64–128 卡超节点做解码、多供应商、谷电价	算力密集处用普通机器，访存密集处才上超节点	单集群 155 万亿 Token/天

下面逐层拆开。

9.2.1 模型层：先让每个 Token「算得少、存得小」

成本的第一性来源，是「每生成一个 Token 要做多少计算、读多少字节」。DeepSeek 在这一层做了三件事。

稀疏激活。V4.1 Flash 是 MoE 模型，约 5,500 亿参数主干加 1,960 亿参数的 Engram 条件记忆模块，但编码器每个 Token 只激活约 80 亿、解码器约 160 亿。参数规模决定能力上限，激活规模决定成本——这是它能把「大模型」卖出「小模型价」的前提。

非对称编解码（CED）。40 层被切成前 20 层因果编码器与后 20 层解码器；解码器的全局 KV 不由各层自身生成，而是从编码器第 20 层的隐藏状态投射得到，每层独立投影。于是绝大多数 prompt Token 只走前 20 层，预填充复杂度从 O(NL) 降到约 O(NL/2)。这一条也解释了后文「解码器侧只需回放 128 Token」为什么成立。

注意力与精度。CSA2 沿条目大小、序列长度、层维度三个方向同时压缩 KV，并用 Full / Reindex / Reuse 三种静态模式跨层复用全局 KV 与 Top-K 索引；主 KV 压到 FP4（per-16 e4m3，省掉全局缩放），索引器与 MoE 权重用 MXFP4，只有对量化更敏感的 SWA KV 保留 FP8。官方口径：V4.1 相比上一代，KV 对 HBM 的需求降到 1/4、对 SSD 降到 1/8；从 V1 算起，KV 总量缩到 1/437。官方博客媒体

三项叠加的效果是：同一张卡能装下更长的上下文、更大的 batch。而解码阶段是内存带宽瓶颈，KV 位宽减半几乎等于吞吐翻倍——这是「算得快」的物理基础。

9.2.2 复用层：96% 命中 + 128 Token 回放 ＝ 25 倍

这是整套成本机器里最值钱、也最容易被忽略的一层：把预填充从「每次都算」变成「大部分时候查表」。

官方披露的线上数字是：平均请求输入约 77K Token，前缀缓存命中率约 96%。把它代入算术：未命中部分只有 4% × 77K ≈ 3.1K Token；SWA 有界回放再补最近 128 Token，实际重算约 3.2K Token。77,000 ÷ 3,208 ≈ 24——与官方「命中后单卡预填充从 6 万提升到 150 万 Token/s」的 25 倍几乎完全吻合。推算

支撑这个命中率的是第 5 节那套三层 KV 体系：块 KV 放在独立 3FS 集群上，约 100 PiB、TTL 3 天（Agent）/ 7 天（聊天），任意预填充机都能命中任意前缀；SWA KV 放在本机内存池，TTL 约 180 秒，命中率仍在 98% 以上；在途 KV 留在显存。

为了让「查表」真的便宜，DeepSeek 还做了三件反直觉的事：放弃前缀亲和路由（否则负载均衡与命中率只能二选一）；用独立存储集群而不是本机内存（存储节点故障率比计算节点低一个数量级以上，扩容也不牵连计算）；用 GDR 而不是 CUDA copy engine 做 KV 换入（细粒度块拷贝上 copy engine 表现很差，GDR 让网卡不占 SM 打满 PCIe，并与逐层前向计算重叠）。

最后一块拼图是 SWA 有界回放：解码器每层都有自己的滑动窗口 KV，精确重建要跑「2,560 Token × 20 层」；V4.1 只回放最近 128 Token 做近似重建，把重算成本变成常数。官方称这一项让预填充总算力近乎减半。

9.2.3 调度层：把批处理做大，把空转和长尾吃掉

模型再省、缓存再准，GPU 闲着就是浪费。调度层解决的是「分母里的利用率」。

批处理是解码成本的命门。单用户生成速度约 230 Token/s，而官方解码基准在 60 并发时是 13,730 Token/s/卡——两者相差约 60 倍，正好等于并发数。也就是说，解码的每 Token 成本 ≈ 单流成本 ÷ 并发数；把并发做上去，就是最直接的降本。Wide-EP（EP64–128）的意义正在这里：它把专家权重摊到更多卡上，让单卡每步访存降下来，才装得下 60+ 的并发而不掉速。配套的 EPLB 用「冗余专家 + 周期重排」把最慢 rank 与均值的差距压到 9%（moe_lb 1.090）。

分桶与配额消除长尾。预填充按上下文长度分四档（<16K / 16–64K / 64–256K / ≥256K），每档独立配额；单卡内不设固定 chunk，而是给每步一个时间预算，用二次代价模型反解「这一步该算多少 Token」。这样既不会因为一条超长请求拖垮整批，也不会把 chunk 切得过碎。

异步调度抹掉空转。解码一步里，调度与后处理是纯 CPU 逻辑，但中间要一次 GPU–CPU 同步，GPU 会空等。DeepInfer 把 schedule(N+1) 与 forward(N)/sample(N) 流水线错开，默认开启，官方称「零开销批调度」。

投机解码再加一点。DSpark 用置信度头预测每个草稿位的接受率，动态决定验证长度，把验证量从固定 5.00 降到 3.2–4.4，生产点吞吐 +4%–7%。量不大，但几乎是白送的。

这些叠起来的官方结论是：调度能达到「完全均衡离线基准」的约 80%——换个说法，仍有约 20% 的算力耗在长尾、桶间迁移与冗余配额上。

9.2.4 系统与硬件层：把「等待」和「贵硬件」换成便宜资源

系统层的原则只有一句：凡是等待，都不要放在关键路径上。前缀匹配只查元数据；KV 拉取在独立进程异步做；换入用线程与逐层计算重叠；结构化输出的语法编译放到专用机器异步完成；分词从线性改成「按特殊 Token 分段并行」（核心路径 Rust 实现），专门优化长输入的 TTFT。结果是官方给出的线上延迟：平均 TTFT 约 400 ms、生成约 230 Token/s（写代码约 300 Token/s）——延迟不靠堆卡换。

硬件层的原则是「把贵的地方用对」：预填充是算力密集型，用普通 8 卡机（EP2–8）就够；解码是访存密集型，才上 64–128 卡超节点；视觉编码器单卡、且建议用更便宜的卡。KV 存 SSD 而不是 HBM，每 GB 成本差一到两个数量级；3FS 用 10+2 纠删码换容量效率。再叠加多供应商（SM100 + 昇腾 950）的采购议价，以及官方口径里的谷电价，才撑得起「单卡每小时 38 美元收入」这个价格水平（官方只披露收入，未披露毛利）。

9.2.5 一张理想化成本账

把上面的数字代进一个具体请求：输入 77K Token、输出 500 Token（输入取官方平均值，输出为示例假设）。

表 11　单请求算力账（本报告理想化推算，不含调度损耗、空闲、存储与网络）

环节	无优化（全量重算、单流解码）	生产配置（96% 命中 + 批处理）	倍率
预填充（GPU·秒）	77,000 ÷ 60,000 ≈ 1.28	77,000 ÷ 1,500,000 ≈ 0.051	25×
解码（GPU·秒）	500 ÷ 230 ≈ 2.17	500 ÷ 13,800 ≈ 0.036	60×
合计（GPU·秒 / 请求）	≈ 3.45	≈ 0.087	≈ 40×

这张表要读三遍：第一，它是理想化推算，不含调度损耗（官方承认约 20%）、闲置配额、存储与网络；第二，60 倍来自批处理而非 DeepSeek 独有，但 Wide-EP 是让它成立的前提；第三，25 倍依赖 96% 命中，短 prompt、低复用流量的收益会小得多。所以真实世界的差距小于 40 倍，但「预填充成本降一个数量级、解码成本靠并发摊薄」这两个结论是稳的。

把时间轴拉长，还能看到这套账的连续性：2025 年 2 月官方公布的 H800 生产数据是单节点输入 73.7k Token/s、输出 14.8k Token/s，按 2 美元/卡·时租金计日成本 8.7 万美元、日收入 56.2 万美元、成本利润率 545%。一年半后硬件、模型、价格都换了，但「把账算给你看」的方法没变——DeepInfer 只是把那张账本变成了代码。官方

9.2.6 成本优势的边界：什么情况下不成立

• 短 prompt / 低复用流量。25 倍建立在 77K 平均输入与 96% 命中上；如果请求都是几百 Token 的一次性输入，缓存几乎帮不上忙，优势退化为「模型架构 + 调度」的部分。
• 命中率对 TTL 敏感。聊天流量的 TTL 从 7 天缩到 3 天，命中率掉 0.5%–1%；反过来，任何缓存失效都会让那部分请求回到全量预填充。
• 低并发时投机解码会亏。DSpark 在 16 并发时是 −1.5%，要到 32 并发以上才转正。
• 规模不够摊不薄。最小高效单元是 64P + 64D；小集群享受不到 Wide-EP 与 3FS 的规模效应，反而要承担超节点与存储的固定成本。
• 口径本身有水分。155 万亿 Token/天是名义 Token（很可能包含缓存命中），不等于实际计算量；38 美元是收入不是毛利；80% 的调度效率意味着还有 20% 的浪费。

9.2.7 为什么别人难复制

表 12　成本能力的可复制性

可复制性	内容
已开源、可直接借	算子与内核（FlashMLA / DeepGEMM / DeepEP / TileKernels / DeepSelect）、SWA 有界回放、DSpark、异步调度、EPLB 超参、结构化输出、deepseek-recipe 协议层
需要重资产	Wide-EP 所需的 64–128 卡超节点、3FS 级共享存储、以及集群本身
未开源、也最难	KV Cache 系统（kvcache-store + 3FS 客户端）、E/P/D 分离编排、跨 DP 请求级负载均衡、自动扩缩容与配额
前提条件	模型权重可用（V4.1 Flash 已开源）、流量结构足够「长上下文 + 高复用」、硬件在 SM100 / 昇腾 950 之列

这张表解释了 DeepInfer 开源的真实边界：它开源了「算得快」的引擎，却没有开源「算得省」的缓存与调度。成本是五层相乘——只拿到引擎，最多复刻其中一层半；想要同样的成本曲线，得自己补齐存储、编排与调度，而那恰好是与 3FS、集群配额、内部运维强耦合的部分。

这也是为什么「开源生产栈」对 MaaS 市场是压力而不是礼物：当「高效推理应该长什么样」被写成代码，推理溢价就很难再靠信息不对称维持。但真正决定成本的那几件东西仍在 DeepSeek 手里，所以短期内它依然是「参考实现」，而不是「可复制的成本」。

9.3 对开源生态：参考实现的价值大于可部署价值

对绝大多数团队，DeepInfer 今天不能直接用：硬件门槛（SM100/950）、单模型、缺三件套、无服务层，四道门加起来，迁移成本约等于「自建一个新服务栈」。它真正的作用是参考实现——把 DeepSeek 踩过的坑与调好的参数（EPLB 冗余专家数、重排周期、DSpark 验证长度、SWA 命中回退策略、3FS 块粒度）摊开，让后来者少走弯路。

这也解释了一个看似矛盾的现象：Star 数很高（1.26 万），但社区讨论集中在「缺什么」「能不能支持 H100」「怎么接 HTTP」，而不是「我跑起来了」。判断

9.4 对 DeepSeek：三层开源栈成型

把三件事放在一起看，DeepSeek 的意图很清楚：模型权重开源（V4 Pro/Flash）+ 引擎开源（DeepInfer）+ API 协议对齐（deepseek-recipe，与官方 API 行为一致）。这套组合的目标不是「让所有人自建」，而是降低「第三方部署与官方 API 行为不一致」的摩擦，把生态锁在自己的协议与模型上。

至于为什么 KV Cache 与负载均衡不开源，官方的解释是与内部基础设施耦合太深。这个解释成立，但也要看到另一面：这两块恰好是与 3FS、集群调度、配额系统绑定的部分，开源出去对内部没有收益，对竞争对手却是直接帮助。判断

9.5 三类读者分别该怎么看

表 13　行动建议

读者	建议
云厂商 / MaaS	读 doc/inference_deployment_qa.md 的调度与 KV 章节，对标自己的分桶策略、EPLB 超参、KV TTL；不建议直接替换现有栈
有 Blackwell 集群的企业	可做 V4.1-Flash 私有化部署的可行性验证，但要预留服务层与存储层工作量；先确认 128 卡起步的规模是否匹配负载
开发者 / 研究者	把它当教材：SWA 有界回放、DSpark 变长验证、异步调度的实现细节都在代码里；昇腾适配可作国产化迁移参考

SECTION 10上手清单与风险

10.1 硬门槛

10.2 最小验证路径

编译与离线推理的命令很短，真正的成本在环境与权重：

export DEEPINFER_ACCELERATOR=nvidia（昇腾用 ascend）
./build.sh
python examples/offline_inference.py --ep 8

——DeepInfer README / examples

仓库还给了 benchmark、sweep（吞吐—延迟曲线）、YoCo mask 等价性验证、AIME/HLE/GPQA 离线评测四套脚本，是复现官方曲线最直接的入口。

10.3 风险清单

表 14　采用前必须评估的风险

风险	说明
硬件锁定	仅 SM100 与昇腾 950，且 FP4 权重需要相应算力；H100 及以下无路径
单模型绑定	只支持 V4.1-Flash，模型换代可能需要重新适配；官方承诺后续模型继续在 DeepInfer 开源，但节奏未知
半成品交付	无服务层、无存储层、无编排层；0.1.0 Beta、无 release、无 CI
无第三方复现	所有性能数字厂商自报，benchmark 只有 PNG 曲线，没有原始数据与数据集
维护不确定性	无 issue 区、119 个 PR 待合并、文档中英混杂；上游同步计划未公布
昇腾信息空白	无性能、无精度、无最佳实践，短期不可用于生产评估

SECTION 11资料来源

一手（官方）

1. DeepInfer 仓库与 README：github.com/deepseek-ai/DeepInfer
2. 部署 Q&A（本报告核心依据，312 行）：doc/inference_deployment_qa.md
3. 评测说明与参考分数：eval/README.md
4. 示例与 benchmark 说明：examples/README.md
5. deepseek-recipe：github.com/deepseek-ai/deepseek-recipe
6. 2025 年「为何不开源推理引擎」声明：open-infra-index
7. 官方技术报告（知乎，直连 403，经媒体转述引用）：zhuanlan.zhihu.com/p/2095560295930508953
8. 模型权重：huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017

媒体报道（二手，用于交叉核对）

9. 智东西《DeepSeek 推理框架全开源，公布日均吞吐和毛利》：zhidx.com/p/602635.html
10. 量子位《DeepSeek V4 报告太详尽了！484 天换代之路全公开》：qbitai.com/2026/04/406809.html
11. 量子位《DeepSeek V4.1 重回国产一哥！全新架构非对称 Transformer》：智源社区转载
12. 量子位《DeepSeek 新模型发布（V4.1-Flash-1017）》：qbitai.com/2026/10/504067.html
13. 新华社《China Focus: DeepSeek unveils new AI model》（V4 发布）：english.news.cn

第三方核查

14. Hacker News 讨论（2,132 分 / 830 评论）：news.ycombinator.com/item?id=50163277
15. GitHub API 元数据与 PR 列表（Star / Fork / has_issues 实测）：api.github.com/repos/deepseek-ai/DeepInfer