OpenAI 12小时 Prompt Caching 完整教程：Responses API 缓存配置、Token 价格、命中率与成本优化

一、OpenAI API 新增 12 小时提示词缓存

2026 年 10 月 20 日，OpenAI 在开发者平台更新日志中宣布，Responses API 正式增加可选的 12 小时 Prompt Caching。

这一功能面向需要重复使用大段相同提示词的开发者，尤其适合长上下文 AI Agent、企业知识处理和复杂工具调用系统。

在传统 API 调用中，应用可能每次都要向模型提供相同的系统指令、工具定义和业务背景。

例如，一个企业 AI Agent 每次执行任务，都需要读取固定的操作规则、数据结构说明和内部知识材料。

即使这些内容没有变化，模型也可能需要重复完成相应的输入处理。

Prompt Caching 则尝试复用此前计算得到的缓存状态，减少重复计算。

OpenAI 此次增加的 12 小时缓存，能够让符合条件的共享上下文在较长时间间隔内继续具备缓存读取资格。

但开发者需要理解一个重要变化：

12 小时缓存的写入价格更高，只有在复用次数足够多时，才可能带来更明显的经济收益。

它不是自动让全部 API 费用下降，也不是把模型上下文窗口扩展到 12 小时。

二、Prompt Caching 的工作原理是什么？

当语言模型接收一段输入时，需要对输入 Token 进行计算，并形成供后续推理使用的中间状态。

其中，Key-Value Cache 通常简称 KV Cache。

KV Cache 可以帮助模型在处理后续 Token 时复用之前的部分计算结果。

OpenAI Prompt Caching 的核心思想，是保存可复用提示词前缀对应的计算状态。

假设一个应用包含以下内容：

第一部分是固定系统指令。

第二部分是稳定的工具定义。

第三部分是业务知识说明。

第四部分才是用户当前提出的问题。

如果多个请求的前三部分保持一致，就有机会通过 Prompt Caching 复用这些内容。

模型仍然需要处理新问题，并生成新的回答。

因此，缓存并不意味着模型直接复制上一次答案。

它复用的是符合条件的输入计算状态，而不是最终回答文本。

OpenAI 官方也明确指出，Prompt Cache 保存的是 KV 张量，并非简单保存一份可供检索的普通文本副本。

三、30 分钟与 12 小时缓存有什么区别？

对于 GPT-5.6 及之后支持该机制的模型，OpenAI 在 Responses API 中提供两种主要缓存生命周期。

30m 是对应新机制的默认配置。

它更适合连续进行的对话和短时间内反复执行的 Agent 任务。

12h 则适合上午、下午和晚上都需要调用的稳定系统背景。

例如，一个客服 Agent 每隔两小时处理一批用户请求，但所有请求使用相同的业务规则。

在这种情况下，12 小时缓存可能减少重复写入的次数。

不过，官方所说的生命周期是最短保留期限，并不意味着 OpenAI 必然在期限结束的一刻立即删除缓存。

另外，12 小时并不是模型处理一次任务的最长运行时间，也不是系统承诺缓存百分之百命中的时间。

四、缓存写入的 2.5 倍价格如何理解？

这是此次更新最容易产生误解的地方。

OpenAI 官方写入倍率是总计费倍率，不是普通输入价格之外另行加收的附加费用。

假设某个模型普通输入价格为每百万 Token 1 美元。

那么在这一假设下：

普通输入价格为 1 美元。

30 分钟缓存写入价格为 1.25 美元。

12 小时缓存写入价格为 2.50 美元。

这里的 2.50 美元已经是缓存写入的完整价格，不需要再次加上 1 美元普通输入费用。

需要注意，上述每百万 Token 1 美元只是为了说明计算方法，并不代表所有 OpenAI 模型的实际定价。

不同模型的输入、输出和缓存读取价格可能不同。

开发者应使用所选模型当前的官方价格重新计算。

五、缓存读取能够节省多少费用？

