如何跨 OpenAI、Anthropic 和 Gemini 设计缓存感知 LLM 提示

只有当相同的令牌在正确的位置重复使用足够长的时间并且在您实际调用的提供程序语义下时，提示缓存才会有帮助。团队经常错过这种好处，因为他们将缓存视为模型功能而不是请求架构问题。他们将时间戳放在每个提示的顶部附近，将特定于请求的检索结果与可重用的工具架构交错，或者针对一个提供程序进行优化，同时默默地增加另一个提供程序的成本。

实际的解决方法是将提示缓存作为网关请求编译器的一部分。网关应将稳定的提示材料与易失的请求材料分开，编译特定于提供商的缓存指令，并通过可缓存前缀测量成本和延迟。这在多模型环境中最为重要，其中 OpenAI、Anthropic 和 Gemini 公开不同的缓存行为、记帐字段、TTL 和设置成本。

从可缓存单元开始，而不是提供程序

可重用单元通常不是整个提示。它是由许多请求共享的提示材料组成的前缀或上下文对象。在生产企业 LLM API 中，该材料通常包括平台政策、组织政策、应用说明、工具定义、响应格式规则、编码代理说明或静态语料库指南。

易失部分是根据请求更改的材料：用户的当前任务、请求 ID、时间戳、对话尾部、新检索的 RAG 段落、帐户特定数据和一次性工具结果。如果不稳定内容出现在稳定内容之前，则可能会破坏前缀重用或强制提供程序将大提示视为新提示。

事实：提供程序实现有所不同。 OpenAI 文档提示缓存作为共享前缀的重用，并带有缓存令牌记帐。其公开提示缓存文章称，自动缓存从 1,024 个令牌前缀开始，并以 128 个令牌增量增长，并且缓存条目通常会在不活动 5 到 10 分钟后以及上次使用后一小时内被清除。 Anthropic 记录显式缓存断点，并建议将 cache_control 放置在最后一个共享块上，例如系统提示或工具定义。 Gemini 将上下文缓存记录为一项付费功能，并在缓存操作和使用缓存的生成调用的使用元数据中返回缓存令牌计数。

建议：在将任何内容映射到提供程序 API 之前，围绕稳定块和易失性块设计内部提示表示。

编译从最稳定到最易失的请求

A缓存感知请求编译器应该对材料进行排序，以便最大的可重用部分出现在特定于请求的部分之前。实用的默认顺序为：

1. 平台安全和合规性政策。
2. 组织或租户政策。
3. 应用程序角色和任务说明。
4. 工具架构和工具使用规则。
5. 静态知识或长期参考材料。
6. 对话历史记录轮流重复使用。
7. 检索的段落或其他请求特定的上下文。
8. 当前用户任务。
9. 仅此调用所需的临时元数据。

此顺序并非普遍真理。当指令发生变化时，某些提供商或模型可能会做出不同的反应。政策优先级和行为质量仍然很重要。将缓存感知排序视为受控更改：在更改布局之前和之后运行提示回归测试。

内部提示块示例

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

编译器可以在渲染稳定前缀后对其进行哈希处理。该哈希成为缓存分析的连接键：模型、租户、应用程序、可缓存前缀哈希、提示版本、TTL 选择、未缓存的输入令牌、缓存的输入令牌、可用的缓存写入令牌、输出令牌、延迟和最终成本。

使用提供程序适配器而不是单一缓存假设

单个“启用缓存”标志对于多提供程序操作而言过于模糊。网关应公开一项内部缓存策略，并将其编译为特定于提供程序的行为。

OpenAI 适配器

对于 OpenAI，针对重复的共享前缀和使用情况统计进行优化。请求编译器应将稳定的材料保留在前面，并避免第一个可缓存范围内的微小差异。跟踪来自提供商使用字段的缓存输入令牌。如果可用，还可以跟踪缓存写入令牌，以便成本分类帐可以比较缓存创建和重用。

由于缓存是面向前缀的，因此重要的操作任务是防止前缀漂移。人类看来相同的两个提示可能会有所不同，因为时间戳、构建 ID、随机工具顺序或租户个性化是在顶部附近呈现的。

