Amazon Bedrock 现在允许开发者缓存提示词（prompt）的部分内容，对于重复使用静态提示词前缀的应用，这可以将 Token 使用费用降低多达 90%，并将响应延迟缩短高达 85%。

为什么这一变化至关重要

按需运行大语言模型意味着每次向模型发送 Token 都会产生费用。聊天机器人、代码助手和文档搜索工具通常会重复发送相同的系统指令或参考材料，从而增加了开销并减慢了响应速度。

提示词缓存的工作原理

Bedrock 增加了一个“可缓存”（cacheable）标志，开发者可以将其附加到提示词的任何片段上——通常是系统级指令、长背景文档或在会话期间不会改变的工具定义。当请求到达时，Bedrock 会检查标记的片段是否与存储的条目匹配。如果匹配，服务将跳过对该部分的重新编码和重新运行，而是直接从缓存中提取预先计算好的表示形式。

数据表现

  • 输入 Token 成本： 降低多达 90%，因为缓存的前缀在每次调用时不再消耗 Token。
  • 延迟： 提速高达 85%，因为模型无需再为静态部分进行繁重的计算。

最佳适用场景

当提示词包含一个庞大且不变的区块，随后紧跟一个简短且多变的查询时，该功能的效果最为显著。常见模式包括：

  • 在检索增强生成 (RAG) 流水线中，在每个查询前添加检索到的文档。
  • 始终以相同的政策声明或语气设定文本开头的客户支持机器人。
  • 在开发者的代码片段之前加载固定语言工具定义的编程助手。

开发者需要做哪些调整

开发者必须重新排列提示词，使静态内容位于最开头，并且在多次调用中保持字节级的一致性。多变的输入内容紧随缓存的前缀之后。无需切换模型；相同的 Bedrock 端点即可处理请求。

谁能获益，谁需留意

这一优势仅适用于前缀确实保持静态的工作负载。对于会根据用户个性化系统指令或频繁更改上下文的应用，其获益将微乎其微，必须权衡增加的提示词复杂度与微小的收益。

总结： 只要应用能够分离出可复用的提示词前缀，提示词缓存就能为 Bedrock 用户提供一个直接的手段，用以削减 AI 运营成本并缩短响应时间。