上下文缓存实战：用稳定的前缀把成本降下来
发布于 2026-10-01
上下文缓存实战：用稳定的前缀把成本降下来
同样一段对话，有没有命中缓存，账单可能差出好几倍。缓存计费的前提是缓存命中，而命中与否，取决于你请求的组织方式——很多团队花了大价钱，只因为提示词开头多了一个时间戳。
一、缓存按“前缀”匹配
主流平台的上下文缓存都基于前缀：从请求最前面的内容开始比对，遇到第一处不同就停止。
这意味着顺序即成本：
稳定的内容放最前：系统提示、角色设定、工具定义、固定示例；
变化的内容放最后：用户本轮输入、当前时间、随机 ID。
把 当前时间 写在系统提示第一行，等于每个请求都是全新的前缀，缓存永远命中不了。
二、稳定前缀的三件套
1. 系统提示：措辞、标点、空行都要稳定。改一个字，整段缓存失效；
2. 工具定义：工具集合与顺序保持一致，不要按请求动态排列；
3. 固定示例：Few-shot 示例是缓存的好朋友——它们长、稳定、每次都一样。
三件套加起来往往是请求里最长的部分，命中一次省下的就是这部分。
三、多轮对话怎么排
多轮场景里，历史消息天然是“前缀”：
历史消息要原样保留，不要每轮重新摘要后再拼接（摘要变化会让前缀失效）；
需要滚动裁剪时，从最早的轮次开始整段删除，而不是修改中间内容；
每轮只追加，不改写——追加不破坏前缀，改写会。
四、把命中率变成可观测指标
响应里通常会返回缓存相关的用量字段（命中缓存的部分与未命中的部分分开计）。把它们记进日志并按接口聚合：
命中率突然下降 → 通常是有人改动了提示词或消息拼装逻辑；
某接口命中率长期为 0 → 检查是否有动态字段插在前面。
有了这条曲线，优化才有抓手。
五、常见的“打碎缓存”写法
系统提示里插入当前时间、请求 ID、会话随机串；
把用户输入拼在系统提示中间，再附加固定说明；
每轮对历史消息做不同的格式化（有时带 user:，有时不带）；
工具列表按可用性动态增删且顺序不稳定。
六、收益预期
缓存的收益与“稳定前缀的占比”直接相关：前缀越长、越稳定，命中后节省越明显。对于“长系统提示 + 固定示例 + 多轮对话”的应用，这几乎是最容易拿到的成本优化之一——不需要改模型，只需要改请求的排列方式。
从今天开始，把请求按“稳定的在前、变化在后”重排一次，再观察一周账单，你大概率会看到差别。