OpenAI 提示词缓存（2026 年 10 月）：工作原理、价格与 ROI
OpenAI 提示词缓存默认开启：当一个请求的开头前缀与近期某个请求相同（GPT-5.6 及之后的模型要求至少 1,024 个 token）时，OpenAI 会复用已保存的计算结果，并按缓存输入价格对这部分 token 计费，比普通输入便宜约 90–95%。 截至 2026 年 10 月 25 日，在 GPT-5.6 及之后的模型上，你还需要支付一次性的缓存写入费用：默认 30 分钟有效期为输入价格的 1.25 倍，12 小时有效期为 2.5 倍。只要一个前缀在有效期内被复用哪怕一次，开启缓存就已经比发送两次更便宜。
本文介绍 OpenAI 缓存的工作原理、当前模型上的费用、如何通过断点和 TTL 进行控制、如何衡量节省效果，以及它与 Anthropic、Gemini 缓存的对比。所有价格均来自 OpenAI 提示词缓存指南 和 OpenAI API 定价页，核对日期为 2026 年 10 月 25 日。
OpenAI 提示词缓存价格
标准层级价格（每 100 万 token）：
| 模型 | 输入 | 缓存输入（读取） | 30 分钟写入 | 12 小时写入 | 输出 |
|---|---|---|---|---|---|
| gpt-6-astra | $10.00 | $1.00 | $12.50 | $25.00 | $50.00 |
| gpt-6.1-sol | $2.00 | $0.10 | $2.50 | $5.00 | $10.00 |
| gpt-6-luna | $0.10 | $0.01 | $0.125 | $0.25 | $0.50 |
| gpt-5.6-sol | $4.00 | $0.40 | $5.00 | $10.00 | $20.00 |
大多数模型的缓存读取价格是未缓存输入价格的 0.1 倍，GPT-6.1 Sol 为 0.05 倍。Batch 层级将表中所有价格减半，Fast 模式则翻倍。对于 2026 年 3 月 5 日及之后发布的模型，区域数据驻留端点会额外加价 10%。
有一点常被误解：缓存写入价格并不是在输入费用之外额外加收的。 每个输入 token 只计费一次，按未缓存、缓存读取或缓存写入三种价格之一计算。30 分钟写入时，这部分 token 比普通输入贵 25%，之后每次命中只需支付其 10%（或 5%）。
OpenAI 提示词缓存的工作原理
模型读取提示词时，会为每个 token 计算键值（KV）状态。提示词缓存会为可复用前缀（即提示词中保持不变的开头部分）保存这些状态。如果后续请求以完全相同的前缀开头并找到匹配的缓存条目，模型就会跳过重新计算，从而同时降低成本和首 token 延迟。
缓存前缀涵盖 OpenAI 在你的内容发生变化之前渲染的所有内容：隐藏的系统内容、developer 消息、工具定义和对话历史，包括文本、图像、文档和受支持的音频。匹配必须完全一致。只要断点之前有任何变化，例如系统提示词中的时间戳、工具列表顺序调整或换了一张图片，变化之后的所有内容都会未命中。
GPT-5.6 及之后模型的关键规则：
- 最低长度： 前缀至少需要 1,024 个 token 才能被缓存。OpenAI 隐藏的系统 token 不计入其中。
- 断点： 断点标记可写入缓存的前缀结尾。隐式模式（默认）下，OpenAI 会在最新一条符合条件的消息末尾放置断点。显式模式下，你可以用
prompt_cache_breakpoint自行指定位置。 - 每个请求最多四次写入： 每个请求最多可创建四个缓存写入，因此你可以按变化速度不同对内容分层缓存。
- 有效期： 在 Responses API 中将
prompt_cache_options.ttl设为"30m"（默认）或"12h"。两种有效期的缓存读取价格相同。
在 GPT-5.6 之前的模型上，只能使用隐式缓存。你可以通过 prompt_cache_retention 控制保留时间：in_memory 会在大约 5–10 分钟无活动后失效（最长一小时），24h 则可延长至最多 24 小时。未开通零数据保留（ZDR）的组织默认使用 24h，ZDR 组织默认使用 in_memory。在这些旧模型上，稳定的 prompt_cache_key 有助于把相关请求路由到同一个缓存。OpenAI 建议每个 key 控制在每分钟约 15 个请求，流量更大时拆分到多个 key。
什么时候缓存划算
OpenAI 的指南给出了基本算法。按 0.1 倍读取价和 1.25 倍写入价计算，写入一次再复用一次的成本是正常输入价的 1.35 倍，而发送两次是 2 倍。10 个请求（一次写入加九次读取）的成本是 2.15 倍，不使用缓存则是 10 倍。
| 共享前缀的请求数 | 不使用缓存 | 30 分钟缓存 | 12 小时缓存 | 30 分钟缓存节省 |
|---|---|---|---|---|
| 1 | 1.00× | 1.25× | 2.50× | −25% |
| 2 | 2.00× | 1.35× | 2.60× | 33% |
| 10 | 10.00× | 2.15× | 3.40× | 79% |
| 100 | 100.00× | 11.15× | 12.40× | 89% |
只有当请求间隔超过 30 分钟、但前缀仍会被多次复用时，12 小时有效期才有意义，例如一个低流量的内部工具在整个工作日里反复查询同一份大型产品手册。
OpenAI 还说明了何时值得把短前缀填充到最低长度。在 1,024 token 最低门槛、0.1 倍读取价和 1.25 倍写入价下，当原始前缀长度超过 102.4 + 1,177.6 / N 个 token（N 为请求数）时，填充更便宜。按 10 个请求计算，221 个 token 及以上的前缀扩充到 1,024 个 token 就是划算的。
计算示例
假设一个基于 gpt-6.1-sol 的客服助手每天处理 50,000 个请求。每个请求发送 8,000 token 的稳定前缀（指令、工具定义和政策文档）、500 token 的用户消息，并返回 400 token 的回答。流量平稳，因此 30 分钟缓存每天大约重新写入 48 次。
| 每日费用项 | 不使用缓存 | 使用显式缓存 |
|---|---|---|
| 稳定前缀 | 400M × $2.00 = $800.00 | 写入：0.38M × $2.50 = $0.96；读取：399.6M × $0.10 = $39.96 |
| 用户消息 | 25M × $2.00 = $50.00 | 25M × $2.00 = $50.00 |
| 输出 | 20M × $10.00 = $200.00 | 20M × $10.00 = $200.00 |
| 合计 | $1,050.00 | ≈ $290.92 |
每日账单下降约 72%。两列中的输出费用相同，所以缓存生效后，缩短回答长度就是下一个可调节的杠杆。
为什么这里用显式模式？在隐式模式下，断点位于最新消息的末尾，因此每次请求中不断变化的 500 个用户 token 也会按 1.25 倍写入缓存。在本例中每天会多花约 $12.50。显式模式让缓存写入在稳定前缀之后立即结束，用户消息按普通输入价计费。
如何配置
使用隐式缓存无需修改任何代码。如果想要精细控制，请使用 Responses API。下面的请求将共享指令缓存 12 小时，将会话上下文缓存 30 分钟，当前问题则不缓存：
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6.1-sol",
"prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
"input": [
{ "role": "developer", "content": [
{ "type": "input_text", "text": "<shared instructions and policy docs>",
"prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" } } ] },
{ "role": "user", "content": [
{ "type": "input_text", "text": "<session context>",
"prompt_cache_breakpoint": { "mode": "explicit" } },
{ "type": "input_text", "text": "What is the refund window for annual plans?" } ] }
]
}'
从每个响应中读取缓存字段并记录日志：
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(model="gpt-6.1-sol", input=[...]) # same input as above
d = resp.usage.input_tokens_details
print("input:", resp.usage.input_tokens)
print("cache reads:", d.cached_tokens)
print("cache writes:", d.cache_write_tokens)
hit_rate = d.cached_tokens / max(resp.usage.input_tokens, 1)
print(f"token cache-hit rate: {hit_rate:.0%}")
对于支持 prompt_cache_options 的模型，cache_write_tokens_details 会把写入拆分为 ttl_30m_tokens 和 ttl_12h_tokens。返回的 cached_tokens 会向下取整到 128 的倍数。OpenAI 还提供 Prompt Caching Dashboard 用于跟踪命中率，以及 Prompt Cache Diagnostics 工具用于解释未命中的原因。
提高命中率的提示词设计规则
- 静态内容在前，动态内容在后。 把指令、工具 schema、few-shot 示例和参考文档放在最前面。把用户消息、检索到的片段以及任何带日期或 ID 的内容放在最后。
- 固定工具列表。 修改工具定义会破坏前缀。如果不同请求需要不同工具，请保持定义不变，只改变哪些工具可被调用。
- 追加，而不是改写。 在多轮对话中，把新轮次追加到末尾。总结或编辑之前的轮次会使缓存失效。
- 保持设置稳定。 模型、推理设置和其他请求选项都可能改变渲染后的前缀。对走缓存的流量固定这些设置。
- 注意回退。 如果切换到其他模型或供应商，缓存就要从零开始。我们的 模型回退策略手册 介绍了如何在故障切换时尽量保留缓存局部性。
OpenAI、Anthropic 与 Gemini 提示词缓存对比
缓存无法在供应商之间迁移，机制和价格各不相同：
| OpenAI（GPT-5.6+） | Anthropic Claude | Google Gemini | |
|---|---|---|---|
| 默认 | 自动 | 通过 cache_control 选择开启（自动或按块） |
Gemini 2.5 及更新模型自动隐式缓存 |
| 最低前缀 | 1,024 token | 当前模型 512 token | Gemini 4 Argon 和 3.8 Flash 为 4,096 token |
| 写入成本 | 1.25×（30 分钟）或 2.5×（12 小时） | 1.25×（5 分钟）或 2×（1 小时） | 隐式缓存无写入费；显式缓存另收按小时计的存储费 |
| 读取成本 | 0.1×（GPT-6.1 Sol 为 0.05×） | 0.1×（Opus 5.5 和 Sonnet 5.5 为 0.05×） | 例如 Gemini 4 Argon 为 $0.10，对比输入价 $2.00 |
| 用量字段 | cached_tokens、cache_write_tokens |
cache_read_input_tokens、cache_creation_input_tokens |
total_cached_tokens |
来源：Anthropic 提示词缓存文档、Claude API 定价、Gemini 上下文缓存 和 Gemini API 定价，均核对于 2026 年 10 月 25 日。Gemini 4 Argon 仅支持隐式缓存。显式缓存对象可通过 generateContent 在受支持的 Gemini 3 和 2.5 模型上使用，存储按每百万 token 每小时计费（例如 Gemini 3.8 Flash 在 2026 年 12 月 31 日前为 $0.50）。DeepSeek 同样自动缓存，详见 DeepSeek 缓存指南。
七天缓存 ROI 检查
在宣布缓存成功之前，请用真实流量进行衡量：
- 第 1 天： 选择一个共享前缀较长的高流量工作流。按请求记录输入 token、
cached_tokens、cache_write_tokens、输出 token 和延迟。 - 第 2–3 天： 把所有静态内容移到最前面，并移除其中的动态值。对比调整前后的 token 缓存命中率（缓存 token ÷ 输入 token）。
- 第 4–5 天： 如果写入多、读取少，说明流量太稀疏，不适合 30 分钟缓存。可以对稳定层尝试
"12h"，或合并前缀，让更多请求共享它。 - 第 6–7 天： 计算每个被采纳回答的实际成本，而不只是每 token 成本。用户不接受的便宜请求不算节省。
对于稳定的聊天或 Agent 工作负载，合理目标是 token 缓存命中率超过 60%，读取次数至少是写入次数的 10 倍。我们的 LLM API 可观测性指南 和 token 用量看板指南 介绍了如何搭建这些视图。
Flatkey 的作用
Flatkey 是兼容 OpenAI 的路由服务，一个 key、一份余额即可调用 OpenAI、Claude、Gemini、DeepSeek、Qwen 等模型。供应商缓存仍遵循各家规则，因此如果想要命中缓存，请让每个模型的提示词保持稳定，避免每次请求都轮换模型。可以从 路由快速上手 开始，在 Flatkey 定价 查看实时价格，并参阅我们的 AI API 成本优化指南 了解其他降本方法。
常见问题
OpenAI 提示词缓存是自动的吗？
是的。受支持的 OpenAI 模型默认开启提示词缓存，无需修改代码即可命中缓存。在 GPT-5.6 及之后的模型上，你可以切换到显式模式，用 prompt_cache_breakpoint 指定断点。
OpenAI 提示词缓存能省多少钱？
在大多数当前模型上，缓存输入价格是正常输入价的 0.1 倍，GPT-6.1 Sol 为 0.05 倍，即缓存部分享受 90–95% 的折扣。总体节省取决于每个提示词中共享前缀的占比以及复用频率。
缓存的最低提示词长度是多少？
GPT-5.6 及之后的模型为 1,024 个 token。更早的模型因请求设置而异。更短的前缀会正常处理，不会报错。
OpenAI 提示词缓存能保留多久？
在 GPT-5.6 及之后的模型上，条目默认至少保留 30 分钟；若将 ttl 设为 "12h"，则至少保留 12 小时。在更早的模型上，in_memory 会在约 5–10 分钟无活动后失效（最长一小时），24h 最多可保留 24 小时。
提示词缓存能降低延迟吗？
能。复用缓存前缀可以跳过重新计算，从而缩短首 token 时间，长提示词尤其明显。
写入缓存需要付费吗？
在 GPT-5.6 及之后的模型上需要：30 分钟写入为输入价的 1.25 倍，12 小时为 2.5 倍。该费用替代这些 token 的普通输入费用，而不是额外叠加。
什么是 prompt_cache_key？
这是一个可选参数，用于把相关请求分组，使其路由到同一个缓存。在 GPT-5.6 之前的模型上，它可以提高命中率；OpenAI 建议每个 key 每分钟约 15 个请求。
参考来源
- OpenAI 提示词缓存指南（核对于 2026 年 10 月 25 日）
- OpenAI API 定价（核对于 2026 年 10 月 25 日）
- Anthropic 提示词缓存（2026 年 10 月）
- Claude API 定价（2026 年 10 月）
- Gemini 上下文缓存（2026 年 10 月）
- Gemini API 定价（2026 年 10 月）
- DeepSeek 上下文缓存（2026 年 10 月）
