AI Infra学习之旅-从模型执行到推理系统的桥接

这是“Transformer 原理深讲系列”的第 5 篇。
前面 4 篇我们已经把 Transformer 的核心结构拆开讲清楚了：
从为什么需要 Transformer，到文本如何进入模型；从位置编码、Q/K/V 和 Attention，到多头、Mask、FFN；再到残差、LayerNorm、一层完整 Transformer Block，以及 Encoder/Decoder 的结构分化。
这一篇不再继续拆单个模块，而是回答一个更关键的问题：
同样是 Decoder-only Transformer，为什么训练时能高吞吐并行，而推理时却常常慢、贵、吃显存？
也正是这个问题，把“模型原理”真正连接到了“推理系统”。

一、先给结论：训练和推理虽然都在做 Next-Token Prediction，但执行方式完全不同

如果先用一句话概括这一篇的核心，那就是：

训练时，模型在已知完整序列上并行学习多个位置的“下一个 token 预测”；推理时，模型只能根据当前已有前缀，一个 token 一个 token 地向前生成。

这句话非常重要。
因为今天大模型推理系统中的大多数核心问题——例如：

  • Prefill / Decode
  • TTFT / TPOT
  • KV Cache
  • Paged Attention
  • continuous batching
  • speculative decoding
  • prefix caching

几乎都能追溯到这条结构事实：

训练看的是完整已知序列，推理面对的是尚未存在的未来。

所以，如果你真的想理解 AI 推理 / Infra，这一篇必须吃透。

二、从训练目标开始：Decoder-only Transformer 到底在学什么

今天主流大语言模型基本都属于 Decoder-only Transformer。
这类模型的训练目标，本质上是标准的语言建模目标：

P(xt∣x1,…,xt−1)P(x_t \mid x_1,\dots,x_{t-1})

也就是：

  • 给定前面的 token
  • 预测当前位置应该是什么 token

如果一段序列是：

x1,x2,x3,…,xTx_1, x_2, x_3, \dots, x_T

那么模型学习的是一串条件概率：

P(x2∣x1),P(x3∣x1,x2),…,P(xT∣x1,…,xT−1)P(x_2|x_1),\quad P(x_3|x_1,x_2),\quad \dots,\quad P(x_T|x_1,\dots,x_{T-1})

这就是“Next-Token Prediction”。

很多人只记住这点，但没有再往下想一步：

既然每个位置都依赖前缀，为什么训练时还能并行？

这正是 Transformer 相比 RNN 的关键优势之一。

三、为什么训练时可以并行：因为完整序列已经已知

这是整个问题的第一关键点。

设真实训练样本是：

我 喜欢 学习 Transformer

训练时，这整段序列是完整已知的。
也就是说，虽然模型目标是“根据前缀预测下一个 token”，但前缀和目标 token 在训练数据里都已经给定。

于是，Transformer 可以一次性把整段序列送入网络。
通过 causal mask 保证每个位置只能看到自己和前面的 token，而不能偷看未来。

例如长度为 4 的序列：

  • 位置 1 只能看位置 1
  • 位置 2 只能看位置 1,2
  • 位置 3 只能看位置 1,2,3
  • 位置 4 只能看位置 1,2,3,4

这样一来，虽然逻辑上模型学的是自回归条件概率，但计算上却可以通过一个大矩阵完成整段并行前向。

也就是说：

  • 目标是因果的
  • 计算是并行的

这是 Transformer 训练效率极高的根本原因。

四、Teacher Forcing 是什么：训练为什么像“老师给答案做练习”

上面的并行训练方式，有一个非常重要的名字：

Teacher Forcing（教师强制）

它的意思是：

在训练中，模型在每一步看到的前缀，不是“自己上一轮生成出来的结果”，而是“数据集中真实存在的标准答案前缀”。

例如句子：

我 喜欢 学习 Transformer

模型训练时并不是先生成“喜欢”，再拿自己生成的“喜欢”去预测“学习”。
而是直接用真实的：

  • “我” 去预测 “喜欢”
  • “我 喜欢” 去预测 “学习”
  • “我 喜欢 学习” 去预测 “Transformer”

这意味着，训练过程本质上是在做：

