View a markdown version of this page

用于加快模型推理速度的提示缓存 - Amazon Bedrock

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

用于加快模型推理速度的提示缓存

提示缓存是一项可选功能,可以在 Amazon Bedrock 上与受支持的模型配合使用,来降低推理响应延迟和输入词元成本。Amazon Bedrock 支持两种类型的提示缓存:隐式提示缓存显式提示缓存。对每种类型的支持因型号和 API 而异。

当您的工作负载包含冗长而重复的上下文,并且这些上下文频繁用于多个查询时,提示缓存会有所帮助。例如,如果您有一个聊天机器人,用户可以在其中上传文档并询问有关文档的问题,那么每次用户提供输入时,模型都需要处理文档,这可能非常耗时。利用提示缓存,您可以缓存文档,这样后续包含该文档的查询就无需重新处理文档。

提示缓存的类型

这两种类型在选择可重复使用的提示内容的方式上有所不同:

Type 工作原理 请求配置
隐式提示缓存 亚马逊 Bedrock 和模型会自动尝试重复使用符合条件的提示前缀。 您的请求中不需要缓存控件或断点。
显式提示缓存 您可以通过添加特定模型的缓存控件或断点来识别可重复使用的提示前缀。 您的请求必须包含模型和 API 支持的缓存控件。

隐式提示缓存

隐式提示缓存会自动尝试重复使用符合条件的提示前缀,而无需在请求中进行缓存控制。将静态内容保留在提示的开头,将动态内容保留在提示的末尾,以增加前缀精确匹配的可能性。

隐式提示缓存是最好的选择。重复相同的提示并不能保证缓存命中率,缓存命中率可能会有所不同。

显式提示缓存

显式提示缓存允许您使用特定模型的缓存控件或缓存检查点来识别可重复使用的提示前缀。缓存检查点是用于定义要缓存的提示的连续子节的标记。请求之间的提示前缀应保持静态。在后续请求中更改提示前缀会导致缓存丢失。

缓存检查点具有最小和最大令牌数,具体取决于模型。仅当您的提示前缀总数达到最小词元数时,您才能创建缓存检查点。例如,每个缓存检查点Claude Opus 5需要至少 512 个令牌,每个缓存检查点至少Claude Sonnet 5需要 1,024 个令牌,每个缓存检查点至少Claude Haiku 4.5需要 4,096 个令牌。最小值累积适用于每个检查点之前的整个提示前缀,包括toolssystem、和messages字段中的内容(如果适用)。缓存检查点之间没有最低要求的令牌数量。对于最少 1,024 个令牌的模型,只要每个检查点之前的总提示前缀包含至少 1,024 个令牌,您就可以定义相隔少于 1,024 个令牌的额外检查点。如果您在总提示前缀满足最小令牌数之前添加缓存检查点,则您的推理仍然会成功,但您的前缀不会被缓存。

缓存具有生存时间 (TTL),每次成功命中缓存时都会重置。在此期间,缓存中的上下文将被保留。如果在 TTL 时段内没有发生缓存命中,缓存将过期。许多型号支持 5 分钟的 TTL。查看您的模型卡以查看确切的 TTL 条件。

显式提示缓存可以控制哪些提示内容符合缓存条件。它不能保证符合条件的请求会导致缓存命中。

缓存代币的计费

对于隐式提示缓存和显式提示缓存,成功从缓存中读取的令牌将报告为缓存令牌,并按模型的缓存读取费率计费。未从缓存中读取的令牌按标准输入令牌费率计费。根据模型的不同,写入缓存的令牌可以以高于标准输入令牌费率的费率计费。有关更多信息,请参阅 Amazon Bedrock 定价页面。

重要

支持提示缓存并不能保证任何请求的缓存命中。检查模型响应中的缓存使用情况字段,以确定令牌是从缓存读取还是写入缓存。

使用支持的模型在 Amazon Bedrock 中运行推理时,可以使用提示缓存。每种提示缓存类型的可用性因型号和 API 而异。可通过以下亚马逊 Bedrock 功能进行即时缓存:

