KV Cache 讲透：为啥大模型“第一个字慢得要命”，后面却像开了机关枪？
你肯定见过这个场景：
你把一段 prompt 发给 ChatGPT/Claude
光标闪啊闪，半天才吐出第一个字
然后就开始连续输出，像开闸放水一样
这不是玄学。
背后就是 KV Caching（KV 缓存）。
这篇文章咱们不绕弯子，按你真正会遇到的推理链路，把它讲清楚：
LLM 是怎么“一个 token 一个 token”吐字的
Attention 里到底在算啥
计算浪费发生在哪里
KV Cache 怎么把浪费砍掉
为啥第一个字最慢（prefill）
为啥 KV Cache 会把显存吃爆（以及工程上怎么救）
1）LLM 吐 token 的方式：每次只关心“最后一个位置”
Transformer 做推理时，会把输入序列里 每个 token 都过一遍网络。
得到一堆 hidden state：
token1 → h1
token2 → h2
...
tokenN → hN
关键点来了：
真正用来预测“下一个 token”的，是 最后一个 token 的 hidden state（hN）。
前面的 h1…h(N-1) 并不是没用。
它们更像“为最后一步服务的中间产物”。模型需要它们来做上下文建模，但在“生成下一个 token”这件事上，只有最后一个位置负责出结果。
你可以把它想成：
你问模型一句话
模型要把整段上下文都读懂
真正开口回答时，只从最后这个位置往外续写
2）Attention 到底在算什么：Q、K、V 是怎么用的
每一层 attention 里，每个 token 都会变成三样东西：
Q（Query）：我现在要查什么
K（Key）：我这里有什么线索
V（Value）：线索对应的内容
当模型要算“最后一个 token”的输出，它会做这件事：
拿 最后一个 token 的 Q
去和 所有 token 的 K 做匹配（相似度）
用匹配权重去加权汇总 所有 token 的 V
一句话：
生成下一个 token 时，最后一个位置会“回头看”整个上下文。
这就是为啥大模型能记得你前面说的梗、你的约束条件、你的上下文细节。
3）真正的浪费：每生成一个 token，都在“从头复读”
现在看浪费点。
假设你已经生成到第 50 个 token。
你要生成第 51 个 token 时，attention 需要什么？
token1～token50 的 K、V
token51（当前最后一个位置）的 Q
问题是：
生成第 50 个 token 时，token1～token49 的 K、V 已经算过了
到生成第 51 个 token，token1～token49 的 K、V 根本没变
如果你每一步都把整段序列重新过一遍 Transformer，那就是：
反复重算老 token 的 K、V
序列越长，重复越离谱
复杂度直观感受：
不缓存：越写越慢，计算量接近 O(n²) 的增长（长对话直接炸）
有缓存：每步只做增量，增长更像 线性
你平时觉得“越聊越卡”，很多时候就是这里在作妖。
4）KV Cache 怎么干活：把算过的 K/V 存起来，后面直接用
KV Cache 的做法很粗暴，也很有效：
第一次把 prompt 全部跑一遍
把每层每个 token 的 K、V 都存起来
后续每生成一个新 token：
只算这个新 token 的 Q/K/V
把新 token 的 K/V 追加到缓存
用新 token 的 Q 去对“完整缓存”做 attention
你可以把 KV Cache 理解成：
以前每次写字都要把前面全文重新抄一遍；现在把全文复印件放旁边，写新句子只补最后一行。
这就是为什么主流推理框架离不开 KV Cache：
vLLM
TGI
TensorRT-LLM
没 KV Cache 的推理，基本没法看。
5）为啥第一个字最慢：prefill 才是最吃算力的那一下 😵💫
你发 prompt 的那一刻，模型干的是一件“大工程”。
它要把整段输入一次性处理完：
全部 token 过网络
全层的 K/V 计算出来
KV Cache 建好
这段叫：Prefill（预填充）。
Prefill 的特点：
token 很多
并行计算量巨大
GPU 负载高
等 prefill 做完，模型进入另一段：Decode（逐 token 解码）。
Decode 的特点：
一次只生成 1 个 token（自回归）
每步只算“新 token”的那点东西
KV Cache 让历史部分不用重算
所以你看到的现象就很自然了：
第一个 token 慢：prefill 在干重活
后面快：decode 在吃缓存红利
如果你在做产品体验优化，建议把指标拆开看：
TTFT（Time To First Token，首 token 延迟）
TPS（Tokens Per Second，持续输出速度）
很多团队只盯 TPS，然后用户还在骂“怎么老半天不出字”，就是没把 TTFT 当回事。
6）代价：KV Cache 吃显存，吃到你怀疑人生
KV Cache 省的是计算，花的是显存。
而且是每个请求一份。
模型越大、层数越多、上下文越长、并发越高，KV Cache 越夸张。
你可以记住这条朴素规律：
长上下文 + 高并发
最先顶不住的往往不是算力
是显存（KV Cache 把卡塞满了）
有些大模型（比如 70B 级别）在长对话场景下，单请求的 KV Cache 就能吃掉好几 GB 显存。
并发一上来，KV Cache 甚至可能比模型权重还占地方。
这也是为啥工程界搞了很多“省 KV”方案：
MQA/GQA：让多个 query head 共享更少的 K/V head，减少缓存体积
Paged Attention：把 KV Cache 当成分页内存来管理，减少碎片，提升并发下的显存利用率
你照着做：推理优化时怎么用 KV Cache 思路排查问题
把下面这张“排查清单”贴到工位上都行。
✅ 你想让“首字更快”
盯 prefill：
prompt 砍短一点（少废话、少长系统提示）
控制输入上下文长度（别无限拼历史）
用更快的推理引擎/更激进的 kernel 优化
✅ 你想让“持续输出更快”
盯 decode：
确认 KV Cache 真在用（很多自研代码一不小心就没 cache）
batch/并发策略要合理（别让 GPU 空转）
✅ 你想让“并发更高不爆显存”
盯 KV Cache 占用：
上 GQA/MQA 的模型版本
用支持 Paged Attention 的框架（典型是 vLLM 思路）
限制每个会话的最大上下文长度（这是最直接也最有效的开关）
常见坑：很多人优化半天，其实输在这几件事上
以为慢是网络问题：其实是 TTFT（prefill）太慢
只看平均延迟：用户感知更在意“多久看到第一个字”
无限堆上下文：历史越长，prefill 越重，KV 越大，并发越差
没把 KV Cache 当成本：显存预算不做，线上迟早炸
一句话收尾
你看到的“第一个字慢、后面飞快”，不是模型在装。
是 prefill 在狠狠干活，KV Cache 建好后，decode 才开始享受增量计算的爽感。
真要把推理体验做好，别只盯模型有多大。盯住 TTFT、TPS、KV Cache 显存 这三件事，才是真正能让你少加班的东西。