为什么大模型缓存命中率能到 90%？一篇技术文背后的简单逻辑

最近读了阿里技术公众号的一篇长文《为什么大模型的缓存命中率能到 90%》（陈威特，2026-07-03）。文章把一套"看起来很黑科技"的现象讲得很透，其实底层逻辑非常朴素。

这篇博文不打算复述全文，而是挑出我觉得最关键的几条线，做一点自己的解读，顺便聊聊它和我们写 Agent、看成本账单有什么关系。

原文：《为什么大模型的缓存命中率能到 90%》 链接：https://mp.weixin.qq.com/s/bsSBfvWyLUEdFHFZmFOckQ

先说结论：高命中率不是"黑科技"，是工作负载的必然

文章开头抛了一个现象：很多团队的大模型 token 看板上，主力模型缓存命中率常年挂在 90% 上下，而且跑得越久、用得越频繁，越稳。

直觉上会觉得"这是某家模型特别强"。但文章给出的答案是反直觉的：这主要不是模型能力，而是"agent 式调用"这种使用模式，恰好踩中了前缀缓存（Prefix Caching）最舒服的工作区间。

换句话说，是"只追加的对话 + 跨请求复用缓存"这套组合拳，把命中率推到了 90%。模型换成谁家，结果大概率都差不多。

缓存到底缓存了什么：从"回看"说起

大模型是自回归生成的：一个 token 一个 token 往外蹦，每蹦一个，都要"回看"前面所有 token（注意力机制）。如果不缓存，生成第 1000 个字时，要把前 999 个字重新算一遍注意力——计算量随长度平方级膨胀。

缓存的正是每个 token 算出来的 Key/Value 中间结果，也就是 KV Cache：历史 token 的 K/V 算过一次就不再变，下一步直接读，不用重算整段历史。这把每步计算从"重算全部历史"降到了"只算新增的一个"。

但 KV Cache 有个先天局限：它默认只在一次请求内部有效。请求一结束，缓存通常就丢了。下一个请求哪怕开头一模一样，也得从头再算。真正决定"命中率"的，是能不能把缓存跨请求复用——这就引出了前缀缓存。

核心规则：相同前缀，只算一次，且必须逐字一致

Prefix Caching（前缀缓存）的思想很简单：真实流量里海量请求的开头高度重复——同一个 AI 助手，每个请求都带着同一份几千 token 的系统提示词；同一段多轮对话，第 5 轮的开头就是第 4 轮的全部内容。把这部分"公共前缀"的 KV 留下来跨请求复用，新请求命中了就直接读，跳过最贵的"预填充（prefill）"环节。

但这里有一条最反直觉、也最关键的铁律：前缀必须逐字完全一致。 因为现代模型用的是 RoPE 这类位置编码，每个 token 的 K/V 不仅取决于"它是什么词"，还取决于"它排第几位"，而且多层注意力下，某 token 的 K/V 还依赖前面整段上下文。所以你在前缀中间插一句话、改个时间戳，后面的缓存就集体失效。

这条规则带来两个直接推论，记牢了，后面解释"为什么命中率高/低"全靠它：

• 稳定的内容放最前面（系统提示、工具定义），易变的内容放最后（用户每次不同的问题、时间戳）；
• 只能追加（append），不能插改。在已缓存内容后面接新内容，前缀不变、缓存照命中；改前面内容，缓存全废。

为什么 agent 对话天然命中率高

铺垫到这，答案就出来了。各类 AI agent 的多轮调用，恰好是"只追加"的形状：

每一轮请求，都把整段历史原封不动重发一遍，再在末尾追加一点点新内容（上一步工具输出 + 模型新回复）。于是除了最新追加的一小段，前面巨大的前缀全部命中缓存。会话越长，被反复重读的前缀越大，命中占比越高。

文章给了一个很妙的简化模型：设一次会话共 T 轮，每轮新增量相当（记为 d）。累计命中读 ≈ d·T(T−1)/2，累计新写入 ≈ d·T，两者相除：

