本文深入解析大模型缓存技术，从KV Cache原理到Prefix Caching的跨请求复用，再到当前主流的PagedAttention、Automatic Prefix Caching等缓存技术方向，以及最先进模型的落地实践。文章揭示了为何大模型缓存命中率通常高达90%，并解释了高命中率背后的工作负载特点。同时，文章还提醒高命中率并不一定等于省钱或高效，需注意缓存使用的契约。对于想要了解大模型推理优化技术的小白或程序员来说，本文提供了宝贵的知识和实践指导。
缘起：一个 90% 的观察
如果看过自己团队的大模型 token 消耗看板，我们多半会注意到一个现象：主力模型的缓存命中率常年挂在 90% 上下，而且越是高频使用、跑得越久的模型，命中率越稳。
这不是某一家的「黑科技」，实际上，这是一整套已经成为行业标配的推理优化技术，叠加上「agent 式调用」这种使用模式后的必然结果。
这篇文章想把这件事梳理清楚：
缓存到底缓存了什么（KV Cache 原理）；
当前有哪些缓存技术方向；
最先进的几个模型是怎么落地的；
为什么命中率会这么高——以及它高，到底意味着什么。
本文全程尽量用类比和图片说话，不陷进矩阵和算子的细节里。
01
第一性原理：模型为什么需要缓存
大模型是「一个字一个字往外蹦」的
当前主流大模型都是自回归（autoregressive）生成：每次只预测下一个 token，把它接到已有文本后面，再预测再下一个。问题在于，Transformer 的注意力机制要求——预测每一个新 token，都要「回看」前面所有 token。
如果什么都不缓存，那就是一场灾难：生成第 100 个字时，要把前 99 个字重新计算一遍注意力；生成第 1000 个字时，把前 999 个字再算一遍……计算量随长度平方级膨胀。
KV Cache：把「回看」的中间结果存下来
注意力机制里，每个 token 都会被换算成三样东西：Query（查询）、Key（键）、Value（值）。预测新 token 时，用新 token 的 Query 去和所有历史 token 的 Key/Value 做运算。
关键洞察是：历史 token 的 Key/Value 一旦算出来就不再变了。那为什么每步都重算？把它们缓存下来，下一步直接读，新 token 只需要算自己那一份，就是 KV Cache（键值缓存）。它把每步的计算从"重算整段历史"降到"只算新增的一个"，是所有大模型推理的地基 [2][3]。
但 KV Cache 有个「先天局限」：它默认只在一次请求内部有效。请求一结束，这块缓存通常就被丢弃了。下一个请求哪怕开头一模一样，也得从头再算。真正决定"命中率"高低的，是能不能把缓存跨请求复用，这就引出了下一层。
02
从 KV Cache 到 Prefix Caching：
跨请求复用
核心思想：相同的前缀，只算一次
观察真实流量我们会发现：海量请求的开头是高度重复的。同一个 AI 助手，每个请求都带着同一份几千 token 的系统提示词（system prompt）；同一段多轮对话，第 5 轮请求的开头就是第 4 轮的全部内容。
Prefix Caching（前缀缓存） 就是把这部分"公共前缀"的 KV Cache 留下来、跨请求复用：新请求进来，先看它的前缀是不是已经被算过、缓存过；命中了就直接读，跳过最昂贵的"预填充（prefill）"环节 [1][6]。
为什么必须「逐字完全一致」？
这是 prefix caching 最反直觉、也最关键的一条规则：前缀从第一处不一致开始、往后就无法复用——分歧点之前的完整块仍然命中，之后的缓存才失效。
原因在于现代模型用的位置编码（如 RoPE 旋转位置编码）：每个 token 的 Key/Value 不仅取决于"它是什么词"，还取决于"它排在第几位"。而且在多层注意力下，某个 token 的 K/V 还依赖它前面的整段上下文——前面一改，后面每个 token 的 K/V 都跟着变。所以你在前缀中间插一句话、改一个时间戳，后面的缓存就集体失效。
这条规则有两个直接推论，记住它们，后面解释"为什么命中率高/低"全靠它：
- 稳定的内容要放在最前面（系统提示、工具定义），易变的内容（用户每次不同的问题、时间戳）放最后；
- 只能追加（append），不能插改。在已缓存内容后面接新内容，前缀不变、缓存照命中；一旦改动前面的内容，缓存全废。
03
当前缓存技术有哪些方向
围绕「如何更好地缓存与复用」，工业界和学术界大致形成了四个层层递进的方向。
方向一/二：让缓存「装得下、不浪费」——PagedAttention
KV Cache 很吃显存：一条长序列就能占用数 GB（论文实测 OPT-13B 上单序列约 1.6GB）。早期系统因为要给每条序列预留连续显存，碎片化和冗余拷贝白白浪费了 60%–80% 的显存 [3]。
vLLM 的 PagedAttention 借鉴了操作系统管理内存的经典思路：把 KV Cache 切成固定大小的「页（block）」，像虚拟内存分页一样按需分配、灵活共享，把浪费压到 4% 以下，吞吐量提升 2–4 倍（SOSP 2023）[3]。这一步看似只是「省显存」，也大大降低了跨请求共享 KV 的工程成本——把 KV 拆成可独立管理的小块后，多个请求才好「共享其中几块」（但前缀缓存本身并不必然依赖 PagedAttention）。
方向三：跨请求复用的两条数据结构路线
怎么快速判断「这段前缀以前算过没有」？两大开源引擎给出了不同答案：
- vLLM 的 Automatic Prefix Caching（APC）：把前缀切成定长 block，每个 block 的哈希由「父块哈希 + 本块内容」链式生成——这条哈希链天然表达了「完整前缀」。所有块丢进一张哈希表，不维护树结构，块独立分配/释放，用 LRU 淘汰最久未用的。命中要求逐块精确匹配（只缓存写满的整块）[15]。
- SGLang 的 RadixAttention：用基数树（前缀树）显式建模请求间的前缀共享关系：树以 token 序列为路径，共享前缀的请求自然落在同一条分支上；用「递归淘汰叶子节点」的 LRU 管理，再配合「缓存感知调度」主动提高命中率。论文报告相比当时 SOTA 吞吐最高提升 6.4 倍 [4][5]。
两条路线殊途同归：让相同前缀的 KV 只算一次、被很多请求复用。
方向四：突破「必须是前缀、必须逐字一致」的限制
前面说过，标准 prefix caching 有两个硬约束：必须是前缀、必须逐字一致。这对 RAG（检索增强）这类场景很不友好——检索到的文档每次都不同、又往往夹在中间而非开头。学术界正在攻这个方向：
- Prompt Cache（MLSys 2024）：让开发者用一套标记语言（PML）把系统提示、模板、常用文档声明成可复用模块，服务端预先算好它们的注意力状态，无论这个模块出现在 prompt 的哪个位置都能复用，做到一定程度的「位置无关」。首 token 延迟最高加速 8×（GPU）/ 60×（CPU）[7]。
- CacheBlend（EuroSys 2025 最佳论文）：允许把非前缀位置的文档块缓存直接拼接，只对一小部分 token 做「选择性重算」来修正跨块的注意力，TTFT 加速2.2–3.3×、吞吐提升2.8–5×，且不掉生成质量 [8]。
- EPIC（ICML 2025）：系统性地提出「位置无关缓存（Position-Independent Caching）」，把非前缀复用的主要障碍归因于 attention sink（每个片段的首 token 过度吸走注意力），并据此做针对性修正 [6]。
这些还多在前沿研究/特定引擎阶段，但代表了缓存技术「从前缀走向任意片段」的演进方向。
04
最先进的模型是怎么落地的
把上面的原理对照到几家最先进的商用模型，会发现它们的产品形态高度趋同：自动前缀缓存 + 命中大幅降价 + 短时 TTL。差异主要在「自动还是手动」「折扣多少」「缓存放哪里」。
| 维度 | 模型A | 模型B | 模型C | 模型D |
| 开启方式 | 手动打断点cache_control（也可自动）[1] | 全自动，无需改代码 [9] | 隐式(自动) + 显式(手动建CachedContent) [11] | 全自动前缀缓存 [13] |
| 命中折扣 | 命中约 0.1× 原价 [10] | 初版约 5 折；新文档口径"成本最高省 90%"，以定价页为准 [9]（注） | 隐式命中约 75% 折扣（按原价 25% 计）[12]（注） | 命中价约为未命中的 1/10（官方页 $0.014 vs $0.14 /百万 token）[13] |
| 写入成本 | 5 分钟档 1.25×、1 小时档 2× [10] | — | 显式缓存另收"按时长"的存储费 [11] | 存储免费 [13] |
| 缓存寿命(TTL) | 默认 5 分钟，每次命中自动续期且不额外收费；可选 1 小时 [1] | 不活跃 5–10 分钟清除、最长 1 小时；部分模型支持延长至 24 小时 [9] | 默认 1 小时，可自定义 [11] | 数小时至数天后自动清除 [13] |
| 最小可缓存 | 约 1024–4096 token，随模型版本不同 [1] | 1024 token 起，按 128 增量 [9] | 隐式 1024–2048、显式 2048–4096，随版本不同 [11][12] | 最小缓存单位 64 token [13] |
| 缓存放哪 | 厂商侧 | 厂商侧 | 厂商侧 | 分布式硬盘阵列（靠 MLA 架构压缩 KV 体积才放得下）[13] |
注：折扣口径各家随模型版本变动较大——有的早期公告写“输入 5 折”，新文档改成“最高省 90%”的整体表述；有的隐式缓存官方明确 75% 折扣（网传“九折优惠/付一折”是更早 1.5 系列的说法）。引用具体折扣请以具体的当前定价页为准，本表只标可核实到的官方数字。
几个值得注意的落地细节：
- 官方收益数字（下列为各家早期公告数据，当前定价与文档页多已调整，仅作量级参考）：模型 A 在首发公告中称提示缓存可「降低成本最高 90%、降低延迟最高 85%」，并给了一个例子：缓存一本 10 万 token 的书后，响应延迟从 11.5 秒降到 2.4 秒 [10][14]。模型 D 则举例 128K 高重复 prompt 的首 token 延迟从约 13 秒降到约 0.5 秒 [13]。
- 模型D的「硬盘缓存」很有代表性：常规 KV Cache 太大放不进内存，它靠 V2 的 MLA 架构把 KV 体积大幅压缩，才得以低成本地落到分布式硬盘上长期保留。这是「把缓存做大做久」的另一条工程路线 [13]。
05
为什么命中率会这么高
铺垫到这里，可以回答文章最初那个问题了。命中率高的原因在于，当前主流的「agent 式」调用，恰好是 prefix caching 的完美工作负载。
关键：agent 对话是「只追加」的
回想第二节那条铁律：只追加、不插改，缓存就一直命中。而各类 AI agent 的多轮调用，正好就是这个形状：
每一轮请求，都把整段历史原封不动重发一遍，再在末尾追加一点点新内容（上一步的工具输出 + 模型新回复）。于是除了最新追加的一小段，前面的巨大前缀全部命中缓存。会话越长，被反复重读的前缀越大，命中占比越高。
一个简化模型：命中率 ≈ (T−1)/(T+1)
可以做个粗略估算。设一次会话共 T 轮，每轮新增的内容量大致相当（记为 d）。第 k 轮请求时，前面 (k−1) 段都已缓存、走「命中读」，只有最新 1 段是「写入」。把整场会话的 token 累加起来：
- 累计命中读 ≈ d × [0 + 1 + … + (T−1)] = d·T(T−1)/2
- 累计新写入 ≈ d × T
两者相除，命中率 ≈(T−1) / (T+1)。代入实际会话长度：
| 每次会话轮数 T | 理论命中率 |
| 10 | 81.8% |
| 20 | 90.5% |
| 40 | 95.1% |
一次典型的 agent 编码会话往往要跑十几到几十轮工具调用，命中率就容易落到 90% 上下。这大致解释了不同厂商主力模型的命中率为何都在这个区间——主要是「只追加对话 + 前缀缓存」这种工作负载的结果，而非某家模型的特殊能力；实际数值还受系统提示大小、块粒度、TTL、路由等因素影响。
TTL 短，为什么不掉链子
也许有人会疑惑：缓存默认只活 5 分钟，会话跑久了不会过期吗？答案是：不会。因为每次命中都会刷新 TTL，且不额外收费 [1]。只要你在持续编码（隔几十秒就有一次工具往返），缓存被一次次"续命"，整场会话几乎不过期。TTL 短只在你长时间挂起后才咬人。
反过来：什么时候命中率会掉到 50%
理解了机制以后，「低命中」也就好解释了。凡是破坏「只追加 + 前缀一致」的场景，命中率立刻塌方：
- 中途切换模型：缓存是按模型隔离的，换个模型等于前缀全部作废，相当于每次都冷启动；
- 改动了工具集或系统提示：它们排在最前面，一动则后面全废 [1]；
- 会话很短：T 很小时，(T−1)/(T+1) 本来就低（T=3 时正好约 50%）；
- 请求被分散路由到不同后端：若缓存按后端隔离、且路由不感知前缀（自建或非 cache-aware 网关常见），轮询会打散前缀的局部性；不少商用 API 已用 cache-aware 路由缓解这一点。
所以如果我们在看板上看到某个「自动路由 / 多模型聚合」档位的命中率只有 ~50%，多半就是它在请求间不断切换模型 / 重置前缀，把有效会话深度压到了三五轮。
06
一个反直觉的提醒
最后说明一个容易陷入的认知误区：高命中率 ≠ 一定省钱、一定高效。
命中率高，恰恰是「每一轮都把整段大上下文重发一遍」的副产物。命中读虽然只要 0.1× 价钱，但你的绝对输入量也被这种重发模式撑得很大。真实成本由命中读 + 写入 + 未缓存三部分的总和决定，单看命中率会误判。
换句话说：
- 命中率 90% 是好事，说明缓存机制在替用户省钱、降延迟；
- 但真要压成本，杠杆往往在那 掉到 50% 的少数流量上（让它们绑定单一模型、稳定工具集、复用前缀），而不是在已经 90% 的主力模型上抠。
把缓存当成一种「奖励只追加、惩罚乱插改」的契约——顺着它的脾气用，命中率自然就上去了。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：
- ✅ 从零到一的 AI 学习路径图
- ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
- ✅ 百度/阿里专家闭门录播课
- ✅ 大模型当下最新行业报告
- ✅ 真实大厂面试真题
- ✅ 2026 最新岗位需求图谱
所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~
① 全套AI大模型应用开发视频教程
（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）
② 大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
③ 大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
以上资料如何领取？
为什么大家都在学大模型？
最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！
不出1年，“有AI项目经验”将成为投递简历的门槛。
风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！
这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
