在此页面上
简短的回答
当请求共享可重用前缀时，提示缓存可以减少重复输入处理。这并不意味着应用程序返回旧答案。测量实际计费输入、适用情况下的写入、输出、延迟和接受的结果；仅靠高命中率并不能降低总运营成本。
拿走什么
- 在可行的情况下，保持可重复使用的指令稳定。
- 将提示缓存与应用程序响应缓存分开。
- 检查确切型号的保留和计费规则。
已检查来源 .研究综合和 Rubrex 建议。示例和本地实验均已标记；它们不是客户结果。
了解正在重用的内容
OpenAI 将提示缓存描述为重复使用中间状态来匹配提示前缀。该模型仍然处理新输入并生成响应。其当前文档使定价和保留行为模型相关。避免在未检查支持的情况下从旧型号复制配置。我们的建议是从请求清单开始：识别重复的指令和工具，然后测量有多少实际流量共享这些前缀。
证据： OpenAI提示缓存 [1]
构建真实的交通实验
比较具有相同模型、任务分布和输出期望的等效流量。重复的合成提示可以产生有吸引力的缓存结果，但该结果会在不同的客户请求下消失。包括冷启动和重复交互，并记录观察窗口。如果实验更改了提示布局，请确认答案质量仍然符合相同的标准。通过删除有用的上下文来实现成本改进是一种不同的干预措施，值得单独解释。
解释整个请求
将缓存的读取、未缓存的输入、计费的缓存写入以及生成的输出保留在单独的记帐字段中。计算任务总计时添加工具成本和重试。作为一个说明性的例子，假设其他一切保持不变，将占总成本五分之一的输入组件减半，总成本就会减少十分之一。它不会将账单减半。当用预测替换该简单示例时，请使用实际使用记录和当前提供商费率。
| 公制 | 如何计算或检查 | 它支持的决定 |
|---|---|---|
| 缓存输入共享 | 缓存的输入令牌/报告的输入令牌总数 | 有多少输入从重用中受益？ |
| 观察到的请求成本 | 计费输入、写入、输出和工具组件的总和 | 发票与预测相符吗？ |
| 第一个令牌的时间 p95 | 从请求开始到第一个输出令牌的第 95 个百分位数 | 重用是否会改善感知延迟？ |
| 每个接受任务的成本 | 总尝试和审核成本/接受的任务 | 缓存是否可以改善业务成果？ |
将缓存更改视为操作更改
检查所选保留行为是否符合应用程序的数据处理承诺。让租户授权独立于缓存，并避免仅仅为了提高命中率而存储敏感材料。留意会减少前缀重用的流量变化，例如频繁的提示编辑或高度可变的工具定义。部署后，将预测与观察到的成本和质量进行比较。如果节省消失，请在假设提供商更改其费率之前调查使用情况。
证据的局限性
缓存行为、会计字段和保留选项因提供商和型号而异。计算是说明性的；本文报告没有测量 Rubrex 延迟或节省，并且不承诺特定折扣。
常见问题
提示缓存与保存响应相同吗？
否。提示缓存重用输入处理；应用程序响应缓存可以返回以前存储的答案，并且需要自己的新鲜度策略。
缓存命中率越高越好吗？
不。总成本、质量、保留要求和延迟都很重要。缓存的请求仍然会产生昂贵或无法使用的答案。
来源和进一步阅读
本简报背后的主要来源。来源的研究结果适用于其自身的研究条件； arXiv 上的出版物不建立同行评审。
- OpenAI提示缓存 OpenAI · 生活参考 · 维护文档已审核： 前缀重用、缓存核算和特定于模型的保留指南.已访问 2026年9月25日.