# 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：

```text
输入长度分布 + 输出长度分布 + 到达过程 + 并发
+ 模型/精度 + GPU/互连 + SLO + 质量门槛
```

### Q2: 什么是自回归生成？Prefill 和 Decode 有什么区别？

自回归分解：

```text
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 的粗略元素数：

```text
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 量化兼容矩阵](https://docs.vllm.ai/en/latest/features/quantization/) 会持续变化，应在锁定版本后核对硬件。当前官方建议以 LLM Compressor 作为 FP8/INT8/INT4 等部署优化入口。

### Q7: GPTQ、AWQ 是什么？它们有什么区别？

- GPTQ：逐层/逐块近似二阶信息，目标是降低权重量化误差；常见 W4A16。
- AWQ：利用激活统计保护重要权重通道，常见 weight-only 4 bit。
- 两者是算法/格式家族，不代表任意硬件都有同等快的 kernel。

截至 2026-10：

- vLLM 仍支持 GPTQ/AWQ 等格式。
- [AutoAWQ 已被官方标为 deprecated](https://docs.vllm.ai/en/stable/quantization/auto_awq.html)，推荐转向 vLLM 的 LLM Compressor 工作流。
- [LLM Compressor INT4 示例](https://docs.vllm.ai/projects/llm-compressor/en/stable/examples/quantization_w4a16/) 使用贴近部署分布的 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：

1. draft 从分布 `q` 采样候选。
2. target 计算对应位置分布 `p`。
3. 以 `min(1, p(x)/q(x))` 的规则逐个接受。
4. 拒绝后从校正分布采样，保证目标分布不变。

把它描述成“target top-1 等于 draft token 就接受”只适用于某些贪心变体，不是通用采样算法。

变体：

- 小 draft 模型。
- self-speculation / early-exit。
- Medusa/EAGLE 类多头或树状候选。
- n-gram / prompt lookup。

是否加速取决于接受长度、draft 成本、验证 kernel、批量、网络和 target 模型；不能固定宣称 2.6×。

### Q11: PagedAttention 如何在 vLLM 中工作？

服务层流程可以概括为：

```text
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 当前设计文档](https://docs.vllm.ai/en/stable/design/prefix_caching/) 和固定部署版本。

## 五、工程实现与框架选型

### 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](https://github.com/huggingface/text-generation-inference)，新部署应优先评估 vLLM/SGLang；存量系统按风险维护。

不要写死“vLLM 0.5、TGI 2.0、TensorRT-LLM 1.8”做 2026 横评。框架迭代快，选型要固定 commit/container 后跑相同 harness。

比较维度：

1. 模型架构、量化和 tokenizer/chat template 支持。
2. 单机/多机 TP、PP、DP、EP。
3. TTFT、ITL、吞吐、P99 和 OOM 恢复。
4. prefix cache、spec decode、structured output、LoRA、multimodal。
5. 指标、tracing、滚动升级、请求取消、限流。
6. CUDA/ROCm/CPU/Apple 等硬件和内核成熟度。

### 2026 补充：Prefill–Decode Disaggregation

PD 分离把 prefill 和 decode 放到不同 worker：

- 可分别为 TTFT 和 ITL 配置并行度/硬件。
- 避免大 prefill 干扰 decode，改善尾部 ITL。
- 代价是 KV Cache 跨进程/节点传输、路由、容量预留和故障处理。

[vLLM PD disaggregation](https://docs.vllm.ai/en/stable/features/disagg_prefill/) 当前仍明确标为 experimental，并说明它用于独立调 TTFT/ITL，**不保证提高吞吐**。

[SGLang PD 文档](https://docs.sglang.io/docs/advanced_features/pd_disaggregation) 支持 Mooncake/NIXL 等传输引擎；[TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/latest/features/disagg-serving.html) 也提供 context/generation workers 与 orchestrator。

### Q13: TurboQuant 是什么？如何看待研究型 KV 量化？

[TurboQuant（ICLR 2026）](https://proceedings.iclr.cc/paper_files/paper/2026/file/5c802ef38ab6e366c2ea06eee554c088-Paper-Conference.pdf) 是在线、data-oblivious 向量量化方法：

- 先随机旋转，使坐标分布更集中。
- 用标量量化处理 MSE。
- 用 1-bit Quantized JL 残差修正内积估计偏差。
- 可用于 KV Cache 和 ANN。

论文报告的 3.5 bits/channel 质量结果属于其模型、任务和实现条件，不能直接等同于框架默认生产能力。[AMD 生产化分析](https://rocm.blogs.amd.com/artificial-intelligence/turboquant-vllm-agentic/README.html) 也强调 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](https://docs.vllm.ai/en/latest/features/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 已进入维护模式。

## 主要来源（参考）

- [vLLM Automatic Prefix Caching](https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/)
- [vLLM Disaggregated Prefilling](https://docs.vllm.ai/en/stable/features/disagg_prefill/)
- [vLLM 量化支持矩阵](https://docs.vllm.ai/en/latest/features/quantization/)
- [vLLM LLM Compressor FP8](https://docs.vllm.ai/en/latest/features/quantization/llm_compressor/fp8/)
- [SGLang PD Disaggregation](https://docs.sglang.io/docs/advanced_features/pd_disaggregation)
- [TensorRT-LLM Disaggregated Serving](https://nvidia.github.io/TensorRT-LLM/latest/features/disagg-serving.html)
- [Hugging Face TGI Maintenance Mode](https://github.com/huggingface/text-generation-inference)
- [TurboQuant（ICLR 2026）](https://proceedings.iclr.cc/paper_files/paper/2026/file/5c802ef38ab6e366c2ea06eee554c088-Paper-Conference.pdf)

时效说明：框架能力与硬件矩阵截至 2026-10。吞吐、延迟和压缩收益都依赖模型、硬件、输入/输出长度、并发与质量门槛；本文不提供无条件性能承诺。

AI面试八股文-09_8-LLM 推理优化面试题

- Prefill / Decode 与 KV Cache
- 权重、激活和 KV 量化
- Attention、批处理与投机解码
- 2026 推理框架、PD 分离与前缀复用

编程语言

LLM推理优化核心围绕KVCache、量化与解码加速展开：Prefill偏算力，Decode偏带宽，需分别监控TTFT与ITL。优化策略包括PagedAttention按需分配显存、KV低精度存储、Continuous Batching提升吞吐、投机解码减少串行步数。框架选型需固定版本实测，vLLM与SGLang生态活跃，TGI已维护模式。量化收益依赖硬件kernel与质量门槛，不按bit数直接推导加速比。

内存管理

代码解释

数据泄漏

路由

Python

Kernel

Agent

LoRa

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

LLM推理优化核心围绕KVCache、量化与解码加速展开：Prefill偏算力，Decode偏带宽，需分别监控TTFT与ITL。优化策略包括PagedAttention按需分配显存、KV低精度存储、Continuous Batching提升吞吐、投机解码减少串行步数。框架选型需固定版本实测，vLLM与SGLang生态活...

AI面试八股文-09_8-LLM 推理优化面试题-腾讯云开发者社区-腾讯云

AI面试八股文-09_8-LLM 推理优化面试题

AI面试八股文-09_8-LLM 推理优化面试题

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