Converse 和 API ConverseStream

您可以与支持的模型进行对话。对于显式提示缓存,请在提示中指定缓存检查点。

InvokeModel 和 InvokeModelWithResponseStream API

您可以向支持的模型提交单一提示请求。对于显式提示缓存,启用提示缓存并指定缓存检查点。

使用推理进行即时 Cross-region 缓存

提示缓存可以与跨区域推理结合使用。 Cross-region 推理会自动选择您所在地理 AWS 区域内的最佳区域来满足您的推理请求,从而最大限度地提高可用资源和模型可用性。在需求高峰期,这些优化可能会导致缓存写入量增加。

Amazon Bedrock 提示管理器

创建修改提示时,您可以选择启用提示缓存。根据模型,您可以缓存系统提示、系统指令和消息(用户和助手)。您也可以选择禁用提示缓存。

注意

仅按需推理端点支持提示缓存。批量推理 API 不支持它。

对于支持显式提示缓存的模型,API 提供对提示缓存的精细控制。您可以在提示中设置单个缓存检查点,并将检查点添加至模型允许的最大值。有关更多信息,请参阅 支持的模型、区域和显式缓存限制

支持的模型、区域和显式缓存限制

对提示缓存的支持因型号和 API 而异。模型卡可识别模型是否支持隐式提示缓存、显式提示缓存或两者兼而有之。提示缓存适用于支持模型的所有 AWS 区域。要按地区查看型号的可用性,请参阅按型号划分的区域可用性

下表列出了支持显式提示缓存的模型及其令牌最小值、最大缓存检查点数和允许缓存检查点的字段。

要查看模型支持哪些提示缓存类型,请参阅模型一览,然后选择您感兴趣的模型。

模型名称 模型 ID 版本类型 每个缓存检查点的最小词元数 每个请求的最大缓存检查点数 支持的 TTL 接受提示缓存检查点的字段

Claude Fable 5.1

anthropic.claude-fable-5-1

正式发布

512

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Mythos 5.1

anthoripic.claude-mythos-5-1

受限

512

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Fable 5

anthropic.claude fable-5

正式发布

512

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Mythos 5

anthoripic.claude-mythos

受限

512

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Mythos Preview

anthropic.claude-mythos-预

受限

4,096

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Opus 5

anthropic.claude-opus-5

正式发布

512

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Opus 4.8

anthropic.claude-opus-4-8

正式发布

1024

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Opus 4.7

anthropic.claude-opus-4-7

正式发布

4,096

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Opus 4.6

anthropic.claude-opus-4-6-v1

正式发布

4,096

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Opus 4.5

anthropic.claude-opus-4-5-20251101-v 1:0

正式发布

4,096

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Sonnet 5

anthropic.claude-sonnet

正式发布

1024

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Sonnet 4.6

anthropic.claude-sonnet-4-6

正式发布

1024

4

5 分钟,1 小时

“system”、“messages”和“tools”

Claude Sonnet 4.5

anthropic.claude-sonnet-4-5-20250929-v1:0

正式发布

1024

4

5 分钟,1 小时

“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”

Claude Haiku 4.5

anthropic.claude-haiku-4-5-20251001-v1:0

正式发布

4,096

4

5 分钟,1 小时

“system”、“messages”和“tools”

GPT-5.6 索尔

openai.gpt-5.6-sol

正式发布

1024

4

30 分钟

prompt_cache_breakpointon input_text input_image、和 bl input_file ock(响应 API)

GPT-5.6 泰拉

openai.gpt-5.6-terra

正式发布

1024

4

30 分钟

prompt_cache_breakpointon input_text input_image、和 bl input_file ock(响应 API)

GPT-5.6 露娜

openai.gpt-5.6-luna

正式发布

1024

4

30 分钟

prompt_cache_breakpointon input_text input_image、和 bl input_file ock(响应 API)

