OpenAI Prompt Caching：成本砍半，速度翻倍

Prompt Caching 是 OpenAI 推出的一项 API 优化功能。核心逻辑很简单：相同的 prompt 前缀不再重复计算。虽然思路简单，但它在实际使用中带来的成本降低和速度提升非常显著。

为什么要做 Prompt Caching？在一个典型的 AI 应用中，多次 API 调用之间通常共享大量的相同内容。比如一个客服机器人，每次处理用户问题时，都需要把系统 prompt、客服规范、品牌调性说明、已加载的工具定义等重复信息发送给模型。这些内容在每次请求中都是完全一样的，但传统做法是每次请求都重新处理这些重复的 token，从 tokenization 到 embedding 再到 attention 计算，全部重新做一遍。

Prompt Caching 自动检测并缓存重复的 prompt 前缀。当一次 API 请求到来时，系统检查请求的开头部分是否和之前某个已缓存的 prompt 前缀匹配。如果匹配，直接从缓存中读取已经计算好的中间状态，只需要从缓存命中位置开始继续计算新的内容。不匹配的或者匹配度不足的，正常从头计算。

从收益来看，效果很直接。当 prompt 前缀被缓存命中时，该部分 token 的价格降低 50%，同时响应延迟减少约 50%。对于高频调用的 API 应用来说，这个优化能节省大量的运营成本。对于一个每天调用百万次的客服机器人来说，省下的 API 费用相当可观。

哪些场景适合使用 Prompt Caching？最典型的场景是 system prompt 固定的应用。比如 AI 客服，系统 prompt 在应用的生命周期内几乎不变，变的是用户的输入。这种情况下缓存命中率非常高。其次是工具调用频繁的应用，工具定义部分的内容通常也是固定的。还有大段的上下文信息在多次请求中共享的应用。

Prompt Caching 的实现依赖于一些技术细节。缓存是基于输入的 token 序列前缀匹配的，只有完全匹配的前缀才能被缓存命中。这意味着即使 system prompt 中有一个字符的差异，缓存也无法命中。所以 system prompt 需要保持严格一致，任何变化都会导致缓存失效。

多轮对话场景是 Prompt Caching 的理想使用场景。对话历史中较早期的内容通常不会变化，只有最新的消息会变化。这种情况下缓存可以命中历史对话部分，只对最新的消息进行完整计算。随着对话进行，缓存命中的比例会逐渐降低，但整体上仍然能节省大量计算。

Prompt Caching 对长文本场景的收益特别明显。一些应用需要每次请求都附带大量的上下文信息，比如产品文档、政策文件等。这些内容在多次请求之间不会变化，但每次都要重新处理。使用 Prompt Caching 后，这些长文本只需要处理一次，后续请求直接命中缓存。

当然 Prompt Caching 也有局限。如果每次请求的 prompt 内容完全不同，缓存命中率会很低。缓存不是永久有效的，OpenAI 在一定时间后会自动清除缓存。对于不定期使用的低频应用，缓存生效的概率不高。但对于高频使用的生产级应用，这是目前最简单有效的降本手段。

一个实用的建议是合理设计 system prompt 的结构。将不变的内容放在开头，变化的内容放在末尾，这样能最大化缓存命中率。如果系统 prompt 中有部分内容需要变化，尽量把变化部分放在 prompt 的末尾，让不变的部分得到缓存。

Prompt Caching 的技术实现依赖于高效的缓存系统。OpenAI 使用分布式缓存架构，将计算过的 prompt 前缀缓存在多个节点上。当一个请求到来时，系统通过一致性哈希找到缓存所在节点，快速读取缓存结果。缓存的容量和淘汰策略影响实际缓存命中率。缓存容量有限，需要在命中率与存储成本之间做权衡。常用的缓存淘汰策略包括 LRU（最近最少使用）和 TTL（过期时间）。对于生产级应用，建议定期监控缓存命中率，调整缓存配置来优化实际效果。开发者可以通过调整 prompt 结构来最大化缓存收益。将频繁使用的内容放在 prompt 开头，变化的内容放在结尾，能让更多的前缀被缓存命中。如果应用中有多个不同的场景，每个场景使用独立的 system prompt，缓存收益会降低。可以考虑将所有场景共用的内容提取出来放在同一个前缀中。