缓存命中率设计是什么
上下文缓存（prompt caching）的收益等于命中率乘以折扣幅度，所以设计的核心是把请求结构做成「长稳定前缀加短动态后缀」：系统指令、工具定义、少样本示例与长文档放在前面并保持逐字节稳定；用户问题、当轮检索结果与时间戳一律放在后面。命中率能否从几十个百分点拉到九成以上，取决于前缀有没有被无关变量污染。可观测指标是按接口统计缓存命中的 token 占比，命中率骤降通常意味着前缀被某处改动破坏了。
基本信息
| 稳定在前 | 系统指令、工具定义、示例、长文档 |
|---|---|
| 动态在后 | 用户问题、当轮检索结果、时间戳 |
| 命中前提 | 前缀逐字节一致，任何插值都会破坏 |
| 监控指标 | 按接口统计命中 token 占比并设告警 |
| 排查方向 | 命中率骤降先查前缀是否被改动 |
| 配套手段 | 与检索、压缩配合控制总输入量 |
典型使用场景
- 固定助手：系统提示与工具定义长期不变，天然适合命中
- 长文档问答：同一份资料反复提问，前缀保持不变
- 批量任务：同一模板跑大量请求，只有输入内容不同
- 成本治理：定位哪些功能因前缀不稳定而吃不到折扣
- 版本发布：评估改系统提示带来的缓存收益损失
命中率排查流程
命中率排查流程
# 对每条响应统计：hit_rate = cached_tokens / prompt_tokens
# 按日聚合看 P50，若某天骤降按顺序排查：
# 1) 检查 system 提示是否改版（哪怕改一个标点也会失效）
# 2) 检查模板里是否插入了时间戳、会话标识或随机数
# 3) 对比不同渠道（SDK / 网关 / 自研客户端）的请求拼装顺序
# 4) 检查长文档是否每次重新拼接导致字节不一致
# 结论落到行动：变量后移、文档快照固定、模板统一命中率骤降的常见原因
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| 整体命中率下降 | system 提示改版 | 评估改动收益与缓存损失的取舍 |
| 只有部分渠道下降 | 某 SDK 或网关拼装顺序不同 | 统一请求模板并加校验 |
| 几乎全部未命中 | 前缀中插入时间或会话标识 | 把变量移到请求末尾 |
| 长文档命中偏低 | 文档每次拼接结果字节不同 | 固定文档快照，避免重复转码 |
| 账单没降 | 只优化单价不看命中率 | 把命中率纳入成本看板 |
改系统提示前先估算缓存损失：前缀改了，全量流量会在短时间内失去折扣，收益很小的措辞调整未必划算。
A/B 测试模板时保留对照组流量，能快速区分命中率变化来自模板改动还是流量结构变化。