向大模型发送一个问题，等待通常分成两段：先等它开始输出，再等它把回答生成完。遇到长文档、长回答或高峰期，这两段等待还可能以不同方式变长。

DeepInfer关注的正是这些计算背后的执行效率。它是DeepSeek开源的推理框架：围绕模型执行，协调计算内核、设备通信和任务调度，让已有硬件更有效地完成推理工作。 它本身不会因为运行得更快，就让同一组模型权重学会新的知识。

本文以2026年10月26日核对的官方README及问答为项目依据，结合原始论文与技术文档解释机制，不包含安装步骤或作者性能实测。DeepInfer资料固定在提交553741557a57，避免把后续变化混入当前说明。

DeepInfer与模型、在线服务分别负责什么

理解推理框架，可以先分清三层：

层次 主要职责 可以怎样理解
模型 依据结构、权重和输入计算输出分布 决定当前模型具备怎样的能力
推理框架 执行模型计算，安排批次、内存与并行任务 组织这些计算怎样完成
在线服务 接收请求，提供路由、鉴权、限流与服务保障 让用户能够稳定调用

三者会相互影响，但不能互相替代。读到“模型开源”“推理框架开源”或“提供API”时，首先应确认说的是哪一层。

在本文核对版本中，DeepInfer列出的支持模型为DeepSeek-V4.1-Flash，公开内容提供离线推理及相关核心能力。README也单独列出了完整服务还需要补齐的系统组件。因此，不能把官方问答里的全部生产系统能力，都直接算作公开仓库已经交付的功能。

为什么读问题与生成回答会有不同瓶颈

理解推理效率，要先认识两个阶段。

Prefill负责处理输入上下文。 例如输入一篇长文档时，模型需要计算各位置的表示，并准备后续生成会用到的状态。由于输入内容已经给定，许多位置的计算可以组织成较大的并行任务；这与“不知道后面会生成什么”的情况不同。

Decode负责继续生成输出。 在普通自回归生成中，下一个token依赖已有上下文和刚生成的内容，因此同一条回答存在逐步推进的依赖。token是模型处理文本的单位，并不固定等于一个汉字或一个单词。

这两段计算都可能受到算力、显存访问、通信等因素限制。较长输入常增加Prefill工作量；小批次Decode则可能更容易受到搬运权重、读取缓存等开销影响。随着并发、上下文和硬件变化，主要瓶颈也会变化，不能把所有Decode一概称为“只受显存带宽限制”。

NVIDIA的推理基准说明还提醒：用户感受到的首个token等待时间不仅包含Prefill，也可能包含排队、网络和其他处理开销。因此，首字慢不一定是模型计算本身慢。

Prefill处理已知输入与Decode按依赖继续生成的原理示意，以及KV缓存和用户等待的区别
图1：Prefill与Decode承担不同计算任务；图中编号仅示意阶段内的生成顺序，不编码实测耗时。

计算内核：让数据搬运和矩阵计算更有效率

推理过程中会反复执行矩阵乘法、注意力等操作。硬件标称算力很高，也不意味着每一种计算形状都能充分利用它：数据布局、批次大小、中间结果存放位置和算子衔接，都可能影响实际耗时。

DeepInfer列出的底层组件包括DeepGEMM、FlashMLA和DeepEP等。这里可以先抓住一个原则：优化不仅是“多做并行计算”，也包括减少不必要的数据搬运，并让计算形状更适合硬件。

FlashAttention原始论文提供了一个有代表性的例子：通过分块组织注意力计算，减少GPU不同存储层级之间的读写。它说明，数学任务相同，执行方法不同，时间和内存开销仍可能不同。这里借用的是通用原理，不能把FlashAttention与DeepInfer所用的FlashMLA当作同一个实现。

在MoE模型中，不同专家收到的token数量也可能不同。DeepGEMM文档介绍了面向专家计算的分组矩阵乘法布局。这样的优化针对具体计算形状和数据组织，并不是给任意模型加上一个“提速开关”。

专家并行：计算分出去以后，还要把数据送对地方

