DOCAI · 课程 · L3 · 30 分钟
用上下文缓存省钱
缓存不是打开开关就生效。这一课教你按「稳定在前、变化在后」重排请求，用一次对照实验算出命中率与真实节省。
你将学会
- 把请求重排成缓存友好的前缀结构
- 用两次对照实验测出真实命中率
- 算清缓存带来的节省，而不是凭感觉
第一步：把稳定的放前面
缓存匹配的是前缀，要求逐字节一致。所以请求要按「稳定度」排序：
[稳定] 系统提示 → 工具定义 → 长期参考资料
[变化] 历史对话 → 本轮用户问题常见错误正好相反：把用户问题拼在系统提示开头，后面跟着几万字资料。 前缀每次都不一样，后面再长也命中不了。
第二步：清理「伪随机」内容
这些东西每变一次，缓存就废一次：
- 当前时间戳、请求 ID、随机种子；
- 用户名、订单号等每用户不同的内容；
- 每次重新排序的工具列表；
- 每次重新摘要的历史对话。
处理办法：把它们移到提示末尾或请求参数里，不要进前缀。
第三步：确认门槛
多数服务对缓存有最低长度要求（常见是几百到一千 token）， 短提示本来就不缓存。如果你的系统提示只有两三百 token，先别指望缓存。
另外注意存活时间：缓存通常有 TTL（分钟到小时级）， 请求间隔太长会失效。离线任务之间隔夜跑，基本每次都是冷启动。
第四步：做一次对照实验
拿同一批 50 条输入，跑两次：
| 组 | 做法 |
|---|---|
| A | 缓存友好的前缀结构 |
| B | 把变化内容放最前（模拟原来的写法） |
记录每次响应里的 usage 字段：
cache_read_input_tokens（或同类字段）：命中的 token；input_tokens：未命中的 token。
命中率 = 命中 ÷（命中 + 未命中）。
第五步：算真实节省
原成本 = 总输入 token × 原价
新成本 = 命中 token × 折扣价 + 未命中 token × 原价 + 写入溢价写入缓存的那一次可能要付溢价（部分服务是原价的 1.25 倍）， 所以只调用一两次的场景，缓存可能反而更贵。调用次数越多越划算。
常见错误
- 开缓存不重排：命中率接近 0，还多付写入溢价。
- 以为缓存能省输出：输出每次都要重新生成，一分不省。
- 所有请求都用缓存：低频调用算不过账。
- 缓存里放敏感信息：缓存按前缀共享，跨用户场景要确认隔离边界。
自测
- 你的系统提示加资料有多少 token？达到缓存门槛了吗？
- 你的请求里，哪些内容每次都在变？它们在第几位？
- 一天调用多少次？算上写入溢价，还划算吗？