要将 1 小时 TTL 选项用于支持的型号(Claude Fable 5、、Claude Opus 5、Claude Opus 4.8、Claude Opus 4.7、Claude Opus 4.6、Claude Opus 4.5Claude Sonnet 5Claude Sonnet 4.6Claude Sonnet 4.5、和Claude Haiku 4.5),请在缓存检查点中指定该ttl字段。在 Converse API 中,"ttl": "1h"向您的cachePoint对象中添加内容。在 Claude 模型 InvokeModel 的 API 中,"ttl": "1h"向您的cache_control对象中添加。如果未提供任何ttl值,则适用默认的 5 分钟缓存行为。1 小时 TTL 对于运行时间较长的会话或批处理场景非常有用,在这些场景中,您希望延长缓存的维护时间。

Amazon Nova为所有文本提示(包括UserSystem消息)提供隐式提示缓存。当提示从重复的部分开始,没有明确的配置时,这种机制可以提供延迟优势。Amazon Nova在其模型卡中显示为支持显式提示缓存的模型还允许您指定缓存检查点,以更好地控制缓存资格。

提示缓存来自 Anthropic 的模型

在 Amazon Bedrock 上支持提示缓存的 Anthropic 模型支持隐式提示缓存和显式提示缓存。隐式提示缓存会自动尝试重复使用符合条件的提示前缀,而无需在请求中进行缓存控制。

对于显式提示缓存,Amazon Bedrock 提供了一种简化的缓存管理方法,可降低手动放置缓存检查点的复杂性。您无需指定确切的缓存检查点位置,只需在静态内容末尾设置一个断点即可使用自动缓存管理。

启用简化的缓存管理后,系统会自动在之前的内容块边界处检查缓存命中情况,从指定的断点开始回溯最多约 20 个内容块。这样,模型就可以从缓存中找到最长的匹配前缀,无需您预测最佳检查点位置。要使用此功能,请在静态内容的末尾且在任何动态或可变内容之前放置一个缓存检查点。系统将自动查找最佳缓存匹配。

为了实现更精细的控制,您仍然可以使用多个缓存检查点(Claude 模型最多支持 4 个)来指定确切的缓存边界。如果您要缓存的内容片段更新频率不同,或者您希望更精确地控制哪些内容会被缓存时,就应该使用多个缓存检查点。

重要

自动前缀检查只会从缓存检查点回溯大约 20 个内容块。如果您的静态内容超出了此范围,建议使用多个缓存检查点,或者重构提示以将最常重复使用的内容置于此范围内。

在 Anthropic 模型中使用缓存管理的最佳实践

如果你的提示按常规节奏使用(即系统提示的使用频率超过每 5 分钟一次),请继续使用 5 分钟缓存,因为缓存将继续刷新,不收取额外费用。

1 小时缓存最适合用于以下场景:

  • 当您遇到提示的使用频率可能低于 5 分钟,但频率高于每小时时。例如,当代理人副代理花费的时间超过 5 分钟时,或者当您存储与用户的长时间聊天对话时,您通常预计该用户在接下来的 5 分钟内可能不会做出回应。

  • 当延迟很重要时,您的后续提示可能会在 5 分钟后发送。

  • 当你想提高速率限制使用率时,因为缓存命中不会从速率限制中扣除。

您可以在同一个请求中同时使用 1 小时和 5 分钟的缓存控制,但有一个重要的限制:TTL 较长的缓存条目必须出现在较短的 TTL 之前(即,1 小时的缓存条目必须出现在任何 5 分钟的缓存条目之前)。

提示缓存来自 OpenAI 的模型

亚马逊 Bedrock 上的 OpenAI 模型通过响应 API 支持隐式提示缓存。 GPT-5.6 模型还支持显式提示缓存。响应 API 在bedrock-runtimebedrock-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.5openai.gpt-5.4),隐式提示缓存是自动的。您无需添加任何特殊参数。系统会自动尝试缓存 1,024 个令牌或更长时间的符合条件的提示前缀。这些模型的缓存写入不收取额外费用。