MoE可以理解为：模型中有多个专家子网络，路由机制让token交给其中选定的专家处理。“专家”在这里是计算模块，不是若干个独立聊天机器人。

当专家分布在不同设备上时，一次计算往往包含数据分发、专家计算和结果合并。设备更多，既增加了可用计算资源，也增加了组织通信的要求。

DeepEP官方说明将MoE的dispatch和combine列为专家并行通信的重要操作。可以把它理解成：任务分出去之前先送到正确位置，做完以后再把结果汇合。只计算专家内部的耗时，可能遗漏这两段成本。

此外，负载不均衡也会拖慢整体进度。某些专家很忙、另一些设备很空时，关键路径仍可能被最慢的一方决定。专家负载均衡与更高效的通信，都是让并行真正产生收益的条件。

因此，阅读DeepInfer的专家并行设计时，更值得问的是：什么工作被分散了，哪些数据必须交换，最忙的设备是否决定了等待时间？仅看设备数量，回答不了这些问题。

异步调度：让CPU安排工作时，GPU继续计算

推理不只是GPU运行模型。CPU还需要维护请求状态、决定下一批处理哪些序列，并接收生成结果。

若这些步骤严格串行，GPU做完一轮后，可能还要等CPU整理结果、安排下一轮。这段时间里，计算设备未必有足够工作可做。

DeepInfer官方问答描述的异步调度，将CPU调度与设备执行重叠起来：当前轮计算推进时，CPU准备后续工作，缩短两轮之间的空档。

这里减少的是等待，不代表模型中的矩阵乘法天然变快，也不代表CPU工作消失了。官方使用的“zero-overhead batch scheduler”名称，应结合其流水线目标理解，不能外推成整个服务没有调度或同步成本。

批处理则解决另一个相关问题：让多条请求共享一轮计算，提高资源利用率。但批次越大未必越好，等待凑批、内存占用和请求间干扰都可能影响延迟。PagedAttention论文讨论了KV缓存管理如何限制可承载批次，这可作为理解批处理与内存关系的背景，并非证明DeepInfer采用了该论文的全部机制。

草稿验证：一次主模型计算能否推进更多token

普通生成按依赖关系逐步推进。推测解码换了一个思路：先用更便宜的路径提出若干候选token，再交给目标模型验证；被接受的候选可以一次推进多个位置。

这不是直接把草稿展示给用户。收益取决于候选有多少能被接受，以及生成草稿、验证和处理回退各要花多少时间。若候选经常被拒绝，额外工作就可能抵消收益。

DeepInfer中的DSpark进一步涉及“验证多少草稿”的选择。官方问答描述了利用置信估计分配验证预算的方式：有限的计算不一定平均花在每个候选上，而是考虑预计能接受多少内容以及硬件的处理效率。

ICML 2023的推测解码论文展示了在其算法条件下保持目标采样分布的做法。但这不意味着任意带“草稿”或“置信度”字样的实现，都自动获得同样保证；分布一致也不等于每次运行都会生成逐字相同的文本。

分析具体系统时，仍需核对验证规则、采样参数、数值精度与复现条件。

缓存与有界重放：减少重复工作，但要分清代价

KV缓存复用的是中间状态

普通自回归注意力在生成新token时，会再次使用已有上下文对应的Key和Value。KV缓存把这些中间结果保留下来，避免每一步都重新计算已有部分；Hugging Face文档对此给出了逐层解释。

它不是“把整道题的最终答案存起来”。新问题即使能复用部分上下文状态，仍可能需要新的计算和生成。

复用也有条件：输入前缀及相关执行状态需要兼容，缓存还会占用容量。缓存命中后是否值得读取，要结合传输与重新计算的代价判断。上下文长度、并发数增加时，缓存管理本身也可能成为压力来源。

SWA有界重放包含近似恢复

DeepInfer还提供SWA有界重放。SWA指滑动窗口注意力；“重放”是重新计算一段内容，以恢复后续执行需要的状态。

