GPT-6 的 Prompt 缓存已经成为可控制、可诊断的 API 合同。应用可以选择隐式或显式断点，提前预热稳定前缀，用诊断接口比较两次请求，并把写入与读取成本分开核算。真正的工程任务，是证明某组真实请求复用了预期前缀、降低了总成本，同时在冷缓存下仍然保持正确。
阅读时间：约 9 分钟 · 约 3200 字
TL;DR
- GPT-5.6 及后续模型，包括 GPT-6，要求可复用前缀至少包含 1024 个可见输入 Token。
- 缓存写入按普通输入费率的 1.25 倍计费，读取按 0.1 倍计费。
- Explicit-only 模式缺少显式 breakpoint 时，既不读缓存，也不写缓存。
- 稳定内容放在断点前，用户特定、时间敏感和频繁变化的内容放在断点后。
- Model、service tier、tools、Schema、输出格式、request-level reasoning effort、verbosity 和早期输入都要保持稳定。
- Diagnostics 只返回第一个可分类原因。修复后继续比较，直到 Usage 证据与设计一致。
- 缓存属于性能与计价优化。每个请求都要在冷缓存下正常完成。
先分清三种不同的缓存问题
OpenAI 的 Prompt Caching 官方文档描述的是跨请求复用相同 Prompt 前缀。服务为符合条件的前缀保存 Key-Value Tensor，后续请求可以复用这部分计算。
它与站内已经讨论过的两个问题处于不同层级：
- KV Cache 作为 Agent Runtime讨论可写、多流推理状态，以及调度、隔离、来源和恢复。
- DeepSeek SWA 有界重放讨论滑动窗口注意力下的服务端 KV 状态重建。
GPT-6 Prompt 缓存面向 API 请求合同：哪个渲染后前缀符合条件、可以在哪里查找、发生了什么变化，以及 Usage 怎样计费。它不承担应用记忆，也不应成为正确性的前提。
写入计费改变了回本点
对于 GPT-5.6 及后续模型，OpenAI 官方文档给出的缓存写入价格是普通未缓存输入的 1.25 倍，缓存读取价格是 0.1 倍。一次完整写入加一次完整复用共需 1.35 份普通输入成本，低于两次冷请求的 2 份成本。一次写入加九次读取共需 2.15 份，冷请求则需要 10 份。
若某段前缀的普通输入成本为 C，可以用下面的简化模型估算：
缓存方案 = 1.25C × 写入次数 + 0.10C × 读取次数 + miss 成本
冷处理 = 1.00C × 请求次数
复用频率因此成为设计变量。写入一次且从未复用的前缀，比直接冷处理更贵。被大量请求共享的稳定政策，通常可以很快覆盖写入成本。
最低可缓存前缀为 1024 个可见输入 Token，OpenAI 提供的隐藏 System 内容不计入该阈值。GPT-5.6 及后续模型当前使用 30m 设置，条目在最近一次写入或复用后至少可用 30 分钟。这个数字代表最低可用窗口，不应被理解为精确的强制清除时刻。
有意识地选择 implicit 或 explicit-only
Implicit 模式由 OpenAI 在最新的合格消息结尾设置断点，适合保留历史并持续追加新轮次的对话。
Explicit-only 模式由应用明确标记可复用边界：
response = client.responses.create(
model="gpt-6-sol",
prompt_cache_options={"mode": "explicit"},
input=[
{
"role": "developer",
"content": [{
"type": "input_text",
"text": stable_policy,
"prompt_cache_breakpoint": {"mode": "explicit"},
}],
},
{"role": "user", "content": changing_request},
],
)
Explicit-only 模式在请求中没有显式断点时，不会读取或写入 Prompt 缓存。最后一个断点后的内容按普通输入费率处理，也不会产生缓存写入费。这很适合前半段是长而稳定的政策，后半段是快速变化的用户数据。
每个请求最多产生四次缓存写入。查找也有明确边界：Explicit-only 会检查最前两个与最新 50 个显式断点。Implicit 还会检查自身隐式断点、最多 20 个较早的合格消息结尾，以及初始连续 Developer Message 块的结尾。
断点数量应对应真实变化频率。例如在版本化全局政策后设置一个断点，在客户专属知识包后设置另一个。继续增加标记会扩大调试面，并不保证获得有效复用。
九类失效原因构成审计矩阵
Prompt Cache Diagnostics可以把当前请求与同一 Organization 近期完成的 Response 对比。将基线 Response ID 写入 prompt_cache_options.comparison_response_id，再检查 prompt_cache_diagnostics 和本次 Usage。
| 诊断原因 | 合同发生的变化 | 优先修复方式 |
|---|---|---|
model_changed |
实际处理请求的模型变化 | 为同一请求族固定模型 |
prompt_cache_key_changed |
分账或隔离 Key 变化 | 在预期分组内保持稳定 Key |
service_tier_changed |
处理层级变化 | 比较请求保持相同 Tier |
tools_changed |
工具名称、顺序、说明或 Schema 变化 | 保持 Tools 数组稳定，单独控制可用范围 |
text_format_changed |
Structured Output 指令或 Schema 变化 | 对格式做版本管理，并按 Schema 分组 |
reasoning_effort_changed |
顶层 effort 改写隐藏指令 | GPT-6 对话中使用 configuration_update |
verbosity_changed |
响应详略指令变化 | 同一请求族保持 verbosity 稳定 |
context_compacted |
更早历史被压缩内容替换 | Compaction 后建立新的比较基线 |
input_changed |
早期消息、指令、ID 或时间戳变化 | 把动态内容移到断点后，并持续追加轮次 |
Diagnostics 每次只报告第一个可分类原因，一次请求可能同时发生多处漂移。修复当前原因，使用同一基线继续测试，再处理下一项。unavailable 无法证明命中，诊断记录过期后则可能返回 comparison_response_not_found。
Usage 字段才是复用和计费证据。应检查 usage.input_tokens_details.cached_tokens 和 cache-write tokens，避免把诊断标签直接当成账单。
让工具与推理配置保持追加式变化
工具定义位于渲染后的前缀内。函数改名、工具换序、修改描述或调整 JSON Schema，都可能让复用失效。
应用需要改变工具可用范围时，可以保留完整 Tools 数组，再通过 tool_choice: "none" 暂停工具调用，或通过 allowed_tools 限制可调用集合。Deferred tool search 和 additional_tools 可以把新发现的工具追加到已有上下文之后，保留前面的稳定前缀。
GPT-6 还支持在对话中追加 configuration_update 修改推理强度：
{
"type": "configuration_update",
"reasoning": { "effort": "high" }
}
Request-level reasoning.effort 保持原值。直接改写顶层设置可能改变更早的隐藏指令，降低缓存复用。
只有预期复用能回本时才预热
prompt_cache_options.prewarm: true 可以提前准备符合条件的前缀，同时不生成输出。它适合已知即将到来的工作负载，例如在定时评测批次开始前装载共享政策。
预热产生的写入按正常缓存写入费率计费。因此触发器至少要包含四项：
- 预计请求数量；
- 距离第一次使用的最长时间；
- 前缀版本；
- 工作负载取消后的处理方式。
为不确定的一次性请求预热，相当于用确定成本购买可能出现的延迟收益。
一套可重复的上线审计
为某个请求族启用缓存前，冻结 10 到 50 个代表性请求，执行下面的测试：
- 冷基线：记录输入、输出 Token，TTFT 的 p50 与 p95，总延迟和任务成功率。
- 写入：使用设计好的 implicit 或 explicit breakpoint，记录 cache-write tokens。
- 复用：只改变预定后缀，记录 cached-token ratio 和成本。
- 变异测试：依次改变 Model、Tier、工具顺序、Schema、verbosity、effort、早期指令和 compaction 状态。
- 诊断：逐项与基线比较，保存返回原因。
- 冷缓存正确性：主动制造 miss，并用同一任务验收标准检查结果。
- 生产门禁：监控 cached-token ratio 下降、异常写入、延迟回归和单个合格任务成本上升。
OpenAI Platform 中的 Prompt Caching Dashboard 适合观察整体行为。根因分析仍需要请求级 Trace，因为全局命中率可能掩盖某个客户或 Prompt 版本持续重写前缀。
FAQ
GPT-6 Prompt 缓存是自动的吗？
Implicit 模式会自动放置合格断点。Explicit-only 至少需要一个显式断点；缺少断点时，请求不会读写 Prompt 缓存。
Breakpoint 前必须有 1024 个 Token 吗？
GPT-5.6 及后续模型的可复用可见前缀需要达到 1024 Token。OpenAI 隐藏 System 内容不计入阈值。
GPT-6 还必须使用 prompt_cache_key 吗？
不需要。GPT-5.6 及后续模型会自动处理缓存路由。该 Key 主要用于按客户、用户或 Workspace 做独立分账与隔离。
工具内容相同，仅调整顺序为什么也会 miss？
OpenAI 缓存的是包含工具定义及顺序在内的渲染前缀。断点前结构变化会改变前缀。
应用可以手动清空 Prompt 缓存吗？
当前官方文档没有提供手动清除接口。需要逻辑隔离时可以调整前缀版本或分账 Key，同时保证每次请求都能在冷缓存下工作。
Diagnostics 是否单独收费？
诊断功能本身没有额外费用，也不单独占用 Rate Limit。为了建立基线或复测而增加的 Responses API 请求会正常计费。
让缓存可观测，同时保持可选
选择一个高频请求族，写清稳定前缀、动态后缀、断点、预期复用次数、隔离 Key 和冷缓存验收标准。完成七步审计后再上线。有效缓存会降低实测延迟和总成本，可靠应用则在缓存缺席时依然正确。