大模型推理与加速：
沿着一次请求从输入走到输出

为什么推理加速值得做：两大根本矛盾

过去做后端，我们优化的是 QPS、RT、连接池与缓存；转到 AI Infra 后，优化对象变成了大模型推理（Inference）本身。训练是“一次性把题算完”，而推理是 7×24 小时在线、要同时服务海量用户、且逐字（token）生成的过程。它决定了两件最花钱的事：用户的等待时延与GPU 的持有成本。

从成本结构看，训练是一次性的大额投入，而推理成本随请求量线性增长、永不停机——在一个模型服务的整个生命周期里，推理的累计算力开销往往远超训练；同一张 GPU 卡能同时服务多少用户、每个 token 摊多少成本，全部取决于推理层的效率。这就是推理加速“值得做”的定量理由：每一点吞吐与时延的改善，都会直接折算进 GPU 账单。

大模型推理慢、贵，根子上是两个绕不开的矛盾：

• 矛盾一：自回归的串行依赖（算法层面）。第 $N$ 个 token 必须等前 $N-1$ 个 token 全部生成后才能计算。哪怕 GPU 有上万个并行核心，原生解码也只能“一个一个往外蹦”，并行度天然为 1。
• 矛盾二：重复计算 + 显存墙（系统层面）。每生成一个新词都要把全部历史重新参与注意力计算（重复算力浪费）；而真正算的时候，GPU 算力又远快于显存搬运速度，计算单元大部分时间在“等数据”——这就是显存墙（Memory Wall）。

两大矛盾对所有业务都成立，但不同业务痛的点不一样：在线聊天最在意 TTFT 与 ITL；IDE 代码补全输出短、追求极低 ITL，是投机解码的最佳猎场；RAG 与长文档问答痛在长 Prefill 的 TTFT；Agent 多轮调用共享大量 system prompt，前缀命中率决定成本；离线批处理没有时延约束，只看吞吐与每 token 成本。读后面每章都可以带着这个问题：我的业务属于哪一类，这项优化为我解决什么？

旅程第一站，是把人能看懂的输入变成模型能处理的整数序号（token ID）。这一站不占 GPU、却决定了后续所有计算的粒度：同一个意思，切出来的 token 越少，算得越快、KV Cache 也越小。

Tokenizer：文本怎样切成序号

主流大模型使用 BPE（Byte-Pair Encoding，字节对编码）类分词器：它在语料上预先统计“哪两个相邻片段最常一起出现”，把它们逐步合并成一个子词，最终形成一张 3–15 万大小的词表。分词时把句子从左到右 greedily 匹配词表，输出一串 ID；遇到没见过的词，就拆成已知的更小片段（极端情况退到字节），因此不会出现 OOV。

对中文业务还有一个容易忽略的量化事实：不同词表对中文的切分粒度差异很大。早期以英文为主的词表里一个汉字可能要拆成 2–3 个 token，而面向中文扩容过的词表（Qwen、GLM 等）通常在 1 个汉字 1 个 token 上下——同一句话的 token 数可以差到 1.5–2×。token 数直接决定 Prefill 算力、KV Cache 体积和按 token 计费的账单，所以评估一个模型是否适合自己的业务，用真实业务语料实测“每千字 token 数”，是比看参数量更实在的口径。

图片怎样进来：视觉编码器与图像 token

多模态模型里，图片不是直接进入 Transformer：它先被切成小块（patch），由一个视觉编码器（ViT）编码、再经投影层对齐维度，变成一组图像 embedding，与文本 token 的向量拼接成同一条序列，之后走的是完全相同的推理路径。分辨率越高、图像 token 越多（常见一张图数百到上千 token），算力与 KV Cache 开销随之增长。

图像 token 的数量是可以自己算出来的：以 Qwen2-VL 式的动态分辨率为例，ViT 按 14×14 像素切 patch、再经 2×2 合并，图像 token 数约为 $\frac{H}{28}\times\frac{W}{28}$（不同模型的 patch 与合并参数不同）——一张 1024×1024 的图约 1300 token，4K 分辨率则上万。视频则是“帧采样 × 每帧 token”，几秒视频轻松吃掉数千 token。多模态场景的显存规划，第一步就是把这条公式代进第 3 章的 KV 公式里。

第二站很短，但它是“离散符号”进入“连续计算世界”的入口：ID 序列被查成一批浮点数向量，之后 GPU 才能大展拳脚。

Embedding：一次近乎免费的查表

模型自带一张 Embedding 矩阵（词表大小 × 隐藏维度，如 15 万 × 4096），每个 ID 对应矩阵的一行；所谓 embedding，就是按 ID 把对应行取出来、拼成向量序列，再乘一个缩放系数。它是显存 gather 操作、没有矩阵乘，开销在整条路径中几乎可以忽略。图像 embedding 也在这一站与文本向量汇合。

位置编码：给向量装上“坐标”

自注意力只看内容相关性、对 token 的先后顺序天然无感（打乱输入，注意力照样能算）。因此必须显式注入位置信息：主流做法是 RoPE（旋转位置编码），在每个注意力层对 Q、K 按位置做一次与相对距离相关的“旋转”，让注意力打分天然带有相对位置信息，且能外推到训练时没见过的长度。RoPE 之外还有 ALiBi 等替代方案（不给向量做旋转，而是给注意力打分直接加上与距离线性相关的偏置，外推性好但表达力略弱），不过当前主流模型几乎清一色采用 RoPE。

