DeepSeek 把支撑 V4.1 Flash 在线服务的核心推理引擎 DeepInfer 开源了。它负责安排显卡怎样分工、怎样复用已算过的结果、怎样连续生成回答，让硬件少重算、少等待。

这套技术已经用于单集群每天约 155 万亿 token 的生产服务。它省掉的计算也有具体结果：准备模型开始回答时，一项局部状态重建优化让总预填充计算量接近减半；生成回答时，系统根据草稿的把握大小分配验证计算，在接近生产负载的官方基准中，相比每轮固定验证 5 个草稿的方案，估算吞吐提高约 4%～7%。一个减少回答前的准备计算，一个提高生成阶段单位时间的产出。

同批开放的还有 deepseek-recipe：它把外部软件的 API 请求转成模型输入，再把模型输出还原为正文、思考内容或工具调用响应。这次交给开发者的是可查看、测试和复用的核心代码；完整在线服务所需的缓存管理和服务层负载均衡还需另行配套。

要理解这两套组件解决的核心问题，可以看一个常见的实际交互：你向大模型发送了一篇长文让它写总结，随后又针对总结中的某一点继续追问。

这次交互包含两段主要计算，以及一项决定追问时是否需要重算的缓存机制：

1. 读输入（Prefill）：模型首先要读取你发来的长文。文字会被切分成模型处理的基本单位——token（token 与字数不一一对应，一个词可能被切成多个 token）。这些输入 token 是预先给定的，GPU 可以把它们组织成大矩阵批量计算，充分调动张量计算核心。
2. 逐步生成（Decode）：总结正文时，模型无法预知后续内容，只能基于前面的输入一步步计算并预测下一个 token。混合专家模型（MoE）包含许多称为“专家”的计算模块，每个 token 只选择其中一部分参与计算。模型虽然不必每步动用全部专家，但每生成一个 token 都需要访存并推进自回归计算，往往更受显存带宽与卡间通信约束。
3. 状态复用（KV 缓存）：当你基于总结继续追问时，前文的上下文其实已经计算过。如果系统能把先前计算的键值缓存（KV Cache）保存下来，第二轮对话就可以复用已经算好的部分，减少对整篇长文的重复计算。

针对这些环节的计算开销，DeepInfer 在离线引擎中实现了算子优化、大专家并行、有界重放与动态投机验证；deepseek-recipe 则在前后端之间架起高效对齐的协议与解析通道。

读输入与逐步生成：服务规模化时的解耦设计

读取长输入与逐步生成回复，对硬件的需求不同。将它们分开部署，可以分别分配资源，优化开始回答前的等待和回答过程中的生成速度。

在其大规模在线服务中，DeepSeek 选择了将视觉编码（VE）、输入预填充（Prefill）与逐步生成（Decode）在物理服务层面进行解耦部署（E/P/D Disaggregation）：

• Prefill 阶段：面对长文或大批用户提问，计算模式更适合大批次（batch）矩阵运算。DeepSeek 将其部署在普通的 8 卡 GPU 机器上，采用较小规模的专家并行（如 EP2～EP8），利用显卡的张量计算能力快速处理未缓存的输入。
• Decode 阶段：逐步生成需要兼顾批处理并发、显存带宽与跨卡通信。DeepSeek 将其部署在 64～128 卡的高带宽互联超节点上，使用超大专家并行（Wide-EP），把专家分散在更多卡上以摊薄单步访存压力。
• 视觉编码（VE）：独立使用单卡处理图片输入，根据图像的 patch 数量进行负载均衡，再将视觉特征送入 Prefill 节点。

通过这种服务分工，Prefill 可以专注优化首字生成前的吞吐与计算效率，Decode 则专注保障用户接收回复时的平稳流速。完整的在线分工还依赖缓存与负载均衡服务；本次开放的是离线推理引擎核心，尚未包含整套线上服务。

访存与复用：Wide-EP、按类型存放的 KV 缓存与 SWA 有界重放

在 Decode 阶段，由于每个 token 只激活 MoE 模型的部分专家，如果只在少数几张显卡上运行，每张卡都需要承载较多专家参数，多并发下显存带宽容易成为瓶颈。

把专家分到更多卡上，也给热门专家安排副本

