OpenAI Prompt Caching 上线，API调用成本显著降低

先分享一个好消息：OpenAI 悄然上线了提示缓存（Prompt Caching）功能，其核心目标直截了当——帮助开发者降低成本、缩短延迟。具体如何实现？简而言之，系统会重复利用近期已计算过的输入令牌，这样一来，开发者的 API 调用成本最高可降低 50%，提示处理时间也能显著缩短。

为何突然推出此功能？

原因其实很清晰。许多开发者在构建 AI 应用时，经常在多次 API 调用中反复使用相同的上下文。例如，当你正在编辑一个庞大的代码库，或与聊天机器人进行多轮长对话——这些场景下，重复的上下文几乎成为常态。借助提示缓存，这些重复劳动不再构成成本压力。

可用性与定价

即日起，提示缓存将自动应用于 GPT-4o、GPT-4o mini、o1-preview 和 o1-mini 的最新版本，同时也支持这些模型的微调版本。至于定价，下表一目了然：

模型 | 缓存命中后的成本
GPT-4o | 输入：$1.25/1M tokens（缓存命中）
GPT-4o mini | 输入：$0.075/1M tokens（缓存命中）
o1-preview | 输入：$7.50/1M tokens（缓存命中）
o1-mini | 输入：$0.55/1M tokens（缓存命中）

如何监控缓存使用情况？

对于支持模型的 API 调用，只要提示词超过 1024 个 Token，系统便会自动启用缓存。API 会缓存那些已经计算过的最长前缀——从 1024 个令牌开始，以 128 个令牌为增量逐步扩展。如果开发者重复使用具有共同前缀的提示，OpenAI 会自动应用提示缓存，开发者无需改动 API 集成代码。

那么，如何知晓自己是否用上了缓存？只需关注 API 响应中 usage 字段里的 cached_tokens 值：

usage: {
  total_tokens: 2306,
  prompt_tokens: 2006,
  completion_tokens: 300,
  prompt_tokens_details: {
    cached_tokens: 1920,
    audio_tokens: 0,
  },
  completion_tokens_details: {
    reasoning_tokens: 0,
    audio_tokens: 0,
  }
}

缓存通常在 5-10 分钟不活动后清除，最长保留到缓存最后一次使用后的一小时。因此，若想持续享受优惠，就需要保持频繁调用。

如何高效结构化提示词？

这里有一个关键点：只有提示内完全匹配前缀时，才可能触发缓存命中。想获得缓存收益？方法很简单——将静态内容（如系统指令、示例）放在提示开头，将可变内容（如用户特定信息）放在末尾。这一原则同样适用于图像和工具：它们在不同请求之间必须保持完全一致。

工作原理

缓存是如何运作的呢？简单拆解如下：

1. 缓存查找：系统首先检查你提示的初始部分（即前缀）是否已存在于缓存中。
2. 缓存命中：如果匹配成功，系统直接复用缓存结果，延迟大幅降低，成本也随之缩减。
3. 缓存未命中：若未找到匹配前缀，系统将处理完整提示，处理完成后，该提示前缀会被缓存，供下次使用。

可缓存的内容

• 消息：完整的消息数组，包括系统、用户和 AI 的交互内容，均可被缓存。
• 图像：用户消息中附带的图像（无论是链接还是 base64 编码的数据），也能被缓存。同时发送多个图像也没有问题，但需确保 detail 参数保持一致，因为它会影响图像的标记化处理。
• 工具使用：消息数组和可用的 tools 列表都可以被缓存，有助于快速达到 1024 个令牌的最低门槛。
• 结构化输出：结构化输出模式作为系统消息的前缀，同样可以被缓存。

最佳实践

• 将静态或重复内容置于提示开头，动态且多变的内容放在末尾——这才是省钱提速的关键策略。
• 日常监控缓存命中率、延迟和缓存令牌百分比等指标，以便及时调整提示结构和缓存策略。
• 想提高缓存命中率？可以尝试更长的提示，或选择非高峰时段发起 API 请求。因为高峰时段缓存清理更频繁。
• 那些近期未被使用的提示，系统会自动清理出缓存。为避免缓存丢失，建议保持对相同提示前缀的稳定请求流。

祝愿大家的 AI 应用开发越来越顺畅，成本越来越低！

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：OpenAI Prompt Caching 上线，API调用成本显著降低要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题