本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
用于加快模型推理速度的提示缓存
提示缓存是一项可选功能,可以在 Amazon Bedrock 上与受支持的模型配合使用,来降低推理响应延迟和输入词元成本。通过将部分上下文添加到缓存中,模型可以使用缓存来跳过输入的重新计算,从而允许 Bedrock 共享计算节省的费用并降低响应延迟。
当您的工作负载包含冗长而重复的上下文,并且这些上下文频繁用于多个查询时,提示缓存会有所帮助。例如,如果您有一个聊天机器人,用户可以在其中上传文档并询问有关文档的问题,那么每次用户提供输入时,模型都需要处理文档,这可能非常耗时。利用提示缓存,您可以缓存文档,这样后续包含该文档的查询就无需重新处理文档。
使用提示缓存时,从缓存读取的词元将按较低费率计费。根据模型的不同,写入缓存的词元的费率可能高于未缓存输入词元。所有未从缓存读取或写入缓存的词元都按该模型的标准输入词元费率计费。有关更多信息,请参阅 Amazon Bedrock 定价
工作原理
如果您选择使用提示缓存,Amazon Bedrock 会创建一个由缓存检查点组成的缓存。缓存检查点是一些标记,用于定义您希望缓存的提示的连续分段(通常称为提示前缀)。这些提示前缀在不同请求之间应保持静态,如果后续请求中对提示前缀进行了更改,则会导致缓存丢失。
缓存检查点具有最小和最大词元数,具体取决于您使用的特定模型。仅当您的提示前缀总数达到最小词元数时,您才能创建缓存检查点。例如,每个缓存检查点至少Claude 3.7 Sonnet需要 1,024 个令牌,而、、Claude Opus 4.5Claude Opus 4.6Claude Haiku 4.5、和每个缓存检查点至少Claude Sonnet 4.5需要 4,096 个令牌。这意味着,对于最小值为 1,024 个令牌的模型,第一个缓存检查点可以在 1,024 个令牌之后定义,第二个缓存检查点可以在 2,048 个令牌之后定义。如果您在未达到最小词元数时尝试添加缓存检查点,推理仍然会成功,但系统不会缓存您的前缀。缓存有一个 Time To Live (TTL),它会在每次成功命中缓存时重置。在此期间,缓存中的上下文将被保留。如果在 TTL 时段内没有发生缓存命中,缓存将过期。许多型号支持 5 分钟的 TTL。查看您的型号的型号卡片以查看确切的 TTL 条件。
每当您在 Amazon Bedrock 中使用受支持的模型进行模型推理时,您都可以使用提示缓存。以下 Amazon Bedrock 功能支持提示缓存:
- Converse 和 API ConverseStream
-
您可以与模型进行对话,并在提示中指定缓存检查点。
- InvokeModel 和 InvokeModelWithResponseStream API
-
您可以提交单独的提示请求,在请求中启用提示缓存并指定缓存检查点。
- 使用 Cross-region 推理提示缓存
-
提示缓存可以与跨区域推断结合使用。 Cross-region 推理会自动选择您所在地理 AWS 区域内的最佳区域来满足您的推理请求,从而最大限度地提高可用资源和模型可用性。在需求高峰期,这些优化可能会导致缓存写入量增加。
- Amazon Bedrock 提示管理器
-
创建或修改提示时,您可以选择启用提示缓存。根据模型,您可以缓存系统提示、系统指令和消息(用户和助手)。您也可以选择禁用提示缓存。
注意
仅按需推理端点支持提示缓存。批量推理 API 不支持该功能。
API 为您提供了高度灵活性以及对提示缓存的精细控制。您可以在提示中设置单独的缓存检查点。您可以通过创建更多缓存检查点来增加缓存内容,创建的数量上限为特定模型允许的最大缓存检查点数量。有关更多信息,请参阅 支持的模型、区域和限制。
支持的模型、区域和限制
所有支持型号的 AWS 区域均提供提示缓存。要按地区查看型号的可用性,请参阅各型号的地区供货情况。
下表列出了支持的模型及其最小词元数、最大缓存检查点数以及可以使用缓存检查点的字段。
要查看哪些模型支持提示缓存,请参阅模型一览,然后选择您感兴趣的模型。下表一目了然地显示了模型中不存在的模型的提示缓存。
| 模型名称 | 模型 ID | 版本类型 | 每个缓存检查点的最小词元数 | 每个请求的最大缓存检查点数 | 支持的 TTL | 接受提示缓存检查点的字段 |
|---|---|---|---|---|---|---|
Claude Opus 4.5 |
anthropic.claude-opus-4-5-20251101-v 1:0 |
正式发布 |
4,096 |
4 |
5 分钟 1 小时 |
“system”、“messages”和“tools” |
Claude Opus 4.6 |
anthropic.claude-opus-4-6-v1 |
正式发布 |
4,096 |
4 |
5 分钟 |
“system”、“messages”和“tools” |
Claude Sonnet 4.5 |
anthropic.claude-sonnet-4-5-20250929-v1:0 |
正式发布 |
4,096 |
4 |
5 分钟 1 小时 |
“system”、“messages”和“tools” |
Claude Sonnet 4.6 |
anthropic.claude-sonnet-4-6 |
正式发布 |
1024 |
4 |
5 分钟 |
“system”、“messages”和“tools” |
Claude Haiku 4.5 |
anthropic.claude-haiku-4-5-20251001-v1:0 |
正式发布 |
4,096 |
4 |
5 分钟 1 小时 |
“system”、“messages”和“tools” |
Claude Opus 4 |
anthropic.claude-opus-4-20250514-v1:0 |
正式发布 |
1024 |
4 |
5 分钟 |
“system”、“messages”和“tools” |
Claude 3.7 Sonnet |
anthropic.claude-3-7-sonnet-20250219-v1:0 |
正式发布 |
1024 |
4 |
5 分钟 |
“system”、“messages”和“tools” |
Claude 3.5 Sonnet v2 |
anthropic.claude-3-5-sonnet-20241022-v2:0 |
预览 |
1024 |
4 |
5 分钟 |
“system”、“messages”和“tools” |
GPT-5.6 Sol |
openai.gpt-5.6-sol |
正式发布 |
1024 |
4 |
30 分钟 |
|
GPT-5.6 泰拉 |
openai.gpt-5.6-terra |
正式发布 |
1024 |
4 |
30 分钟 |
|
GPT-5.6 露娜 |
openai.gpt-5.6-luna |
正式发布 |
1024 |
4 |
30 分钟 |
|
要在支持的型号(Claude Opus4.5、和Claude Sonnet 4.5)上使用 1 小时 TTL 选项Claude Haiku 4.5,请在缓存检查点中指定该ttl字段。在 Converse API 中,添加"ttl": "1h"至您的cachePoint对象。在 Claude 模型的 InvokeModel API 中,添加"ttl": "1h"至您的cache_control对象。如果未提供任何ttl值,则适用默认的 5 分钟缓存行为。1 小时 TTL 对于运行时间较长的会话或需要长时间维护缓存的批处理场景非常有用。
Amazon Nova 为所有文本提示(包括 User 和 System 消息)提供了自动提示缓存。这种机制可在提示以重复部分开头时降低延迟,即使没有显式配置也是如此。但是,为了实现成本节省和确保更稳定的性能优势,建议选择使用显式提示缓存。
Anthropic 模型的缓存管理
对于 Claude 模型,Amazon Bedrock 提供了简化的缓存管理方法,可减少手动放置缓存检查点时的复杂性。您无需指定确切的缓存检查点位置,只需在静态内容末尾设置一个断点即可使用自动缓存管理。
启用简化的缓存管理后,系统会自动在之前的内容块边界处检查缓存命中情况,从指定的断点开始回溯最多约 20 个内容块。这样,模型就可以从缓存中找到最长的匹配前缀,无需您预测最佳检查点位置。要使用此功能,请在静态内容的末尾且在任何动态或可变内容之前放置一个缓存检查点。系统将自动查找最佳缓存匹配。
为了实现更精细的控制,您仍然可以使用多个缓存检查点(Claude 模型最多支持 4 个)来指定确切的缓存边界。如果您要缓存的内容片段更新频率不同,或者您希望更精确地控制哪些内容会被缓存时,就应该使用多个缓存检查点。
重要
自动前缀检查只会从缓存检查点回溯大约 20 个内容块。如果您的静态内容超出了此范围,建议使用多个缓存检查点,或者重构提示以将最常重复使用的内容置于此范围内。
在 Anthropic 模型中使用缓存管理的最佳实践
如果您有按常规节奏使用的提示(即系统提示的使用频率高于每 5 分钟一次),请继续使用 5 分钟缓存,因为该缓存将继续刷新,无需额外付费。
1 小时缓存最适合用于以下场景:
-
当你的提示使用频率可能低于 5 分钟,但频率高于每小时使用频率时。例如,当代理副代理花费的时间将超过 5 分钟,或者存储与用户的长时间聊天对话时,您通常预计该用户在接下来的 5 分钟内可能不会做出回应。
-
当延迟很重要并且您的后续提示可能会超过 5 分钟时。
-
当你想提高速率限制时,请使用,因为缓存命中率不会从你的速率限制中扣除。
您可以在同一个请求中同时使用 1 小时和 5 分钟的缓存控制,但有一个重要的限制:TTL 较长的缓存条目必须出现在较短的 TTL 之前(即,1 小时的缓存条目必须出现在任何 5 分钟的缓存条目之前)。
来自 OpenAI 的模型缓存管理
亚马逊 Bedrock 上的 OpenAI 模型支持通过终端节点上的响应 API 进行提示缓存。bedrock-mantle缓存行为因模型生成而异。
GPT-5.6 模型
GPT-5.6 Sol (openai.gpt-5.6-sol)、Terra (openai.gpt-5.6-terra) 和 Luna (openai.gpt-5.6-luna) 引入了明确的提示缓存断点,让你可以精确控制缓存提示的哪些部分。这对于代理工作流程特别有用,在这些工作流程中,系统指令、工具定义和参考文件在许多呼叫中重复执行,而只有最新的输入会发生变化。
主要特性:
显式缓存断点-通过添加到
"prompt_cache_breakpoint": {"mode": "explicit"}支持的内容块中来标记可重复使用的提示前缀的确切结尾。缓存模式-设置
prompt_cache_options.mode为控制断点行为:implicit(默认)— 在最新消息上放置自动断点,并使用您提供的任何显式断点。explicit— 禁用自动断点。缓存读取和写入仅使用显式断点。如果不存在显式断点,则请求不使用提示缓存或产生缓存写入费用。
最小前缀长度-每个断点 1,024 个标记。
最少 30 分钟的 TTL — 缓存的前缀在至少 30 分钟内仍可供重复使用,足够覆盖单个代理运行产生的突发呼叫。TTL 通过设置
prompt_cache_options.ttl,默认为。30m缓存写入计费 — 写入缓存的令牌按未缓存的输入令牌费率的 1.25 倍计费。与未缓存的输入令牌相比,缓存读取的计费折扣为 90%。
缓存的令牌不计入速率限制 — 通过提示缓存读取的缓存输入令牌不计入每分钟输入令牌配额。
了解响应
响应中的使用对象包括两个缓存特定的字段:
cached_tokens— 从缓存中读取的输入令牌数量(按缓存读取折扣率计费)。cache_write_tokens— 写入缓存的输入令牌数量(按未缓存的输入令牌费率的 1.25 倍计费)。
当大cached_tokens于零且cache_write_tokens为零时,您的请求与现有缓存条目完全匹配,不会发生新的写入操作,并且可以最大限度地节省成本。
在 GPT 5.6 机型中使用缓存管理的最佳实践
在稳定内容之后放置断点 — 系统指令、工具定义和在两次调用之间不变的参考文档应出现在断点之前。断点之后的内容可以自由更改,而不会使缓存的前缀失效。
将@@
explicit模式用于代理循环 — 当您想要完全控制缓存的内容并希望避免自动断点占用写入槽时。监控
cache_write_tokens— 将缓存写入量与后续缓存读取量进行比较,以了解净成本影响并相应地调整断点位置。
GPT-5.5 和较早的型号
对于之前的 OpenAI 模型 GPT-5.6 (例如openai.gpt-5.5和openai.gpt-5.4),提示缓存是自动的。您无需添加任何特殊参数——系统会自动缓存 1,024 个或更多令牌的符合条件的提示前缀。这些型号的缓存写入不收取额外费用。
主要特性:
自动缓存-无需更改代码。系统会根据精确的前缀匹配自动缓存前缀。
最小前缀长度 — 1,024 个令牌。
无缓存写入费-只有缓存读取按折扣费率计费。
缓存的令牌不计入速率限制 — 通过提示缓存读取的缓存输入令牌不计入每分钟输入令牌配额。
在 GPT-5.5 及更早版本的模型中使用缓存管理的最佳实践
将静态内容(系统提示、工具定义、参考文档)放在提示的开头。
将可变内容(用户特定的输入)放在末尾。
保持具有相同前缀的稳定请求流,以最大限度地减少缓存驱逐次数。
开始使用
以下部分针对通过 Amazon Bedrock 与模型进行交互的每种方法,简要概述了如何使用提示缓存功能。
Converse API 为在多回合对话中实施提示缓存供了先进而灵活的方案。有关各个模型的提示要求的更多信息,请参阅之前的支持的模型、区域和限制部分。
示例请求
以下示例展示在发送到 Converse API 请求的 messages、system 或 tools 字段中设置的缓存检查点。对于给定请求,您可以将检查点放在这些位置中的任何一个。例如,如果要向 Claude 3.5 Sonnet v2 模型发送请求,您可以在 messages 中放置两个缓存检查点,以及分别在 system 和 tools 中放置一个缓存检查点。有关构造和发送 Converse API 请求的更多详细信息以及示例,请参阅使用匡威 API 进行推理。
重要
缓存检查点按以下顺序处理:tools→ system → messages。最小缓存大小是根据所有三个部分的累积令牌进行评估的,而不是根据每个部分的累积令牌进行单独评估。由于这些部分是链接的,因此更改前一节中的内容会使后面部分的缓存失效(例如,修改会使和缓存tools失效)。system messages为了获得最佳缓存命中率,请将稳定内容 (tools,system) 放在变量内容 (messages) 之前,将缓存检查点放在稳定内容之后。
按如下方式指定所需的 ttl 值,如果未指定 ttl 值,则适用 5 分钟缓存的默认行为。
"cachePoint" : { "type": "default", "ttl" : "5m | 1h" }
来自 Converse API 的模型响应包括三个专门用于提示缓存的新字段。cacheReadInputTokens 值表示由于您之前的请求而从缓存中读取的词元数量,cacheWriteInputTokens 值表示写入缓存的词元数量。这些cacheDetails值告诉你写入缓存的令牌数量所使用的 ttl。Amazon Bedrock 根据这两个值向您收取费用,其费率会低于完整模型推理。
重要
启用提示缓存后,该inputTokens字段仅表示未缓存的输入标记(未从缓存中读取或写入缓存的标记)。要计算请求中发送的输入令牌总数,请使用以下公式:
total input tokens = inputTokens + cacheReadInputTokens + cacheWriteInputTokens
默认情况下,当您调用 InvokeModelAPI 时,提示缓存处于启用状态。您可以在请求正文中的任何位置设置缓存检查点,这与前面的 Converse API 示例类似。
有关发送 InvokeModel 请求的更多信息,请参阅使用以下命令提交单个提示 InvokeModel。
对于bedrock-mantle端点上的 OpenAI 模型,您可以使用带有特定于模型生成的提示缓存参数的响应 API。对于 GPT-5.6 模型,您可以使用显式断点控制缓存。在 GPT-5.5早期版本中,缓存是自动的。
GPT-5.6 带有显式缓存断点的示例
以下示例显示了openai.gpt-5.6-sol使用显式缓存断点的响应 API 请求。系统指令被缓存,并在后续请求中重复使用。
{ "model": "openai.gpt-5.6-sol", "prompt_cache_key": "my-app:system-prompt-v1", "prompt_cache_options": { "mode": "explicit" }, "input": [ { "type": "message", "role": "developer", "content": [ { "type": "input_text", "text": "You are a technical support agent. Use the company knowledge base to answer questions. Follow these guidelines: 1. Always cite the relevant documentation section. 2. If unsure, escalate to a human agent. 3. Be concise but thorough...", "prompt_cache_breakpoint": { "mode": "explicit" } } ] }, { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "How do I configure SSO for my organization?" } ] } ] }
GPT-5.5 自动缓存示例
对于 GPT-5.5 及更早的型号,提示缓存是自动的。不需要断点或缓存密钥——只要确保你的提示前缀超过 1,024 个令牌即可。
{ "model": "openai.gpt-5.5", "input": [ { "type": "message", "role": "developer", "content": [ { "type": "input_text", "text": "You are a technical support agent. Use the company knowledge base to answer questions..." } ] }, { "type": "message", "role": "user", "content": [ { "type": "input_text", "text": "How do I configure SSO for my organization?" } ] } ] }
响应
响应包含usage对象中的缓存使用率指标:
{ "id": "resp_abc123", "output": [...], "usage": { "input_tokens": 2048, "output_tokens": 256, "total_tokens": 2304, "input_tokens_details": { "cached_tokens": 1920, "cache_write_tokens": 0 } } }
在此响应中,缓存中提供了1,920个令牌,并且没有写入任何新令牌,这表明缓存已满,可以最大限度地节省成本。
在 Amazon Bedrock 控制台的聊天演练场中,您可以开启提示缓存选项,Amazon Bedrock 会自动为您创建缓存检查点。
按照使用操场在控制台中生成响应中的说明,在 Amazon Bedrock 演练场中开始使用提示。对于支持的模型,提示缓存会在演练场中自动开启。但是,如果不是,请执行以下操作以打开提示缓存:
-
打开配置菜单。
-
打开提示缓存开关。
-
运行您的提示。
在您的输入和模型响应组合达到检查点所需的最小词元数(因模型而异)后,Amazon Bedrock 会自动为您创建第一个缓存检查点。随着您继续聊天,后续每次达到最小词元数时,就会创建一个新的检查点,最多不超过模型允许的最大检查点数。您可以随时选择提示缓存开关旁边的查看缓存检查点来查看缓存检查点,如以下屏幕截图所示。
通过查看演练场响应中的缓存指标弹出窗口,您可以了解每次与模型交互时,从缓存中读取的词元数以及写入缓存的词元数,弹出窗口内容为:
如果您在对话进行中关闭了提示缓存开关,仍可继续与模型聊天。