DeepSeek 的应对方案是采用 Wide-EP，将专家分布到 64 甚至 128 张 GPU 上。每张卡负责的专家数量减少，每张卡在一步中需要读取的专家权重随之减少。为了防止某些热门专家请求过于集中导致计算不均，系统引入了专家并行负载均衡（EPLB）：在各卡保留若干冗余专家槽位作为热点副本，根据近期执行统计动态调整专家分配。

下图把 8 卡和 64 卡两种配置放在一起比较。图中的 DP rank 指参与数据并行的一路计算进程；这里每张 GPU 对应一路。“每路 64 个请求”指各路分别同时处理 64 个请求，并非整个集群合计只有 64 个。单用户速度、每卡吞吐和集群总吞吐因此是不同的统计范围。

追问长文时，复用上一次的计算

当用户反复针对长文提问时，重复计算历史提示词的开销极大。生产系统将两类缓存分开保存：

• 分块 KV 缓存（Block KV）：模型主体的分块 KV 缓存储存在专用的 3FS 分布式固态硬盘集群中（规模约 100 PiB），在 Agent 场景保留约 3 天，Chatbot 场景保留约 7 天。将这部分缓存独立出来，使得任意一台 Prefill 机器都能读取已有的前缀缓存，避免为了命中文档而必须把请求路由到特定机器，不必把追问固定送回上次计算长文的那台机器。
• SWA 状态与主机内存：滑动窗口相关的 SWA 状态并不写入 3FS，而是保留在生成它的计算节点本地主机内存中，通过局域网在机器间调度调取。
• 匹配与传输：前缀匹配必须在请求路由前由入口节点基于哈希快速完成，以便确认有效命中长度；随后在后台异步拉取缓存数据，尽量让数据搬运与前向计算重叠，减少搬运造成的等待。

局部状态缺了，只重建需要的那一段

这套模型同时使用局部窗口内的状态和可复用的分块缓存。滑动窗口注意力（SWA）只在一个有限窗口内计算相邻 token 的关系。当长文缓存出现部分缺失或初始化解码器时，是否需要把数千个 token 完整重算？

DeepInfer 采用 SWA 有界重放 进行近似局部状态重建：

• 分块缓存命中、局部 SWA 状态缺失时：如果 Block KV 命中但局部的 SWA 状态缺失，系统无需重新计算整篇长文，只需重算命中前缀末尾的 128 个 token 来重建局部 SWA 状态，同时直接复用既有的 Block KV。
• 解码器（Decoder）预填充时：这个模型内部还有分工：编码层先处理上下文，把计算结果交给解码层。解码层所需的分块缓存可以由编码层的结果直接转换而来，无需逐层重新建立；还要恢复的是每层的局部 SWA 状态。这里说的是模型内部的计算层，与前文分开部署的两类服务是不同层次的分工。若精确重建解码器 SWA 状态，需要让最后 2,560 个 token 通过 20 层解码器；而有界重放仅对提示词末尾的 128 个 token 在解码层进行近似局部重算。该近似结果仅用于启动当前解码，不写入前缀持久缓存，官方测算这一做法将总 Prefill 计算量减少了近一半。

在引擎配置中，参数通常设为保留 140 个 token（如 DEEPINFER_YOCO_PREFILL_KEEP_TOKENS=140），这是因为保留区间除了 128 个 token 的局部窗口外，还需覆盖投机回溯等边界余量，两者在机制上各有分工。

流水线重叠：减少设备空等的异步调度

在大模型逐步解码过程中，标准的执行流程通常是：GPU 计算当前步（前向计算与采样）→ 结果同步回 CPU → CPU 整理结果并规划下一步批次 → 向 GPU 下发新任务。在每一步之间，GPU 往往需要等待 CPU 的调度与后处理逻辑完成。

业界在 SGLang、NanoFlow 等框架中已广泛探索重叠流水线。DeepInfer 同样采用了异步调度机制：当 GPU 执行第 N 步的前向计算与采样时，CPU 在后台并行完成第 N+1 步的批调度与前向任务派发，并穿插处理第 N-1 步的后处理，使 CPU 准备工作与 GPU 计算尽量重叠，从而减少 GPU 的空闲等待。

