这是 2026 年的第 29 篇文章（本文阅读时间：约 15 分钟）
缘起：一个 90% 的观察
若查看团队大模型 token 消耗看板，常会发现主力模型的缓存命中率常年维持在 90% 左右，且使用频率越高、运行时间越久的模型，命中率越稳定。
这并非某家厂商的“黑科技”，而是行业标配的推理优化技术叠加"Agent 式调用”模式后的必然结果。本文将梳理以下核心内容：
- 缓存的本质（KV Cache 原理）；
- 当前主流缓存技术方向；
- 先进模型的落地实践；
- 高命中率的成因及其实际意义。
全文将尽量通过类比与图示阐述，避免陷入矩阵与算子的细节。
01 第一性原理：模型为什么需要缓存
大模型是「逐字生成」的
当前主流大模型均采用自回归（autoregressive）生成模式：每次仅预测下一个 token 并追加至文本末尾，再基于新序列预测后续内容。Transformer 的注意力机制要求预测每个新 token 时，必须“回看”此前所有 token。
若无缓存机制，计算量将随文本长度呈平方级膨胀：生成第 100 个字需重算前 99 个字的注意力，生成第 1000 个字则需重算前 999 个字，这将导致灾难性的性能瓶颈。
KV Cache：存储「回看」的中间结果
在注意力机制中，每个 token 被转换为 Query（查询）、Key（键）和 Value（值）。预测新 token 时，需用其 Query 与所有历史 token 的 Key/Value 进行运算。
关键洞察在于：历史 token 的 Key/Value 一旦计算完成便不再变化。因此，无需每步重算，只需将其缓存，新 token 仅需计算自身部分即可。这就是 KV Cache（键值缓存），它将每步计算从“重算整段历史”优化为“仅算新增部分”，是大模型推理的基石。
KV Cache 的局限在于其默认仅在一次请求内部有效。请求结束，缓存即丢弃。若下一请求开头完全相同，仍需从头计算。真正决定“命中率”高低的关键，在于能否实现跨请求的缓存复用，这引出了下一层技术。
02 从 KV Cache 到 Prefix Caching：跨请求复用
核心思想：相同前缀，只算一次
真实流量中存在大量重复开头：同一 AI 助手的每个请求均携带相同的系统提示词（System Prompt）；多轮对话中，第 N 轮请求的开头即为前 N-1 轮的全部内容。
Prefix Caching（前缀缓存）旨在留存并复用这部分“公共前缀”的 KV Cache。新请求进入时，系统先检测其前缀是否已缓存，若命中则直接读取，跳过昂贵的“预填充（prefill）”环节。
为何必须「逐字完全一致」？
这是 Prefix Caching 最关键且反直觉的规则：前缀从第一处不一致开始，后续内容均无法复用。
原因在于现代模型的位置编码（如 RoPE）：Token 的 Key/Value 不仅取决于内容，还取决于其位置序号。且在多层注意力下，某 Token 的状态依赖其前文上下文。一旦前缀中间插入或修改内容，后续所有 Token 的 K/V 均会改变，导致缓存失效。
由此得出两条重要推论：
- 稳定内容前置：系统提示、工具定义等不变内容应放在最前，易变内容（如用户问题、时间戳）放最后；
- 只能追加，不能插改：在已缓存内容后追加新内容可命中缓存；若改动前部内容，缓存将全部失效。
03 当前缓存技术有哪些方向
围绕“如何更高效地缓存与复用”，工业界与学术界形成了四个递进方向。
方向一/二：提升显存利用率——PagedAttention
KV Cache 极度消耗显存，早期系统因需预留连续显存，导致 60%–80% 的资源浪费。vLLM 提出的 PagedAttention 借鉴操作系统虚拟内存分页思路，将 KV Cache 切分为固定大小的“页（block）”，按需分配、灵活共享，将浪费降至 4% 以下，吞吐量提升 2–4 倍。这不仅节省了显存，也降低了跨请求共享 KV 的工程成本。
方向三：跨请求复用的数据结构路线
针对如何快速判断前缀是否已计算，两大开源引擎给出了不同方案：
- vLLM 的 Automatic Prefix Caching (APC)：将前缀切分为定长 block，通过链式哈希表达完整前缀。所有块存入哈希表，不维护树结构，采用 LRU 淘汰机制。其特点是要求逐块精确匹配。
- SGLang 的 RadixAttention：利用基数树（前缀树）显式建模请求间的前缀共享关系。共享前缀的请求落在同一分支，配合递归淘汰叶子节点的 LRU 管理及缓存感知调度，吞吐最高提升 6.4 倍。
两者殊途同归：让相同前缀的 KV 只算一次，供多请求复用。
方向四：突破「前缀」与「逐字一致」的限制
标准 Prefix Caching 要求必须是前缀且逐字一致，这对检索增强生成（RAG）等场景并不友好。学术界正致力于突破此限制：
- Prompt Cache (MLSys 2024)：允许开发者声明可复用模块，无论其出现在 Prompt 何处均可复用，实现一定程度的“位置无关”，首 token 延迟最高加速 8 倍（GPU）/ 60 倍（CPU）。
- CacheBlend (EuroSys 2025)：允许直接拼接非前缀位置的文档块缓存，仅对少量 token 进行选择性重算以修正注意力，TTFT 加速 2.2–3.3 倍，吞吐提升 2.8–5 倍且不损失质量。
- EPIC (ICML 2025)：系统性提出“位置无关缓存”，指出非前缀复用的主要障碍是 attention sink，并据此进行针对性修正。
这些技术代表了缓存从“前缀”走向“任意片段”的演进方向。
04 最先进的模型是怎么落地的
对照几家先进商用模型，其产品形态高度趋同：自动前缀缓存 + 命中大幅降价 + 短时 TTL。差异主要体现在开启方式、折扣力度及存储策略上。
维度 |
模型 A |
模型 B |
模型 C |
模型 D |
开启方式 |
手动打断点 cache_control（也可自动） |
全自动，无需改代码 |
隐式 (自动) + 显式 (手动建 CachedContent) |
全自动前缀缓存 |
命中折扣 |
命中约 0.1× 原价 |
初版约 5 折；新文档称“最高省 90%" |
隐式命中约 75% 折扣（按原价 25% 计） |
命中价约为未命中的 1/10 |
写入成本 |
5 分钟档 1.25×、1 小时档 2× |
— |
显式缓存另收存储费 |
存储免费 |
缓存寿命 (TTL) |
默认 5 分钟，命中自动续期；可选 1 小时 |
不活跃 5–10 分钟清除，最长 1 小时；部分支持 24 小时 |
默认 1 小时，可自定义 |
数小时至数天后自动清除 |
最小可缓存 |
约 1024–4096 token |
1024 token 起，按 128 增量 |
隐式 1024–2048、显式 2048–4096 |
最小单位 64 token |
缓存放哪 |
厂商侧 |
厂商侧 |
厂商侧 |
分布式硬盘阵列（靠 MLA 架构压缩） |
注：折扣口径随版本变动较大，具体请以官方当前定价页为准。
值得关注的落地细节：
- 官方收益数据：模型 A 曾公告提示缓存可降低成本最高 90%、延迟最高 85%（如 10 万 token 书籍响应从 11.5 秒降至 2.4 秒）；模型 D 举例 128K 高重复 prompt 首 token 延迟从 13 秒降至 0.5 秒。
- 硬盘缓存策略：模型 D 利用 V2 的 MLA 架构大幅压缩 KV 体积，使其能低成本存储在分布式硬盘上长期保留，这是“做大做久”缓存的另一条工程路线。
05 为什么命中率会这么高
命中率高的根本原因在于，当前主流的"Agent 式”调用恰好是 Prefix Caching 的完美工作负载。
关键：Agent 对话是「只追加」的
回顾前文铁律：只追加、不插改，缓存就一直命中。AI Agent 的多轮调用正是如此：
每一轮请求都将整段历史原封不动重发，仅在末尾追加少量新内容（工具输出 + 模型回复）。除最新追加部分外，巨大前缀全部命中缓存。会话越长，重复读取的前缀占比越高，命中率随之上升。
简化模型：命中率 ≈ (T−1)/(T+1)
设会话共 T 轮，每轮新增内容量为 d。第 k 轮请求时，前 (k−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 且不额外收费。只要持续交互（如隔几十秒一次工具往返），缓存便会不断“续命”，整场会话几乎不会过期。
反之：何时命中率会跌至 50%
凡是破坏“只追加 + 前缀一致”的场景，命中率将显著下降：
- 中途切换模型：缓存按模型隔离，切换模型等于前缀作废，每次冷启动；
- 改动工具集或系统提示：此类内容位于最前，一动则后续全废；
- 会话过短：T 较小时，(T−1)/(T+1) 数值本身较低（如 T=3 时约 50%）；
- 请求分散路由：若缓存按后端隔离且路由不感知前缀，轮询会打散前缀局部性。
若观察到某档位命中率仅 ~50%，多半是因请求间频繁切换模型或重置前缀，导致有效会话深度被压低。
06 一个反直觉的提醒
需警惕一个认知误区：高命中率 ≠ 一定省钱、一定高效。
高命中率往往是“每轮重发整段大上下文”的副产物。虽然命中读价格低廉（如 0.1×），但绝对输入量因重发模式而剧增。真实成本由命中读 + 写入 + 未缓存三部分总和决定，单看命中率易产生误判。
结论如下：
- 命中率 90% 说明缓存机制在生效，有助于降本降迟；
- 若要进一步压降成本，杠杆往往在于那命中率较低的少数流量（通过绑定单一模型、稳定工具集、复用前缀来提升其命中率），而非在已达 90% 的主力模型上过度优化。
将缓存视为一种“奖励只追加、惩罚乱插改”的契约，顺应其机制使用，命中率自然提升。
关于文中数据的说明
文中数字仅为辅助理解：定价/TTL/token 阈值为 2026 年初口径且随版本频繁变动，报价请以官方当前页为准；各类性能倍数均为特定模型与负载下的最高值，非通用收益；命中率 90% 与公式属经验观察与简化模型，实际受系统提示、块粒度、TTL、路由等因素影响。
References
以下来源均经 arXiv 摘要页/官方文档核实。涉及折扣比例、价格等随版本变动的数据，正文已标注“以官方定价页为准”。
【基础原理与学术论文】
[1] Anthropic. Prompt caching — Claude API 文档.
[2] Pope et al. Efficiently Scaling Transformer Inference. MLSys 2023.
[3] Kwon et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP 2023.
[4] Zheng et al. SGLang: Efficient Execution of Structured Language Model Programs. NeurIPS 2024.
[5] LMSYS Org. Fast and Expressive LLM Inference with RadixAttention and SGLang. 2024.
[6] Hu et al. EPIC: Efficient Position-Independent Caching for Serving LLMs. ICML 2025.
[7] Gim et al. Prompt Cache: Modular Attention Reuse for Low-Latency Inference. MLSys 2024.
[8] Yao et al. CacheBlend: Fast LLM Serving for RAG with Cached Knowledge Fusion. EuroSys 2025.
【推理引擎实现】
[9] OpenAI. Prompt Caching in the API.
[10] Anthropic. Pricing — Claude API 文档.
[11] Google. Context caching — Gemini API 文档.
[12] Google Developers Blog. Gemini 2.5 models now support implicit caching.
[13] DeepSeek. DeepSeek API introduces Context Caching on Disk. 2024-08.
[14] Anthropic. Prompt caching with Claude.
[15] vLLM. Automatic Prefix Caching.
（注：工程博客中具体延迟数据依工作负载而定，未作为普适结论写入正文。）
* 文中所有数据与分析均聚焦于技术原理与工程实践本身；涉及对其他产品的引用，已做模糊化处理，不代表对任何产品的评价或比较。
