M7 · AI 模型如何生成输出？ - Inference & Decoding

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：02 · AI 模型是如何构建和工作的？ - Model Architecture
文档类型：模型推理机制与技术架构研究
版本：v1.0
更新日期：2026 年 10 月 27 日
核心问题：什么是模型推理？模型如何将输入转换为输出？大语言模型为什么逐 Token 生成内容？Logits、Softmax 和解码策略如何决定输出？Temperature、Top-k、Top-p 分别控制什么？Prefill、Decode 和 KV Cache 如何工作？推理时计算如何影响任务表现？推理成本、延迟和吞吐量由哪些因素决定？

专题导读

M6 研究了模型如何通过训练获得能力。M7 将研究模型训练完成之后，如何接收输入、执行计算并生成输出。

本篇重点解释大语言模型的推理过程，包括 Token 预测、自回归生成、解码策略、Temperature、Top-k、Top-p、KV Cache、Prefill、Decode、推理时计算，以及延迟、吞吐量和显存占用之间的关系。同时说明图像、音频等生成模型与语言模型在推理机制上的区别。

一、研究概述

在前面的研究中，我们已经建立了 AI 模型的基本技术框架。

M1 解释了模型架构、参数与计算之间的关系；M2 研究了神经网络如何学习；M3 解释了 Transformer 的内部结构；M4 和 M5 分别研究了大语言模型与多模态模型；M6 则系统研究了模型如何通过预训练与后训练获得能力。

这些内容主要回答了：

模型是什么、如何构建，以及如何获得能力。

但当一个已经完成训练的模型接收到用户输入时，究竟会发生什么？

例如，用户向语言模型输入：

请解释什么是人工智能。

模型为什么能够生成一段完整回答？

它是一次性计算出所有文字，还是逐步生成？

为什么相同的问题有时会得到不同回答？

为什么某些模型回答很快，而另一些模型需要等待较长时间？

为什么输入一篇很长的文档，会增加模型的计算成本？

这些问题都与模型推理（Inference）有关。

1.1 本篇的研究目标

本篇主要建立五个方面的认识。

第一，推理的基本机制。 模型如何接收输入，执行前向计算并产生输出。

第二，语言生成机制。 Token、Logits、概率分布和解码算法如何共同决定生成结果。

第三，Transformer 推理架构。 Prefill、Decode、KV Cache 和注意力计算如何影响运行效率。

第四，推理时计算。 模型如何利用额外的生成、搜索或验证计算改善复杂任务表现。

第五，推理工程。 延迟、吞吐量、显存、批处理和模型部署之间有什么关系。

1.2 本篇的研究边界

本篇以自回归大语言模型为主要研究对象，因为它是当前许多 AI 助手和 Agent 使用的核心模型类型。

但并非所有 AI 模型都采用逐 Token 生成。

因此，本篇还将介绍图像、音频和其他模型的典型推理方式，避免将语言模型的生成机制误认为所有 AI 模型的通用机制。

二、什么是模型推理？

2.1 模型推理的定义

模型推理（Model Inference）是指利用已经训练好的模型参数，对输入数据执行计算，并生成预测、表示或其他输出的过程。

对于参数化模型：

y = f_{θ} (x)

其中：

$x$ ：输入；
$f_{θ}$ ：模型定义的计算函数；
$θ$ ：训练得到的参数；
$y$ ：模型输出。

在常规推理过程中，模型参数通常保持固定。

模型利用这些参数执行前向计算。

2.2 推理不一定意味着生成文本

不同模型的推理输出可能完全不同。

模型类型	输入	典型输出
分类模型	图片	类别概率
回归模型	数值特征	连续数值
Embedding 模型	文本	向量
自回归语言模型	Token 序列	后续 Token
图像生成模型	文本或噪声	图像
语音识别模型	音频	文本
语音生成模型	文本	音频
VLA 模型	视觉与指令	动作表示

因此，推理是一个广义概念。

文本生成只是其中一种形式。

2.3 推理与训练的区别

维度	Training	Inference
主要目的	优化模型参数	使用已有模型
参数更新	通常更新	通常不更新
前向计算	需要	需要
反向传播	通常需要	常规推理不需要
优化器	通常需要	通常不需要
典型输出	更新后的参数	预测或生成结果
主要关注	学习效果与训练效率	输出质量、延迟与成本

需要注意，某些特殊方法可能在测试阶段更新参数，但这不属于常规语言模型推理流程。

三、大语言模型如何生成文本？

3.1 自回归生成

现代 Decoder-only 大语言模型通常采用自回归生成（Autoregressive Generation）。

其核心思想是：

根据已有 Token 序列预测下一个 Token，再将生成的 Token 加入上下文，继续预测。

假设输入为：

人工智能是一种

模型可能预测：

技术

随后根据：

人工智能是一种技术

继续预测下一个 Token。

这一过程不断重复，直到满足停止条件。

3.2 概率分解

对于生成序列：

y_{1}, y_{2}, \dots, y_{T}

模型通常按照以下形式建模：

P (y_{1}, \dots, y_{T} ∣ x) = \prod_{t = 1}^{T} P (y_{t} ∣ x, y_{< t})

其中：

$x$ ：输入上下文；
$y_{t}$ ：第 $t$ 个生成 Token；
$y_{< t}$ ：之前已经生成的 Token。

3.3 自回归生成流程

text

用户输入
   │
   ▼
Tokenizer
   │
   ▼
输入 Token
   │
   ▼
Transformer
   │
   ▼
下一个 Token 的概率分布
   │
   ▼
选择 Token
   │
   ▼
将 Token 加入上下文
   │
   ▼
再次执行模型计算
   │
   └──────────────► 重复

3.4 模型不是一次性输出完整文章

对于常见的自回归语言模型，最终文本通常通过多个生成步骤逐渐形成。

即使用户最终看到的是一篇完整文章，底层也通常经历了逐 Token 生成过程。

但需要区分模型的生成过程与应用界面的显示方式。

应用可以逐步显示 Token，也可以等待生成完成后一次性显示结果。

3.5 Token 不等于一个汉字或一个单词