主要特性:

  • 隐式提示缓存 -无需更改代码。系统尝试根据精确的前缀匹配自动缓存前缀。

  • 最小前缀长度 — 1,024 个令牌。

  • 无缓存写入费 -仅缓存读取按折扣费率计费。

  • 缓存的令牌不计入速率限制 -通过提示缓存读取的缓存输入令牌不计入每分钟输入令牌配额。

在 GPT-5.5 及早期模型中使用缓存管理的最佳实践

  • 将静态内容(系统提示、工具定义、参考文档)放在提示的开头。

  • 将可变内容(用户特定的输入)放在末尾。

  • 使用相同前缀保持稳定的请求流,以最大限度地减少缓存被驱逐的情况。

开始使用

以下部分针对通过 Amazon Bedrock 与模型进行交互的每种方法,简要概述了如何使用提示缓存功能。

Converse API 为在多回合对话中实施提示缓存供了先进而灵活的方案。有关各个模型的提示要求的更多信息,请参阅之前的支持的模型、区域和显式缓存限制部分。

示例请求

以下示例展示在发送到 Converse API 请求的 messagessystemtools 字段中设置的缓存检查点。对于给定请求,您可以将检查点放在这些位置中的任何一个。例如,如果要向 Claude 3.5 Sonnet v2 模型发送请求,您可以在 messages 中放置两个缓存检查点,以及分别在 systemtools 中放置一个缓存检查点。有关构造和发送 Converse API 请求的更多详细信息以及示例,请参阅使用 Converse API 进行推理

重要

缓存检查点按以下顺序处理:toolssystemmessages。最小缓存大小是根据所有三个部分的累积令牌的总和来评估的,而不是每个部分的单独计算。由于各节是链接的,因此更改前一节中的内容会使后续部分的缓存失效(例如,修改tools会使和缓存失效)。system messages要获得最佳缓存命中率,请在可变内容 (toolssystem) 之前放置稳定内容 (,messages),并在稳定内容之后放置缓存检查点。

按如下方式指定所需的 ttl 值,如果未指定 ttl 值,则适用 5 分钟缓存的默认行为。

"cachePoint" : { "type": "default", "ttl" : "5m | 1h" }
messages checkpoints

在此示例中,第一个 image 字段为模型提供图像,第二个 text 字段要求模型分析图像。只要 content 对象中 cachePoint 前面的词元数达到了模型的最小词元数,系统就会创建一个缓存检查点。

... "messages": [ { "role": "user", "content": [ { "image": { "bytes": "asfb14tscve..." } }, { "text": "What's in this image?" }, { "cachePoint": { "type": "default" } } ] } ] ...
system checkpoints

在此示例中,您将在 text 字段中提供系统提示。此外,您还可以添加一个 cachePoint 字段来缓存系统提示。

... "system": [ { "text": "You are an app that creates play lists for a radio station that plays rock and pop music. Only return song names and the artist. " }, { "cachePoint": { "type": "default" } } ], ...
tools checkpoints

在此示例中,您在 toolSpec 字段中提供工具定义。(或者,你可以调用之前定义的工具。有关更多信息,请参阅使用工具完成 Amazon Bedrock 模型响应。) 之后,您可以添加 cachePoint 字段来缓存该工具。

... toolConfig={ "tools": [ { "toolSpec": { "name": "top_song", "description": "Get the most popular song played on a radio station.", "inputSchema": { "json": { "type": "object", "properties": { "sign": { "type": "string", "description": "The call sign for the radio station for which you want the most popular song. Example calls signs are WZPZ and WKRP." } }, "required": [ "sign" ] } } } }, { "cachePoint": { "type": "default" } } ] } ...