长上下文外推：PI、NTK 与 YaRN。RoPE 的“外推”其实有限——拿按 4K 训练的模型直接跑 128K，注意力打分会迅速退化。工程上靠三类位置编码改造把窗口拉长：位置插值（PI）把超长位置线性压缩回训练范围，配合少量微调即可；NTK-aware 插值改为非均匀缩放旋转频率、压低频保高频，短文本几乎无损；YaRN 在此基础上按维度分频段处理并引入注意力温度校正，成为长上下文模型（Qwen、GLM 等）的主流配置。它们的共同点：不改模型结构、只动 RoPE 的“坐标系”，是部署长上下文时成本最低的改造。

RoPE 与 KV Cache 的耦合。旋转是施加在 Q、K 上的，因此缓存进 KV Cache 的 K 已经带上了位置信息——这带来两个直接后果：① 前缀复用（6.2 RadixAttention）要求命中的前缀位置编号完全一致，否则缓存的 K 与新请求的坐标系对不上；② DeepSeek MLA（3.2）之所以要在潜向量之外单独缓存一份 RoPE 部分，正是因为位置分量无法和内容一起被低秩压缩。同理，用 PI / YaRN 改坐标系扩上下文时，存量 KV 也必须一并重算。

向量序列进入模型主体——$L$ 个结构相同的 Transformer Block，这是整条路径上算力、显存带宽与优化手段最密集的一环。本章先用 3.1 建立背景、诊断 Decode 为什么慢；再沿三条优化主线展开：3.2 KV Cache 家族（少算、放得下、装得少，能复用见 6.2）、3.3 FlashAttention、3.4 量化。

背景：推理只有前向，Decode 为什么慢

推理只有前向：权重固定，不断预测下一个 token

前向传播（Forward）是数据从 Embedding 一路算到 logits 的过程，训练和推理都有；反向传播（Backward）从损失 Loss 倒推梯度、更新权重，只在训练中存在。推理阶段权重固定、只有前向、不断预测下一个 token，不更新任何参数——这也是为什么推理优化的抓手集中在“怎么搬数据、怎么调度”，而不需要保存反向用的中间状态。

30 秒回顾 Transformer 与 QKV

向量序列流过 $L$ 个结构相同的 Transformer Block（多头自注意力 MHA + 前馈网络 MLP/FFN，配 LayerNorm 与残差），最后由输出 Linear 层投影成词表维度的 logits。注意力做的事，是让当前 token 的 Query 与所有历史 token 的 Key 打分、再按权重取 Value：

其中 $Q$ 是当前 token 在“问什么”，$K$ 是每个历史 token 的“标签”，$V$ 是每个历史 token 的“内容”。多头（Multi-Head）只是把 Q/K/V 切成多组并行计算后拼回。

容易被忽略的是另一半参数：MLP/FFN。每个 Block 里注意力只占约 1/3 参数，剩下约 2/3 在两层（或 SwiGLU 三层）的前馈网络里——Decode 每步“搬权重”，大头其实是搬 MLP。现代模型的主流做法是把 MLP 换成 MoE（Mixture of Experts，混合专家）：把一个大 FFN 拆成数十到数百个“专家”，每个 token 由路由器只激活其中少数几个（如 Qwen3-30B-A3B 总参 30.5B、每 token 仅激活 3.3B）。MoE 对推理的含义是显存按总参数装、带宽与算力按激活参数算：模型必须完整常驻显存，但每个 token 只需读取被激活专家的权重——Decode 访存大减、TPS 天花板抬高（6.1 会按此修正口径），代价是专家路由引入 All-to-All 通信与负载均衡问题（见 7.3 趋势）。

两个节拍：Prefill 与 Decode

为什么 Decode 每次只输入 1 个 token？不是硬件强制，而是自回归逻辑 + KV Cache 设计的自然结果：Prefill 已把全部历史 K/V 存好，Decode 时“新信息”只有刚生成的那 1 个 token，所以本轮的 Q 只有 1 个；它用这 1 个 Q 去和缓存里全部历史 K/V 打分，采样出下一个 token，再把这 1 个 token 的 K/V 追加进缓存。第 $N$ 个 token 无法提前知道第 $N+1$ 个，只能逐步进行。

显存占用：模型权重、KV Cache 与激活

• 模型权重：参数量 $P$ × 每参数字节。BF16/FP16 = 2B/参数，FP8 = 1B，INT4 ≈ 0.5B。如 7B BF16 ≈ 14 GiB，70B BF16 ≈ 140 GiB——这部分常驻、不随上下文变化。
• KV Cache：随并发数与序列长度线性增长，是长上下文、高并发场景下最容易爆显存的部分，也是调度要重点管理的对象。
• 激活 $A$：推理时主要是 Prefill 的中间张量，相对权重小得多，Decode 阶段几乎可忽略。

先看清 GPU 的存储层级

GPU 不是一块“均匀的大内存”，而是一个越靠近计算核心越快、但容量越小的层级结构。硬件细节不是本文重点，只需记住结论：数据在不同层级之间搬运的速度，往往才是推理的真正瓶颈。

显存墙：算得快，搬得慢

当一次计算的算术强度（Arithmetic Intensity，每搬运 1 字节能做多少次浮点运算，FLOPs/Byte）很低时，计算单元会大量空转等数据，这就是 Memory-Bound。Decode 阶段每个 token 要把全部权重 + 全部 KV Cache 从 HBM 读一遍，却只做约 2 倍参数量的运算，算术强度极低，因此被显存带宽死死卡住。

Roofline：一张图判断瓶颈在算力还是带宽

KV Cache 家族：少算、分页、压缩与逐出

