推理优化问一个很多做了半年 LLM 应用的人都答不上来的问题为什么大模型生成第二个 token 比第一个快得多答案是 KV Cache。理解它不仅能看懂推理性能指标还能解锁生产环境最重要的优化开关之一——前缀缓存。本文用最短的篇幅讲透。原理别重复算已经算过的Transformer 生成第 n 个 token 时需要对前 n-1 个 token 计算注意力。如果每步都从头算所有历史 token 的 Key/Value 向量复杂度是平方级的。KV Cache 的思路朴素到极致算过的 Key/Value 存起来下一步直接用。无 KV Cache每生成一个 token重算全部历史的 K/V → O(n²) 有 KV Cache增量计算新 token 的 K/V追加进缓存 → O(n)这就是自回归生成的标配优化现代推理框架默认开启。显存账本为什么长上下文这么贵KV Cache 不是免费的它吃显存KV Cache 显存 2 × 层数 × KV头数 × 头维度 × 序列长度 × 精度字节数 × batch 以 7B 模型32层,GQA 8 KV头FP16 估算 4K 序列 ≈ 0.5 GB/请求 32K 序列 ≈ 4 GB/请求 三个结论直接从公式里读出来 1. **长上下文的成本大头在 KV Cache不在模型权重**。32K 输入的 KV Cache 可能比模型本身还占显存 2. **并发数 显存 ÷ (权重 单请求 KV Cache)**所以压上下文长度是最有效的扩容手段 3. **GQA分组查询注意力是显存救星**KV 头从 32 降到 8缓存直接缩到 1/4——这就是为什么新模型架构都用 GQA/MLA。 ## 生产级优化前缀缓存 KV Cache 还有一个容易被忽略的打开方式。观察两类真实请求 text 请求Asystem prompt(3K) 用户问题1 请求Bsystem prompt(3K) 用户问题2 请求Csystem prompt(3K) 用户问题3system prompt 部分完全相同——它的 KV 完全可以算一次、处处复用。这就是 Prefix Caching# vLLM 一个开关python-mvllm.entrypoints.openai.api_server\--modelQwen/Qwen2.5-14B-Instruct\--enable-prefix-caching 我们的客服场景实测system prompt3.2K token开启前缀缓存后首 token 延迟 P99 从3.8s 降到2.1sGPU prefill 计算量下降约40%。多轮对话场景历史即前缀收益更大。## 实践清单text ✅ 监控 KV Cache 利用率vLLM /metrics 的 gpu_cache_usage ✅ 业务允许就压 max-model-len别开满窗口 ✅ system prompt 固定 → 无脑开 prefix caching ✅ 多请求共享长前缀同一文档多个问题→ 前缀放最前共享最大化 ❌ 不要在 prompt 开头放时间戳等变化内容会打破前缀复用KV Cache 是理解推理性能的钥匙算力账、显存账、延迟账全绕不开它。把这套账算明白容量规划和成本优化就有了抓手。