pdf版下载链：https://pan.quark.cn/s/9cc742e9c2a8
09 LLM 推理优化：KV Cache、量化与服务加速
更新： 2026-10-12
时效说明：框架能力与硬件矩阵截至 2026-10。吞吐、延迟和压缩收益都依赖模型、硬件、输入/输出长度、并发与质量门槛；本文不提供无条件性能承诺。
📋 目录
- Prefill / Decode 与 KV Cache
- 权重、激活和 KV 量化
- Attention、批处理与投机解码
- 2026 推理框架、PD 分离与前缀复用
一、推理基础
Q1: LLM 推理和训练有什么区别？为什么推理更难优化？
训练通常一次处理完整序列并做前向、反向和优化器更新；在线自回归推理只做前向，但要逐 token 解码，并承受动态请求。
主要矛盾：
- Prefill 对长 prompt 做大矩阵计算，通常更偏算力密集。
- Decode 每步只生成少量 token，反复读取权重与 KV Cache，通常更偏显存带宽和调度。
- 请求长度、采样参数、到达时间不同，静态 batch 容易被最慢请求拖住。
- KV Cache 随并发与上下文增长，容量会先于权重成为瓶颈。
- 生产目标不只 tokens/s，还包括 TTFT、ITL/TPOT、P99、可用性和每 token 成本。
优化前必须定义 workload：
输入长度分布 + 输出长度分布 + 到达过程 + 并发
+ 模型/精度 + GPU/互连 + SLO + 质量门槛
Q2: 什么是自回归生成？Prefill 和 Decode 有什么区别？
自回归分解：
P(y|x) = ∏t P(y_t | x, y_<t)
Prefill：
- 一次处理 prompt，生成各层初始 KV Cache。
- 关注 TTFT、长序列 attention、chunked prefill 和 prefix cache 命中。
Decode：
- 每步用新 token 的 query 读取历史 KV 并追加新 KV。
- 关注 ITL、内存带宽、并发序列数、KV 容量和采样开销。
因此不能用单一“平均延迟”评估。至少报告：
- TTFT：从请求到首 token。
- ITL / TPOT：输出 token 间延迟。
- E2E latency。
- request throughput 与 output tokens/s。
- P50/P95/P99，并按输入/输出长度分桶。
二、KV Cache 优化
Q3: 什么是 KV Cache？为什么需要它？
若每个 decode 步都重算全部历史 token 的 K/V，会产生大量重复计算。KV Cache 保存每层历史 K/V，新一步只计算新 token 并与历史交互。
标准 MHA 的粗略元素数：
2 × layers × sequence_length × num_kv_heads × head_dim
再乘 dtype 字节数、并发序列和副本数。实际显存还包含 block 元数据、对齐、临时 workspace 和碎片。
降低 KV 成本的路线：
- GQA/MQA：减少 KV heads。
- Paged/block KV 管理：按块分配，减少预留与碎片。
- Prefix caching：共享相同前缀的 KV。
- Sliding window / attention sink / 状态空间或混合架构：限制历史状态，取决于模型。
- KV 低精度、CPU/SSD 分层、跨节点 KV 传输。
- PD disaggregation：prefill 与 decode 分开扩缩。
Q4: KV Cache 量化是什么？如何实现？
KV 量化把 K/V 从 BF16/FP16 降到 FP8、INT8、INT4 或研究型更低 bit 表示，降低容量和带宽。
关键维度：
- K 与 V 可使用不同粒度和精度。
- per-tensor / per-channel / per-token / per-group scale。
- 静态校准 vs 在线动态 scale。
- 量化后的 attention kernel 是否融合，若频繁反量化可能得不偿失。
- 长上下文、不同层和异常值下的质量退化。
验证不能只跑困惑度：
- 长上下文检索与多轮对话。
- 领域任务和结构化输出。
- TTFT、ITL、吞吐与最大并发。
- 不同上下文长度下的误差。
“INT4 必然 4× 加速”是错误的：容量缩小不等于计算路径等比例加速。
Q5: 什么是 PagedAttention？它解决什么问题？
PagedAttention 的思想是把每个请求的逻辑 KV 序列映射到固定大小物理块，而非预留一整段最大长度连续显存：
- 按需分配，减少过度预留。
- 物理块无需连续，降低外部碎片。
- beam / parallel sampling 可用 copy-on-write 共享块。
- 调度器能回收完成请求的块并立即服务新请求。
它不是“零浪费”：
- 最后一个块仍有内部碎片。
- block table、引用计数和 kernel 有开销。
- block size 会影响碎片、调度与 kernel 效率。
PagedAttention 解决的是 KV 内存管理；它不自动解决模型计算、网络排队、tokenizer 或前端瓶颈。
三、模型量化
Q6: 模型量化是什么？INT8、INT4、FP8 有什么区别？
先用记法避免混淆：
- W8A8：权重和激活 8 bit。
- W4A16：权重 4 bit，激活/计算通常 16 bit。
- FP8：浮点 8 bit，常见 E4M3/E5M2，依赖硬件和 kernel。
- KV8/KV4：KV Cache 精度，和权重量化是不同维度。
选择依据：
- 模型是否 memory-bound。
- 硬件是否原生支持该 dtype。
- 是否有高效 GEMM/MoE/attention kernel。
- 量化 checkpoint 格式能否被服务引擎直接加载。
- 校准数据是否贴近部署分布。
- 质量、吞吐、TTFT、ITL 和显存是否整体改善。
vLLM 量化兼容矩阵 会持续变化，应在锁定版本后核对硬件。当前官方建议以 LLM Compressor 作为 FP8/INT8/INT4 等部署优化入口。
Q7: GPTQ、AWQ 是什么？它们有什么区别？
- GPTQ：逐层/逐块近似二阶信息，目标是降低权重量化误差；常见 W4A16。
- AWQ：利用激活统计保护重要权重通道，常见 weight-only 4 bit。
- 两者是算法/格式家族，不代表任意硬件都有同等快的 kernel。
截至 2026-10：
- vLLM 仍支持 GPTQ/AWQ 等格式。
- AutoAWQ 已被官方标为 deprecated，推荐转向 vLLM 的 LLM Compressor 工作流。
- LLM Compressor INT4 示例 使用贴近部署分布的 calibration data 和 GPTQ recipe。
面试回答不要只比较“谁精度高”。要同时说 checkpoint 生态、校准时间、Marlin/CUTLASS 等 kernel、硬件和服务引擎。
四、推理加速
Q8: FlashAttention 是什么？为什么能加速？
标准 attention 若显式物化 N×N score 矩阵，会产生大量 HBM 读写。FlashAttention 用分块与 online softmax：
- 将 Q/K/V 分块搬入片上 SRAM。
- 在块内计算并维护 softmax 归一化统计量。
- 避免把完整 attention matrix 写回 HBM。
- 保持数学等价（允许浮点舍入差异），不是稀疏近似。
收益依赖序列长度、head dimension、mask、dtype、GPU 架构和框架是否真正命中优化 kernel。训练阶段的 backward 和推理阶段的 prefill/decode 也应分别测试。
Q9: Batching 如何提升吞吐？Continuous Batching 是什么？
静态 batch 等所有序列一起结束，短请求会占着槽位。Continuous/iteration-level batching 在解码迭代边界：
- 移除完成请求。
- 从等待队列补入新请求。
- 动态决定本轮 token budget。
- 将 prefill 与 decode 以 chunked prefill 或优先级策略混排。
调度目标有冲突：
- 更大 batch 提高吞吐，却可能增加排队和 ITL。
- 长 prefill 可能阻塞 decode，恶化尾部 ITL。
- 过度偏向 decode 会让新请求 TTFT 变差。
生产需要 admission control、每租户配额、最大 token 预算、取消传播和背压；不是只调 max_num_seqs。
Q10: Speculative Decoding（投机解码）是什么？
draft 模型/辅助头先提出多个 token，target 模型一次并行验证。若接受多个草稿 token，就减少 target 串行 decode 步数。
严格的 speculative sampling：
- draft 从分布
q采样候选。 - target 计算对应位置分布
p。 - 以
min(1, p(x)/q(x))的规则逐个接受。 - 拒绝后从校正分布采样，保证目标分布不变。
把它描述成“target top-1 等于 draft token 就接受”只适用于某些贪心变体，不是通用采样算法。
变体：
- 小 draft 模型。
- self-speculation / early-exit。
- Medusa/EAGLE 类多头或树状候选。
- n-gram / prompt lookup。
是否加速取决于接受长度、draft 成本、验证 kernel、批量、网络和 target 模型；不能固定宣称 2.6×。
Q11: PagedAttention 如何在 vLLM 中工作？
服务层流程可以概括为：
request → scheduler 分配 token budget
→ block manager 映射逻辑 KV blocks
→ attention kernel 读取 block table
→ 完成/抢占时释放或重计算/交换
调优关注：
- block size 与 KV dtype。
max_model_len、并发和 GPU memory utilization。- preemption 频率和 waiting/running 队列。
- chunked prefill 与 prefix caching。
- 多模态 encoder cache、LoRA adapter 和 structured output 带来的额外状态。
不要把旧版内部类名写进长期文档；vLLM 内部实现演进很快，应引用 vLLM 当前设计文档 和固定部署版本。
五、工程实现与框架选型
Q12: 2026 年主流推理框架怎么选？
截至 2026-10：
- vLLM：通用 OpenAI-compatible serving、Paged KV、continuous batching、prefix caching、量化、spec decode 与分布式能力广。
- SGLang：RadixAttention、结构化生成、agent/program workload 与 PD disaggregation 生态活跃。
- TensorRT-LLM：NVIDIA 栈深度优化，适合愿意承担 engine/build 与硬件耦合的场景。
- llama.cpp：CPU、边缘和 GGUF 生态；适合本地、异构后端和较小部署。
- MLX：Apple Silicon 本地推理/训练。
- TGI：截至 2025-12 已由 Hugging Face 宣布 maintenance mode，新部署应优先评估 vLLM/SGLang；存量系统按风险维护。
不要写死“vLLM 0.5、TGI 2.0、TensorRT-LLM 1.8”做 2026 横评。框架迭代快，选型要固定 commit/container 后跑相同 harness。
比较维度：
- 模型架构、量化和 tokenizer/chat template 支持。
- 单机/多机 TP、PP、DP、EP。
- TTFT、ITL、吞吐、P99 和 OOM 恢复。
- prefix cache、spec decode、structured output、LoRA、multimodal。
- 指标、tracing、滚动升级、请求取消、限流。
- CUDA/ROCm/CPU/Apple 等硬件和内核成熟度。
2026 补充：Prefill–Decode Disaggregation
PD 分离把 prefill 和 decode 放到不同 worker：
- 可分别为 TTFT 和 ITL 配置并行度/硬件。
- 避免大 prefill 干扰 decode，改善尾部 ITL。
- 代价是 KV Cache 跨进程/节点传输、路由、容量预留和故障处理。
vLLM PD disaggregation 当前仍明确标为 experimental，并说明它用于独立调 TTFT/ITL，不保证提高吞吐。
SGLang PD 文档 支持 Mooncake/NIXL 等传输引擎；TensorRT-LLM 也提供 context/generation workers 与 orchestrator。
Q13: TurboQuant 是什么？如何看待研究型 KV 量化？
TurboQuant（ICLR 2026） 是在线、data-oblivious 向量量化方法：
- 先随机旋转，使坐标分布更集中。
- 用标量量化处理 MSE。
- 用 1-bit Quantized JL 残差修正内积估计偏差。
- 可用于 KV Cache 和 ANN。
论文报告的 3.5 bits/channel 质量结果属于其模型、任务和实现条件，不能直接等同于框架默认生产能力。AMD 生产化分析 也强调 kernel、精度和 serving 行为仍需工程处理。
落地前检查：
- 当前引擎/硬件是否有融合 kernel，而不是 Python 原型。
- 与 FP8/INT8 KV baseline 的质量和端到端性能。
- 长上下文、不同层、并发和 prefix cache 的兼容性。
- 量化/反量化 workspace 是否抵消容量收益。
Q14: 什么是 Prefix Caching 和 RadixAttention？
Prefix caching 复用相同 token 前缀已经计算的 KV：
- system prompt、固定文档、多轮会话和 few-shot 模板复用率高。
- 只减少重复 prefill，不能缩短长输出的 decode。
- cache key 必须包含模型、adapter、token IDs、位置/多模态内容、相关配置。
- 多租户要防碰撞与跨租户数据泄漏。
vLLM Automatic Prefix Caching 使用 KV block hash；其文档明确说明收益只在 prefill。
SGLang 的 RadixAttention 用 radix tree 组织共享前缀及 KV，便于 longest-prefix match、插入与回收。适合高度前缀复用的程序/agent workload，但缓存命中率、驱逐和租户隔离仍需监控。
关键指标：
- 可复用 token 比例，而不只是 request hit rate。
- cache lookup/eviction 开销。
- 节省的 prefill GPU 时间。
- 因 cache 占用导致的 decode 容量变化。
📝 速记卡片
- Prefill 偏算力，Decode 偏带宽；分别看 TTFT 与 ITL。
- KV Cache 优化包括分页、共享、量化、分层和 PD 分离。
- 量化先看硬件 kernel 与质量，不按 bit 数推导加速比。
- Continuous batching 提吞吐，也可能恶化排队和尾延迟。
- 严格投机采样有接受—拒绝校正，不是简单 top-1 比较。
- vLLM/SGLang/TRT-LLM 要在固定版本和真实 workload 下横评；TGI 已进入维护模式。
