Token 缓存（Prompt Caching）是把”每次都要重复发送的 prompt 前缀”在模型服务侧存下来，下次匹配上就只对增量部分重新计费的机制；2024 年 OpenAI 把它做成自动能力、Anthropic 在 Claude 3.5 上推出显式 cache_control、2025 年 Google 把 Gemini 2.5 的 Context Caching 默认 TTL 拉到 1 小时，三家把缓存折扣普遍拉到 50%-90% 区间。它对 AI 应用真正的价值，是把”系统提示词 + RAG 上下文 + 工具 schema”这种每天被重发几万次的长前缀从计费表上挪走。下文把它的机制、定价、落地步骤和常见坑一次性拆开。
一、Token 缓存解决的本质问题
LLM 推理的开销集中在 Transformer 的自注意力层——每个 token 都要算一遍 K-V 张量。一段 10k token 的系统提示词加上 RAG 检索片段，每请求重算一次，10k 流量就是 1 亿 token 的重复计算。Token 缓存把这个 K-V 状态保存在服务侧，下次同样的前缀进来时直接复用，CPU/GPU 和延迟同时下来。
要拿到这笔收益，必须满足三个条件：稳定的前缀（system prompt、知识库、few-shot 示例）、足够长的前缀长度（通常 ≥ 1024 token）、足够密集的请求（TTL 窗口内多次命中）。任一条件不满足，缓存就是空转。
二、三家主流厂商的缓存策略对比
2025 年下半年 OpenAI、Anthropic、Google 的缓存方案已经基本收敛，但具体折扣率、最小 token 数、TTL 长度仍有差异。
| 维度 | OpenAI（GPT-5.1 / GPT-4o） | Anthropic（Claude 3.5/4.x） | Google（Gemini 2.5） |
|---|---|---|---|
| 启用方式 | 自动（≥1024 token） | 显式 cache_control 断点 | 隐式+显式（context cache API） |
| 最小前缀 | 1024 token | 1024 token | 1024/2048 token 起步 |
| 缓存写入价 | 等于标准输入 | 1.25× 标准（5 分钟 TTL）；2.0× 标准（1 小时 TTL） | 不收写入费，等于基础价 |
| 缓存读取价 | 标准的 0.5×（约 50% 折扣） | 标准的 0.1×（90% 折扣） | 标准的 0.25×（75% 折扣） |
| 默认 TTL | 5–10 分钟，可延长 | 5 分钟 | 1 小时，可配置 |
| 缓存断点数 | 不暴露 | 最多 4 个 | 显式创建缓存对象 |
| 延迟改善 | TTFT 下降 50–80% | TTFT 下降 60–85% | TTFT 下降 40–70% |
| 命中率可见性 | 账单聚合，按请求不可见 | cache_read_input_tokens 字段 |
显式 cache 对象返回 |
折扣深度上 Anthropic 最高（90%）、Google 居中（75%）、OpenAI 偏稳（50%）；但 OpenAI 的优势是零代码改动。把它们混在一起选型时要权衡”折扣深度”和”接入成本”。
三、缓存命中的硬规则
“前缀完全一致”四个字是整个机制的核心。Anthropic 官方文档反复强调一点：哪怕一个空格、一个 JSON 键顺序变化、一个 tool schema 重排，都会让缓存直接 miss。常见的杀手细节有：
- 把时间戳、用户 ID、请求 ID 写进 system prompt 段——每次都变，永远 miss；
- RAG 检索片段插入 system 段而不是 user 段——前缀被污染；
- 多语言版本把不同语言混在同一个 system 段顶部——版本差异直接 miss；
- 工具描述改了一个字段顺序——schema 整体失配。
正确做法是”稳定前缀在前 + 动态请求在后”：所有静态内容（系统指令、风格规范、知识库摘要、工具 schema）都放进前缀区，所有动态内容（用户问题、当前文档、检索片段）放在尾部。Anthropic 允许最多 4 个 cache_control 断点，便于在不同模块边界精确控制哪些段缓存、哪些不缓存。
四、缓存落地的四步流程
把一个 AI 应用改造成”默认走缓存”通常按下面四步走：
- 拆分 prompt 结构：用编辑器把当前 prompt 切成”静态前缀”和”动态后缀”两段，列出每段的 token 数；
- 选择断点策略：Anthropic 走显式
cache_control: { type: 'ephemeral' }，断点放在工具段、System 段、Messages 段；OpenAI 只需把静态段放最前面； - 改造业务代码：把 system 段从字符串改成内容块数组，给每块加断点；调用时读取响应的
cache_creation_input_tokens与cache_read_input_tokens； - 监控与调优：按小时统计 cache hit 率、缓存 token 占比、TTFT 变化，命中率稳定后再扩量。
下面是 Anthropic Claude 接入缓存的最小化示例：
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": "你是法律分析助手，按以下格式输出...",
"cache_control": {"type": "ephemeral"} # 缓存系统指令
},
{
"type": "text",
"text": large_legal_doc, # 1.2 万 token 文档
"cache_control": {"type": "ephemeral"} # 缓存长文档
}
],
messages=[{"role": "user", "content": query}]
)
# 查看这次调用到底命中了多少缓存
print(response.usage.cache_creation_input_tokens) # 首次写入
print(response.usage.cache_read_input_tokens) # 后续命中效果上，第一次写入多花 25%，但同一会话里 10 次后续调用对 12k token 的前缀只收 10% 价——单次成本从 $0.036 降到 $0.0036，降幅约 90%。
五、缓存的边界与坑
缓存不是万能药。三个最常踩的坑值得提前知道：
- 未达最小 token：Anthropic 与 OpenAI 都需要 ≥1024 token，<1k token 的 prompt 加断点反而会被忽略或扣写入费；
- 请求稀疏：TTL 是 5 分钟，请求间隔超过这个窗口就会被清空；选 TTL 时要在”命中率”与”写入价”之间算账；
- 用户级 system prompt：把用户名、个人偏好塞进 system 段会让缓存始终 miss，正确做法是把它放 user 段或单独走个性化层。
此外，缓存只覆盖输入侧，输出 token 仍然按原价计；如果业务瓶颈在长文生成（输出远大于输入），缓存的收益要打折扣。
到这里，Token 缓存从机制、定价、命中规则到落地步骤就清楚了：成本优化的关键不是”开不开缓存”，而是”前缀能不能稳定地、不被动态内容污染地保持在 1024 token 以上”。
常见问题（FAQ）
Q1：缓存会改变模型输出吗？
不会。缓存只复用 K-V 内部状态，输出与重新计算完全一致，不会因为缓存导致质量下降。
Q2：OpenAI 的缓存和 Anthropic 的缓存能混用吗？
不能。OpenAI 自动、Anthropic 显式；两家的缓存对象、K-V 存储都隔离，跨厂商调用不会共享缓存。
Q3：缓存命中率多少算合格？
稳定业务在 TTL 窗口内连续请求，命中率 70% 以上是健康水位；<30% 通常意味着前缀没拆干净。
