简单讲“缓存命中便宜、不命中贵”，省的不是 token 本身。而是模型把你的 prompt 跑一遍预计算的算力。痛点：你在实际项目里常常看到一样的程序提示被反复计费，却不知道可以通过缓存省下大量算力费用。其实，

一、先用一个比喻搞懂

把大模型想成一个赶作业的学霸。每次交的“卷子”，开头都要写一段一模一样的个人陈述。

• 笨办法：每次都把那段文字重新手写一遍。
• 聪明办法：第一次写完后photocopy了一份。挂在卷子头上，以后每次直接贴复印件，只手写后面不一样的部分。

这里的“复印件”就是缓存——模型算好的中间成果。

• 命中：这次卷子开头和上次复印件一字不差 → 直接使用复印件，省得重写 → 这部分按低价计费。
• 不命中：开头改了一个字 → 复印件用不了需要重新手写 → 按原价计费。不过，

痛点：只要前缀保持一致。算力就能被重复利用，一旦前缀哪怕改动一个字符，后面的全部计算都要重新进行，费用瞬间飙升。

这笔账有多夸张

以 Anthropic 定价为例：假设程序提示占 2050 token每次使用者问题占 150 token。

痛点：请求越多，省下的费用越明显。百次级请求能砍掉 %60‑%70. 如果你的 prompt 是几万 token 的长文档，差距会扩大到数倍。

二、硬核原理：KV Cache 与为什么前缀能复用

预计算到底算了什么？其实，

Transformer 在处理你的 prompt 时会把整段文字逐层扫过。每层为每个 token 生成两组向量：K和 V**，合称 KV**。生成回答时模型靠 attention 回顾前面所有 token 的 K 和 V。为了避免每次都重新计算，这些 KV 会保存在显存里——这就是 KV cache**。

alert: alert: attention 是单向的，只往后看。第 N 个 token 的 KV 向量只取决于它之前的 N‑1  个 token，与后面的内容毫无关系。只要两个请求的前 N  个 token 完全相同，它们对应的 KV cache 就可以直接共享。

K/V 向量占用显存非常昂贵。例如 Llama‑2‑70B 每层每 token 大约需要 4KB ;共​320KB/token​<\/span>. 一个仅 {system_prompt} 的前缀就会占用约 ∼640MB 显存**。如果每次请求都重新计算并丢弃，这块显存浪费得惊人——正是 prefix caching 想要解决的问题。

实际是按“块”复用，不是按单个 token 比对

推理框架不会逐 token 比对。而是把 KV 切成固定大小的块进行哈希匹配：

key_0 = hash
key_1 = hash
key_2 = hash
...

A 与 B 两个请求可能在末尾相同但前半段不同，如 “A 国首都是巴黎” 与 “B 国首都是巴黎”。因为链式哈希会导致后一块的 key 完全不同，从而避免误命中。

从调用栈看。这事儿分四层

*我们平时说的“token 缓存命中”，本质上就是最底层物理层那块 KV 被成功复用了。

三、命中 / 不命中的流程差异

• # 命中 #：
  • K V 前缀直接被取出，无需 预计算；计费走 “cache read” 的低价档；TTFT显著下降——长 Prompt 可快约 %30‑%50 .
  • *痛点*: 如果没有及时监控，你可能根本不知道自己已经享受了多少折扣。
• # 不命中 #：
  • Llama/Anthropic/Gemini 会把整个 Prompt 预计算；随后可能将该 Prefix 写入缓存并收取 “cache write” 费用。
  • *痛点*: 对于高频调用。一次写入费用可能远超单次节省，使得整体成本反而上升。

DOS 注意事项：

1. CACHE 只认“前缀”。老实说，- 一旦从某个位置开始与已缓存版本不一致。该位置之后的所有缓存立即失效。
2. CACHE 必须字节级精确匹配。- 多加一个空格、改动标点、甚至时间戳都会导致失效，不能依赖“意思相近”。
3. *业务痛点*：很多团队在日志或调试信息里随手拼接时间戳导致缓存永远不命中，从而付出额外算力费用。

四、三大厂商实现 & 定价 差别比想象大