Anthropic 适配器

对于 Anthropic，编译显式缓存断点。将 cache_control 放在应与后续请求共享的最后一个块上。好的候选者是大型系统指令、工具定义或稳定的参考上下文。较差的候选者包括一次性用户消息、当前任务负载或特定于请求的 RAG 代码段。

事实： Anthropic 记录了默认的 5 分钟缓存持续时间和额外收费的 1 小时缓存持续时间。这使得 TTL 选择成为一个经济决策。长缓存对于交互式编码代理、多步骤文档审查或支持轮流之间暂停的副驾驶来说很有意义。对于低重复次数的一次性任务来说可能会造成浪费。

Gemini适配器

对于Gemini，将上下文缓存视为一项资源决策。当预期重用证明设置和存储成本合理时，创建缓存内容，然后从生成调用中引用该缓存。这与仅依赖自动前缀缓存不同。适配器应拥有缓存生命周期、TTL、元数据和清理策略。

Gemini 式上下文缓存通常最适合许多请求将重复使用的大型、稳定上下文：冗长的策略手册、静态产品目录摘录、固定的编码代理工具环境或针对同一文档集反复提出问题的审核工作流程。

衡量缓存经济性，而不仅仅是命中速率

缓存命中率很有用，但这还不够。微小前缀的高命中率可能节省很少。非常大的政策和工具前缀的较低命中率可能更重要。某些提供程序会公开缓存写入或设置成本，如果重用率较低，这些成本可能会抵消节省的费用。

在提供程序公开这些字段或网关可以估计这些字段时，捕获这些字段：

• 提供程序和模型。
• 租户、应用程序、环境和 API 密钥身份。
• 提示模板版本和可缓存前缀hash.
• TTL 政策或缓存持续时间。
• 未缓存的输入令牌。
• 缓存的输入令牌。
• 缓存写入或缓存创建令牌（如果可用）。
• 输出令牌。
• 第一个令牌的时间和总延迟时间。
• 提供商用于成本计算的标价版本。
• 请求是否属于交互式会话、批处理作业、代理循环或一次性调用的一部分。

然后按工作负载（而不是全局）计算缓存值。支持副驾驶、编码代理、文档审阅者和一次性总结者具有不同的重用模式。汇总应显示节省的资金、花费的缓存写入资金、延迟变化以及前缀哈希的命中率。

一个简单的 ROI 模型就足以开始：

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

此模型故意简单。在启用长期或显式缓存之前，应将其用作门户，而不是作为生产测量的替代品。

为缓存破坏者添加 Lint 规则

大多数缓存故障来自于即时构建习惯，而不是提供程序错误。添加在请求到达提供程序之前运行的网关 lint 规则。

在提示顶部附近标记时间戳。如果模型需要当前时间，请将其放置在可重用前缀之后或将其作为延迟请求块传递。

在系统消息中标记随机 ID。相关 ID 属于元数据或日志，而不是稳定提示前缀。

标记动态排序的工具架构。在渲染之前对工具和架构属性进行确定性排序。即使工具集逻辑上相同，针对每个请求更改顺序的工具列表也可能会破坏重用。

在稳定工具之前标记特定于请求的 RAG。检索到的段落常常是不稳定的。首先放置稳定的说明和工具架构，然后放置检索的段落，除非提示测试证明需要其他顺序。

在共享策略中标记用户特定的个性化设置。租户政策可以跨租户缓存，但用户偏好设置和当前帐户状态通常不可缓存。

标记模板版本流失。如果每次部署都更改空格、注释或未使用的指令文本，则可缓存前缀哈希会发生更改。谨慎地版本提示模板，避免对大型稳定块进行不必要的编辑。

小心处理 RAG 工作负载

RAG 是团队经常过度缓存的地方。稳定的检索指令、引用规则、工具模式和语料库描述可以重复使用。检索到的段落本身通常是特定于请求的。如果将检索到的段落放在稳定说明之前，则会减少重复使用。如果您在段落不太可能重复时缓存整个上下文，则可能会在没有足够的未来点击量的情况下支付写入或设置成本。