Token 是模型使用的离散符号单位。

一个 Token 可能对应：

一个词；
词的一部分；
一个汉字；
多个汉字；
标点；
空格；
特殊符号。

具体划分取决于 Tokenizer。

因此，不能直接将 Token 数量等同于字符数量。

四、输入如何进入语言模型？

4.1 输入预处理

用户输入通常先经过应用层处理。

例如：

text

System Instructions
        │
Developer Instructions
        │
User Message
        │
Conversation History
        │
        ▼
模型输入构建

实际输入可能还包含：

工具定义；
工具返回结果；
检索文档；
图片或音频表示；
特殊控制 Token。

4.2 Chat Template

对话模型通常需要使用特定的消息格式。

例如，概念上可以表示为：

text

[system]
你是一个 AI 助手。
[user]
什么是 Transformer？
[assistant]

不同模型可能使用不同的特殊 Token 和 Chat Template。

如果输入格式与模型训练时使用的格式不一致，可能影响输出质量。

4.3 Tokenization

模型将文本转换为 Token ID。

X = (x_{1}, x_{2}, \dots, x_{n})

这些 Token ID 随后进入 Embedding 层。

4.4 Embedding

Embedding 层将 Token ID 转换为连续向量。

e_{i} = E [x_{i}]

其中：

$E$ ：Embedding 矩阵；
$x_{i}$ ：Token ID；
$e_{i}$ ：对应向量。

4.5 Transformer 前向计算

Token 向量进入 Transformer。

经过多层 Attention、FFN 和其他计算后，模型得到隐藏状态：

H = f_{θ} (X)

对于典型的自回归语言模型，可以使用最后一个有效位置的隐藏状态预测下一个 Token。

4.6 输出层

模型将隐藏状态映射为词表大小的分数向量。

z = h W_{out} + b

其中：

$h$ ：最后位置的隐藏状态；
$W_{out}$ ：输出投影矩阵；
$z$ ：Logits。

部分模型不使用独立的输出偏置项，或采用权重共享等设计。

五、什么是 Logits？

5.1 Logits 的定义

Logits 是模型在概率归一化之前，对候选输出给出的数值分数。

对于词表大小为 $V$ 的语言模型：

z \in R^{V}

其中每个元素对应一个候选 Token。

5.2 一个简化示例

假设词表只有四个候选 Token。

模型输出：

Token	Logit
苹果	3.2
香蕉	2.4
汽车	0.5
天气	-0.2

Logit 越高，通常意味着在经过相同概率变换后，对应 Token 的概率越高。

但 Logit 本身不是概率。

它可以是负数，也不需要位于 0 到 1 之间。

5.3 Logits 如何转换为概率？

通常使用 Softmax：

P_{i} = \frac{e^{z_{i}}}{\sum_{j = 1}^{V} e^{z_{j}}}

经过 Softmax 后：

0 < P_{i} < 1

并且：

\sum_{i = 1}^{V} P_{i} = 1

这就得到了下一个 Token 的概率分布。

5.4 概率分布不是最终输出

模型计算出概率分布后，还需要决定实际选择哪个 Token。

这个过程称为解码（Decoding）。

六、什么是 Decoding？

6.1 Decoding 的定义

在自回归语言生成中，Decoding 通常指根据模型输出的分数或概率分布，选择后续 Token 并逐步构造生成序列的过程。

需要注意，Decoding 一词也可能在其他模型架构中表示解码器网络的计算过程。

本篇主要使用语言生成中的解码含义。

6.2 为什么需要解码策略？

假设模型预测：

Token	概率
A	0.50
B	0.30
C	0.15
D	0.05

模型可以始终选择概率最高的 A。

也可以按照概率分布随机采样。

这两种方法可能生成不同结果。

6.3 解码策略影响什么？

解码策略会影响：

输出的随机性；
多样性；
重复程度；
稳定性；
生成结果的概率特征。

但解码策略不会直接修改模型参数。

因此，调整解码参数与重新训练模型是两种不同操作。

七、什么是 Greedy Decoding？

7.1 Greedy Decoding 的定义

Greedy Decoding（贪心解码）在每个生成步骤选择当前概率最高的 Token。

y_{t} = \arg max_{v} P (v ∣ x, y_{< t})

7.2 示例

假设：

A：0.60
B：0.25
C：0.15

贪心解码选择 A。

下一步再次选择当前概率最高的 Token。

7.3 优点

贪心解码通常具有：

实现简单；
不需要随机采样；
在相同条件下较容易复现；
每一步只保留一个候选序列。

7.4 局限

贪心解码只考虑当前步骤的局部最优选择。

它不能保证得到整体概率最高的完整序列。

例如：

第一步：
A 的概率更高
但选择 A 后：
后续序列概率很低

因此，局部最优不一定意味着全局最优。

八、什么是 Temperature？

8.1 Temperature 的定义

Temperature（温度）用于调整 Token 概率分布的形状。

常见形式为：

P_{i} (T) = \frac{e^{z_{i} / T}}{\sum_{j} e^{z_{j} / T}}

其中：

T > 0

8.2 Temperature 的作用

当：

T < 1

概率分布通常变得更加集中。

当：

T > 1

概率分布通常变得更加平坦。

8.3 示例

假设模型原始概率为：

Token	原始概率
A	0.70
B	0.20
C	0.10

降低 Temperature 后，A 的概率通常会进一步提高。

提高 Temperature 后，B 和 C 获得的相对采样机会通常增加。

8.4 Temperature 是否越低越准确？

不一定。

较低 Temperature 可以降低随机性，但不能保证事实正确。

如果模型本身对错误答案赋予较高概率，降低 Temperature 反而可能使错误输出更加稳定。

8.5 Temperature = 0

一些推理 API 将 Temperature = 0 解释为使用贪心解码或近似确定性解码。

但严格的 Softmax 温度公式要求：

T > 0

因此，Temperature = 0 通常属于推理系统定义的特殊行为，而不是直接代入公式计算。

此外，即使使用确定性解码配置，实际系统仍可能因为数值计算、并行执行或服务端实现差异而出现输出变化。