如果只记住一个推理优化，那就是 KV Cache。本节把所有围绕 KV Cache 的手段收为一个家族，按四个问题展开：① 少算——历史 K/V 只算一次；② 放得下——PagedAttention 分页管理；③ 装得少——GQA/MQA、MLA 与运行时逐出（KIVI 位宽量化见 3.4）；④ 能复用——RadixAttention 前缀树（见 6.2）。

① 少算：把历史 K/V 存起来，注意力计算 O(n²) → O(n)

它的思想极其朴素：把已经算过的历史 token 的 K、V 存起来，新 token 只算自己的 Q，直接复用旧 K/V，从而把每步“重算全部历史”的开销砍掉。

KV Cache 的数据流动：HBM、SRAM 与一次写入

把 KV Cache 放到硬件层面看，它改变的是「数据在 HBM 与片上 SRAM 之间怎么流动」。没有缓存时，每生成一个新 token，都要把它之前所有 token 的 K/V 重新算一遍（生成第 k+1 个 token 时，重算的是之前的 1~k 个）：权重反复从 HBM 读进 SRAM、算出的 K/V 用完即弃，下一步全部重来。有了缓存，Prefill 阶段权重只需流式读一遍，算出的 K/V 作为结果写回 HBM 的 KV Cache 区、只写一次；Decode 每生成一个 token，只算自己的 Q/K/V，把之前已缓存 token 的 KV 块从 HBM 读进 SRAM，在片上完成 $QK^\top$、softmax、乘 V，再把新 token 的 K/V 作为增量追加写回。另外要严格区分两层含义：「缓存随生成变长」说的是已缓存的有效内容逐步增多；而物理显存是按块管理的——旧式方案按最大生成长度连续预留一整段，PagedAttention（②）则切成固定页、按需分配、写满再取新页，空间总是先备好、内容再逐步写入。

注意区分两件正交的事：KV Cache 让历史 K/V「不重算」（省计算，代价是占用 HBM）；FlashAttention（3.3）让注意力的中间矩阵「不落地」——读进 SRAM 的 KV 块在片上算完、结果只写回一次（省访存）。二者叠加，才构成 Decode 的完整数据流。

为什么只缓存 K、V，从不缓存 Q？

这来自注意力结构的根本不对称：

• $K$、$V$ 是历史 token 的表示，一旦算好就不再改变，后续每一步都要反复使用——天然值得缓存。
• $Q$ 是“当前这一步”的查询，只在当前位置、当前这一次注意力里使用，用完即弃；下一步的新 token 会产生全新的 Q。缓存 Q 没有复用价值，反而白占显存。

一句话：K/V 面向过去、可复用；Q 面向当下、一次性。所以 KV Cache 里永远只有 K 和 V。

KV Cache 显存，一个公式算清

• $2$：K 和 V 两份，最容易漏；
• $n_{\text{kv}}$：KV 头数（GQA/MQA 用它，不是 Query 头数！Q 头再多也不影响 KV 大小）；
• $d_{\text{head}}$：单头维度，Llama/Qwen 系列一般为 $128$；
• $L$：模型层数；$s$：序列总长度（prompt + 生成）；$b_{\text{size}}$：并发 batch；
• $b$：每元素字节，BF16/FP16 = 2，FP8/INT8 = 1。

② 放得下：PagedAttention，像操作系统管内存一样管 KV

缓存本身该怎么在显存里摆放？传统做法给每个请求按最大生成长度连续预留一整段显存。但请求实际生成长度未知，预留多了形成内部碎片、预留少了直接 OOM；再加上预留的显存无法在请求间灵活共享，浪费惊人（vLLM 论文测得浪费 60–80%）。

PagedAttention 借鉴 OS 虚拟内存分页：把 KV Cache 切成固定大小的 Block（页，如每块 16 个 token）；逻辑上连续的 KV，物理上可以分散存放，由页表记录映射；按需分配、用完即回收。更进一步，相同前缀（系统提示、公共 few-shot、beam/采样分叉）的 KV 块可以在多个请求间共享（写时复制），几乎消灭碎片。

③ 装得少（结构侧）：减头 GQA / MQA

先从模型结构入手，减少每个 token 要缓存的 K/V。

KV Cache 大小正比于 KV 头数，于是模型侧最直接的演进就是减少 KV 头、让多个 Q 头共享同一组 K/V：

③ 装得少（维度侧）：MLA 多头潜在注意力

GQA/MQA 减的是 KV 头的数量；DeepSeek 提出的 MLA（Multi-head Latent Attention）走另一条路——把 K、V 向量本身通过低秩投影压缩成更小的潜向量（latent），缓存里只存这个潜向量，Decode 时再投影还原。KV 头数量不变，但每个 token 缓存体积大幅下降。

同属“结构侧装得少”的前沿方向还有稀疏注意力：DeepSeek 的 NSA 与月之暗面的 MoBA 让注意力只计算被选中的 KV 块、而非全部历史，把长上下文的注意力开销从 $O(n^2)$ 压到近线性，且设计为可训练、近无损——可以理解为“把 KV 驱逐（3.2）直接做进模型结构”的版本，二者均已进入新一代长上下文模型（趋势见 7.3，论文见参考文献）。工程上还有一个更温和的中间档：滑窗注意力（SWA）及其与全局注意力的层间混合——大部分层只看最近 W 个 token、每隔几层插一层全局注意力（Mistral 首开，Gemma 2/3 的 5:1 局部/全局交替即此路线；Qwen3-Next 等则把部分层换成线性注意力），KV 占用随窗口封顶、实现简单，是中长上下文模型的实用默认。

三个主流模型，代入公式实算

③ 装得少（运行时）：KV 逐出 H2O 与 SnapKV