官方问答说明，有界重放只重算最近一段内容，并限制重放段内的注意力范围，得到近似的SWA缓存。它减少了恢复状态需要的工作量，但不能简单写成“与完整重算严格等价”。这与前文介绍的精确注意力执行优化，是不同性质的处理。

这里也不意味着随意删除用户输入。它依赖特定模型结构、状态布局与边界条件，效果要结合任务评估，不能照搬为所有模型都适用的技巧。

单次生成缓存与跨请求缓存系统不同

单次生成过程复用KV、重复前缀跨请求复用，以及跨节点保存和调取缓存，属于不同层次。

公开框架包含相关引擎机制，不等于完整生产缓存系统已经一并公开。本文只解释减少重复计算的思路，不把内部系统的全部缓存能力算成公开代码的开箱即用功能。

计算内核、专家通信、异步调度、草稿验证、KV缓存与近似SWA重放各自减少的开销及适用边界
图2：不同优化机制对应不同瓶颈；有界重放的近似状态不能与精确计算优化混为一谈。

推理更快，是否意味着模型更聪明

通常不能这样判断。同一模型的执行效率提高，首先改变的是完成计算所需的资源与时间，不会自动增加模型已经学到的知识。

但“优化执行”也不能一概等同于“所有输出完全不变”。可以区分三种情形：

优化性质 阅读时应追问的问题
调整内核与执行安排 数值精度、计算顺序和复现条件是否一致？
借助候选与验证减少串行工作 采用什么接受规则，是否有分布保持条件？
用近似状态减少重算 近似作用于哪里，质量评估覆盖哪些任务？

更高效率可能为更长上下文、更多并发或更多推理预算创造空间，但是否将这些资源用于提高回答质量，仍取决于模型、产品和具体运行策略。

吞吐量、首字延迟与生成速度应该怎样看

“快”至少包含下面几种含义，不能只选一个数字代表全部体验。

指标 主要回答的问题 容易忽略的条件
首个token延迟（TTFT） 请求发出后，多久开始收到输出？ 排队、网络、输入长度与缓存命中
token间延迟（ITL） 输出开始后，后续内容推进有多快？ 流式响应可能一次携带多个token，需看工具定义
输出吞吐量 系统单位时间合计生成多少token？ 并发数、输出长度及统计时间窗口
端到端延迟 从发出请求到接收完整回答要多久？ 前期等待和整个生成过程

这些指标可对照NVIDIA的基准指标定义。系统总吞吐量提高，不代表每个用户都更快；低并发下某条回答生成很快，也不保证高峰期仍有相同体验。

DeepInfer README中的Prefill与Decode图分别使用4块和64块SM100 GPU测量，不能忽略设备配置，更不能把两张图直接合成一次真实请求的完整耗时。比较之前，还应核对模型版本、上下文长度、缓存条件、并发、精度及草稿验证设置。

本文没有运行这些测试，也不据此宣称DeepInfer在任意硬件、任意任务上都领先其他框架。它更值得关注的地方，是把推理效率拆成一组具体问题：计算是否合适、数据怎样流动、设备为何等待，以及哪些工作可以复用或减少。

参考资料

以下资料用于解释产品机制和通用原理；论文中的实验并不是对DeepInfer的独立性能复现。

  1. DeepInfer README（固定提交）：项目定位、公开范围与基准环境。
  2. DeepSeek推理问答（固定提交）：异步调度、DSpark、SWA重放与生产系统说明。
  3. FlashAttention原始论文：注意力计算中的存储读写优化。
  4. DeepGEMM官方仓库：矩阵计算与专家分组计算布局。
  5. DeepEP官方仓库：专家并行的数据分发和结果合并通信。
  6. Fast Inference from Transformers via Speculative Decoding（ICML 2023）：推测解码及其采样条件。
  7. How caching works：KV缓存的作用与生成过程。
  8. Efficient Memory Management for Large Language Model Serving with PagedAttention：服务内存管理与批处理的关系。
  9. LLM Inference Benchmarking: Fundamental Concepts：Prefill、Decode与延迟吞吐量概念。
  10. GenAI-Perf指标文档：具体测量指标与统计口径。