九、什么是 Top-k Sampling？

9.1 Top-k 的定义

Top-k Sampling 只保留概率最高的 $k$ 个候选 Token。

其余候选 Token 被排除，然后在保留集合中重新归一化并采样。

9.2 示例

假设：

Token	概率
A	0.40
B	0.30
C	0.15
D	0.10
E	0.05

当：

k = 3

只保留：

A
B
C

D 和 E 不参与当前采样。

9.3 Top-k 的特点

Top-k 使用固定数量的候选 Token。

但不同生成步骤的概率分布可能不同。

例如，有时前两个 Token 已经占据绝大部分概率；有时概率可能分布在大量候选 Token 上。

固定的 $k$ 不一定适合所有分布。

十、什么是 Top-p Sampling？

10.1 Top-p 的定义

Top-p Sampling，也称 Nucleus Sampling，根据累计概率选择候选 Token 集合。[1]

模型先按照概率从高到低排序，然后选择累计概率达到指定阈值的最小候选集合。

10.2 示例

假设：

Token	概率	累计概率
A	0.40	0.40
B	0.30	0.70
C	0.15	0.85
D	0.10	0.95
E	0.05	1.00

如果：

p = 0.90

则保留：

A
B
C
D

因为前三个 Token 的累计概率为 0.85，尚未达到 0.90；加入 D 后达到 0.95。

10.3 Top-p 的特点

Top-p 的候选数量可以动态变化。

当概率分布高度集中时，候选集合可能较小。

当概率分布较平坦时，候选集合可能较大。

10.4 Top-k 与 Top-p 的区别

维度	Top-k	Top-p
控制对象	候选 Token 数量	累计概率
候选数量	固定	动态
参数	$k$	$p$
主要特点	简单直接	适应概率分布变化

部分推理系统允许同时设置 Temperature、Top-k 和 Top-p。

但具体执行顺序和参数支持情况取决于实现。

十一、什么是 Beam Search？

11.1 Beam Search 的定义

Beam Search（束搜索）在生成过程中保留多个候选序列，而不是每一步只保留一个序列。

例如：

text

初始输入
   │
   ├── 候选 A
   ├── 候选 B
   └── 候选 C
         │
         ▼
    扩展候选序列
         │
         ▼
    计算序列分数
         │
         ▼
    保留较优候选

11.2 Beam Width

Beam Width 控制同时保留的候选序列数量。

例如：

BeamWidth = 4

表示每轮保留一定数量的高分候选序列。

11.3 Beam Search 与 Greedy Decoding

Greedy Decoding 每一步只保留一个候选。

Beam Search 同时考虑多个候选序列。

因此，Beam Search 可以探索更多可能的生成路径。

11.4 Beam Search 的局限

Beam Search 通常增加计算和内存开销。

此外，序列概率更高不一定意味着生成内容在事实性、创造性或用户偏好方面更好。

在现代开放式聊天生成中，采样解码通常比传统 Beam Search 更常见。

十二、语言模型什么时候停止生成？

自回归模型不会因为理解到“回答已经完整”就必然自动停止。

实际生成通常依赖明确的停止机制。

12.1 EOS Token

EOS（End of Sequence）是表示序列结束的特殊 Token。

当模型生成相应结束标记时，推理系统可以停止生成。

12.2 Stop Sequences

应用可以设置特定停止序列。

例如，当输出包含指定分隔符时停止。

12.3 Maximum Output Tokens

推理系统通常允许设置最大生成 Token 数。

达到限制后，即使模型尚未完成回答，也可能停止。

12.4 其他停止原因

生成还可能因为以下原因结束：

工具调用交接；
服务端限制；
请求取消；
超时；
内容处理策略；
推理任务中断。

因此，生成停止不一定意味着任务已经完成。

对于 Agent 系统，需要进一步检查停止原因和输出状态。

十三、什么是 Prefill？

13.1 Prefill 的定义

在典型的自回归 Transformer 推理中，Prefill 是指处理已有输入 Token，并计算其内部表示及相关注意力缓存的阶段。

例如，用户输入：

请总结以下 5000 字的文章。

模型需要先处理输入上下文。

这一阶段通常称为 Prefill。

13.2 Prefill 的计算过程

text

输入 Token 序列
        │
        ▼
Embedding
        │
        ▼
Transformer 前向计算
        │
        ▼
计算注意力所需的 K、V
        │
        ▼
建立 KV Cache
        │
        ▼
得到下一 Token 的预测分数

13.3 Prefill 的特点

Prefill 通常可以对输入序列中的多个位置进行并行计算。

但在标准因果注意力下，每个位置只能关注允许访问的前文位置。

因此，并行计算不意味着模型违反自回归依赖关系。

现代推理系统还可能使用 FlashAttention 等方法优化注意力计算的内存访问与性能。[5]

13.4 输入长度为什么影响 Prefill？

输入越长，需要处理的 Token 通常越多。

这会增加计算量和缓存需求。

在标准全注意力 Transformer 中，注意力相关计算还可能随序列长度呈二次增长。

但具体性能取决于注意力实现、模型结构和硬件。

十四、什么是 Decode 阶段？

14.1 Decode 的定义

Decode 阶段是指模型在已有上下文基础上，逐步生成后续 Token 的阶段。

在使用 KV Cache 的典型实现中，每一步主要处理当前新增 Token，并利用之前保存的注意力缓存。

14.2 Decode 的流程

text

Prefill 完成
      │
      ▼
预测 Token 1
      │
      ▼
更新 KV Cache
      │
      ▼
预测 Token 2
      │
      ▼
更新 KV Cache
      │
      ▼
预测 Token 3
      │
      ▼
……

14.3 为什么 Decode 难以完全并行？

自回归生成具有顺序依赖。

第 $t + 1$ 个 Token 的生成通常依赖第 $t$ 个 Token 的实际选择结果。

因此，不能在不知道前面 Token 的情况下，直接完成整个输出序列的常规自回归采样。

14.4 Prefill 与 Decode 的区别

