通俗读懂 KV Cache：大模型对话越聊越慢，背后的显存消耗元凶

接好运鸭

前言

很多人使用大模型聊天会遇到一个现象：刚开始对话响应飞快，当来回多轮聊天、粘贴几万字长文档之后，AI 输出速度明显变慢，显存占用疯狂上涨，甚至直接报显存 OOM（显存耗尽）崩溃。造成该现象的核心幕后技术就是 KV Cache（键‑值缓存），它是现在所有 Transformer 大模型推理必不可少的工程优化手段，同时也是长上下文场景下显存占用最大的一块开销。

提示：本文为 AI 技术科普，面向开发者与技术爱好者，不构成产品选型建议。

很多初学者会把 KV Cache 当成模型权重参数，其实二者完全不一样：模型权重是训练完成之后固定不变的 70B/13B 那套参数；KV Cache 是每一轮对话动态生成、保存在显存中的临时中间计算结果，每一次对话都会生成专属的一份缓存数据，会话结束才会释放显存空间。

一、没有 KV Cache，大模型推理会发生什么

大模型是自回归逐 token 生成，输出一个字，再用包含这个字的完整上下文预测下一个字。
如果不做任何缓存优化：每新生成一个 token，就要把全部历史输入 + 已经输出过的所有 token 完整重新跑一遍前向计算。

• 对话越变长，token 总量越大；
• 注意力计算量是平方级增长（O (N²)）；
• 聊的轮次越多，算力开销爆炸式上涨，速度会惨不忍睹。
  

举个简单例子：你上传一份 5 万 token 的文档，每多输出一个字，就要把 5 万多 token 全部重新算一遍，算力完全被重复计算吃掉，几乎不可用。
KV Cache 就是用来解决这个重复计算问题的工程方案：已经算过的历史 token 的 Key、Value 向量，算完就存在显存，后面每一步直接复用，不再重复计算历史部分，只对最新生成的 token 做新的运算，把每一步的计算开销大幅降下来。

通俗类比：写长篇报告，每新增一小段文字，不需要把整篇几万字全部重写一遍；只新增新写的片段，前面已经写好的直接拿来复用。KV Cache 就相当于把前面已经算好的 “草稿” 保存在显存。

二、KV Cache 完整工作流程

• Prompt 预处理阶段（Prefill 预填充）把用户提问、历史全部上下文一次性输入模型，对全部 token 做一次完整前向计算，算出每一层 Transformer 对应的 Key（键）、Value（值）向量，存入显存，这就是 KV Cache 的初始内容。这一步就是大家常说的Prefill 填充阶段。输入越长，这一步耗时越高。
• 解码生成阶段（Decode）模型输出第一个 token。此时不再重新计算全部历史上下文，直接读取显存里面已经存好的历史 K/V 缓存，只计算刚刚新出来这一个 token 的 Q/K/V；新生成 token 的 K、V 追加写入 KV 缓存。
• 循环往复：每输出一个新 token，就把它的 K、V 追加进缓存，读取旧缓存做注意力运算，持续输出，直到遇到停止符结束回答。
  

关键点：对话每多一轮，缓存就继续变大；上下文越长，KV Cache 占用显存就越大。缓存只存活于本次会话，关闭对话窗口，缓存才会释放显存。

三、为什么长对话、多会话会把显存吃满

KV Cache 显存占用，和上下文 token 长度几乎成正比。

• 单轮简短问答：缓存体积很小，显存压力不大；
• 上传长文档、几十轮持续聊天：缓存会持续膨胀，吃掉大量显存；
• 服务端同时接待大量用户会话，每一路对话都要保存独立 KV Cache，并发上来，显存会被迅速打满。
  

这也是为什么推理服务最头疼的不是 Prefill 填充，而是大量长会话并发；很多推理引擎性能瓶颈，往往卡在 KV Cache 显存，而不是模型权重本身。

四、主流的 KV Cache 优化技术

既然 KV Cache 是显存大户，行业诞生大量优化手段，也是现在推理引擎的核心能力：

• PagedAttention（分页 KV 缓存）把 KV Cache 切成分页块，不再需要连续一大块显存，显存碎片化大幅降低，大幅提升服务器可承载并发，vLLM 推理引擎核心就是这套技术。
• 前缀缓存 Prefix‑Caching不同用户共享完全一致系统提示词（system prompt），这部分公共的 KV 缓存只计算一次，多个会话直接复用，适合大量 Agent、客服场景。
• KV 缓存压缩FP8、INT4 量化 KV 缓存，降低每一个 K/V 向量字节大小，用轻微精度损失换取显存空间，长上下文场景效果明显。
• 滑动窗口、淘汰旧缓存超过上下文窗口之后，丢弃最早期部分 KV 缓存，保留近期上下文，避免缓存无限膨胀（会丢失早期记忆）。
• MLA/MQA/GQA多查询注意力、分组查询注意力，从模型架构层面直接降低 KV 缓存体积，现在 Llama‑3、DeepSeek 系列普遍采用。
  

五、容易混淆概念对比

项目	模型权重 (Weight)	KV Cache
是否固定	训练结束永久固定，不会随对话改变	每一次对话动态生成，临时中间结果
存储位置	显存 / 磁盘，全局共用	显存，每一个会话独立一份
会不会随聊天变大	不会	上下文越长，体积越大
会话结束	依旧保留	立刻释放显存

六、大众与开发者常见认知误区澄清

误区 1：70B 模型权重多大，运行的时候显存就只用多大。纠正：除模型权重显存，还要额外留出 KV Cache 的显存开销，长上下文并发场景，缓存显存开销甚至可以超过模型权重本身。
误区 2：KV Cache 属于大模型神经网络的一部分，是训练出来的参数。纠正：它属于推理阶段动态生成的临时计算缓存，模型训练阶段不存在 KV Cache。
误区 3：有了 KV Cache 就不怕无限长上下文。纠正：KV Cache 只是避免重复计算，依然受模型上下文窗口上限约束，token 超过窗口，依旧需要截断。
误区 4：关闭网页对话，KV Cache 还会继续占用服务器显存。纠正：正常实现会话销毁，KV Cache 就释放；如果服务端存在会话内存泄漏，会持续占显存。
误区 5：Prefill 和 Decode 速度慢，是模型权重太大导致。纠正：Prefill 慢来自输入 prompt 长；Decode 生成慢很多时候瓶颈来自 KV Cache 读写带宽，而不是单纯的计算。
结语

KV Cache 不是大模型本身的能力，而是一项极其关键的推理工程优化，解决自回归生成中大量重复计算的痛点，让长对话、长文档分析变得现实可用。
但它是一把双刃剑：换来速度的代价就是显存消耗。对话轮次越多、文档越长，缓存膨胀越严重。
现在主流推理引擎 vLLM、TensorRT‑LLM 都围绕 KV 缓存做大量优化：分页、量化、前缀复用等，本质目标就是在有限显存之下，承载更多长上下文会话。理解 KV Cache，就能看懂大模型为什么短回答飞快，而长文档分析、多轮聊天会越跑越慢，甚至显存溢出崩溃。