给定真实历史，学习下一个 token 的条件分布。

Teacher Forcing 的优点是非常直接的：

  1. 可以并行训练整段序列
  2. 不需要等待模型一步步生成
  3. 训练更稳定，梯度更容易对齐到真实目标

但它也隐含了一个重要事实：

训练时模型看到的前缀是“标准答案前缀”，而推理时看到的是“自己生成出来的前缀”。

这就导致训练和推理之间有明显的执行差异。

五、训练时输出和损失是怎么对齐的

在实现上，语言模型训练常常可以理解成“输入和目标右移一位”。

例如序列：

[x1,x2,x3,x4][x_1, x_2, x_3, x_4]

可以理解成：

  • 输入给模型的是：

[x1,x2,x3][x_1, x_2, x_3]

  • 监督目标是：

[x2,x3,x4][x_2, x_3, x_4]

当然，在具体实现中，也常常把整段都送进去，再让每个位置的输出负责预测下一个 token。
无论怎么写，本质都一样：

第 (t) 个位置的 hidden state，用来预测第 (t+1) 个 token。

形式上，每个位置最终会输出一个词表大小维度的 logits：

zt∈RVz_t \in \mathbb{R}^{V}

然后通过 softmax 变成概率分布，再与真实 token 做交叉熵损失。

所以训练时模型做的事情可以概括为：

在真实完整序列上，并行学习每一个位置的 next-token 预测。

六、为什么推理时不能像训练那样并行

现在进入真正和大模型推理密切相关的部分。

推理时，你给模型的是一个 prompt，例如：

我想系统学习 Transformer，请先从整体结构讲起。

然后模型需要继续生成回答。
这时，与训练最大的不同出现了：

未来 token 根本还不存在。

训练时你已经知道完整句子，所以可以把后面 token 也送进去；
但推理时，模型必须自己先生成第一个新 token，才能知道下一步的输入长什么样。

也就是说，推理时只能这样做：

  1. 根据当前前缀，预测下一个 token
  2. 把这个 token 拼接回序列
  3. 再基于更长的前缀预测下一个 token
  4. 重复以上步骤

这就是 自回归生成 的真实运行方式。

所以，推理不能像训练那样一次性并行算完整未来，不是因为工程还不够好，而是因为：

未来 token 在推理开始时本来就不存在。

七、推理为什么天然串行：自回归依赖的结构后果

设当前已有前缀是：

x1,…,xtx_1,\dots,x_t

模型可以计算：

P(xt+1∣x1,…,xt)P(x_{t+1} \mid x_1,\dots,x_t)

然后采样或选择得到 (\hat{x}_{t+1})。
接下来第 (t+2) 个 token 的分布变成：

P(xt+2∣x1,…,xt,x^t+1)P(x_{t+2} \mid x_1,\dots,x_t,\hat{x}_{t+1})

注意，这里第 (t+2) 个 token 的计算，依赖刚刚生成出来的 (\hat{x}{t+1})。
而 (\hat{x}{t+1}) 在上一时刻之前并不存在。

所以第 (t+2) 步不可能提前完全展开。

这意味着：

  • 第一步要先走完
  • 第二步才能开始
  • 第三步又依赖第二步
  • 于是形成时间上的严格串行链

这就是推理天然慢于训练的根本原因之一。

不是“模型不够优化”，而是：

Decoder-only Transformer 的自回归生成，本身就带有不可消除的时间依赖。

八、Prefill 和 Decode：为什么推理阶段会被自然分裂成两部分

一旦真正站在推理执行角度看 Transformer，就会发现，模型在服务一个请求时其实会经历两个性质非常不同的阶段：

Prefill和Decode这两个词你以后做推理系统会一直见到。

1. Prefill 是什么

假设用户给了一个 prompt，长度可能已经很长。
模型首先必须把这段 prompt 整段读入并处理，建立当前上下文状态。

这一步就是 Prefill。

它的本质是：

对已知完整前缀做一次并行前向，得到最后位置的输出基础，并建立所有历史 token 的 attention 状态。

换句话说，Prefill 更像训练时的那种“整段并行处理”。

2. Decode 是什么