维度	Prefill	Decode
处理对象	已有输入 Token	新生成 Token
主要目的	建立上下文表示与缓存	逐步生成输出
并行特点	可处理多个输入位置	具有逐步依赖
主要成本	输入计算	多步生成与缓存访问
典型影响	首 Token 延迟	后续 Token 生成速度

14.5 一个完整推理请求

text

用户请求
    │
    ▼
输入预处理
    │
    ▼
Prefill
    │
    ▼
第一个输出 Token
    │
    ▼
Decode
    │
    ▼
后续 Token
    │
    ▼
停止条件
    │
    ▼
最终输出

十五、什么是 KV Cache？

15.1 KV Cache 的定义

KV Cache（Key-Value Cache）是 Transformer 自回归推理中常见的缓存机制。

它保存此前 Token 在各注意力层中计算得到的 Key 和 Value 表示，以减少后续生成步骤中的重复计算。

15.2 为什么需要 KV Cache？

假设模型已经处理：

A B C D

现在需要生成下一个 Token。

如果没有缓存，某些朴素实现可能在每一步重新计算整个已有序列的注意力相关表示。

当序列不断增长时，这会产生大量重复计算。

15.3 KV Cache 的基本过程

text

Token A ──► K_A、V_A
Token B ──► K_B、V_B
Token C ──► K_C、V_C
Token D ──► K_D、V_D
                │
                ▼
             KV Cache
                │
                ▼
新 Token E 的 Query
                │
                ▼
与历史 K、V 交互

15.4 KV Cache 保存什么？

对于标准多层 Transformer，KV Cache 通常保存各层历史位置的 Key 和 Value 张量。

它不是简单保存原始文本。

也不等于 Agent 的长期记忆。

15.5 KV Cache 的内存需求

对于采用标准多头注意力、未进行特殊压缩的模型，KV Cache 的理论元素数量可以近似表示为：

N_{KV} = 2 \times L \times S \times H_{KV} \times D

其中：

$L$ ：Transformer 层数；
$S$ ：缓存的序列长度；
$H_{KV}$ ：每层 KV Head 数量；
$D$ ：每个 Head 的维度；
$2$ ：分别对应 Key 和 Value。

如果每个元素占用 $b$ 字节：

M_{KV} \approx 2 L S H_{KV} D b

对于批处理，还需要考虑不同请求的缓存占用。

这一公式没有包含内存分配开销、缓存管理元数据和其他运行时资源。

15.6 一个计算示例

假设某个模型具有：

32 层；
32 个 KV Heads；
Head Dimension 为 128；
序列长度为 4096；
每个元素占用 2 字节。

则：

M_{KV} = 2 \times 32 \times 4096 \times 32 \times 128 \times 2

得到：

M_{KV} = 2,147,483,648 bytes

约为：

2 GiB

这是单条序列在上述假设下的理论 KV 数据量。

实际模型如果采用 GQA、MQA、KV 量化或其他缓存优化，结果可能明显不同。

15.7 KV Cache 的代价

KV Cache 减少重复计算，但需要占用内存。

因此，长上下文和高并发请求可能使 KV Cache 成为重要资源瓶颈。

十六、什么是 MHA、MQA 和 GQA？

这些机制与注意力计算和 KV Cache 效率密切相关。

16.1 Multi-Head Attention

MHA（Multi-Head Attention）通常为多个注意力头分别计算 Query、Key 和 Value。

不同 Head 可以学习不同的注意力表示。

16.2 Multi-Query Attention

MQA（Multi-Query Attention）允许多个 Query Heads 共享一组 Key 和 Value Heads。[3]

这样可以减少 KV Cache 占用。

16.3 Grouped-Query Attention

GQA（Grouped-Query Attention）介于 MHA 与 MQA 之间。[4]

多个 Query Heads 被分组，每组共享对应的 Key 和 Value Heads。

16.4 三者比较

机制	Query Heads	KV Heads	主要特点
MHA	多个	通常数量相同	标准多头注意力
MQA	多个	通常为 1 组	减少 KV Cache
GQA	多个	少于 Query Heads	在表示能力与效率之间折中

16.5 为什么 GQA 重要？

对于长上下文推理，KV Cache 可能占用大量显存。

减少 KV Heads 可以降低缓存需求和部分内存访问成本。

但具体性能与模型质量取决于模型设计和训练过程。

十七、什么是推理时计算？

17.1 Inference-time Compute

推理时计算（Inference-time Compute）是指模型在处理一个具体任务时使用的计算资源。

对于复杂任务，开发者可以通过增加生成、搜索、验证或其他计算步骤改善任务表现。[8]

17.2 与训练时计算的区别

训练时计算主要用于优化模型参数。

推理时计算主要用于处理当前输入。

维度	Training-time Compute	Inference-time Compute
发生阶段	模型训练	模型使用
是否更新参数	通常更新	通常不更新
主要目的	改善模型能力	改善当前任务结果
典型方法	预训练、SFT、RL	多候选生成、搜索、验证

17.3 增加输出 Token

一种简单方式是允许模型生成更长的中间分析或求解过程。

但输出更长不一定意味着推理更正确。

17.4 多候选生成

模型可以针对同一个问题生成多个候选答案。

例如：

text

问题
  │
  ├── 候选 A
  ├── 候选 B
  ├── 候选 C
  └── 候选 D
         │
         ▼
      结果比较
         │
         ▼
      最终选择

17.5 Self-Consistency

Self-Consistency 是一种通过采样多条推理路径，并对最终结果进行聚合的方法。[2]

它在部分具有明确答案的任务中可能改善表现。

但如果多个候选共享相同错误，聚合也不能保证正确。

17.6 验证器

模型可以结合外部验证机制。

例如：

数学答案检查；
程序测试；
约束验证；
格式验证。

验证器可以提供比单纯语言概率更直接的任务反馈。相关研究也指出，在扩展测试时计算时，带验证的方法往往更有效。[9]

17.7 搜索

某些系统会探索多个候选推理状态，并根据评价结果继续搜索。

例如：

text

初始问题
    │
    ▼
生成候选步骤
    │
    ▼
评价候选
    │
    ▼
选择后续路径
    │
    ▼
继续搜索
    │
    ▼
输出结果