OpenAI 官方文档显示，对于支持新缓存机制的大部分相关模型，缓存读取费用为普通输入 Token 价格的 10%。

GPT-6.1 Sol 则可以达到普通输入价格的 5%。

如果普通输入价格假设为每百万 Token 1 美元，那么对应缓存读取理论费用分别为：

需要强调，缓存读取优惠适用于实际命中的 Token。

如果请求中的大部分内容没有命中缓存，整体费用未必明显下降。

因此，真正决定经济收益的是缓存写入成本、命中量以及后续复用次数。

六、12 小时缓存的盈亏平衡点怎么算？

为了方便开发者理解，我们构造一个纯理论计算案例。

假设某段稳定提示词包含 10,000 个 Token。

普通输入价格为每百万 Token 1 美元。

缓存读取按照普通输入的 10% 计算。

所有后续请求均能完整命中这 10,000 个 Token。

在这种理想情况下，结果如下：

根据该假设，使用 12 小时缓存后，如果完整前缀能够复用三次，就开始低于完全不使用缓存时的输入处理费用。

但这个示例没有考虑缓存未命中、额外动态输入、输出 Token 和其他工具费用。

而且，实际业务还需要比较 30 分钟缓存方案。

如果请求连续发生在较短时间内，30 分钟缓存的低写入成本通常更有优势。

因此，不能简单得出所有请求都应该使用 12 小时缓存的结论。

七、为什么连续聊天更适合 30 分钟缓存？

假设用户在十分钟内连续与 AI 编程 Agent 交互十次。

这十次请求都复用相同的项目背景。

由于调用间隔很短，30 分钟缓存可能已经足够。

其初始写入价格只有普通输入的 1.25 倍。

后续相同前缀命中缓存时，同样能够享受对应缓存读取价格。

如果在这种场景中改用 12 小时缓存，可能只是增加初始写入成本，而没有带来必要的额外生命周期收益。

因此，OpenAI 建议对于短时间重复的 Agent 步骤优先考虑 30m。

只有稳定资料需要跨越较长时间间隔重复使用时，才值得进一步评估 12h。

一个实用原则是：

按照实际复用间隔选择缓存生命周期，而不是默认认为时间越长越好。

八、如何通过 Responses API 启用 12 小时缓存？

对于支持新缓存参数的模型，可以通过 prompt_cache_options.ttl 指定生命周期。

例如：

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6.1-sol",
    prompt_cache_options={
        "ttl": "12h"
    },
    input=[
        {
            "role": "developer",
            "content": (
                "这里放置需要重复使用的稳定业务规则、"
                "工具说明和其他共享上下文。"
            )
        },
        {
            "role": "user",
            "content": "请整理今天的异常请求类型。"
        }
    ]
)

print(response.output_text)

上述代码展示请求参数的配置方法，未使用真实 API Key 执行。

还需要注意，示例中的提示词较短，实际可能达不到缓存的最低长度要求。

OpenAI 官方文档指出，支持新机制的模型通常要求可缓存前缀至少达到 1,024 个可见输入 Token。

因此，只有满足相应条件的真实请求才有机会产生缓存读取效果。

不能因为设置了 ttl 就认定每次都会产生缓存命中。

九、显式缓存断点有什么作用？

除了隐式缓存，OpenAI 还提供显式缓存断点。

显式模式允许开发者决定哪些上下文前缀需要建立缓存。

例如，一个企业 Agent 同时包含长期稳定的业务规则和短时间变化的会话上下文。

可以将业务规则设置为 12 小时缓存。

再将较短时间内重复使用的会话信息设置为 30 分钟缓存。

当前用户问题则保持为动态输入。

通过这种设计，可以避免把所有内容都写入较贵的长期缓存。

官方使用的关键参数包括：

prompt_cache_options.mode

以及内容块中的：

prompt_cache_breakpoint

例如，可将长时间稳定的开发者指令设置为独立断点，并指定 ttl: "12h"。