当 Prefill 完成后，模型开始生成第一个新 token。
之后每一步都只新增一个位置，并基于已有上下文继续往后生成。

这一阶段就是 Decode。

它的本质是：

在已有上下文状态基础上，逐 token 自回归延长序列。

所以：

  • Prefill 更像“大块已知上下文的并行读入”
  • Decode 更像“严格串行的小步推进”

这两者的资源画像差异非常大，后面很多系统设计都由此而来。

九、为什么 KV Cache 会成为推理核心

这是整个推理系统最核心的概念之一。

Attention 的结构决定了：

当前新 token 做 Self-Attention 时，它需要和所有历史 token 的 Key / Value 交互。

也就是说，当前 token 的 query 要去匹配历史所有 key，再聚合历史所有 value。

如果你在每一步 Decode 时，都把所有历史 token 从头再经过每一层重新计算一遍，会发生什么？

成本会迅速爆炸。

因为随着序列越来越长，每一步都重复计算越来越长的前缀，非常浪费。

于是，一个极其自然的工程想法出现了：

把历史 token 已经算好的 Key 和 Value 缓存起来。

这就是：

KV Cache

十、KV Cache 的本质到底是什么

KV Cache 不是别的东西，它就是：

每一层中，历史 token 已计算好的 Key 和 Value 的缓存。

有了它之后：

  • 历史 token 的 K/V 不用重算
  • 当前步只需要为“新 token”计算它自己的 Q/K/V
  • 然后用新 token 的 Q 去和历史缓存的 K 做匹配
  • 再用匹配结果去加权读取历史缓存的 V

也就是说，KV Cache 的核心价值是：

避免在 Decode 阶段重复计算历史上下文。

这就是它为什么是现代大模型推理几乎不可缺少的东西。

十一、为什么只缓存 K/V，而不是缓存 Q

这是一个非常值得问的问题。

原因在于 Decode 的查询方向是：

  • 当前新 token 的 Query
    去查询
  • 历史 token 的 Key
    并读取
  • 历史 token 的 Value

所以：

  • 历史 K/V 会被反复使用
  • 历史 Q 一般不会再参与未来 token 的主查询路径

因此，缓存最有价值的是：

  • K
  • V

而不是 Q。

所以名字叫 KV Cache，不叫 QKV Cache，这并不是命名习惯问题，而是由 attention 的使用方式直接决定的。

十二、Prefill 和 Decode 的差异，为什么会进一步导出系统问题

现在我们可以更精确地看 Prefill 和 Decode 的资源特征。

Prefill 的特征

  • 输入序列通常较长
  • 可以对整段已知前缀并行处理
  • 更偏“大矩阵吞吐型计算”
  • 对 TTFT（首 token 延迟）影响很大

Decode 的特征

  • 每一步只新增一个 token
  • 强依赖 KV Cache
  • 时间上严格串行
  • 更偏“低延迟小步推进”
  • 对 TPOT（每 token 时间）影响很大

所以你会发现：

同一个模型，在 Prefill 和 Decode 阶段，其实像是在做两种不同风格的计算。

这就是为什么现代推理系统会围绕它们做大量设计，例如：

  • Chunked Prefill
  • PD 分离
  • TTFT / TPOT 分别优化
  • KV transfer
  • Decode-Specific Scheduling

这些都不是额外加戏，而是 Transformer 自身执行阶段异质性带来的自然工程后果。

十三、为什么训练和推理的差异会直接导出推理系统的技术树

如果把上面的结构事实再往系统层推进一步，就会得到今天很多非常熟悉的工程技术。

1. 因为 Decode 串行

所以会有：

  • inter-token latency 问题
  • speculative decoding
  • MTP
  • 各类 Decode Acceleration 路线

2. 因为 Attention 依赖历史 K/V

所以会有：

  • KV Cache
  • Paged Attention
  • cache offloading
  • quantized cache
  • Distributed KV Cache

3. 因为 prompt 通常很长

所以会有：

  • Prefill
  • TTFT 优化
  • Chunked Prefill

4. 因为不同请求长度和生成长度差异巨大

所以会有：

  • continuous batching
  • inflight batching
  • cache-aware scheduling

