第2章 · 流式LLM推理性能优化

第 2 章 · 流式LLM推理性能优化

章节摘要：大语言模型的流式推理是当前性能优化最密集的战场。这一章钻进推理引擎的内核：KV Cache 解决了重复计算 attention 的问题但带来了显存碎片，PagedAttention 借鉴操作系统的分页机制把碎片化管理掉；连续批处理（continuous batching）让不同请求能在 token 级别动态进出 batch，把 GPU 利用率从 30% 拉到 80% 以上；推测解码用小模型猜、大模型验，在不掉精度的前提下加速 decode。最后对比 vLLM 和 TensorRT-LLM 两大主流引擎的设计差异和适用场景。

学习目标

阅读完本章，你应当能够：

1. 解释 KV Cache 的工作原理，以及它为什么会造成显存碎片
2. 说清 PagedAttention 借鉴操作系统分页机制解决了什么问题
3. 区分静态批处理和连续批处理，说明后者为什么能大幅提升吞吐
4. 复述推测解码的"小模型猜大模型验"机制及其加速来源
5. 对比 vLLM 和 TensorRT-LLM 的设计哲学，根据场景选型

核心概念速览

LLM 推理优化的核心矛盾：显存是瓶颈，不是算力。大部分时间 GPU 在等数据从显存搬过来，优化的是搬运效率而非计算速度。

子章节导航

2.1 KV Cache 与 PagedAttention 原理

讲 KV Cache 为什么能让 decode 不重复算历史 token，以及它带来的显存碎片问题怎么被 PagedAttention 的分页机制解决。这是理解 vLLM 为什么快的根基。

2.2 连续批处理与推测解码

两个独立的吞吐和延迟优化：连续批处理让请求在 token 级别动态进出 batch，解决"长请求拖死整个 batch"的问题；推测解码用小模型预生成候选 token、大模型并行验证，降低单请求 decode 延迟。

2.3 vLLM 与 TensorRT-LLM 对比实战

两大主流引擎的设计差异——vLLM 重通用性和易用性，TensorRT-LLM 重极致性能和硬件深度优化。对比它们的吞吐、延迟、部署成本，给出选型建议。

子章节之间的逻辑关系

先理解底层的显存管理机制（2.1 的 KV Cache 和 PagedAttention），这是所有上层优化的基础；再看怎么在此基础上提升吞吐和降低延迟（2.2 的批处理和推测解码）；最后落到具体的引擎选型（2.3）。从原理到策略再到工具。

2.1 显存机制  ──►  2.2 吞吐与延迟策略  ──►  2.3 引擎选型
（为什么快）        （怎么更快）            （用什么工具）
​

前置知识与后续延伸

• 前置知识：第 1 章的延迟构成和 batch 权衡是基础，尤其是 prefill 与 decode 的区别、利用率曲线。
• 后续延伸：本章聚焦文本 LLM。第 3 章会把流式推理的方法论扩展到语音（流式 ASR/TTS），第 4 章扩展到端侧（资源更受限场景下的同类问题）。

这套优化技术是怎么一步步长出来的

本章的三个核心技巧有一条清晰的演化线索。最早只有朴素批处理：把同时到达的请求攒成一批一起跑，批内最长的请求不结束，整个 batch 的槽位就空着不放人，GPU 利用率常年在三成徘徊。2022 年前后业界提出连续批处理（也叫 iteration-level scheduling），调度粒度从"一次请求"细化到"一步解码"，短请求做完立刻退出、新请求立刻补位，这一步直接把吞吐拉高了数倍，也让"长短请求混合流量"第一次变得可运营。

第二个阶段解决显存。KV Cache 按最大序列长度预留显存的传统做法造成大量浪费——实际序列长度分布是重尾的，多数请求远短于上限。vLLM 团队 2023 年发表的研究把操作系统的分页思想搬进 attention 计算，显存浪费从百分之六十以上压到百分之四以下，同等硬件能同时容纳的请求数翻了数倍，这成了 PagedAttention 的成名之战。第三个阶段是算法侧的推测解码：先在 2023 年由 DeepMind 和清华各自提出雏形，思路是把"逐 token 串行"改成"小模型草拟一段、大模型并行验一段"，验证利用了 GPU 天然擅长并行前向的特性，在不改变输出分布的前提下加速两到三倍。

值得注意的转折是：这些技术原本散落在不同论文和私有实现里，是 vLLM、TensorRT-LLM 这类开源引擎把它们工程化、组合化，普通团队才得以用一条命令享受到全部收益。这也解释了 2.3 节为什么要专门讲引擎对比——引擎的选择如今等同于这套技术栈的选择。

常见误读与澄清

初学者容易把 KV Cache 当成"缓存"从而误解它的开销：它不是可丢弃的性能加速层，而是 decode 的必需数据结构，丢一块就得重算一段 prefill，因此"显存不够时清 cache"在推理服务里几乎从来不是正确选项，正确选项是换更省显存的管理策略。另一个常见误读是以为推测解码"总能让输出变快"——它对小模型与大模型分布差异大的场景（代码、严格格式输出）会频繁打回重猜，加速比可能跌破一，上线前必须用真实流量分布回测。第三，连续批处理并非没有代价：动态进出 batch 意味着调度器每步都要做决定，调度本身成为 CPU 瓶颈，超高并发下引擎的 Python 调度层会先于 GPU 饱和，这也是各引擎近年重写调度器、引入零拷贝张量传递的原因。读完本章不妨带着这三条误读去检验你手上的服务：说清楚你的显存花在哪、你的调度器是否先饱和，能回答这两问的团队，通常也已经把自己的 P99 延迟调到了体面的位置。

图：LLM 推理优化技术演化三阶段