命中率 ≈ (T−1) / (T+1)

代入实际会话长度：

一次典型的 agent 编码会话往往跑十几到几十轮工具调用，命中率落到 90% 上下也就说得通了。

还有一个容易被问住的点：缓存默认只活 5 分钟，会话跑久了不会过期吗？答案是不会——每次命中都会刷新 TTL，且不额外收费。只要你在持续编码（隔几十秒一次工具往返），缓存被一次次"续命"，整场会话几乎不过期。TTL 短只在你长时间挂起后才咬人。

反过来想：什么时候命中率会掉到 50%

理解了机制，"低命中"就好解释了。凡是破坏"只追加 + 前缀一致"的场景，命中率立刻塌方：

• 中途切换模型：缓存按模型隔离，换模型等于前缀全部作废，每次冷启动；
• 改动了工具集或系统提示：它们排最前面，一动后面全废；
• 会话很短：T 很小时 (T−1)/(T+1) 本来就低（T=3 时刚好约 50%）；
• 请求被分散路由到不同后端：若缓存按后端隔离、且路由不感知前缀（自建或非 cache-aware 网关常见），轮询会打散前缀局部性。

所以如果你在看板上看到某个"自动路由 / 多模型聚合"档位命中率只有 ~50%，多半就是它在请求间不断切换模型、重置前缀，把有效会话深度压到了三五轮。

一个反直觉的提醒：高命中率 ≠ 一定省钱

这是全文我最想划重点的部分。

命中率高，恰恰是"每一轮都把整段大上下文重发一遍"的副产物。命中读虽然只要 0.1× 价钱，但你的绝对输入量也被这种重发模式撑得很大。真实成本由 命中读 + 写入 + 未缓存 三部分总和决定，单看命中率会误判。

换句话说：

• 命中率 90% 是好事，说明缓存机制在替用户省钱、降延迟；
• 但真要压成本，杠杆往往在那掉到 50% 的少数流量上（让它们绑定单一模型、稳定工具集、复用前缀），而不是在已经 90% 的主力模型上抠。

把缓存当成一种"奖励只追加、惩罚乱插改"的契约——顺着它的脾气用，命中率自然就上去了。

落到我们自己身上：几个可执行的提醒

读完这篇，我觉得对日常写 Agent / 调 prompt 的人，有几点很实在：

1. 系统提示和工具定义放最前，且尽量保持稳定。 它们排在前缀最前面，一旦改动会让后面整段缓存失效。频繁改 system prompt 不仅影响效果，还直接抬高 token 成本。
2. 尽量复用同一段前缀。 多轮对话、批量任务，别在前面塞易变内容（时间戳、随机 id）。需要"每次不同"的东西，往后放。
3. 别为了"高命中率"指标自嗨。 90% 命中率背后是巨大的重复输入。真正省成本，是去修那 50% 的低命中流量：固定模型、稳定工具集、避免把请求打散到不同后端。
4. 理解厂商的缓存策略差异。 自动前缀缓存 + 命中大幅降价 + 短时 TTL 已是行业标配（Claude 的 cache_control 断点、OpenAI 自动前缀缓存、Gemini 上下文缓存、DeepSeek 硬盘缓存等），但具体折扣、TTL、最小 token、存放位置各家不同，选型时可以按需对比。

总结

这篇技术文把一个"看起来很玄"的现象，还原成了非常朴素的逻辑链：

KV Cache（单次请求内复用）→ Prefix Caching（跨请求复用公共前缀）→ agent 只追加式调用（完美契合前缀缓存的工作负载）→ 命中率自然冲到 90%。

它既不是某家的黑科技，也不代表"绝对高效"。它是一套推理优化技术叠加特定使用模式后的必然结果。理解了这套机制，我们既能更合理地解读成本账单，也能更有意识地写出"对缓存友好"的 Agent。

最后用文章里那句话收尾：高命中率是奖励，真正省钱的是顺着缓存的脾气去设计。