结构改动需要重新训练模型；不训练模型，也能在运行时主动丢 KV——这就是逐出（eviction）。

KV Cache 随序列线性膨胀，长上下文下甚至超过权重。但注意力本身是高度稀疏的：实证表明，生成时 95% 以上的历史 token 几乎从未被高权重关注，真正反复被“看”的只有少数“关键 token”（Heavy Hitters）加上最近的一小段。这给了我们主动丢弃低价值 KV的空间（属有损压缩，需控制比例以保质量）。

H2O：Heavy-Hitter Oracle · 边生成边驱逐。

H2O 观察到一个规律：历史贡献（累计注意力得分）高的 token，未来也更可能被需要。它在每步维护一个固定大小的 KV 池，保留“累计注意力最高的 Heavy Hitter”加“最近窗口”，其余直接驱逐，从而把 KV Cache 变成有上界的滚动窗口，训练免费、可直接嵌入任意引擎。

SnapKV：生成前「一次看对眼」。

SnapKV 利用 prefill 末尾若干 query 位置（观察窗口）对各历史 KV 的注意力作为投票，选出对当前任务真正重要的 KV 位置，在 Decode 开始前一次性批量压缩。它特别契合长 prompt / RAG 场景——大量无关文档块可以在生成前就被丢掉，且因为依据的是真实任务相关的投票，压缩近无损。

Attention Sink：为什么开头几个 token 永远丢不得。驱逐类方法有一个共同的实证基础：softmax 要求注意力权重归一，模型会把大量“无处安放”的注意力倾倒给序列最开始的几个 token（Attention Sink）——它们被关注的强度远超其语义重要性，一旦被驱逐，输出立刻崩坏。StreamingLLM 利用这一点给出极简方案：只保留最前 4 个 sink token + 最近滑动窗口，KV 有界、无需微调，即可在远超训练长度的流式输入上稳定生成。它既是所有驱逐策略“特殊照顾开头”的物理直觉，也是无限流式对话（直播字幕、持续监控等场景）的经典解法。

FlashAttention：用分块把 N×N 矩阵“焊”在片上

先把标准注意力的完整计算写全（与 3.1 的公式一致）：

拆成三步看：$S=\dfrac{QK^{\top}}{\sqrt{d_k}}$（打分，别忘了除以 $\sqrt{d_k}$ 做缩放，防止分数随维度变大把 softmax 推进饱和区）、$P=\mathrm{softmax}(S)$（归一化成注意力权重）、$O=PV$（按权重加权求和 Value）。标准实现要把 $S$、$P$ 这些 $N\times N$ 中间矩阵反复写回 HBM 再读出，访存量是 $O(N^2)$。FlashAttention 的做法是算子融合 + 分块（Tiling）+ 在线 Softmax（Online Softmax）：把 Q/K/V 分块搬进片上 SRAM，在片上连续完成 $QK^\top$、softmax、乘 V，用流式方式逐块更新 softmax 归一化因子，最终输出 $O$ 只写回 HBM 一次，HBM 访存降到 $O(N)$。

同层的另一件武器：CUDA Graph 消除启动开销

FlashAttention 优化的是单个算子内部的访存；Decode 还有一层更“机械”的开销——每步前向要发起成百上千次 kernel launch，每次 launch 本身有数微秒的 CPU→GPU 开销，而 Decode 的每个 kernel 只算几十微秒，小 batch 下 launch 开销能占单步耗时的两三成（这正是 6.1 实测低于理论天花板的原因之一）。CUDA Graph 把 Decode 的整条计算图一次性“录制”下来，之后每步整体回放：CPU 只发一次启动指令，launch 开销几乎归零，vLLM、SGLang、TensorRT-LLM 均已默认对 Decode 开启。它与 FlashAttention、量化正交，是“不改算法、只改执行方式”的纯系统优化——代价是计算图形状（batch、序列长度档位）必须固定，引擎需要按档位预录多份。

量化：直接减少要搬运的字节

Decode 是 Memory-Bound，把权重/KV 从 BF16 降到 FP8/INT8/INT4，直接把搬运字节减半甚至减到 1/4，提速立竿见影；代价是引入微小精度损失（属有损优化，需校准或少量微调）。

Transformer 最后一层输出的隐藏向量，先经 lm_head 输出投影变成词表维度的一批浮点数（logits），采样环节要回答：这批浮点数对应哪个 token ID。本章先在 4.1 建立 logits→ID 的完整背景（采样旋钮），再讲两个优化方向：限制候选的约束解码（4.2），以及把「一次前向只出一个 ID」变成「一次前向出多个 ID」的投机解码家族（4.3）。

背景：logits 怎样变成一个 ID

确定性方法（贪心）直接取 logit 最大的 ID；随机方法先做 softmax 得到概率分布再按分布采样，并用一组旋钮调节随机性与重复度。

先补一笔容易被低估的账：lm_head 本身是词表维度的大矩阵乘（隐藏维 × 词表，如 4096 × 15 万）。Decode 阶段每个 token、每个请求都要过一次，大词表模型在 batch 较大时 lm_head 可占单步耗时的 10–30%。工程上的应对包括：词表维度做张量并行、lm_head 与采样融合为一个 kernel。这也回答了 02 章留下的悬念——同一张矩阵，Embedding 查表几乎免费，lm_head 全量投影却不便宜。

约束解码：把非法 ID 提前屏蔽

做后端最常需要模型输出 JSON、代码、函数调用参数等有严格格式的结果。但自由采样可能在任意位置混入非法字符（缺括号、多余逗号、枚举值乱写），下游解析直接失败。约束解码（Constrained / Guided Decoding）在每一步采样前，根据目标文法（JSON Schema、正则、BNF）判断当前状态下哪些 token 合法，把非法 token 的 logit 屏蔽为 $-\infty$，只在合法集合里采样，从机制上保证输出 100% 可解析。

