OpenAI API 12 小时 prompt caching 更新怎样影响调用设计

OpenAI 在 2026 年 10 月 20 日更新 API：Responses API 现在可以把 prompt cache 的最小寿命设为 12 小时。它解决的是“同一套系统指令、工具和参考上下文，下一次调用已经超过 30 分钟”的场景，但不是把所有请求都改成长期缓存。更长的缓存寿命对应更高的写入价格，调用设计需要一起调整。

官方文档：https://developers.openai.com/api/docs/guides/prompt-caching

这次更新改变了什么

官方变更说明给出的重点是“可以选择 12 小时 prompt caching”。对 GPT-5.6 及更新模型，Responses API 的缓存寿命由 prompt_cache_options.ttl 控制：默认 30m，新增 12h。12 小时表示缓存条目至少在这个时间窗口内具备复用资格，不代表到点立即删除，也不改变平台的数据留存上限。

因此，更新的核心不是“缓存时间越长越好”，而是把缓存策略从固定参数变成调用间隔和前缀稳定性的决策。

调用结构要先把稳定内容和动态内容分开

缓存匹配看的是从开头开始的完整渲染前缀。模型、工具名称与顺序、结构化输出格式、部分推理设置发生变化，都可能让后续前缀无法复用。比较稳妥的布局是把角色规则、工具定义、长期参考资料放前面，把本次用户问题、时间戳和用户数据放后面。

下面是一个最小配置示意。注释说明的是设计意图，不代表已经在本机执行过：

import OpenAI from "openai";

const client = new OpenAI();

const response = await client.responses.create({
  model: "gpt-6.1-sol",
  // 稳定规则与参考资料放前面，减少每次请求改变前缀的机会
  instructions: "固定的业务规则、工具说明和长期参考资料",
  // 动态问题放在后面，避免把一次性内容写入长期缓存
  input: "本次用户的问题和实时业务数据",
  prompt_cache_options: {
    // 跨小时复用时选择 12h；短间隔调用可继续使用默认 30m
    ttl: "12h"
  }
});

什么时候值得为 12 小时缓存付费

先画出真实请求间隔：如果同一工作区的共享前缀通常在 5 分钟内重复，30 分钟已经足够；如果上午建立上下文、下午继续处理，12 小时才有意义。还要确认前缀达到模型的最小可缓存长度，GPT-5.6 及更新模型的可见输入前缀门槛是 1024 token。

成本上，第一次写入 12 小时前缀会比 30 分钟写入贵，但后续缓存读取仍按该模型的 cached input 价格计费。实际判断不能只看一次请求：至少按一周记录普通输入 token、cached_tokens、cache_write_tokens、延迟和请求间隔，再比较“少处理的输入 token”是否覆盖较高的写入费用。

迁移时要盯住 usage，而不是只看响应速度

Responses API 的 usage 会提供缓存读取和写入信息。支持新字段的模型还会在 cache_write_tokens_details 中拆出 ttl_30m_tokens 与 ttl_12h_tokens。记录这些字段后，才能识别“看起来启用了 12h，实际上每次都在重写”的情况。

• 命中率：用 cached_tokens / input_tokens 做同一工作区、同一模型的趋势指标。
• 写入摊销：分别统计 30m 和 12h 写入 token，不要把 cache_write_tokens 再重复加一次。
• 前缀稳定性：工具顺序、模型、输出 schema 或动态时间字段改变时，单独标记一次回归。
• 数据边界：12h 不是删除期限，涉及敏感资料时仍按组织的数据留存设置决策。

建议先给一个低风险工作流配置 12h，保留 30m 作为对照组，观察跨小时复用是否真实发生；确认成本和命中率后再扩大流量。

相关问题

12 小时缓存会让输出变成固定答案吗？

不会。缓存复用的是输入前缀的计算状态，模型仍会为当前输入生成新响应，命中缓存也不保证两次输出完全相同。

12h 会让缓存到点自动删除吗？

不会。它是最小缓存寿命选项，平台可能保留更久，也不改变最大数据留存策略。

旧代码里的 prompt_cache_retention 要不要直接改成 12h？

不要直接替换。对支持新字段的 Responses API 模型，应迁移到 prompt_cache_options.ttl；早期模型仍按其支持的 prompt_cache_retention 规则处理，先查模型差异再改。

怎样确认 12h 真的带来收益？

把请求间隔、cached tokens、两种写入 token、普通输入 token、延迟和总输入成本放到同一张报表中，用对照流量判断，而不是只看单次响应时间。

迁移清单

1. 确认模型支持 prompt_cache_options.ttl 和 12h。
2. 固定稳定前缀，移除其中的时间戳和用户特有内容。
3. 按实际调用间隔选择 30m 或 12h。
4. 记录缓存读写明细，核算一周的真实成本。
5. 完成灰度回归后，再决定是否全量启用。