但断点并不是对任意文本片段进行独立缓存。

缓存通常覆盖从提示词开始到对应断点的完整前缀。

因此，断点顺序会影响实际计费。

十、混合缓存为什么要特别注意断点顺序？

假设请求包含三段内容：

第一段是 2,000 Token 的稳定业务规范。

第二段是 3,000 Token 的会话信息。

第三段是当前用户问题。

如果先为第一段设置 12 小时断点，再为前两段设置 30 分钟断点，初次写入时可以分别计算不同生命周期的缓存写入成本。

但如果先为第一段设置 30 分钟断点，再为覆盖前两段的长前缀设置 12 小时断点，那么长断点可能覆盖前面的全部内容。

按照官方规则，重叠写入的 Token 以覆盖它们的最长生命周期计费。

因此，不正确的断点顺序可能导致原本只需要短期缓存的上下文，也被计入长期缓存。

对于多轮 Agent，建议先把长期稳定的资料放在提示词开头，再依次安排短期会话内容与动态问题。

十一、为什么改一个标点都可能影响缓存命中？

Prompt Caching 依赖请求中的稳定前缀。

如果系统指令经常发生变化，就可能破坏可复用前缀的一致性。

例如，开发者每次请求都在系统提示词开头加入当前时间。

这样即使后面的大部分内容相同，也可能因为前缀变化而影响缓存复用。

类似问题还可能发生在动态工具定义、不断变化的 JSON Schema 或不稳定的文档顺序中。

因此，缓存优化应该从提示词结构开始。

建议将固定系统规则放在最前面。

把稳定工具定义放在较前位置。

将经常变化的用户输入放到最后。

对于需要记录时间戳的任务，可以把时间信息放到动态部分，而不是插入长期缓存的固定前缀。

这有助于提高缓存复用机会。

十二、如何查看缓存是否真正生效？

OpenAI Responses API 的使用量数据提供了相关统计字段。

包括：

usage.input_tokens_details.cached_tokens

以及：

usage.input_tokens_details.cache_write_tokens

对于新机制，还可以查看不同生命周期的写入数量。

例如：

ttl_30m_tokens

ttl_12h_tokens

开发者可以使用这些信息判断：

本次请求有多少输入 Token 按缓存读取计费。

有多少 Token 创建了新的缓存。

长期缓存和短期缓存分别写入了多少。

如果缓存读取 Token 一直为零，应该检查请求前缀是否稳定、长度是否足够，以及是否存在区域或路由差异。

OpenAI 还提供 Prompt Caching Dashboard 和缓存诊断工具。

对于生产系统，建议定期记录缓存读取命中率和实际节省金额，而不只是观察模型输出速度。

十三、缓存命中率应该如何计算？

一种实用的统计方法是：

缓存 Token 命中率 = 缓存读取 Token 总量 ÷ 输入 Token 总量

例如，一个系统当天总共处理 100 万输入 Token。

其中 60 万 Token 通过有效缓存读取完成。

那么缓存 Token 命中率为 60%。

但命中率不能直接等同于费用节省比例。

因为缓存写入本身可能比普通输入更贵。

同时，不同模型的价格也可能不同。

因此，最好同时记录缓存命中率、写入 Token、普通输入 Token 和最终结算费用。

对于拥有多个客户的 API 平台，应按项目、模型和业务类型分别统计。

这样才能避免某些高复用客户掩盖其他业务的低命中问题。

十四、缓存与数据隐私有什么关系？

Prompt Caching 涉及保存可复用的计算状态，因此必须关注数据保留和区域要求。

OpenAI 文档说明，缓存状态可能作为应用状态以加密形式保存在相关计算基础设施中。

同时，不同模型和组织的数据保留策略可能存在差异。

新机制中的 12 小时最短生命周期，不应该被理解为数据将在 12 小时后必然删除。

也不能认为启用缓存就改变了全部 API 数据保留政策。