这种方式可能提高复杂任务表现，但通常增加延迟和计算成本。

17.8 推理时计算的边界

需要区分：

模型内部的推理计算与外部系统组织的搜索、验证和工具调用。

二者都可能增加任务处理时的计算量，但不一定属于同一种模型架构。

十八、什么是 Speculative Decoding？

18.1 基本定义

Speculative Decoding（推测解码）是一种加速自回归生成的方法。[6]

其典型思路是利用较小或较快的草稿模型提出多个候选 Token，再由目标模型进行验证。

18.2 基本流程

text

输入上下文
    │
    ▼
Draft Model
    │
    ▼
提出多个候选 Token
    │
    ▼
Target Model
    │
    ▼
并行验证候选
    │
    ▼
接受部分候选
    │
    ▼
继续生成

18.3 为什么可能更快？

传统自回归生成通常需要逐步调用目标模型。

Speculative Decoding 尝试通过一次目标模型前向计算验证多个候选位置，从而减少目标模型的串行生成步骤。

18.4 是否改变输出分布？

某些严格设计的 Speculative Sampling 算法可以保持与目标模型采样一致的输出分布。

但并不是所有推测解码实现都具有完全相同的分布保证。

18.5 主要限制

加速效果取决于：

草稿模型速度；
草稿 Token 接受率；
目标模型计算成本；
硬件利用率；
推理系统实现。

如果草稿模型提出的候选经常被拒绝，收益可能下降。

十九、什么是 Continuous Batching？

19.1 Batching

Batching 是指将多个请求组合起来执行模型计算。

例如：

text

请求 A ──┐
请求 B ──┼──► Batch ──► GPU
请求 C ──┘

批处理可以提高硬件利用率。

19.2 Static Batching

Static Batching 通常在一个批次开始前确定参与请求。

但不同请求的生成长度可能不同。

这可能导致部分请求完成后，其他请求仍然占用批次执行过程。

19.3 Continuous Batching

Continuous Batching（连续批处理）允许推理系统在生成过程中动态管理请求。[7]

例如：

已完成请求退出；
新请求加入；
不同请求独立维护生成状态。

19.4 Continuous Batching 的价值

它可以改善：

GPU 利用率；
并发处理能力；
整体吞吐量；
请求调度效率。

但实际效果取决于请求负载和调度实现。

19.5 为什么 Agent 系统需要关注？

多 Agent 系统可能同时产生大量模型请求。

例如：

text

Research Agent ───┐
Analysis Agent ───┤
Review Agent ─────┼──► Model Serving
Writing Agent ────┤
Planning Agent ───┘

如果模型服务缺乏合理的请求调度，可能出现：

排队时间增加；
GPU 利用率低；
显存不足；
请求超时。

因此，模型服务的并发管理会直接影响 Agent System 的运行性能。

二十、模型推理有哪些主要性能指标？

模型推理性能不能只用“每秒生成多少 Token”衡量。

实际系统通常需要同时考虑延迟、吞吐量、并发和资源消耗。

20.1 TTFT

TTFT（Time to First Token）表示从请求开始到第一个输出 Token 可用的时间。

它通常受到以下因素影响：

请求排队；
输入处理；
Prefill；
调度；
网络传输。

对于流式应用，TTFT 是影响用户感知速度的重要指标。

20.2 TPOT

TPOT（Time per Output Token）通常表示输出阶段每个 Token 的平均生成时间。

它反映持续生成速度。

不同系统对 TPOT 的统计口径可能略有差异。

20.3 Tokens per Second

Tokens per Second 表示单位时间内生成的 Token 数量。

但需要区分：

单请求生成速度；
整个服务的总生成吞吐量。

20.4 End-to-End Latency

端到端延迟表示请求从开始到完成的总耗时。

可以近似理解为：

T_{total} = T_{queue} + T_{prefill} + T_{decode} + T_{other}

其中：

$T_{queue}$ ：排队时间；
$T_{prefill}$ ：输入处理时间；
$T_{decode}$ ：生成时间；
$T_{other}$ ：网络、预处理及其他开销。

20.5 Throughput

Throughput（吞吐量）表示系统单位时间内处理的工作量。

例如：

Requests per Second；
Output Tokens per Second；
Total Tokens per Second。

20.6 并发

Concurrency 表示系统同时处理的请求数量。

高并发不一定意味着单个请求更快。

系统需要在吞吐量与延迟之间进行权衡。

20.7 性能指标总结

指标	含义	主要关注
TTFT	首 Token 延迟	用户首次响应
TPOT	每输出 Token 耗时	持续生成速度
Tokens/s	Token 生成速率	生成性能
Latency	请求总耗时	完整任务响应
Throughput	单位时间处理量	服务整体能力
Concurrency	同时处理请求数	并发承载
GPU Memory	显存占用	资源限制
Cost per Token	单位 Token 成本	经济效率

二十一、模型推理为什么需要大量显存？

推理阶段虽然通常不需要保存训练梯度，但仍然需要显存存储模型权重和运行状态。

21.1 模型权重

模型参数需要存储在可访问的内存中。

例如，一个具有 70 亿参数的模型，如果每个参数使用 2 字节存储，单纯权重数据量约为：

7 \times 10^{9} \times 2 = 14 \times 10^{9} bytes

约为 14 GB，或 13.0 GiB。

这还不包括其他运行时内存需求。

21.2 KV Cache

长上下文和高并发会增加 KV Cache 占用。

21.3 Activation

模型前向计算还需要临时激活张量。

21.4 Workspace

推理框架可能需要额外的计算工作区和内存管理空间。

21.5 总显存需求

可以概括为：

M_{total} \approx M_{weights} + M_{KV} + M_{activations} + M_{workspace}

实际显存占用还会受到内存碎片、框架实现和批处理策略影响。

二十二、什么是模型量化？

22.1 Quantization

量化（Quantization）是指使用较低精度的数值表示模型权重、激活或其他张量。

例如：

FP16；
BF16；
INT8；
INT4；
FP8。

不同数值格式具有不同的精度范围和计算特征。

22.2 为什么需要量化？

