---
title: "DeepInfer 是什么？DeepSeek 如何优化大模型推理效率"
source: https://www.iowill.com/blog/2026/10/deepinfer-deepseek-inference-efficiency/
date: 2026-10-26
updated: 2026-10-26
tags: [DeepInfer, DeepSeek, 大模型推理, 性能优化]
categories: [软件与工具]
---

# DeepInfer 是什么？DeepSeek 如何优化大模型推理效率

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

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

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

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

模型、推理框架与在线服务承担不同职责：

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

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

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

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

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

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

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

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

[NVIDIA的推理基准说明](https://developer.nvidia.com/blog/?p=98215)还提醒：用户感受到的首个token等待时间不仅包含Prefill，也可能包含排队、网络和其他处理开销。因此，首字慢不一定是模型计算本身慢。

![Prefill处理已知输入与Decode按依赖继续生成的原理示意，以及KV缓存和用户等待的区别](https://img.iowill.com/file/软件与工具/DeepInfer推理效率/body1.png)

图1：Prefill与Decode承担不同计算任务；图中编号仅示意阶段内的生成顺序，不编码实测耗时。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[DeepInfer官方问答](https://github.com/deepseek-ai/DeepInfer/blob/553741557a57df44a46fb3ab72b6aafeaf945337/doc/inference_deployment_qa.md)描述的异步调度，将CPU调度与设备执行重叠起来：当前轮计算推进时，CPU准备后续工作，缩短两轮之间的空档。

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

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

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

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

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

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

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

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

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

### KV缓存复用的是中间状态

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

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

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

### SWA有界重放包含近似恢复

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

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

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

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

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

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

![计算内核、专家通信、异步调度、草稿验证、KV缓存与近似SWA重放各自减少的开销及适用边界](https://img.iowill.com/file/软件与工具/DeepInfer推理效率/body2.png)

图2：不同优化机制对应不同瓶颈；有界重放的近似状态不能与精确计算优化混为一谈。

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

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

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

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

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

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

推理速度需要分别考察响应延迟、生成速度和吞吐等指标，不能只选一个数字代表全部体验。

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

这些指标可对照[NVIDIA的基准指标定义](https://docs.nvidia.com/deeplearning/triton-inference-server/archives/triton-inference-server-2670/user-guide/docs/perf_analyzer/genai-perf/README.html)。系统总吞吐量提高，不代表每个用户都更快；低并发下某条回答生成很快，也不保证高峰期仍有相同体验。

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

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

## 参考资料

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

1.  [DeepInfer README（固定提交）](https://github.com/deepseek-ai/DeepInfer/blob/553741557a57df44a46fb3ab72b6aafeaf945337/README.md)：项目定位、公开范围与基准环境。
2.  [DeepSeek推理问答（固定提交）](https://github.com/deepseek-ai/DeepInfer/blob/553741557a57df44a46fb3ab72b6aafeaf945337/doc/inference_deployment_qa.md)：异步调度、DSpark、SWA重放与生产系统说明。
3.  [FlashAttention原始论文](https://arxiv.org/abs/2205.14135)：注意力计算中的存储读写优化。
4.  [DeepGEMM官方仓库](https://github.com/deepseek-ai/DeepGEMM)：矩阵计算与专家分组计算布局。
5.  [DeepEP官方仓库](https://github.com/deepseek-ai/DeepEP)：专家并行的数据分发和结果合并通信。
6.  [Fast Inference from Transformers via Speculative Decoding](https://proceedings.mlr.press/v202/leviathan23a.html)（ICML 2023）：推测解码及其采样条件。
7.  [How caching works](https://huggingface.co/docs/transformers/main/en/cache_explanation)：KV缓存的作用与生成过程。
8.  [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180)：服务内存管理与批处理的关系。
9.  [LLM Inference Benchmarking: Fundamental Concepts](https://developer.nvidia.com/blog/?p=98215)：Prefill、Decode与延迟吞吐量概念。
10.  [GenAI-Perf指标文档](https://docs.nvidia.com/deeplearning/triton-inference-server/archives/triton-inference-server-2670/user-guide/docs/perf_analyzer/genai-perf/README.html)：具体测量指标与统计口径。