对于 Zero Data Retention 或具有数据驻留要求的组织，应先核对对应模型的支持范围及当前保留政策。

尤其是涉及内部合同、个人资料和商业秘密的应用，不应该只根据降低费用的需要决定缓存策略。

合规要求必须优先于性能优化。

十五、AI API 聚合平台如何利用 12 小时缓存？

对于多模型 API 平台，缓存可以成为新的性能和费用优化维度。

但首先需要确定目标 Provider 是否支持该参数。

不能把 OpenAI 的 prompt_cache_options 直接转发给所有第三方模型，并默认能够成功运行。

即使多个提供商都支持 Prompt Caching，参数名称、生命周期和计费方式也可能不同。

建议平台建立 Provider 级缓存能力记录。

包括支持的模型、最短缓存长度、支持的 TTL、写入价格、读取价格和使用量字段。

如果平台允许用户显式选择缓存生命周期，应在控制台展示相应费用影响。

对于企业客户，还需要记录最终实际使用的缓存策略。

避免因为透明度不足而引发账单争议。

十六、哪些应用最适合 12 小时缓存？

第一类是企业知识 Agent。

如果固定操作手册和背景说明会被多次复用，长期缓存值得评估。

第二类是 AI 编程工作流。

项目级规则、接口定义和稳定工具说明可能需要在一天内重复使用。

第三类是客服机器人。

常见政策、商品规则和工具定义如果比较稳定，可以成为可复用前缀。

第四类是报告生成系统。

对于每天多次分析同一批资料的工作流，可能减少重复输入处理。

但对于一次性任务、频繁变化的资料和极短提示词，长期缓存未必划算。

十七、开发者常见问题 FAQ

12 小时缓存已经正式开放了吗？

OpenAI 于 2026 年 10 月 20 日宣布在 Responses API 中新增该功能，具体适用于支持相应缓存参数的模型。

12 小时缓存写入为什么是 2.5 倍？

这是 OpenAI 公布的完整写入计费倍率，不是额外附加费用。

缓存读取能便宜多少？

大部分相关模型的缓存读取价格为普通输入的 10%，GPT-6.1 Sol 的对应倍率为 5%。

所有模型都支持 prompt_cache_options.ttl 吗？

不支持。应检查对应模型和 API 文档。

设置 12 小时缓存就一定命中吗？

不能保证。前缀一致性、长度、生命周期和服务路由等因素都可能影响命中。

会不会缓存模型最终回答？

Prompt Caching 的核心是输入计算状态复用，而不是直接存储最终回答供后续复制。

应该选择 30 分钟还是 12 小时？

如果调用集中在短时间内，优先评估 30 分钟；如果稳定资料需要跨越较长时间间隔反复使用，再比较 12 小时的成本收益。

十八、结语：Prompt Caching 需要从缓存功能升级为成本策略

OpenAI 12 小时 Prompt Caching 的发布，为长上下文 Agent 提供了新的优化选项。

它让开发者能够更加灵活地安排稳定上下文的缓存生命周期。

但更长的缓存时间并不自动意味着更低的费用。

由于 12 小时写入价格高于 30 分钟写入，是否值得采用仍取决于复用次数、请求间隔和实际命中情况。

对于开发者而言，最重要的不是开启一个参数，而是合理组织提示词前缀，监控缓存命中并持续核算成本。

对于 AI API 平台，则需要进一步建立模型级缓存支持表、透明计费和实际用量分析机制。

未来 AI Agent 的成本优化，将不仅发生在模型单价层面，还会深入到上下文结构、缓存策略、工具调度和完整任务执行流程。

官方参考资料

1. OpenAI API Changelog https://developers.openai.com/api/docs/changelog

2. OpenAI Prompt Caching 开发指南 https://developers.openai.com/api/docs/guides/prompt-caching

3. OpenAI API 价格说明 https://developers.openai.com/api/docs/pricing

4. OpenAI Responses API https://developers.openai.com/api/reference/resources/responses