讲透 KV 缓存：为什么同样的文字，缓存命中只收一折费用
前言很多人使用大模型 API 的时候会留意到一个特殊定价规则：同样的输入文本，缓存命中状态下价格仅为普通输入的 10% 左右。同时大家也会遇到现象：跟 AI 对话越久，回复速度越慢，部分平台还会提示 “对话过长，请开启新对话”。
这两类看似无关的体验，根源都来自同一个核心底层技术：KV 缓存（Key‑Value Cache，键值缓存），它相当于大模型在对话过程中实时写下的一份草稿笔记。
风险提示：本文为技术产业科普，不构成投资建议。
概念释义Token：大模型处理文本最小单元，中文大致一个字或半个词。Prefill 预填充：一次性读取全部输入提示词，计算生成 KV 缓存草稿。Decode 解码：大模型逐字生成回答的阶段，反复读取 KV 缓存。前缀缓存 Prefix Cache：多个请求拥有完全相同开头文本时，直接复用已经算好的 KV 缓存。GQA 分组查询注意力、MLA 多头潜在注意力：模型架构层面压缩 KV 缓存体积的技术。分页注意力 PagedAttention：借鉴操作系统虚拟内存，解决显存碎片化浪费。Mooncake：分布式 KV 缓存池架构，把缓存下沉到内存、SSD 存储，“用存储换计算”MADSys。
一、KV 缓存到底是什么？用便利贴通俗理解
大模型依靠自注意力机制理解上下文关系。我们可以把每一个 token 想象成一张便利贴：
[*]K（Key 键）：便利贴正面标签，标记这个 token 的语义特征；
[*]V（Value 值）：便利贴背面，保存这个 token 携带的内容信息。
当大模型要生成下一个字，就会拿着查询 Q，和墙上全部便利贴的 K 做比对，找出相关性最高的内容，综合之后输出下一个 token。
如果没有 KV 缓存，每生成一个新 token，都需要把前面全部文本重新完整计算一遍。对话越长，计算工作量会按照文本长度的平方暴涨。
KV 缓存的思路就很直接：已经算完的 K、V 便利贴直接保存到 GPU 显存，后续只需要计算新生成 token 的便利贴，历史部分直接读取复用。本质是拿显存存储空间，换取大量重复计算开销，现在几乎所有主流大模型推理都依赖这套技术。
举一个直观的算力消耗例子：以 Llama3‑70B 模型，12.8 万 token 长对话，每一个 token 对应的 KV 缓存大约 320KB，整套对话缓存整体可达 40GB。一台 8 张 80GB H100 服务器，模型参数本身占用 140GB 显存，剩余显存，仅仅只能够同时承载十多个这类长对话。很多时候服务器并发上限，不是 GPU 算力不够，而是 KV 缓存把显存占满了。
二、KV 缓存带来四个直观用户体验
[*]并发数量受显存约束：显存被缓存耗尽，新请求只能排队等待，长上下文会大幅降低单台服务器可接待用户数。
[*]对话越往后生成速度越慢：每输出一个字，都要完整读取全部历史 KV 缓存，上下文越长读取的数据量越大，解码速度逐步下降。
[*]对话到达上限被要求开新会话：显存不足以继续存放缓存，系统只能截断上下文或者强制新建对话。
[*]长对话计费成本更高：每一轮交互都要带上全部历史上下文，输入 token 数量持续膨胀，账单随之上涨。
随着 Agent 智能体普及，AI 大量读取文档、多轮工具调用，上下文持续扩张，KV 缓存的压力还会进一步放大。
三、行业六大类手段，给庞大的 KV 缓存 “减肥降本”
为了解决缓存体积庞大、显存吃紧的痛点，整个行业从模型架构、数值精度、内存管理、缓存复用、分层存储多个方向做优化。
1. 模型架构层面压缩：GQA、MLA
[*]GQA 分组查询注意力：原始 MHA 多头注意力每个查询头拥有独立一套 K/V；GQA 将多个查询头分为一组，组内共享同一套 K/V。以 Llama3‑70B 为例，64 个查询头分为 8 组，缓存体积直接压缩为原来 1/8，精度损失很小，现在绝大多数商用模型默认采用 GQA。
[*]MLA 多头潜在注意力（DeepSeek‑V2 采用）：不再完整存储原始 K/V，压缩成摘要向量，使用时再还原，官方数据 KV 缓存最高减少 93.3%，硬件同等条件下生成吞吐大幅提升，也直接带动国内大模型 API 价格下探。
2. 降低存储精度：FP8 / NVFP4 量化
KV 缓存不一定必须用 16 位高精度存储，可以降低精度保存。FP8、NVFP4 等量化格式，在损失极小模型效果前提下，把缓存占用减半。英伟达 Blackwell 系列芯片硬件原生支持 NVFP4 缓存量化，进一步释放显存空间NVIDI...。
3. 分页注意力 PagedAttention，解决显存碎片化
早期推理框架会按照最大上下文长度，一次性预留一大块连续显存。绝大多数对话用不满预设长度，大量显存白白闲置；请求不断进出，显存碎成大量小块，实测旧框架显存利用率只有 20‑40%。
vLLM 提出 PagedAttention 分页注意力，借鉴操作系统虚拟内存机制，把 KV 缓存切分成固定大小的 “内存页”，需要多少分配多少，不要求连续地址，显存浪费直接压到 4% 以内，服务器吞吐能力最高提升数十倍，如今成为开源推理框架标配。
4. 前缀缓存 Prefix Caching：这就是 “缓存命中打一折” 的来源
大量请求拥有完全一致的开头：比如客服机器人固定系统提示词、Agent 固定工具描述。只要请求从第一个 token 开始的前缀文本完全一模一样，对应的 KV 缓存就可以直接复用，不需要重新做预填充计算，大量算力被节省下来vLLM。
重要限制：必须从头开始完全匹配。哪怕前缀仅仅改动一个字符，从该位置往后全部 KV 缓存失效，无法复用。例如系统提示词里面带了实时时间戳，每次请求时间发生微小变化，就会破坏前缀，无法命中缓存。
服务商把这份节省的算力成本，转化为 API 价格折扣，也就是大家看到 “缓存命中仅一折” 的由来。不是返回缓存好的最终回答，而是复用中间 K/V 计算草稿，重新做后续解码生成，回答内容完全正常，只是省掉预填充阶段的大量计算。
5. 缓存分层存储：把缓存搬出 GPU 显存
GPU HBM 显存很贵容量有限，于是诞生分层缓存思想：
[*]L1 层：GPU 显存，存放正在活跃处理的缓存；
[*]L2 层：服务器 CPU 大内存，存放短期休眠任务缓存；
[*]L3 层：高速 SSD 分布式存储，存放长时间休眠任务缓存。
任务活跃就放在 GPU；任务暂停休眠，把 KV 缓存搬运到内存、SSD；任务恢复再搬回 GPU 继续解码。Mooncake 就是这套思路代表，核心理念：用更多存储资源，换取昂贵的 GPU 算力消耗。Kimi 基于 Mooncake 分布式缓存池，在同样 GPU 集群下，可处理请求数量提升 100% 以上，整套系统每日处理千亿级 token 规模清华大学计...。英伟达也推出硬件方案支持将 KV 缓存下沉到 SSD。
缓存搬移存在开销，如果任务只是短暂等待，来回搬运的耗时成本高于重算，并不适合全部场景。
6. 提示词工程层面人为适配缓存
普通开发者写提示词时，可以把固定不变的系统角色、工具定义放在提示词最开头，把每次变化的用户输入放在末尾，尽可能触发前缀缓存命中，直接降低 API 调用成本。反之，频繁在开头插入动态时间戳、动态变量，会破坏前缀，永远无法命中缓存。
四、现实业务带来的启发
[*]Agent 智能体时代，KV 缓存成为核心瓶颈：智能体反复读长文档、多轮工具调用，输入 token 远大于输出 token，缓存压力爆发式上涨，显存、内存、高速存储、机器之间高速传输网络，全部成为系统性能关键点。
[*]缓存命中≠直接返回旧答案：很多人误解命中缓存就是返回历史旧回复；实际只是复用历史上下文计算草稿，后续依然实时生成全新回答，不会出现答非所问。
[*]优化不只有堆 GPU：大模型服务性能，不再只看 GPU 卡数量；显存容量、内存大小、SSD 带宽、缓存调度策略，都会极大影响整体服务吞吐。
五、常见认知误区澄清
[*]误区：KV 缓存保存的是用户原始对话文本
真相：KV 缓存保存的是经过模型变换后的 K、V 向量，不是原始文字字符串。
[*]误区：缓存命中就是直接读取上一次的回答，不会重新生成
真相：复用历史上下文的计算向量，后续 token 依旧实时生成，回答是全新生成，不会直接返回旧回复。
[*]误区：只要两段内容大体相似，就可以触发前缀缓存命中
真相：必须从第一个 token 起，前缀序列完全一模一样，一个字符改动就会破坏全部后续缓存。
[*]误区：只要用上 GQA、MLA 就可以无限跑超长对话
真相：架构压缩可以降低体积，但缓存依旧会跟随上下文长度线性增长，只是同等显存可以承载更长文本。
[*]误区：分层缓存可以彻底解决所有显存不足问题
真相：缓存从 GPU 搬到内存、SSD 会带来搬移延迟，适合休眠等待任务；高频活跃任务依旧优先放在 GPU 显存。
结语
KV 缓存，就是大模型推理时写在显存里面的草稿笔记。为了避免每一轮对话全部从头重算，行业付出大量工程代价存储、管理这份笔记。
API 价格表里 “缓存命中一折” 的背后，不是什么特殊魔法，而是前缀缓存复用节省了巨大预填充算力；对话越聊越慢、长会话强制开新对话，根源也来自这份笔记越写越厚，耗尽 GPU 宝贵的显存资源。
从 GQA、MLA 模型架构压缩，到分页内存管理，再到 Mooncake 这类分布式分层缓存池，整个行业都在做一件事：用存储资源，去换昂贵 GPU 算力开销。随着 Agent 智能体大规模落地，长上下文场景越来越普遍，KV 缓存已经不再是算力的配角，成为决定大模型服务成本、并发能力的核心一环。
页:
[1]