量化可以降低部分模型数据的存储需求。

在硬件和推理框架支持的情况下，也可能改善计算性能。

22.3 一个简单示例

假设模型具有 70 亿参数。

仅考虑权重：

精度	理论权重数据量
FP32	约 28 GB
FP16 / BF16	约 14 GB
INT8	约 7 GB
INT4	约 3.5 GB

这是理想化计算。

实际量化格式通常还需要保存缩放因子、零点或其他元数据。

22.4 量化的风险

量化可能导致：

数值误差；
输出质量下降；
特定任务性能退化；
部分算子兼容性问题。

因此，需要结合模型、硬件和任务评估量化效果。

22.5 量化不等于模型蒸馏

量化主要改变数值表示。

模型蒸馏（Distillation）通常通过教师模型指导学生模型训练。

两者是不同技术，也可以组合使用。

二十三、不同模态的模型如何生成输出？

前面的讨论主要针对自回归语言模型。

但其他模态可能采用不同推理机制。

23.1 图像分类模型

图像分类模型通常执行一次或少量前向计算，输出类别分数或概率。

text

输入图片
   │
   ▼
图像编码器
   │
   ▼
分类头
   │
   ▼
类别预测

23.2 扩散图像生成模型

扩散生成模型通常从噪声或带噪潜变量开始，通过多个迭代步骤生成结果。

text

文本条件
    │
    ▼
条件编码
    │
    ▼
初始噪声
    │
    ▼
迭代去噪
    │
    ▼
潜变量或图像
    │
    ▼
最终图片

23.3 音频生成模型

音频生成可能采用：

自回归音频 Token 生成；
扩散生成；
Flow Matching；
其他声学建模与声码器方法。

23.4 视频生成模型

视频生成需要处理空间和时间信息。

它可能采用：

时空扩散；
自回归视频 Token；
潜空间生成；
其他联合生成方法。

23.5 多模态生成的共同点

虽然不同模型的生成机制不同，但通常都涉及：

输入表示；
模型计算；
生成策略；
输出转换；
停止或完成条件。

因此，不能将“下一个 Token 预测”视为所有生成式 AI 的唯一机制。

二十四、模型推理与 Agent 执行有什么关系？

24.1 模型推理提供认知计算

Agent 通常利用模型推理完成：

理解任务；
生成计划；
选择工具；
解释结果；
生成回答。

24.2 Agent 执行包含模型之外的操作

例如：

text

用户提出任务
      │
      ▼
Agent Runtime
      │
      ▼
构建模型输入
      │
      ▼
Model Inference
      │
      ▼
模型输出工具调用
      │
      ▼
Agent Runtime 执行工具
      │
      ▼
获得工具结果
      │
      ▼
再次调用模型
      │
      ▼
完成任务

这里可能包含多次模型推理。

24.3 模型推理不等于 Agent Loop

一次模型推理通常对应一次模型请求及其生成过程。

Agent Loop 则可能包含：

多次模型调用；
工具执行；
状态更新；
结果检查；
重试；
人工审批。

因此：

模型推理是 Agent 执行的重要计算环节，但不是 Agent 执行机制的全部。

24.4 为什么 Agent 系统需要关注推理性能？

假设一个任务需要连续调用模型 20 次。

如果每次模型调用平均需要 5 秒，仅模型调用时间就可能累计达到约 100 秒。

实际系统还需要考虑：

工具执行时间；
请求排队；
网络延迟；
重试；
并行执行。

因此，Agent 的整体响应速度可能受到模型推理延迟的显著影响。

24.5 推理成本如何影响 Agent 设计？

复杂 Agent 系统可能需要：

使用不同规模的模型；
控制上下文长度；
缓存可复用结果；
减少无意义调用；
并行处理独立任务；
对复杂任务分配更多推理计算。

这些问题将在 E6、E8 和 Agent System 的资源管理章节中进一步研究。

二十五、如何分析一次模型推理请求？

为了将前面的概念联系起来，可以分析一个完整示例。

25.1 用户请求

用户输入：

请用三句话解释什么是 Transformer。

25.2 输入构建

应用系统组织：

System Instructions；
用户问题；
必要的历史上下文；
模型所需的消息格式。

25.3 Tokenization

输入文本转换为 Token ID。

25.4 Prefill

模型处理输入 Token。

Transformer 执行前向计算，并在支持缓存的实现中建立 KV Cache。

25.5 生成第一个 Token

模型根据最后位置的隐藏状态计算 Logits。

然后根据解码策略选择第一个输出 Token。

25.6 Decode

模型继续逐 Token 生成。

每一步：

使用已有上下文；
执行模型计算；
得到 Logits；
应用解码策略；
选择下一个 Token；
更新缓存。

25.7 停止生成

当模型生成结束标记或达到其他停止条件时，生成结束。

25.8 输出转换

生成的 Token ID 经过 Detokenization 转换为文本。

25.9 返回结果

应用系统将文本返回用户。

完整过程可以表示为：

text

用户问题
    │
    ▼
消息格式化
    │
    ▼
Tokenizer
    │
    ▼
Input Tokens
    │
    ▼
Prefill
    │
    ▼
Transformer
    │
    ▼
Logits
    │
    ▼
Decoding Strategy
    │
    ▼
Output Token
    │
    ▼
KV Cache 更新
    │
    ├── 未结束 ──► 继续 Decode
    │
    ▼
Detokenization
    │
    ▼
最终回答

二十六、模型推理有哪些常见误解？

26.1 误解一：模型一次性生成完整回答

对于典型自回归语言模型，回答通常逐 Token 生成。

但其他类型模型可能采用不同生成机制。

26.2 误解二：Temperature 越低，回答越正确

Temperature 主要影响采样分布。

它不能保证事实正确。

26.3 误解三：模型每生成一个 Token 都重新处理全部历史文本

在使用 KV Cache 的典型实现中，模型可以复用历史 Key 和 Value，减少重复计算。

但缓存仍然需要内存和管理成本。

26.4 误解四：上下文越长，模型能力越强

更长的上下文允许提供更多信息，但也可能增加计算成本，并带来注意力分配和信息利用方面的挑战。