也有例外。法律审查流程、支持工作流程或产品文档助理可能会在一个会话中重复查询同一文档包。在这种情况下，文档上下文的寿命较长的缓存可能会很有用。该决定应取决于预期的重用次数、缓存持续时间、文档上下文的大小以及用户是否倾向于针对同一材料提出多个问题。

建议：将 RAG 上下文分类为以下三种类型之一：静态语料库指导、可重用会话上下文或一次性检索的片段。默认情况下仅缓存前两项。

优化成本之前验证行为

稍后在提示中移动内容可以提高缓存重用，但也可能会更改模型行为。例如，在对话历史记录之后移动工具规则可能会降低其影响。将策略移至检索内容下方可能会削弱指令优先级。如果描述发生变化，标准化架构可能会影响工具选择。

在推出缓存感知布局之前使用回归测试。至少要测试：

• 安全和合规政策的指令优先级。
• 已知任务的工具选择。
• 涉及架构的结构化输出有效性。
• 代表性 RAG 示例的答案质量。
• 重复的延迟和成本轮流。
• 提供商特定的使用情况统计。

对于高风险工作流程，运行影子比较：原始提示布局与缓存感知布局、相同模型、相同输入，并通过人工或自动检查是否存在不可接受的输出更改。如果请求编译器以团队不认可的方式更改业务行为，那么节省成本就没有任何用处。

有选择地选择工作负载

当提示很长且重复时，提示缓存效果最强。好的起点包括具有大型工具架构的编码代理、具有大量策略指令的支持副驾驶、对同一材料重复提问的文档审核流程、大量工具的代理以及具有大型治理块的企业助理。

较弱的候选者包括简短的一次性提示、请求顶部每次都会更改的高度个性化提示、不频繁的管理任务以及输出令牌主导总成本的工作流程。在这些情况下，其他优化可能更重要：更短的提示、更好的检索、模型路由、批处理或更严格的输出限制。

预测：提供程序缓存语义将继续出现分歧。自动前缀缓存、显式断点、付费上下文资源、缓存写入计费和 TTL 定价可能在不同平台上保持不平衡。在网关上集中请求编译和遥测的团队将能够比在应用程序代码中嵌入特定于提供商的缓存逻辑的团队更快地适应。

实施清单

• 创建带有稳定性标签的内部提示块模型：全局、租户、应用程序、工作流、会话和请求。
• 确定性地渲染块，包括工具顺序和架构属性顺序。
• 将易失性字段移出稳定前缀。
• 渲染后计算可缓存前缀哈希。
• 添加提供程序适配器以实现 OpenAI 前缀重用、Anthropic 缓存断点和 Gemini 上下文缓存资源。
• 记录未缓存的输入令牌、缓存的输入令牌、缓存写入令牌，其中可用、输出令牌、延迟、模型、租户、应用程序、前缀哈希和 TTL。
• 构建仪表板，以显示节省的净资金、写入/设置成本、命中率和工作负载延迟。
• 为时间戳、随机 ID、易失性 RAG 放置、动态工具顺序和共享块中的个性化添加 lint 规则。
• 在更改生产之前运行提示行为回归测试布局。
• 首先为高重复工作负载启用缓存，然后根据测量的 ROI 进行扩展。

结论

缓存感知提示设计不仅仅是提示格式设置。它是一种网关功能：确定性渲染、稳定前缀设计、特定于提供者的编译、linting 和成本遥测。受益最多的团队将是那些能够针对每种工作负载回答三个问题的团队：请求的哪一部分真正可重用，该提供商如何对重用进行收费，以及缓存是否在不改变行为的情况下改善了端到端成本或延迟？

从一个高重复工作流程开始。将稳定块与易失性块分开，添加特定于提供商的缓存处理，衡量经济性，然后才能进行概括。该路径避免了常见的失败模式：在不知道缓存功能是否省钱、增加延迟或只是将成本转移到不同会计领域的情况下开启缓存功能。

相关阅读

• 提供商中立的 LLM 可观察性