DSpark：把验证计算花在更有把握的草稿上

在执行解码时，提高生成速度的常用方法是投机解码：由轻量级草稿模型预先连续猜测若干候选 token（默认最多 5 个），再由主模型在单次前向传播中一并验证。

这里比较的固定长度方案，每次验证 5 个草稿 token。但不同请求、不同位置的草稿被接受的概率并不相同，全部验证会把部分计算花在把握较低的候选上。

DeepInfer 的 DSpark 方案引入了基于置信度的动态验证调度。草稿模型提供候选 token 后，系统通过置信度预测头（Confidence Head）评估每个位置的接受概率，并结合硬件吞吐特征动态确定当步最优的验证长度，优先把验证预算分配给高期望收益的 token：

• 生产基准并发（单 rank 60 序列）：平均每步验证的草稿长度从固定 5 个降至 3.58 个；而平均通过验证的草稿数量仅从 3.30 略降至 3.21，官方据此估算单 rank 吞吐从 13,730 提至 14,466 token/s，获得约 +5.4% 的吞吐收益。
• 并发规模的影响：在单 rank 96 序列的高并发下，动态验证的吞吐增益达到 +11.0%；但在单 rank 16 序列的较低并发下，吞吐录得 -1.5%（从 4,891 降至 4,816 token/s/rank）。

服务更多人，和让每个人更快，是两个目标

官方在测试脚本中通过扫描不同批处理参数，绘制了 Prefill 与 Decode 两个阶段的吞吐与响应速度的曲线。阅读这两张图表时，需结合具体的测量口径理解。

1. Prefill 阶段：批大小与单步耗时

在 Prefill 测试中，横轴记录的是 GPU 执行单个批处理分块（Chunk）的物理耗时，纵轴为单卡每秒处理的未缓存输入 token 数量：

• 批大小设为 4,096 时，单步耗时约 68 毫秒，单卡吞吐约 60,000 token/s；当批大小扩大至 65,536 时，单卡吞吐升至约 89,500 token/s，单步耗时相应增加至约 732 毫秒。
• 读图时需注意，单步分块耗时并不等同于用户的首字返回时间（TTFT）。实际线上请求的首字返回还受到网络传输、排队调度、缓存匹配与分块传输等多重环节影响，超长输入也会被拆分为多个分块连续计算。

2. Decode 阶段：并发与交互流速

Decode 曲线展示了在不同并发规模下的资源取舍：

• 当单 DP rank 仅有 8 个并发请求时，每卡输出吞吐约为 2,600 token/s/GPU，折算出的单用户生成速度约为 325 token/s；当并发上升到 256 时，整卡输出吞吐升至约 26,300 token/s/GPU，单用户折算速度降至约 103 token/s。
• 此处曲线采用了扫点脚本中的固定折算参数：设定固定 3 个草稿 token（nextn=3），按假定 75% 接受率折算，即每步按 1 + 3 × 0.75 = 3.25 个 token 折算。这一数值并非直接测量线上用户的终端打字体验，也不同于前文 DSpark 动态验证的 5 草稿配置，而是用于在基准测试中统一衡量包含投机收益时的输出吞吐。

deepseek-recipe：让自建服务接得住真实 API 请求

与 DeepInfer 协同开源的 deepseek-recipe 是一个用 Rust 编写并提供 Python 绑定的请求转换与分词组件。它负责连接上层标准 API 与底层推理引擎：

上层请求 (Messages / Chat Completions / Responses)
  │
  ▼
deepseek-recipe: 转换为统一 Conversation 格式
  │
  ▼
拼装模板并编码为 Token ID 序列（附带结构化输出约束等配置）
  │
  ▼
调用方推理引擎执行前向计算（DeepInfer 等）
  │
  ▼
输出 Token 流解析为事件（思考过程、正文、工具调用）
  │
  ▼
流式组装并返回对应协议响应

该组件的核心职责是实现与 DeepSeek 官方 API 一致的处理逻辑。调用方仍需自行提供推理服务、HTTP 传输及工具执行环境。对齐处理逻辑主要体现在三个具体环节：

1. 控制标记与普通文本隔离