5. 因为 Prefill 和 Decode 资源画像差异大

所以会有：

  • disaggregated serving
  • Prefill/Decode 分离

这说明一个非常关键的事实：

推理系统的很多工程名词，本质上都是对 Decoder-only Transformer 执行方式的回应。

十四、为什么说现代推理系统其实是在替 Transformer “做工程善后”

这是一个非常适合 AI 推理 / Infra 视角的说法。

Transformer 结构本身已经决定了很多事情：

  • 自回归生成带来时间串行性
  • attention 带来历史状态依赖
  • 长上下文带来 cache 膨胀
  • Decoder-only 执行路径自然分裂为 Prefill 和 Decode

而现代推理系统做的事情，几乎就是围绕这些结构事实去优化：

  • 怎么让 Prefill 更快
  • 怎么让 Decode 更稳
  • 怎么管理 KV Cache
  • 怎么让很多请求共享 GPU
  • 怎么减少重复 prefix 计算
  • 怎么在大规模集群里感知和复用 cache 状态

所以推理系统不是脱离模型结构“另起炉灶”，而是：

Transformer 在工程世界中的展开。

十五、从物理和系统直觉看训练与推理的差别

如果你喜欢更统一的理解方式，可以这样看。

训练

更像“已知完整轨迹下的并行拟合”。

  • 整段序列已知
  • mask 约束信息方向
  • 但整段可以同时计算

推理

更像“系统状态沿时间向前推进”。

  • 未来状态尚不存在
  • 每一步都依赖上一时刻新产生的状态
  • 所以只能一步一步演化

这也是为什么从动力系统视角看，推理比训练更像一个真正的“时间推进过程”。

十六、到这里，前面 4 篇博客和这一篇应该真正串起来了

把整个系列连起来看，主线其实已经非常清晰：

  1. 为什么需要 Transformer
  2. 文本如何变成向量
  3. 为什么要位置编码
  4. Q/K/V 和 Attention 如何工作
  5. 多头、Mask、FFN 为什么必要
  6. 一层 Transformer Block 如何被稳定地组织起来
  7. Encoder / Decoder / Decoder-only 如何分化
  8. 训练时为什么能并行
  9. 推理时为什么必须逐 token
  10. 为什么 KV Cache、Prefill、Decode 会自然出现
  11. 为什么现代推理系统会长成今天这样

也就是说：

Transformer 不只是模型结构，它其实决定了整个大模型推理系统的问题形状。

这就是这套原理系列最想带你到达的位置。

十七、本篇真正要记住的四条主线

第一条：训练为什么能并行

  • 因为训练数据中的完整序列是已知的
  • Transformer 可以在 causal mask 约束下一次并行计算所有位置
  • 这正是 Teacher Forcing 的核心

第二条：推理为什么必须串行

  • 因为未来 token 尚不存在
  • 第 (t+1) 步必须先生成，(t+2) 才有定义
  • 所以 Decode 天然是逐 token 推进

第三条：为什么会有 Prefill / Decode / KV Cache

  • Prefill 负责读入整段 prompt
  • Decode 负责逐 token 延长序列
  • KV Cache 负责避免重复计算历史 K/V

第四条：为什么会有现代推理系统

  • 因为 Decoder-only Transformer 的执行方式天然会引出
    • 串行瓶颈
    • KV Cache 管理
    • 显存压力
    • 调度与批处理问题
    • 阶段异质性问题

十八、用一句话压缩本篇

Decoder-only Transformer 在训练时依靠完整已知序列和 causal mask 实现并行 Next-Token 学习，而在推理时由于未来 token 尚不存在，只能经历“Prefill 读入上下文、Decode 逐 token 生成”的过程；KV Cache 则是在这一过程中避免重复计算历史 Attention 状态的核心机制。

十九、本篇小结

到这里，这组“Transformer 原理深讲系列”的前 5 篇已经形成了一个完整闭环。
把前 5 篇真正串起来看，你会形成一种更稳的理解方式：

  • 不只是会背 Transformer 模块
  • 而是能把模块、结构、训练、推理和推理系统放到同一张图里看

这也是从“知道 Transformer”走向“理解大模型推理”的关键一步。