来自 Converse API 的模型响应包括三个专门用于提示缓存的新字段。cacheReadInputTokens 值表示由于您之前的请求而从缓存中读取的词元数量,cacheWriteInputTokens 值表示写入缓存的词元数量。这些cacheDetails值告诉您用于写入缓存的令牌数量的 ttl。Amazon Bedrock 根据这两个值向您收取费用,其费率会低于完整模型推理。

重要

启用提示缓存时,该inputTokens字段仅代表非缓存的输入令牌(未读取或写入缓存的令牌)。要计算请求中发送的总输入令牌,请使用以下公式:

total input tokens = inputTokens + cacheReadInputTokens + cacheWriteInputTokens

当您调用 InvokeModel API 时,默认情况下会启用提示缓存。您可以在请求正文中的任何位置设置缓存检查点,这与前面的 Converse API 示例类似。

Anthropic Claude

以下示例显示如何构建 Anthropic Claude 3.5 Sonnet v2 模型 InvokeModel请求的正文。请注意, InvokeModel 请求正文的确切格式和字段可能因您选择的模型而异。要查看不同模型的请求和响应正文的格式和内容,请参阅基础模型的推理请求参数和响应字段

按如下方式指定所需的 ttl 值,如果未指定 ttl 值,则适用 5 分钟缓存的默认行为。

"cache_control" : { "type": "ephemeral", "ttl" : "5m | 1h" }
body={ "anthropic_version": "bedrock-2023-05-31", "system":"Reply concisely", "messages": [ { "role": "user", "content": [ { "type": "text", "text": "Describe the best way to learn programming." }, { "type": "text", "text": "Add additional context here for the prompt that meets the minimum token requirement for your chosen model.", "cache_control": { "type": "ephemeral" } } ] } ], "max_tokens": 2048, "temperature": 0.5, "top_p": 0.8, "stop_sequences": [ "stop" ], "top_k": 250 }
Amazon Nova

以下示例显示如何构造Amazon Nova模型 InvokeModel请求的正文。请注意, InvokeModel 请求正文的确切格式和字段可能因您选择的模型而异。要查看不同模型的请求和响应正文的格式和内容,请参阅基础模型的推理请求参数和响应字段

{ "system": [{ "text": "Reply Concisely" }], "messages": [{ "role": "user", "content": [{ "text": "Describe the best way to learn programming" }, { "text": "Add additional context here for the prompt that meets the minimum token requirement for your chosen model.", "cachePoint": { "type": "default" } }] }], "inferenceConfig": { "maxTokens": 300, "topP": 0.1, "topK": 20, "temperature": 0.3 } }

有关发送 InvokeModel 请求的更多信息,请参阅使用以下命令提交单个提示 InvokeModel

对于 OpenAI 模型,您可以使用响应API(在bedrock-runtimebedrock-mantle端点上均可用),其中包含特定于模型生成的提示缓存参数。对于 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 演练场中开始使用提示。对于支持的模型,提示缓存会在演练场中自动开启。但是,如果不是,请执行以下操作以开启提示缓存:

  1. 打开配置菜单。

  2. 打开提示缓存开关。

  3. 运行您的提示。

在您的输入和模型响应组合达到检查点所需的最小词元数(因模型而异)后,Amazon Bedrock 会自动为您创建第一个缓存检查点。当您继续聊天时,Amazon Bedrock 可以创建额外的检查点,但不得超过模型允许的最大检查点数量。最小值是根据每个检查点之前的累积令牌数量评估的,而不是自上一个检查点以来添加的令牌数量。您可以随时选择提示缓存开关旁边的查看缓存检查点来查看缓存检查点,如以下屏幕截图所示。

Amazon Bedrock 文本演练场中用于提示缓存的 UI 开关。

通过查看演练场响应中的缓存指标弹出窗口,您可以了解每次与模型交互时,从缓存中读取的词元数以及写入缓存的词元数,弹出窗口内容为: The metrics icon shown in model responses when prompt caching is enabled.

缓存指标框,显示了从缓存中读取和写入缓存的词元数。

如果您在对话进行中关闭了提示缓存开关,仍可继续与模型聊天。