在提示词构建阶段，deepseek-recipe 会显式记录模板自带控制标记（如角色切换标记）的位置，直接映射为对应的特殊 Token ID。而所有来自用户输入或外部工具返回的普通文本，一律使用基础词表编码。 例如，若用户在输入内容中手工写下 <｜User｜>，该字符串会被编码为普通文本字符序列，不会被系统误当成真正的角色控制标记；同样，在输出解析时，模型真正的思考结束标记 </think> 与工具标签也是通过专用 Token ID 识别，即便模型在普通文本中输出了相同的字面文本，也会按原样保留，避免干扰流程控制。

2. 分段并行分词与结构化约束

由于模板中的特殊标记位置在拼装时已经确定，夹在标记之间的普通文本段可以独立进行 BPE 编码。deepseek-recipe 对这些文本段进行并行分词后再行拼接，从而降低长文本输入的编码耗时。 对于需要强制返回特定格式的请求，deepseek-recipe 负责整理并传递结构化输出约束，是否强制执行由推理后端决定。DeepInfer 支持将 JSON Schema、正则表达式或语法规则编译为语法状态机。在模型解码的每一步中，引擎根据当前状态机筛选出合法的候选 token 集合并施加掩码，强制输出符合预设结构，但这只保证格式合规，不保证内容事实正确。

3. 跨分块流式解析与工具参数分片

推理引擎是以 token 为单位流式吐出结果的，一个多字节的 UTF-8 字符、用于组织工具调用的 DSML 标记或工具参数可能被切碎在不同的数据包中：

• 当遇到尚未接收完整的多字节 UTF-8 字符时，组件内部状态机会暂存相应字节，待后续 token 补齐后再行输出，防止向客户端推送乱码。
• 识别到工具调用时，组件无需等待整段 JSON 完整生成，而是根据 DSML 语法边界解析参数，边生成边转义并推向客户端，使客户端能够更快收到首个参数片段。

哪些团队能用，离完整在线服务还有多远

1. 开源范围与未包含组件

• 已开源内容：DeepInfer 开源了离线推理引擎核心，包含注意力数据并行（DP）、MoE 专家并行（EP）、SWA 有界重放、DSpark 投机验证与结构化输出支持，适配 DeepSeek-V4.1-Flash 模型。配套算子库包含 DeepGEMM、DeepEP、TileKernels 以及 FlashMLA（官方注记其相比内部版本缺少一处手调 SASS 优化，解码核函数慢 5%～10%，端到端差异在 5% 以内）。deepseek-recipe 则开放了完整的请求转换、分词与流式解析实现。代码分别采用 Apache 2.0 与 MIT 许可证，官方承诺未来 DeepSeek 模型的推理代码与持续优化将继续在仓库更新。
• 架构归属与未包含部分：DeepInfer 最初主要基于 vLLM 构建，并借鉴了 SGLang 与 TensorRT-LLM 的设计思路。本次未开放的部分包括与生产集群深度耦合的 KV 缓存管理系统集成、跨 DP 副本的负载均衡网关，以及完整的在线 E/P/D 分离服务编排。
• 硬件支持：DeepInfer 首发支持 NVIDIA SM100 GPU 与华为昇腾 Ascend 950 NPU。

2. 部署规模与适用场景

• 集群与测试规模：官方生产部署建议的高效单元为 64 卡 Prefill 配合 64 卡 Decode（64P+64D，以充分利用 Wide-EP 的多卡访存优势）。但框架并非必须 128 卡才能运行，文档说明一个 Prefill 服务实例加一个 Decode 服务实例（1P+1D）即可部署，这里的实例并不等于一张卡，仓库中的离线推理示例也提供了 8 卡单机的运行选项。
• 不同角色的使用价值：
  • 拥有适配硬件的团队：可以直接基于 DeepInfer 的离线引擎与算子库测试长上下文下的吞吐表现，作为工业级分布式推理的参考实现。
  • API 服务集成者：即便不直接运行 DeepInfer 引擎，也可以独立引入 deepseek-recipe，规范处理多协议请求转换、提示词模板拼装与流式事件解析。
  • 需要做回归比较的团队：NVIDIA 平台还提供批次不变性与确定性采样配置，便于检查同一输入的结果是否一致；确定性采样需要固定种子并关闭动态草稿。