投机解码：一次前向，确认多个 Token

前面的优化都在“喂饱”串行解码；投机解码家族更激进——先让一个便宜的“猜测者”一口气写出多个候选 ID，再让大模型用一次并行前向统一验证，对的直接采纳、错的丢弃重算。如果猜测足够准，就相当于用一次前向的时间换出了多个 token，且输出分布与大模型完全一致（无损）。

两阶段：Draft 猜测 → Target 验证

为什么能“无损”：拒绝采样的数学保证

设目标模型分布为 $p(x)$、猜测者分布为 $q(x)$。对候选 token $x$，以概率

决定接受；若被拒绝，则从修正分布 $r(x)\propto\max\big(0,\,p(x)-q(x)\big)$ 中重采样。可以证明：无论 $q$ 准不准，最终被接受的 token 分布严格等于目标分布 $p$。直觉上：猜测者认为概率不低于目标的 token（$q\ge p$）必然被接受；猜测者高估的 token 会以相应概率被拒、并“修正”回目标分布。猜测越准，接受长度越长、加速越多；猜得再差也只是退回普通解码，不会改变结果。

接受率的实战经验：温度越高，草稿与目标分布差异越大、接受率越低，高温创作场景收益会缩水；代码、数学、格式化输出（JSON/SQL）等“高可预测”任务接受长度最长——IDE 补全最先吃到投机红利正因此。评估时按自家任务的温度与内容分布实测接受率，别直接搬论文数字。

自投机：用模型自己的“浅层”当草稿

不想维护一个独立小模型，可以让目标模型自身在中间层提前输出（Early Exit / 早退）：用浅层快速起草，再走完整网络验证。只需少量微调让浅层具备预测能力，权重完全共享、部署简单，属于“自投机（Self-Speculative）”。

Medusa：给大模型加几个“候选头”

Medusa 在冻结的目标模型上新增若干轻量解码头（Medusa Heads）：头 1 预测下一个位置、头 2 预测下两个位置……各头给出 top 候选，组合成一棵候选树；再用 Tree Attention（为每条候选路径构造对应因果掩码）在一次前向里验证整棵树。它不需要逐步自回归起草，配合典型采样（typical sampling）与前缀树，典型加速 2.2–3.6×。

EAGLE：在“特征层”而不是 token 层起草

Medusa 直接猜 token，EAGLE 更进一步：把目标模型中层的隐藏特征与已采样 token 一起喂给一个轻量自回归头，在“特征序列”上做预测，天然贴合目标模型的内部表示，接受率显著更高。三代演进：

• EAGLE（ICML 2024）：特征 + token 起草，静态草稿树，约 3× 量级；
• EAGLE-2（EMNLP 2024）：动态草稿树——根据上下文置信度自适应分配候选，在“容易错”的地方布更多分支；
• EAGLE-3（2025）：提出 Training-Time Test（训练时就模拟测试时的多步草稿过程），去掉特征回归约束、融合低/中/高层特征统一建模，可随训练规模扩展，并原生支持推理（reasoning）模型，是当前公开方案中加速比第一梯队。

MTP：把“多 token 预测”做进模型本体

DeepSeek-V3 的 MTP（Multi-Token Prediction，多 token 预测）把投机能力直接做进模型：主模型之外串联若干 MTP 模块，每个模块接收上一位置的隐藏状态 + token embedding，预测下一个 token；训练时每个模块都作为额外的多任务预测损失（还能提升主模型质量），推理时这些模块自然形成一条候选链，再由主模型一次并行验证。DeepSeek-R1 推理即用 MTP 加速。

Lookahead Decoding：零训练、零小模型的 Jacobi 并行

Lookahead Decoding 完全不引入额外模型、也不做任何微调，而是用 Jacobi 迭代把“串行解码”变成对一个 2D 窗口的并行猜测：每条“猜测分支”在窗口内同时尝试多个未来位置（等价于并行 Jacobi 解码），每条“N-gram 分支”从历史维护的 n-gram 池里取候选序列验证、命中后回填池子。一次前向可能确认多个 token，未命中也无损退回。

同属零训练路线的还有 REST（Retrieval-Based Speculative Decoding）：草稿不从模型自身产生，而是从外部语料库检索与当前上下文匹配的 n-gram 片段作为候选，特别适合代码补全、RAG 等输出大量复用已有文本的场景。

同族还有一个更轻的分支 Prompt Lookup Decoding：草稿不去外部语料库检索，而是直接在当前请求的 prompt 里匹配 n-gram——代码编辑（输出大量重复上下文）、RAG 摘要（答案抄自检索文档）场景命中率极高，实现只需几十行、几乎零额外开销，常作为投机家族里“先试这个”的起步项。

家族全对比与选型

采样产出的 ID 是机器内部表示，用户要看到的是文字。Detokenizer 是 Tokenizer 的逆过程：按 ID 查表得到 token 字符串，再按 BPE 的合并规则把它们拼接还原。这一站计算量极小（仍是 CPU 侧的字符串操作），但有几个直接影响体验的工程细节。

三个工程细节

• 流式优先：不等整句生成完，每凑齐一个可显示的片段（一个词或标点边界）就立即推送，配合低 ITL 形成“打字机”体验；注意不要在多字节字符（中文/emoji）的中间切开，否则前端出现乱码。
• 特殊 token 过滤：停止符、填充符、对话模板标记（<|im_end|> 等）只用于控制流程，绝不能出现在最终文本里。
• 与投机解码对齐：一批被接受的 token 应一次性 detokenize，避免逐个推送造成的抖动；未被接受的候选不进入这一步。

