提示缓存是什么
提示缓存指服务端把你请求里重复出现的开头部分存下来，后续请求命中时这部分按折扣价计费。按前缀匹配的方案不需要改代码，只要请求前缀一致就能命中；要求显式标记的方案则要在内容块上打标。共同的影响因素是一致的：固定内容放前面、变化内容放后面。对把长文档、工具定义、系统提示反复复用的场景，这项优化几乎免费。
基本信息
| 机制 | 对重复出现的请求前缀做缓存，命中部分按折扣价计费 |
|---|---|
| 命中前提 | 前缀完全一致，且长度达到服务要求的最小量级 |
| 对齐方式 | 按 token 块对齐，前缀中任何一处变化都会导致后续失效 |
| 设计要点 | 固定内容前置，动态内容后置 |
| 可观测性 | 响应里的用量字段会区分缓存命中与未命中的 token 数 |
| 另一条路线 | 部分厂商需要显式标记缓存断点，做法见对应厂商文档 |
影响命中率的设计
| 做法 | 命中率 | 说明 |
|---|---|---|
| 固定系统提示与工具定义 | 高 | 这部分每轮不变，最适合缓存 |
| 长文档作为前置资料 | 高 | 同一文档被反复提问时收益明显 |
| 前缀里插入时间戳 | 极低 | 前缀一旦变化，之后的内容全部失效 |
| 前缀内拼接用户信息 | 低 | 每个用户前缀都不同，等于没有缓存 |
| 示例与规则频繁微调 | 波动 | 每次调整后缓存都要重新建立 |
典型使用场景
- 客服知识问答：同一套产品资料被大量用户反复提问
- 代码助手：仓库说明与编码规范长期固定，作为前缀复用
- Agent 场景：工具定义与角色说明较长且不变，最值得缓存
- 批量抽取：同一份指令模板应用于成千上万条文本
- 文档追问：一份长文档配多个问题依次提问
缓存友好的请求结构
缓存友好的请求结构
{
"model": "gpt-4o",
"messages": [
{ "role": "system", "content": "……长期固定的角色规则与格式要求……" },
{ "role": "system", "content": "……固定不变的工具定义与示例……" },
{ "role": "user", "content": "……本轮的用户问题与实时数据……" }
]
}
// 前缀尽量长时间保持不变，变化的内容一律放到最后
// 需要展示时间时，把它放在用户消息里，而不是系统提示里命中率杀手
| 写法 | 后果 | 改法 |
|---|---|---|
| 系统提示里写当前时间 | 前缀每次都变，几乎永不命中 | 把时间放进本轮用户消息 |
| 前缀里拼随机标识 | 每个请求都是新前缀 | 把标识移到后缀 |
| 每次请求重新生成提示模板 | 空白与顺序微小差异导致不匹配 | 固定模板文本并做规范化 |
| 前缀太短 | 达不到最小缓存量级 | 把稳定的示例与规则集中到前缀 |
缓存的命中情况可以在响应用量里看到：把它接进监控，就能发现某次提示词调整是否悄悄毁掉了命中率。
多轮对话里历史消息本身也会成为前缀的一部分：追加消息不影响前面已有部分，但修改、压缩或重排历史会让缓存失效，这也是长会话进行到中段后成本突然上升的常见原因之一。
缓存有存活时间：间隔太久再发请求会重新写入，高频场景的折扣收益需要按实际节奏评估，而不是默认一直命中。