提示缓存与上下文缓存
文档摘要
提示缓存与上下文缓存 本节摘要:你的系统提示 4000 token、RAG 上下文 20000 token,每次请求都发、每次都全价付费。提示缓存(prompt caching)让厂商在它那边把这个前缀「保温」,重用时只按正常费率的 10% 计费。用对了,推理成本降 5090%、首 token 延迟降 4085%。本节讲透它的机制(前缀命中则复用上次 KV 缓存)、三大厂商(Anthropic/OpenAI/Google)的口味差异、缓存友好的提示布局原则,以及盈亏平衡的计算。读完本节,你能把稳定前缀放顶部、变量放底部,让缓存命中率最大化。 对应原课程:Phase 11 · Lesson 15 · (原英文 )。 学习目标 阅读完本节,你应当能够: 说清提示缓存要解决的重复付费问题。
提示缓存与上下文缓存
本节摘要:你的系统提示 4000 token、RAG 上下文 20000 token,每次请求都发、每次都全价付费。提示缓存(prompt caching)让厂商在它那边把这个前缀「保温」,重用时只按正常费率的 10% 计费。用对了,推理成本降 5090%、首 token 延迟降 4085%。本节讲透它的机制(前缀命中则复用上次 KV 缓存)、三大厂商(Anthropic/OpenAI/Google)的口味差异、缓存友好的提示布局原则,以及盈亏平衡的计算。读完本节,你能把稳定前缀放顶部、变量放底部,让缓存命中率最大化。
对应原课程:Phase 11 · Lesson 15 ·
prompt-caching(原英文phases/11-llm-engineering/15-prompt-caching/docs/en.md)。
学习目标
阅读完本节,你应当能够:
- 说清提示缓存要解决的重复付费问题。
- 解释缓存的机制(前缀命中则复用 KV 缓存,首次写有溢价、后续读大打折)。
- 对比三大厂商的缓存口味(显式标记 vs 自动 vs 显式 API)。
- 掌握缓存友好的提示布局(稳定在上、变量在下)。
- 做盈亏平衡计算(写溢价 + 多次读折扣何时回本)。
一、问题与直觉
一个编程 agent 每轮都把同一份 15000 token 的系统提示发给 Claude。20 轮对话,按 3 美元/百万输入 token 算,光输入成本就 0.9 美元——还没算用户实际消息。乘以每天 10000 次对话,账单 9000 美元/天,而这些文本从不变。
你不能缩小提示(伤质量),也不能不发(模型每轮都需要)。唯一的办法是:别为厂商已经见过的前缀付全价。
Anthropic 2024 年 8 月推出(2025 年加 1 小时扩展 TTL 变体),OpenAI 当年晚些时候自动化,Google 随 Gemini 1.5 推出显式上下文缓存——三家现在都把它作为前沿模型的一等特性。
二、从零实现
机制
当一个请求的前缀匹配最近某次请求的前缀,厂商就用上次的 KV 缓存,而非重新编码这些 token。你首次付一小笔写溢价,之后每次大笔读折扣。
三大厂商口味(2026)
| 厂商 | API 风格 | 命中折扣 | 写溢价 | 默认 TTL | 最小可缓存 |
|---|---|---|---|---|---|
| Anthropic | content block 上显式 cache_control 标记 |
输入 90% off | 25% 附加 | 5 分钟(可延至 1 小时) | 1024 token(Sonnet/Opus)、2048(Haiku) |
| OpenAI | 自动前缀检测 | 输入 50% off | 无 | 最长 1 小时(尽力) | 1024 token |
| Google(Gemini) | 显式 CachedContent API |
读约正常 25% | 按 token·小时存费 | 用户设定(默认 1 小时) | 4096(Flash)、32768(Pro) |
不变量
三家都只缓存前缀。 任意一个 token 不同,从第一个不同 token 起全部 miss。所以把稳定部分放顶部、变量部分放底部。
缓存友好的布局
[系统提示] <-- 缓存 [工具定义] <-- 缓存 [少样本示例] <-- 缓存 [检索到的文档] <-- 复用就缓存,否则别 [对话历史] <-- 缓存到上一轮 [当前用户消息] <-- 永不缓存(每次不同)
违反顺序(用户消息放系统提示上面、动态检索插在少样本之间),缓存永远不命中。
盈亏平衡
Anthropic 的 25% 写溢价意味着一个缓存块至少要被读两次才净省。1 写 + 1 读平均 0.675× 成本(省 32%);1 写 + 10 读平均 0.205×(省 80%)。经验法则:凡你预期在 TTL 内复用至少 3 次的,就缓存。
三、框架对比
| 维度 | 不用缓存 | 用提示缓存 |
|---|---|---|
| 重复前缀成本 | 每次全价 | 首次小溢价,后续 ~10% |
| 首 token 延迟 | 全编码 | 命中时大幅降低 |
| 实现复杂度 | 无 | 需正确布局 + 标记(Anthropic/Google) |
| 风险 | 无 | 布局错则零命中,白付写溢价 |
四、可复用产物
本节产出 outputs/skill-prompt-caching-layout.md——提示缓存布局检查清单:前缀稳定性审计、cache_control 标记位置、TTL 与复用次数的盈亏估算、常见布局错误(动态插中间、用户消息前置)。
五、练习
- 盈亏计算:系统提示 8000 token,Anthropic 定价,写溢价 25%、读折扣 90%。计算「1 写 + N 读」在 N=1/3/10/50 时的平均每请求成本倍数,找出回本点。
- 布局审计:给定一个把 RAG 结果插在少样本示例之间的提示,指出为何缓存不命中,改成缓存友好布局。
- 实测延迟:用 Anthropic SDK 对同一长提示跑「无 cache_control」vs「有 cache_control」各 10 次,对比首 token 延迟分布。
- TTL 策略:一个每 30 分钟才有一次请求的服务,5 分钟 TTL 会怎样?设计一个定时「保温」请求或改用 1 小时 TTL 的方案。
本节要点回顾
- 痛点:长系统提示/RAG 上下文每次全价付费,重复内容成本巨大。
- 机制:前缀命中则复用上次 KV 缓存,首次写小溢价、后续读大折扣。
- 三家口味:Anthropic(显式
cache_control,90% off,25% 写溢价)、OpenAI(自动,50% off)、Google(显式CachedContent)。 - 不变量:只缓存前缀,第一个不同 token 起全 miss——稳定在上、变量在下。
- 友好布局:系统/工具/少样本缓存,对话缓存到上轮,当前用户消息永不缓存。
- 盈亏平衡:25% 写溢价下至少读 2 次回本;经验法则——TTL 内复用 ≥3 次就缓存。
- 收益:成本降 5090%、首 token 延迟降 4085%。
下一节,我们看Agent 状态机——把
while True循环变成可检查点、可中断、可回溯的显式图。