还有两类“输出形态”的细节：一是工具调用 / Function Calling——其参数本质是一段受约束的 JSON（4.2），流式解析要按增量 JSON 的方式边收边校验，而不是攒到完整再 parse，否则工具执行要等到输出结束才能启动；二是内容安全审核通常挂在这一环节——流式场景采用“缓冲若干 token 送审、命中风险立即截断”的策略，审核窗口会额外增加首 chunk 延迟，需要在体验与合规之间取平衡。

前面五章跟踪了一个请求从输入到输出的完整旅程；服务端真正面对的是成千上万个请求同时处在流水线的不同环节：有的在 Prefill、有的在 Decode、有的刚结束。这一层横切所有环节，核心命题是调度粒度、显存组织与架构解耦，目标是把 GPU 吞吐打满。本章先看静态做法的痛点与天花板（6.1），再讲机内调度手段（6.2），最后是架构级的 PD 分离（6.3）。

背景：并发处理时 GPU 算力的浪费

最简单的批处理是凑齐一批请求、同时开始、等整批都生成完再返回、再放下一批。它有三个致命问题：

• 木桶效应：整批被最长的请求拖住，短请求早早算完也只能空等；
• 无法动态加入：新请求必须等上一批全部结束，期间 GPU 槽位空闲；
• 显存按最大长度预留：不管实际生成多少都按上限占位，内部碎片严重、且无法在请求间共享（3.2 的 PagedAttention 正是为解决这个问题）

浪费之外，再算清单卡的理论天花板，才知道优化空间有多大。

谈优化前还要先定义「好」：下面这套指标贯穿本章与第 3 章。

机内优化：动态拼批、切块调度与前缀复用

6.1 的痛点对应三类机内手段：调度粒度细化到 iteration（Continuous Batching）、长 Prefill 切块交错（Chunked Prefill）、公共前缀缓存复用（RadixAttention）；显存摆放问题（PagedAttention）已在 3.2 讲过。

Continuous Batching（ORCA 首创）把调度单位从「整批」细化到每个 iteration（一次前向）：完成的请求立刻离开、空槽插入新请求，GPU 持续满载（时序对比见上图）。

Continuous Batching 还有一个高负载下绕不开的问题：KV Cache 不够装时怎么办。当并发请求的 KV 总量逼近显存上限，调度器必须抢占（Preemption）一部分请求腾地方——vLLM 提供两种策略：重计算（Recompute），丢弃被抢占请求的全部 KV、轮到时重跑 Prefill，实现简单但时延开销大；换出（Swap），把 KV 临时搬到 CPU 内存、轮到时再搬回，省算力但吃 PCIe 带宽。工程上通常配合优先级队列与最大并发上限，把抢占压成偶发事件——频繁抢占本身就是“该扩容或上 PD 分离（6.3）”的信号。

Prefill 是 Compute-Bound，一个几万 token 的长请求会连续占用 GPU 多个 iteration，期间正在 Decode 的请求得不到调度，ITL 出现尖刺、用户明显卡顿。Chunked Prefill 把长 Prefill 切成固定小块（chunk），与 Decode 请求在 iteration 级别交错执行，必要时还把多个 prefill 块拼进同一 batch，兼顾首 token 时延与吞吐。chunk 大小是关键参数：切得太小，Prefill 效率下降、调度开销上升；切得太大，ITL 尖刺依旧。vLLM 默认 chunk 约 2048 token（长 prompt 场景可调大到 4096–8192），正确姿势是固定业务流量、按 TTFT 与 ITL P99 实测调参。

多轮对话、Agent、共享系统提示、few-shot 场景里，大量请求共享相同前缀。SGLang 提出 RadixAttention：用一棵 基数树（Radix Tree）维护所有处理过的 prompt，新请求自动做最长前缀匹配，命中的 KV 直接复用、未命中部分才算；缓存紧张时按 LRU 驱逐最少使用的叶子。它与 PagedAttention 是搭档——分页管“块怎么放”，基数树管“哪些前缀能复用”。

一个工程提醒：RadixAttention 的收益完全取决于前缀命中率——多轮对话、共享 system prompt、Agent 场景命中率常超过 50%；但如果业务里每条 prompt 都互不相同（如独立文档的离线批处理），前缀缓存只会白占显存，此时应调低缓存容量甚至关闭。上线前用真实流量统计命中率（vLLM / SGLang 均暴露 prefix cache hit rate 指标），比盲目开启更重要。

架构级优化：PD 分离

当 Prefill 与 Decode 的资源矛盾在机内无法靠调度调和时，必然走向架构解耦。

为什么必须分离：两阶段资源诉求相差约 140 倍。

同一个模型、同一块卡，Prefill 与 Decode 的吞吐差距是数量级的。以 20 层模型在消费级卡上的实测为例（视频作者数据）：Prefill 约 14,000 token/s，Decode 约 100 token/s，相差约 140 倍。更麻烦的是二者对硬件的偏好相反：

• Prefill 要强算力（高 FLOPs、可接受较小显存），算力越猛 TTFT 越低；
• Decode 要大显存 + 高带宽（装得下权重与大量 KV、搬得快），算力反而不重要。

把两阶段混部（Co-located）在同一批 GPU 上，会互相干扰：长 Prefill 拖慢 Decode 的 ITL，Decode 又占着算力让 Prefill 排队，资源配比无法同时满足两边，整体利用率与 SLO 双输。

