共计 2880 个字符，预计需要花费 8 分钟才能阅读完成。
写在前面：推理优化为何成为“兵家必争之地”
2025年下半年，我参与了一个内部大模型服务的性能调优项目。当时团队遇到一个典型困境：训练好的70B模型，在8张A100上跑推理，每秒只能处理不到30个tokens——比用户期望的“秒级回复”差了一个数量级。我们翻遍了论文、改写了三版调度逻辑，最终让吞吐提升了5倍。这个过程中，我深刻意识到：大模型的“智能”往往取决于训练，而它的“可用性”则完全取决于推理优化。今天，就来拆解三个最核心的推理技术，它们也是当前AI基础设施中最容易被忽视却又决定生死的关键概念。
KV Cache：用空间换时间的经典博弈
Transformer的自回归生成过程（每次预测下一个token，并将新token拼到序列中再次输入），天然带来巨大的计算浪费。每次生成时，模型都需要重新计算之前所有token的Key和Value矩阵——即使这些矩阵在每次计算中完全一样。KV Cache的思路简单粗暴：将每一层注意力计算中已经算好的K、V矩阵缓存下来，后续生成只需要计算当前新token的K、V，然后与缓存中的历史K、V拼接。
举个例子：生成第100个token时，如果使用KV Cache，只有1次全链路计算，其余99个token的K、V直接从内存读取，计算量降低约一个数量级。但这带来了新的挑战——显存爆炸。一个70B模型，每层隐藏维度8192，头数64，序列长度8192时，仅KV Cache就需要约：
70B模型约80层，每层2个矩阵（K和V），每个float16占2字节，8192*8192*2*80*2 ≈ 21GB。如果并发处理8个请求，瞬间吃掉168GB显存。更恐怖的是，当序列长度变成128K（许多国产大模型标配），显存需求直接翻16倍——这几乎宣判了“长序列推理必须用巧招”。
量化与共享：KV Cache的生存法则
业界目前主流方案是INT8或INT4量化缓存，将精度从FP16降到INT4，压缩4倍的同时保持1%以内的精度损失。但更值得关注的是跨请求KV Cache共享技术：对于同一个Prompt（比如系统指令、历史对话），不同用户的请求可以复用同一份KV Cache。我见过一个实际案例，某个客服知识库系统，将固定系统提示（约2000 tokens）的KV Cache预热在显存中，每次用户请求时只需计算新输入的几十个tokens，响应时间从2秒降到200毫秒。这个思路后来被vLLM的“前缀缓存”机制实现，现在几乎成为所有推理框架的标配。
投机解码：让“学渣”帮“学霸”猜题
如果你的模型每次推理都需要完整的Transformer前向传播，那么吞吐的上限就被锁死在计算带宽上。投机解码（Speculative Decoding）从根本上改变了这个范式：用一个小模型（Draft Model）快速生成多个候选token，再用大模型（Target Model）一次性验证这些候选的正确性。如果小模型猜对了，一次前向传播就能输出多个token，吞吐倍数大幅提升。
关键点在于：小模型与大模型的“默契程度”决定了提速效果。我见过一个错误案例：团队用一个130M的小模型给7B大模型做投机，但由于小模型词汇表分布差异过大，猜对率只有15%，平均每次验证只能接受1.2个token，反而因为小模型的计算开销导致总延迟增加。正确的做法是：使用与目标模型同源的小模型（比如同一训练流程中剪枝或知识蒸馏得到的），或者直接用目标模型的浅层部分作为草稿模型。谷歌在2024年提出的Medusa方法则更进一步：在目标模型最后一层后添加若干“多头预测器”，每个头预测未来一个位置的token，一次生成多个候选，本质上也是一种投机解码的变体。
实际落地中的取舍
投机解码在2025年的主流推理引擎（如TGI、vLLM、TensorRT-LLM）中都已原生支持，但有一个反直觉的结论：在小batch场景下，投机解码反而可能降低性能。因为小batch时显存带宽不是瓶颈，计算单元本身就接近满负荷，多一次小模型前向会加剧竞争。我一般建议：只有batch size ≥ 8或者序列长度 > 4096时，才开启投机解码。另外，投机解码在面对“非确定性任务”（如开放性生成、创作类）时效果明显不如“确定性任务”（如翻译、代码补全），因为小模型更难猜中创造性的输出。
PagedAttention：把显存管理做成操作系统
前面提到KV Cache会吃光显存，而PagedAttention的灵感直接来自操作系统的虚拟内存分页机制。传统推理框架中，KV Cache是连续分配的，比如请求A生成1000个tokens，就给A预分配1000个token的显存空间。但问题在于：一个请求的最终长度无法预知（直到生成终止符），预分配太多造成浪费，预分配太少则需要在运行时动态扩张（极其缓慢）。
PagedAttention将KV Cache按“块”（Block）划分，每个块通常包含16或32个token的K、V矩阵。生成过程中，每当当前块被填满，就动态分配一个新的块（逻辑上不连续，但物理地址通过页表映射）。这种做法有三个直接好处：
- 内存零碎片：不同请求可以共享块，比如两个请求的前缀相同，只需存储一份公共块。
- 动态扩容零成本：无需提前分配空间，按需增长。
- 支持“Copy-on-Write”：对于beam search等多候选解码，每个候选的前几个token路径唯一，只有分叉时才复制新块，极大节约显存。
vLLM（一作论文发表于2024年OSDI）是PagedAttention的集大成者。我曾在一次测试中比较传统推理框架（如Hugging Face Transformer + PyTorch）与vLLM：在相同显存限制下，vLLM能容纳的并发请求数提升了3-5倍。而2025年出现的PagedAttention v2进一步优化了块分配粒度——根据序列长度动态调整块大小（从8到64个token），在短序列场景下减少额外开销，在长序列场景下降低页表查询损耗。
行业观察：优化工具链正在“内卷”
2026年初，各大云厂商纷纷推出了“推理优化即服务”的产品，比如AWS的Inf2实例内置了KV Cache压缩硬件加速器，Google Cloud的TPU v6增加了专门的投机解码协处理器。但在我看来，真正拉开差距的并不是单一技术，而是组合策略的自动调优。例如，对于短对话场景（平均10轮左右），优先使用KV Cache INT4量化 + PagedAttention的2KB小块策略；对于长文档分析（10万tokens以上），开启投机解码 + 前缀缓存 + 动态块大小。一个成熟的推理系统，应该能自动感知请求模式并切换最优配置。
作为从业者，我建议不要盲目追新。我见过一个团队花费三个月移植了最新的“多令牌预测”论文（并行生成多tokens），但实际测试中因为与公司自研解码器不兼容，最终吞吐下降。推理优化最忌讳“空中楼阁”——先理解你的请求分布（长度、延迟要求、并发量），再选择合适的缓存策略和加速方案。毕竟，AI基础设施的终极目标，不是跑分好看，而是让用户感觉不到“等待”的存在。