26.5 误解五：生成速度只由模型参数规模决定

生成速度还受到：

硬件；
模型架构；
KV Cache；
量化；
批处理；
输入长度；
输出长度；
推理框架。

等因素影响。

26.6 误解六：推理时计算越多，结果一定越好

额外的生成、搜索和验证可能改善部分任务表现，但也可能产生无效计算或重复错误。

26.7 误解七：模型推理就是 Agent 推理

模型推理是模型执行计算的过程。

Agent 推理与执行可能涉及模型调用、工具操作、状态管理和反馈循环。

两者属于不同层次。

二十七、核心结论

模型推理是利用训练完成的模型参数，对输入执行计算并生成预测或输出的过程。

理解现代语言模型推理，需要建立以下认识。

第一，推理与训练是不同阶段。 训练主要调整模型参数，常规推理主要使用已有参数。

第二，自回归语言模型通常逐 Token 生成输出。 每个新 Token 的生成依赖已有上下文。

第三，Logits 是模型对候选 Token 给出的原始分数。 Softmax 可以将其转换为概率分布。

第四，解码策略决定如何从候选 Token 中选择输出。 Greedy、Top-k、Top-p 和 Beam Search 具有不同特点。

第五，Temperature 调整概率分布的集中程度。 它主要影响随机性，而不直接保证正确性。

第六，Prefill 负责处理已有输入上下文。 Decode 负责逐步生成后续 Token。

第七，KV Cache 可以减少自回归推理中的重复计算。 但会增加内存占用。

第八，MHA、MQA 和 GQA 的设计会影响 KV Cache 需求和推理效率。

第九，推理时计算可以通过多候选生成、搜索和验证改善部分复杂任务表现。 但额外计算不保证结果正确。

第十，Speculative Decoding 可以通过草稿生成与目标模型验证减少部分串行计算。

第十一，Continuous Batching 可以改善多请求场景下的资源利用率。

第十二，推理性能需要同时关注 TTFT、TPOT、Latency、Throughput 和 Concurrency。

第十三，模型权重、KV Cache、激活和运行时工作区共同构成推理内存需求。

第十四，量化可以降低部分模型的存储与计算成本，但可能影响模型质量。

第十五，不同模态的生成机制并不相同。 自回归生成只是生成式 AI 的一种技术路线。

第十六，模型推理不等于 Agent 执行。 Agent 可能通过多次模型推理、工具调用和状态更新完成任务。

从整个 AI 技术体系看，模型训练决定模型获得什么样的参数与能力，而模型推理决定这些能力如何在实际请求中被使用。

推理机制直接影响模型的输出质量、响应速度、资源占用和运行成本。

理解这些机制，是进一步研究模型评估、模型部署、推理优化和 Agent System 工程架构的重要基础。

二十八、参考文献与延伸阅读

28.1 语言生成与解码

[1] Holtzman, A., et al. (2019). The Curious Case of Neural Text Degeneration.
研究语言生成中的解码策略，并提出 Nucleus Sampling。
论文：The Curious Case of Neural Text Degeneration

[2] Wang, X., et al. (2022). Self-Consistency Improves Chain of Thought Reasoning in Language Models.
研究多条推理路径采样与答案聚合。
论文：Self-Consistency Improves Chain of Thought Reasoning

28.2 Transformer 推理与注意力优化

[3] Shazeer, N. (2019). Fast Transformer Decoding: One Write-Head is All You Need.
介绍 Multi-Query Attention。
论文：Fast Transformer Decoding

[4] Ainslie, J., et al. (2023). GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints.
研究 Grouped-Query Attention。
论文：GQA

[5] Dao, T., et al. (2022). FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness.
研究注意力计算的内存访问与性能优化。
论文：FlashAttention

28.3 推理加速

[6] Leviathan, Y., Kalman, M., & Matias, Y. (2023). Fast Inference from Transformers via Speculative Decoding.
介绍推测解码方法。
论文：Fast Inference from Transformers via Speculative Decoding

[7] Kwon, W., et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention.
介绍 PagedAttention 与 vLLM 的内存管理设计。
论文：Efficient Memory Management for Large Language Model Serving

28.4 推理时计算

[8] Snell, C., et al. (2024). Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters.
研究测试时计算分配与模型规模扩展之间的关系。
论文：Scaling LLM Test-Time Compute Optimally

[9] Setlur, A., et al. (2025). Scaling Test-Time Compute Without Verification or RL is Suboptimal.
研究测试时计算扩展中验证机制的作用。
论文：Scaling Test-Time Compute Without Verification or RL is Suboptimal

28.5 官方工程文档

[10] Hugging Face. Text Generation Strategies.
介绍 Greedy Search、Sampling、Beam Search 等文本生成策略。
官方文档：Text Generation Strategies

[11] Hugging Face. KV Cache Strategies.
介绍 Transformer 推理中的 KV Cache 管理。
官方文档：KV Cache Strategies

[12] vLLM. Official Documentation.
介绍高吞吐量语言模型推理服务。
官方文档：vLLM Documentation

[13] NVIDIA. TensorRT-LLM Documentation.
介绍大语言模型推理优化与部署。
官方文档：TensorRT-LLM Documentation

二十九、关联研究

关联文档	研究内容
M1 · AI 模型是什么？它由什么构成？	模型架构与参数
M2 · 神经网络如何学习和处理信息？	神经网络计算
M3 · Transformer 如何处理和生成信息？	Attention 与 Transformer
M4 · 大语言模型是如何构建的？	LLM 架构
M5 · AI 模型如何理解和处理不同模态？	多模态模型
M6 · AI 模型如何通过训练获得能力？	预训练与后训练
M8 · 如何评估 AI 模型的能力与局限？	模型能力评估
E1 · 如何通过 API 调用 AI 模型？	模型 API
E3 · 如何管理模型的上下文窗口？	Context Window
E6 · 如何选择和切换不同模型？	Model Routing
E7 · 如何部署和运行开源模型？	Model Deployment
E8 · 如何优化模型调用的成本与性能？	Inference Optimization
A2 · Agent 如何获得认知与推理能力？	Agent 模型能力
L3 · Agent System 如何接入和管理 AI 模型？	Model Services
H8 · 如何管理 Agent System 的资源、成本与预算？	Resource Management

