8.2 推理优化
核心问题： 如何提高 LLM 服务的吞吐、降低延迟，并控制显存占用？
在线 Notebook
对应的交互式版本可在 Google Colab 打开，统一使用方式见 第0章说明。
推理的两个阶段
自回归生成分成两个阶段：
| 阶段 | 做什么 | 主要瓶颈 |
|---|---|---|
| Prefill | 处理输入 prompt，构建初始 KV cache | 计算量大 |
| Decode | 每次生成一个新 token | 内存访问和调度 |
长 prompt 会让 prefill 变重，长输出会让 decode 持续占用资源。
KV Cache
KV cache 保存历史 token 的 Key/Value，避免每生成一个 token 都重新计算全部上下文。
text
没有 KV cache：
每一步重新计算完整上下文
有 KV cache：
历史 K/V 复用，只计算新 token代价是显存占用会随上下文长度、batch size 和层数增长。长上下文服务的核心问题之一，就是 KV cache 管理。
批处理与调度
批处理可以提高 GPU 利用率，但会影响单个请求延迟。
| 策略 | 优点 | 代价 |
|---|---|---|
| 静态 batch | 实现简单 | 请求长度差异大时浪费 |
| 动态 batch | 提高吞吐 | 调度更复杂 |
| 连续批处理 | 适合流式生成 | 需要专门推理框架 |
vLLM、TGI、TensorRT-LLM 等框架的核心价值，就在于更好地管理 batch、KV cache 和显存碎片。
Flash Attention
标准 attention 需要读写完整注意力矩阵，IO 成本高。Flash Attention 通过分块计算减少显存读写，提高训练和推理效率。
它解决的是 IO 和显存访问问题，不改变 attention 的数学结果。
优化指标
上线时至少同时看四个指标：
- 首 token 延迟（TTFT）
- 每秒生成 token 数（tokens/s）
- 最大并发
- 显存占用和 OOM 率
只优化吞吐可能牺牲交互体验，只优化延迟可能导致 GPU 利用率过低。
本节小结
- Prefill 主要受输入长度影响，decode 主要受生成长度和调度影响
- KV cache 是自回归推理提速的关键，但会显著占用显存
- 批处理提升吞吐，但会引入延迟和调度复杂度
- 推理优化必须同时评估吞吐、延迟、显存和稳定性
下一节： 8.3 成本优化