缓存为什么会失效
提示缓存按前缀做精确匹配：请求开头部分与上一次完全一致时才能命中，命中后这部分输入不再重复计算，费用与首字延迟都明显下降。问题在于「完全一致」包括空白与标点，模板里改一个字、变量顺序调整、前缀里放一个时间戳，都会让缓存整段失效并重新写入。于是模板改动就必须按发布来对待：版本化、灰度、可回滚，而不是随手热改。
基本信息
| 命中条件 | 请求前缀逐字符一致，空白与标点同样参与比对 |
|---|---|
| 最小长度 | 多数实现要求前缀达到最小 token 长度才计入缓存，低于门槛不生效 |
| 有效期 | 缓存保留时间有限，闲置过久会失效，具体时长以厂商文档为准 |
| 生效范围 | 通常按组织或租户隔离，不是全局共享 |
| 主要破坏源 | 前缀里放时间戳或随机标识、热改模板、变量位置变化、多版本混跑 |
| 观测指标 | 缓存命中率、缓存读取 token 占比、改造前后的首字延迟 |
典型使用场景
- 长系统提示加固定示例的问答助手：系统提示越长，命中的收益越明显
- 长文档反复追问：把文档放在前缀，后续轮次只变尾部的问题
- 批量任务共用同一模板：批内请求前缀一致才能把缓存用起来
- 发布流程中的模板灰度：按流量比例切换版本，观察命中率与成本曲线
- 成本审计：定位输入 token 为何偏高，很多情况下是缓存没命中导致的重复计费
模板版本元数据
模板版本元数据
{
"template_id": "rag-answer",
"version": "2026-10-01",
"prefix_hash": "sha256:完整前缀的哈希值",
"min_prefix_tokens": 1024,
"notes": "本次改动：措辞微调，注意全量缓存会重建",
"rollback_to": "2026-09-18"
}
# 落库保留前缀哈希与回滚目标，便于事后归因与快速切回
# 同一时间只让一个版本承载主要流量，多版本混跑会摊薄命中率破坏缓存的常见写法
| 写法 | 后果 | 改法 |
|---|---|---|
| 前缀里放当前时间 | 每次请求前缀都不同，缓存永不命中 | 把时间与随机标识移到提示词尾部 |
| 热改模板 | 全部请求同时失效并重建 | 版本化加灰度，低峰期发布 |
| 变量位置与顺序变化 | 前缀不一致，命中率骤降 | 固定变量布局，新增变量追加在尾部 |
| 长文档放在变量区 | 每轮重复计费 | 把稳定文档固定在系统提示或前缀中 |
| 多版本长尾混跑 | 两个版本互相稀释缓存 | 收敛到单版本，灰度期控制时间窗 |
批量修改提示词的合适时机是低峰期：改完的瞬间所有缓存同时重建，请求成本与延迟都会抖动，放在高峰期改动相当于自己制造一次性能事故。
不要为了命中缓存而把敏感内容长期放在前缀里：缓存通常按组织或租户隔离，跨用户共享前缀的设计必须确认隔离边界，否则存在信息串扰风险。