许多 LLM 应用会反复发送相同的指令、工具模式和参考资料。提示词缓存可以复用稳定前缀的计算结果，但前提是应用确实保留了可复用的部分。
缓存复用的是什么
OpenAI 将提示词缓存描述为复用未变化的提示词前缀已经计算出的键值状态。模型仍会处理新输入并生成新的回答。因此，缓存是性能机制，不是用户事实存储，也不保证输出完全相同。
可用条件和定价因模型及服务提供商而异。应阅读最新文档，不要将最小长度、保留期限或折扣等假设写死在代码里。
将稳定内容放在前面
把稳定的系统指令、示例、工具定义和模式放在可变的用户内容之前。开头附近的小改动可能使后面所有内容都无法复用。保持顺序确定，尤其是在提供商按序列化后的前缀逐字匹配时，工具及 JSON 模式属性的顺序也要稳定。
不要仅仅为了达到缓存门槛而填充提示词。额外 token 会增加复杂性，也可能分散模型注意力。应缓存模型在大量请求中确实需要的材料。
衡量命中率和用户实际体验
记录已缓存的输入 token 数、总输入 token 数、首个 token 的生成时间、端到端延迟，以及每个成功任务的成本。按请求路径和提示词版本分组分析。总体命中率可能掩盖高流量且有价值的路径频繁未命中的问题。
比较重构前后可比的工作负载。生成耗时、排队等待和工具延迟可能占主导，因此高缓存命中率不一定带来成比例的端到端改善。
将隐私与隔离纳入考虑
了解提供商在缓存隔离、保留期限和数据控制方面的条款。不要假定缓存会在项目或用户之间共享；没有明确的安全模型，也不要设计跨租户复用。
不要把用户专属密钥放进所谓的公共前缀。内容稳定并不意味着适合共享。应采用与普通提示词相同的数据最小化规则。
将缓存视为可选优化
即使缓存未命中，应用也必须保持正确。不要把缓存是否存在当作会话状态或授权证据。预热请求可能有助于应对可预测的流量，但应由实际需求数据来支持。
有意识地对稳定前缀进行版本管理。当政策或工具定义变化时，使用新前缀是合理的：这样可以避免将旧计算结果误认为当前应用状态。
如何付诸实践
先选取一个与“LLM 应用的提示词缓存：减少重复计算，不走捷径”相关、边界清晰的工作流程。改动系统之前，用一页文档记录基线：目前的完成时间、质量检查项、常见失败类别、升级处理路径和结果负责人。选取有代表性的样本，而不是只挑最干净的案例。纳入普通案例、困难的边缘案例，以及至少一个正确做法是停止或请求更多信息的案例。
在允许候选方案取代现有流程前，先让两者并行运行。成功和失败的输出都要检查，因为错误率下降仍可能掩盖新的高影响失败。记录每次测试使用的准确配置，并保留足以让其他审核人员复现结果的材料。试点结束时，依据事先商定的阈值决定扩大应用、修改方案还是停止，而不是事后凭一次最出色的演示作判断。
向供应商或内部团队提出的问题
询问核心主张有哪些证据支撑、证据基于哪个系统版本和数据版本，以及排除了哪些条件。要求提供与你的部署场景相符的语言、输入类型和风险类别的测试结果。询问变更如何通知、回归问题如何发现，以及客户如何导出事故复盘所需的日志。
还要问清：当置信度低、依赖项故障或请求超出支持范围时，系统会如何处理。可靠的产品应有明确的失败状态，而不是仅仅给出更像样的回答。责任归属同样重要：明确谁能暂停流程、谁批准例外，以及重大错误流入生产环境后由谁通知受影响的用户。
实用检查清单
- 选择模型或工具前，先明确用户任务以及真正需要防范的失败。
- 维护一个来自真实工作的、小规模且有版本记录的测试集，纳入棘手案例和对抗性案例。
- 每次运行都记录模型、提示词、工具、检索设置、数据版本、延迟和成本。
- 不可逆、高影响或对外可见的操作必须经过人工确认。
- 按类别复盘失败，不要只看单一平均分，并将回归案例加入测试集。
Meydo Journal 延伸阅读
原始资料
- 提示词缓存 — OpenAI