怎么做：两池拆分，KV 迁移。

核心是把两阶段拆到不同 GPU 池、各自独立扩缩容：请求先进 Prefill 池完成提示计算与首 token，生成的 KV Cache 通过高速互联整体搬运/复制到 Decode 池，再由 Decode 池完成后续自回归生成并流式返回。难点不在“拆”，而在KV Cache 的高效迁移与全局调度。

两池内部的并行策略也可以各自选。推理常用的并行方式有三种：张量并行（TP）把每层权重切到多卡、每层两次 AllReduce——Decode 带宽受限时，TP 让单卡搬运量除以 N（图 32），是 Decode 池最常用的手段，代价是通信随卡数上升（A10 无 NVLink、走 PCIe，一般不超过 2–4 卡）；流水并行（PP）按层切分、卡间只传激活，通信少但调度复杂，推理用得少；专家并行（EP）是 MoE 专属，专家分到不同卡、token 经 All-to-All 路由。Prefill 池偏算力、常配较大 TP；Decode 池偏带宽与显存，TP / EP 按 KV 容量与带宽目标定——这就是图 31 里“两池并行策略可完全不同”的具体含义。

三篇奠基论文，三种侧重。

关键工程问题：KV Cache 怎么搬。

工程上还会做：KV 块页对齐、压缩后再传（FP8）、传输与计算重叠、只传增量，把迁移成本摊到流水线里，使它不成为新瓶颈。另一个配套手段是 KV 分层 offload：热 KV 留在 GPU 显存，温 KV 下沉 CPU 内存，冷 KV（如多轮对话的历史轮次）落 SSD——Mooncake 的全局 KV Pool 正是这一思路的集群化，让显存只装“正在用”的部分。

前沿：PD 分离正在「产品化、标配化」。

一句话串起全文

沿着一次请求走一遍：文字或图片经 Tokenizer（及视觉编码器）变成 ID 序列，Embedding 查表层把 ID 变成向量，Transformer 层在 Prefill/Decode 两节拍里完成推理计算，lm_head 把隐藏向量变回 logits，采样选出下一个 ID，Detokenizer 把 ID 拼回文字流式输出，再把选中的 ID 喂回入口循环往复。每个环节的优化都有明确指向：输入侧异步分词、识别公共前缀；计算侧KV Cache、GQA/MLA、FlashAttention、量化与 KV 驱逐；调度侧Continuous Batching、PagedAttention、Chunked Prefill、RadixAttention 与 PD 分离；采样侧温度/Top-P 旋钮、约束解码与投机解码家族。它们大多无损、可叠加，最终目标是在 SLO 达标前提下最大化 Goodput、最小化每 token 成本。

这条公式是全文所有优化的最终折算口径：Goodput 越高，每 token 成本越低——PD 分离的资源重配、Splitwise 的异构分工、KV 压缩换来的更高并发，最终都在这条公式上见效。

工程落地 Checklist（按流水线环节）

推理引擎怎么选

全文提到的引擎能力正在收敛（趋势 7），但侧重仍有差异，选型先看业务画像：

前沿趋势（2025–2026）

1. PD 分离“标配化”：NVIDIA Dynamo + NIXL、vLLM/SGLang/Mooncake 全部内置，分离架构成为大规模部署默认项。
2. KV Cache 成为一等公民：跨节点/跨层级（GPU/CPU/SSD）池化、持久化、按需复用甚至单独计费，系统设计从“以计算为中心”转向“以 KV 为中心”。
3. 推理（Reasoning / 思考）模型普及：长 thinking 阶段让 Prefill/Decode 比例剧变，Chunked Prefill、PD 配比与面向推理模型的投机解码（EAGLE-3 等）成为新重点。
4. MoE / EP 推理性价比：大参数、小激活（如 Qwen3-30B-A3B），需要 expert 并行、All-to-All 通信与专家负载均衡配套。
5. 测试时计算（Test-Time Compute）：多路径采样、树/并行验证、自评估与搜索进入推理引擎，天然依赖 Tree Attention 与批量验证能力。
6. 硬件与精度：GB200 NVL72 把整机做成一个 NVLink 域、HBM3e 与 FP8/FP4 普及，带宽与互联持续抬高 Roofline 屋顶。
7. 引擎能力收敛：vLLM、SGLang、TensorRT-LLM 在分页、前缀、PD、投机上能力趋同，竞争转向调度智能、异构支持与端到端成本。
8. 稀疏与混合注意力进入主线模型：NSA / MoBA 等可训练稀疏注意力与 SWA 混合层（Gemma 2/3、Qwen3-Next 等）把长上下文注意力成本压到近线性，"装得少"正从运行时手段变成模型结构的默认项（3.2）。

建议的读论文顺序

1. 打地基：Transformer → FlashAttention
2. 显存与服务：vLLM/PagedAttention → SGLang → Sarathi-Serve
3. 架构：DistServe → Mooncake → Splitwise
4. 解码算法：Speculative Decoding → Medusa → EAGLE（→2→3）→ DeepSeek-V3 MTP → Lookahead
5. 压缩与长上下文：StreamingLLM → H2O → SnapKV → YaRN → XGrammar

参考文献

