05 OpenAI 的缓存，自动省心，但控制感弱

OpenAI 的 prompt caching 更偏自动化。只要请求满足条件，系统会自动尝试复用前缀，不需要开发者手动写 cache breakpoint，也没有额外的 cache write 费用。

官方文档里的核心规则是：1024 token 以上的 prompt 自动进入缓存机制，命中依赖 exact prefix match。静态内容放前面，动态内容放后面，这个原则和 Claude 一样。

一个常见的 OpenAI 请求大概是：

[developer / system instructions]
[tools]
[conversation history]
[current user input]

如果 instructions、tools、历史片段保持一致，后面只是用户输入变化，缓存就有机会命中。工具定义顺序、结构化输出 schema、前置指令每轮变化，都会影响缓存效果。

OpenAI 的 usage 字段主要看 cached_tokens：

{
  "usage": {
    "prompt_tokens": 2006,
    "completion_tokens": 300,
    "total_tokens": 2306,
    "prompt_tokens_details": {
      "cached_tokens": 1920
    }
  }
}

cached_tokens 表示这轮输入里有多少 prompt token 命中了缓存。请求低于 1024 token 时，这个字段也会出现，但值是 0。

和 Claude 相比，OpenAI 给开发者的控制更少。Claude 会拆出 cache_creation_input_tokens、cache_read_input_tokens、input_tokens，还可以用 cache_control 管断点和 TTL；OpenAI 主要暴露 cached_tokens，能看命中数量，但很难精确控制哪一段写缓存、哪一段用更长保留时间。

OpenAI 还有一个关键参数：prompt_cache_key。

OpenAI 会根据 prompt 初始前缀的 hash 路由请求。如果提供 prompt_cache_key，它会和前缀 hash 一起影响路由。对共享长前缀的产品流量，这个参数很重要。

比如一个企业应用里，很多用户共享同一套系统提示词、工具定义和策略说明。稳定使用 prompt_cache_key，可以让这些相同长前缀的请求更容易路由到合适的位置。

但粒度要控制。官方文档提到，如果同一个 prefix + prompt_cache_key 组合超过大约每分钟 15 个请求，部分请求可能溢出到其他机器，缓存效果会下降。太细，共享前缀不够集中；太粗，高峰期容易溢出。

缓存保留策略现在也有两个方向：in-memory 和 extended retention。

in-memory 缓存一般在不活跃 5 到 10 分钟后失效，最长大约 1 小时。extended retention 可以保留更久，部分模型最长到 24 小时。配置字段是 prompt_cache_retention：

{
  "model": "gpt-5.5",
  "input": "Your prompt goes here...",
  "prompt_cache_retention": "24h"
}

保留时间更长，不代表稳定命中。exact prefix match 仍然是前提，路由和并发也会影响缓存效果。

cached tokens 仍然计入 TPM rate limits。缓存能降低延迟和输入成本，但不会让 rate limit 计算消失。

所以 OpenAI 缓存的优化重点很明确：

稳定长系统提示词、工具定义、结构化输出 schema
把动态用户信息放到后面
为共享长前缀的产品流量设计 prompt_cache_key
观察 cached_tokens 占 prompt tokens 的比例
不要把缓存命中和 TPM 限制混为一谈

OpenAI 的优势是接入成本低、自动生效，适合产品化流量。短板是控制感弱：能看到命中了多少，但很难像 Claude 那样精确管理缓存断点和 TTL。