GPT-6 提示缓存优化工作流

一句话结论

GPT-6 家族的提示缓存可通过稳定共享前缀、显式缓存断点、工具定义管理、跨轮调整推理档位、预热和缓存诊断来优化；迁移到 GPT-6 Sol 时需用实际工作负载验证。

适用场景

• 适合的任务：多轮 API Agent 重复发送较长指令、工具定义或参考上下文的工作流。

• 不适合的任务：请求间共享前缀很少，或输入频繁变化而无法稳定复用的工作流。

• 适用的模型版本：原文适用于 GPT-6 家族；本文归档于 GPT-6 Sol，不能视为 Sol 专属实测或收益保证。

• 适用的客户端、Agent 或 API：需要结合 OpenAI API 的提示缓存、Responses API 与对应缓存指南实现；具体能力以所用 API 和账户为准。

• 推荐的推理档位和参数：按任务需求设置。原文未指定固定档位，只说明可在 GPT-6 后续响应间更新 reasoning effort。

可直接使用的内容

1. 建立基线：在 Prompt Caching Dashboard 记录缓存命中率及缓存/未缓存输入 token 组成，并记录延迟和成本。

2. 整理稳定前缀：将跨请求不变的指令、工具定义和参考材料放在共享前缀；把经常变化的内容留在后部。

3. 设置缓存断点：按官方提示缓存指南选择显式 cache breakpoint，确定希望复用的前缀范围。断点的具体位置与请求格式依 API 文档配置。

4. 保持工具定义稳定：尽量维持工具定义、schema 和顺序不变。用 allowed_tools 限定当前可调用工具；没有工具可用时可按接口支持情况设置 tool_choice: "none"，避免为此移除工具定义。

5. 追加新指令：需要更改行为时，在较后的 developer message 追加新指令，让它覆盖较早指令并保留已有前缀。

6. 跨轮调整推理：需要改变 reasoning effort 时，在后续响应追加 configuration_update；保持请求级 reasoning effort 不变，并按 API 文档核对具体结构。

7. 提前预热：在应用启动或用户请求到达前，提交已知的共享指令、工具定义或参考材料，减少用户等待期间的处理。

8. 诊断并复测：命中率意外下降时，用 Prompt Caching diagnostics 对照近期请求与响应，检查模型、工具、设置或输入变化；调整后再次记录命中率、延迟和成本。

配置与适用边界

• OpenAI 表示，对 30 分钟窗口内符合条件且重复使用的共享前缀提供缓存折扣，最高可达缓存输入 token 折扣 90%；实际命中和节省取决于请求及工作负载。

• 原文将这些缓存能力和配置建议描述为 GPT-6 家族能力，没有报告 GPT-6 Sol 单独实验结果。Sol 上的命中率、延迟和成本需单独测量。

• 诊断示例显示工具变化可能造成缓存未命中；其他模型、设置或输入变化也可能影响前缀复用。

• 原文没有给出 cache breakpoint、configuration_update 或预热的完整请求体，也没有规定断点位置、字段值或所有接口的兼容情况。实施时应查阅对应 API 文档，不要从本文推断未展示的 payload。

• 预热和缓存控制是可选优化。仅在 Dashboard 与诊断数据表明对目标工作负载有帮助时采用。