LLM推理优化#
一句话答案#
推理优化核心手段：量化（INT8/INT4/FP8/FP4）、KV Cache、PagedAttention（vLLM）、推测解码、连续批处理；此外还有 FlashAttention 这类注意力内核优化和前缀缓存。
核心要点
主要优化技术对比：
| 技术 | 原理 | 效果 | 代表工具 |
|---|---|---|---|
| 量化（INT8/INT4/FP8/FP4） | 降低权重（和激活、KV）精度 | 体积缩小 2-4x，decode 加速 | GPTQ、AWQ、FP8、NVFP4/MXFP4、GGUF（详见量化篇） |
| KV Cache | 缓存历史 token 的 Key/Value 矩阵 | 避免重复计算注意力 | 所有推理框架默认支持 |
| PagedAttention | 借鉴 OS 虚拟内存分页管理 KV Cache | 解决显存碎片，提升吞吐 | vLLM |
| 推测解码 | 草稿（小模型或附加的预测头）生成候选，大模型一次前向并行验证 | 低并发下常见 2-3x，并发越高收益越小；输出分布不变 | EAGLE-3、MTP、独立草稿模型、n-gram；vLLM/SGLang/TensorRT-LLM 内置 |
| 连续批处理 | 动态加入/退出请求，共享 GPU 计算 | 提高 GPU 利用率 | vLLM、SGLang、TensorRT-LLM |
| FlashAttention | 分块计算注意力、在片上 SRAM 里做 online softmax，不把 N×N 注意力矩阵写回显存 | 省显存、降访存，长序列提速明显；结果精确（不是近似） | FA2 通用；FA3 针对 Hopper；FA4 针对 Blackwell（2026-03 发布，仍标 beta） |
| 前缀缓存 | 相同前缀（system prompt、多轮历史、few-shot）的 KV 复用 | 降低 TTFT 和 prefill 算力 | vLLM Automatic Prefix Caching、SGLang RadixAttention |
量化方案（GPTQ / AWQ / GGUF / NF4 / FP8）、显存估算与部署栈选型：已独立成篇，见 模型量化与本地部署；本篇聚焦运行时优化（KV Cache / PagedAttention / 批处理 / 推测解码）。
KV Cache 显存估算公式：
显存 = 2 × num_layers × hidden_dim × seq_len × batch_size × precision_bytes以 7B 模型 FP16 为例：2 × 32 × 4096 × 2048 × 1 × 2 ≈ 1GB
（此式假设 MHA、KV 维度=hidden_dim；GQA/MQA 下 KV 头数远少于 Q 头，需按 KV head 数折算，显存大幅降低）
PagedAttention 核心思想：
- 传统方式预分配连续显存 → 碎片浪费严重（平均浪费 60-80%）
- PagedAttention 将 KV Cache 分成固定大小的 Block，用 Block Table 映射逻辑块到物理显存
- 类比 OS 虚拟内存分页：逻辑地址连续，物理地址不必连续
推测解码的几种草稿来源：
- 独立草稿模型：同系列小模型（如 1B 给 70B 打草稿），要求词表一致，分布越接近接受率越高
- EAGLE 系列：在目标模型上接一个轻量草稿头，用目标模型的隐藏状态预测后续 token；EAGLE-3 改用多层特征融合和训练时模拟推理，论文报告 3–6.5x 加速，是目前 vLLM/SGLang 推荐的通用方案之一，需要为目标模型单独训练草稿头
- MTP（多 token 预测）：模型预训练时就带多 token 预测模块（如 DeepSeek-V3），推理时直接拿来当草稿
- n-gram / 后缀匹配：从 prompt 或历史里查重复片段当候选，不需要额外模型，适合代码改写、RAG 这种输出大量复用输入的场景
推理框架选型（vLLM / SGLang / TensorRT-LLM / llama.cpp / Ollama）：对比表见 模型量化与本地部署；一句话记：生产高吞吐上 vLLM/SGLang，本地与端侧用 llama.cpp/Ollama。HF 的 TGI 已进入维护模式，GitHub 仓库于 2026-03 归档为只读，官方推荐改用 vLLM/SGLang。
面试回答（2分钟版）
LLM推理优化主要从五个方向入手。第一是量化，把模型权重从FP16降到INT8甚至INT4，模型体积和显存占用大幅减小，推理速度提升，精度损失通常可接受。第二是KV Cache，Transformer自回归生成时每个新token都要和之前所有token做注意力计算，KV Cache把历史token的Key和Value缓存起来避免重复计算，是最基本的优化。第三是PagedAttention，vLLM提出的核心技术，借鉴操作系统的虚拟内存分页思想管理KV Cache，解决了预分配导致的显存碎片和浪费问题。第四是推测解码，用一个小模型快速生成多个候选token，大模型并行验证，如果候选正确就跳过这些步骤，本质是用小模型打草稿大模型审批。第五是连续批处理，不同请求的生成长度不同，连续批处理允许完成的请求退出、新请求随时加入，提高GPU利用率，类似拼车。另外，注意力计算本身靠FlashAttention这类内核减少显存读写，多轮对话和固定system prompt靠前缀缓存复用KV，这两项在现在的推理框架里基本默认开启。
追问与易错
追问方向：
- vLLM 和 SGLang 怎么选型？TGI 还用吗？ → vLLM 模型和硬件覆盖最广、社区最大，是通用默认选项；SGLang 的 RadixAttention 前缀缓存和结构化输出在多轮对话、Agent、共享前缀的 RAG 负载上更有优势。两者都要在自己的负载上压测。TGI 已进入维护模式、仓库已归档，新部署不建议再选
- 量化后精度下降了怎么补救？哪些任务对量化敏感？ → 用 AWQ（激活感知量化）保留重要通道精度，或用 GPTQ 后再做 calibration。数学推理和代码生成对量化最敏感，简单对话影响小
- 推测解码的小模型怎么选？和大模型不匹配怎么办？ → 独立草稿模型选同系列、同词表的小版本（如 1B/8B 给 70B 打草稿），分布越接近接受率越高；现在更常用的是 EAGLE-3 这类草稿头或模型自带的 MTP 模块，接受率更高、额外显存小。不匹配时拒绝率高反而更慢；并发高时 GPU 已经忙满，推测解码收益也会下降，需要在具体任务和并发下评测
- KV Cache 超出显存了怎么处理？ → 三种方案：设 max_seq_len 截断（最简单）、PagedAttention 动态分页（vLLM）、KV Cache 卸载到 CPU/SSD（牺牲延迟换容量）
易错点：
- ❌ “量化不影响精度” → INT4 在复杂推理任务上可能有明显退化，需要评测验证
- ❌ “KV Cache 可以无限增长” → 受显存限制，需要设置 max_seq_len 或用 PagedAttention 动态管理
- ❌ “推测解码一定更快” → 小模型和大模型分布差异大时，候选拒绝率高反而更慢；大 batch 高并发时也可能没有收益
- ❌ “FlashAttention 是近似注意力” → 它只改变计算顺序和访存方式，结果与标准注意力数值等价