M7 · AI 模型如何生成输出？ - Inference & Decoding ​

专题导读 ​

一、研究概述 ​

1.1 本篇的研究目标 ​

1.2 本篇的研究边界 ​

二、什么是模型推理？ ​

2.1 模型推理的定义 ​

2.2 推理不一定意味着生成文本 ​

2.3 推理与训练的区别 ​

三、大语言模型如何生成文本？ ​

3.1 自回归生成 ​

3.2 概率分解 ​

3.3 自回归生成流程 ​

3.4 模型不是一次性输出完整文章 ​

3.5 Token 不等于一个汉字或一个单词 ​

四、输入如何进入语言模型？ ​

4.1 输入预处理 ​

4.2 Chat Template ​

4.3 Tokenization ​

4.4 Embedding ​

4.5 Transformer 前向计算 ​

4.6 输出层 ​

五、什么是 Logits？ ​

5.1 Logits 的定义 ​

5.2 一个简化示例 ​

5.3 Logits 如何转换为概率？ ​

5.4 概率分布不是最终输出 ​

六、什么是 Decoding？ ​

6.1 Decoding 的定义 ​

6.2 为什么需要解码策略？ ​

6.3 解码策略影响什么？ ​

七、什么是 Greedy Decoding？ ​

7.1 Greedy Decoding 的定义 ​

7.2 示例 ​

7.3 优点 ​

7.4 局限 ​

八、什么是 Temperature？ ​

8.1 Temperature 的定义 ​

8.2 Temperature 的作用 ​

8.3 示例 ​

8.4 Temperature 是否越低越准确？ ​

8.5 Temperature = 0 ​

九、什么是 Top-k Sampling？ ​

9.1 Top-k 的定义 ​

9.2 示例 ​

9.3 Top-k 的特点 ​

十、什么是 Top-p Sampling？ ​

10.1 Top-p 的定义 ​

10.2 示例 ​

10.3 Top-p 的特点 ​

10.4 Top-k 与 Top-p 的区别 ​

十一、什么是 Beam Search？ ​

11.1 Beam Search 的定义 ​

11.2 Beam Width ​

11.3 Beam Search 与 Greedy Decoding ​

11.4 Beam Search 的局限 ​

十二、语言模型什么时候停止生成？ ​

12.1 EOS Token ​

12.2 Stop Sequences ​

12.3 Maximum Output Tokens ​

12.4 其他停止原因 ​

十三、什么是 Prefill？ ​

13.1 Prefill 的定义 ​

13.2 Prefill 的计算过程 ​

13.3 Prefill 的特点 ​

13.4 输入长度为什么影响 Prefill？ ​

十四、什么是 Decode 阶段？ ​

14.1 Decode 的定义 ​

14.2 Decode 的流程 ​

14.3 为什么 Decode 难以完全并行？ ​

14.4 Prefill 与 Decode 的区别 ​

14.5 一个完整推理请求 ​

十五、什么是 KV Cache？ ​

15.1 KV Cache 的定义 ​

15.2 为什么需要 KV Cache？ ​

15.3 KV Cache 的基本过程 ​

15.4 KV Cache 保存什么？ ​

15.5 KV Cache 的内存需求 ​

15.6 一个计算示例 ​

15.7 KV Cache 的代价 ​

M7 · AI 模型如何生成输出？ - Inference & Decoding

专题导读

一、研究概述

1.1 本篇的研究目标

1.2 本篇的研究边界

二、什么是模型推理？

2.1 模型推理的定义

2.2 推理不一定意味着生成文本

2.3 推理与训练的区别

三、大语言模型如何生成文本？

3.1 自回归生成

3.2 概率分解

3.3 自回归生成流程

3.4 模型不是一次性输出完整文章

3.5 Token 不等于一个汉字或一个单词

四、输入如何进入语言模型？

4.1 输入预处理

4.2 Chat Template

4.3 Tokenization

4.4 Embedding

4.5 Transformer 前向计算

4.6 输出层

五、什么是 Logits？

5.1 Logits 的定义

5.2 一个简化示例

5.3 Logits 如何转换为概率？

5.4 概率分布不是最终输出

六、什么是 Decoding？

6.1 Decoding 的定义

6.2 为什么需要解码策略？

6.3 解码策略影响什么？

七、什么是 Greedy Decoding？

7.1 Greedy Decoding 的定义

7.2 示例

7.3 优点

7.4 局限

八、什么是 Temperature？

8.1 Temperature 的定义

8.2 Temperature 的作用

8.3 示例

8.4 Temperature 是否越低越准确？

8.5 Temperature = 0

九、什么是 Top-k Sampling？

9.1 Top-k 的定义

9.2 示例

9.3 Top-k 的特点

十、什么是 Top-p Sampling？

10.1 Top-p 的定义

10.2 示例

10.3 Top-p 的特点

10.4 Top-k 与 Top-p 的区别

十一、什么是 Beam Search？

11.1 Beam Search 的定义

11.2 Beam Width

11.3 Beam Search 与 Greedy Decoding

11.4 Beam Search 的局限

十二、语言模型什么时候停止生成？

12.1 EOS Token

12.2 Stop Sequences

12.3 Maximum Output Tokens

12.4 其他停止原因

十三、什么是 Prefill？

13.1 Prefill 的定义

13.2 Prefill 的计算过程

13.3 Prefill 的特点

13.4 输入长度为什么影响 Prefill？

十四、什么是 Decode 阶段？

14.1 Decode 的定义

14.2 Decode 的流程

14.3 为什么 Decode 难以完全并行？

14.4 Prefill 与 Decode 的区别

14.5 一个完整推理请求

十五、什么是 KV Cache？

15.1 KV Cache 的定义

15.2 为什么需要 KV Cache？

15.3 KV Cache 的基本过程

15.4 KV Cache 保存什么？

15.5 KV Cache 的内存需求

15.6 一个计算示例

15.7 KV Cache 的代价