1. Attention Is All You NeedVaswani et al. · NeurIPS 2017 · Transformer 原始论文arXiv:1706.03762
2. Fast Transformer Decoding: One Write-Head is All You Need (MQA)Shazeer · 2019arXiv:1911.02150
3. GQA: Training Generalized Multi-Query Transformer Models from Multi-Head CheckpointsAinslie et al. · EMNLP 2023arXiv:2305.13245
4. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-AwarenessDao et al. · NeurIPS 2022arXiv:2205.14135
5. FlashAttention-2: Faster Attention with Better Parallelism and Work PartitioningDao · 2023arXiv:2307.08691
6. FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precisionShah et al. · NeurIPS 2024arXiv:2407.08608
7. Orca: A Distributed Serving System for Transformer-Based Generative ModelsYu et al. · OSDI 2022 · iteration-level 调度源头USENIX OSDI'22
8. Efficient Memory Management for LLM Serving with PagedAttention (vLLM)Kwon et al. · SOSP 2023arXiv:2309.06180
9. Sarathi: Efficient LLM Inference by Pipelining Token ComputationAgrawal et al. · 2023 · Chunked PrefillarXiv:2308.16369
10. Sarathi-Serve: Chase Away Prefix Queue Under Chunked PrefillsAgrawal et al. · OSDI 2024arXiv:2403.02310
11. SGLang: Efficient Execution of Structured Language Model Programs (RadixAttention)Zheng et al. · NeurIPS 2024/2025arXiv:2312.07104
12. DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM ServingZhong et al. · OSDI 2024arXiv:2401.09670
13. Splitwise: Efficient Generative LLM Inference Using Phase SplittingPatel, Choukse et al. · ISCA 2024arXiv:2311.18677
14. Mooncake: A KVCache-centric Disaggregated Architecture for LLM ServingQin et al. · FAST 2025 最佳论文 / ACM TOS 2025arXiv:2407.00079
15. NVIDIA Dynamo：开源分布式推理编排框架（含 NIXL KV 传输）NVIDIA · 2025 · PD 分离产品化github.com/ai-dynamo/dynamo
16. Fast Inference from Transformers via Speculative DecodingLeviathan, Kalman, Matias · ICML 2023arXiv:2211.17192
17. Accelerating LLM Decoding with Speculative SamplingChen et al. · DeepMind · 2023arXiv:2302.01318
18. Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding HeadsCai et al. · ICML 2024arXiv:2401.10774
19. EAGLE: Speculative Sampling Requires Rethinking Feature UncertaintyLi et al. · ICML 2024arXiv:2401.15077
20. EAGLE-2: Faster Inference of Language Models with Dynamic Draft TreesLi et al. · EMNLP 2024arXiv:2406.16858
21. EAGLE-3: Scaling up Inference Acceleration via Training-Time TestLi et al. · 2025arXiv:2503.01840
22. Break the Sequential Dependency of LLM Inference Using Lookahead DecodingFu et al. · ICML 2024arXiv:2402.02057
23. DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model (MLA)DeepSeek-AI · 2024arXiv:2405.04434
24. DeepSeek-V3 Technical Report (MTP / MLA / FP8)DeepSeek-AI · 2024arXiv:2412.19437
25. Draft & Verify: Lossless LLM Acceleration via Self-Speculative DecodingZhang et al. · 2023arXiv:2309.08168
26. REST: Retrieval-Based Speculative DecodingAnkner et al. · 2023 · 用检索 n-gram 数据起草arXiv:2311.08252
27. H2O: Heavy-Hitter Oracle for Efficient Generative Inference of LLMsZhang et al. · NeurIPS 2023arXiv:2306.14048
28. SnapKV: LLM Knows What You Are Looking for Before GenerationLi et al. · NeurIPS 2024arXiv:2404.14469
29. KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV CacheZhang et al. · ICML 2024arXiv:2402.02750
30. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained TransformersFrantar et al. · ICLR 2023arXiv:2210.17323
31. SmoothQuant: Accurate and Efficient Post-Training Quantization for LLMsXiao et al. · ICML 2023arXiv:2211.10438
32. AWQ: Activation-aware Weight Quantization for On-Device LLM CompressionLin et al. · MLSys 2024arXiv:2306.00978
33. Grammar-Constrained Decoding for Structured NLP Tasks without FinetuningGeng et al. · EMNLP 2023arXiv:2305.13971
34. Efficient Guided Generation for Large Language Models (Outlines)Willard & Louf · 2023arXiv:2307.09702
35. XGrammar: Flexible and Efficient Structured Generation Engine for LLMsDong et al. · 2024arXiv:2411.15100
36. Roofline: An Insightful Visual Performance Model for Multicore ArchitecturesWilliams, Waterman, Patterson · CACM 2009ACM DOI
37. Efficient Streaming Language Models with Attention Sinks (StreamingLLM)Xiao et al. · ICLR 2024 · Attention Sink + 滑动窗口，KV 有界的无限流式生成arXiv:2309.17453
38. Extending Context Window of Large Language Models via Positional Interpolation (PI)Chen et al. · Meta · 2023 · 位置插值扩上下文arXiv:2306.15595
39. YaRN: Efficient Context Window Extension of Large Language ModelsPeng et al. · ICLR 2024 · 分频段 RoPE 外推，长上下文主流方案arXiv:2309.00071
40. Native Sparse Attention: Hardware-Aligned and Natively Trainable Sparse Attention (NSA)Yuan et al. · DeepSeek-AI · 2025 · 可训练稀疏注意力arXiv:2502.11089
41. MoBA: Mixture of Block Attention for Long-Context LLMsLu et al. · Moonshot AI · 2025 · 块混合稀疏注意力（Kimi 长上下文方案）arXiv:2502.13189
42. Mistral 7BJiang et al. · Mistral AI · 2023 · 滑窗注意力（SWA）进入主流模型的开端arXiv:2310.06825
43. Min P Sampling: Balancing Creativity and Coherence at High TemperatureNguyen et al. · 2024 · 按比例动态截断的采样方法arXiv:2407.01082