Prompt Caching 完全指南：原理、成本模型与落地姿势

Prompt caching 解决的是什么问题

大多数 LLM 调用的输入里，有相当大一部分是每次都一样的：系统提示词、few-shot 示例、检索出来的固定文档、工具定义（tool schema）。按普通计费，这些重复内容每次都要重新付一遍输入 Token 的钱，也每次都要重新算一遍 attention。

Prompt caching 的思路很直接：服务端把这段前缀的计算结果存下来，下次请求如果前缀完全相同，就直接复用，只对新增部分重新计算。Anthropic 在 [prompt caching 文档](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)中把它定位为降低延迟与成本的手段，OpenAI 侧对应的是自动 prompt caching 与 batch 折扣等机制。

哪些场景真的省钱

Prompt caching 不是一个「打开就省」的开关。它有一个明确的赢利边界：同一段前缀被复用的次数 × 前缀长度 > 缓存写入的额外开销。

• 长系统提示词 + 多轮对话：系统提示词几千 Token、会话轮次多，几乎必赚。
• RAG + 固定文档集：把不变的政策文档/知识库放前缀，只让用户问题变化。
• 代码 Agent / 工具调用：工具 schema 和仓库结构说明通常在每次调用里重复。
• 单次、短前缀的调用：写入缓存的开销可能高于省下的钱，不要强行缓存。

导致缓存失效的五个常见错误

• 前缀里混入时间戳或随机 ID：哪怕只在一个固定位置放 Date.now()，整段前缀都变了。
• 系统提示词动态拼接：不同用户拿到不同前缀，缓存命中率会被稀释到接近 0。
• 对历史消息做摘要压缩：每轮改写一次，前缀就不稳定了。
• 把用户输入放在最前面：这是最常见的结构错误，应该让变量尽量靠后。
• 只看账单不看命中率：没有命中率指标时，缓存的收益完全无法归因。

在多家模型之间复用同一套缓存策略

如果你的产品同时用 Claude 和 GPT，缓存语义在不同厂商之间并不完全一致（谁声明缓存断点、TTL 多长、计费方式如何）。把这段适配收在一个统一网关后面，好处是业务代码只维护一份提示词结构，切换模型时不必重写。

Admesh 的网关对下游保持 OpenAI 兼容协议，因此同一份提示词结构可以只改 model 字段就在不同厂商之间切换；缓存命中的计费口径统一体现在账单的 usage 明细里，不需要为每家厂商分别对接计费口径。

查看计费单位与缓存 Token 说明 →

落地清单

1. 把提示词拆成「稳定前缀 / 半稳定部分 / 用户输入」三段，稳定部分放最前。
2. 确保稳定前缀中不出现时间戳、随机数、用户 ID。
3. 在账单里单独统计缓存读写 Token，换算成真实命中率。
4. 用一份固定的评测请求集定期回归，确认提示词改动没有打崩命中率。
5. 给缓存收益设一个下限（例如低于 5% 就回滚提示词结构），避免为优化而优化。