Amazon Bedrock 现在为 Claude 4.6 提供提示词缓存 (prompt-caching) 功能，该功能可以缩短生成式 AI 应用的响应延迟并降低推理成本。该功能通过记忆提示词中长达五分钟的静态部分来工作，从而使后续调用能够跳过对该文本昂贵的重新处理过程。
缓存如何融入请求链
当 Claude 4.6 请求到达时，两个层级会协同工作。
模型层 (Model level) – Claude 4.6 在 GPU 显存中维护一个键值 (KV) 缓存。模型第一次解析一段指令块时，会存储生成的内部表示。在后续重用相同指令块的调用中，模型可以直接检索该表示，而无需重新计算。
Bedrock 层 (Bedrock level) – Bedrock 会计算静态提示词片段的指纹 (fingerprint)。如果新请求携带匹配的指纹，Bedrock 会将其直接路由到已经持有缓存状态的 GPU，从而绕过“预热”阶段。
可以将其想象成加载存档，而不是每次都重新开始新游戏。
保持缓存有效的规则
最小 Token 数量 – Claude Sonnet 4.6 要求缓存片段至少包含 1,024 个 Token；Claude Opus 4.6 则需要 4,096 个 Token。任何小于此数值的内容都会被忽略。
五分钟有效期 – 缓存会在五分钟无活动后过期。每次命中都会重置计时器，因此持续不断的调用可以使缓存无限期地保持有效。
提示词顺序 – Bedrock 按顺序读取提示词。静态指令必须首先出现，随后是一个
cachePoint标记，之后才是所有用户生成的消息。即使在标记之前更改单个字符，也会破坏指纹并导致冷读取。
将该功能投入实践
Bedrock Converse API 是入口点。以下是一个展示所需结构的最小 Python 代码片段。
import boto3
bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL_ID = "anthropic.claude-sonnet-4-6"
# Must be >1,024 tokens for Sonnet
BASE_SYSTEM_PROMPT = "Your long instructions here..."
system_configuration = [
{"text": BASE_SYSTEM_PROMPT},
{"cachePoint": {"type": "default"}}
]
conversation_history = []
def run_chat_turn(user_input):
global conversation_history
conversation_history.append(
{"role": "user", "content": [{"text": user_input}]}
)
response = bedrock.converse(
modelId=MODEL_ID,
system=system_configuration,
messages=conversation_history,
inferenceConfig={"maxTokens": 500, "temperature": 0.4}
)
assistant_message = response["output"]["message"]
conversation_history.append(assistant_message)
metrics = response["usage"]
print(f"Read from cache: {metrics.get('cacheReadInputTokens', 0)}")
cachePoint 告诉 Bedrock 不可变片段在哪里结束。在第一次调用后，cacheReadInputTokens 指标应显示非零值，从而确认缓存已被命中。
为什么开发者应该关注
将静态指令与动态用户输入分离，可以将工作负载从昂贵的 GPU 计算周期转移到轻量级的路由步骤。对于聊天机器人、检索增强生成 (RAG) 流水线或任何重复使用相同系统提示词的服务，其结果是更快的回复和更低的计费 Token 数量。在高吞吐量场景下，即使是计算时间的微小减少，也能转化为显著的成本节约。
限制与权衡
只有当提示词片段满足最小 Token 限制且保持不变时，该功能才会发挥作用。频繁调整系统指令或依赖短提示词的应用几乎看不到收益。五分钟的窗口期也意味着，具有长时间闲置间隔的突发流量可能会反复触发冷读取，从而削弱延迟优势。最后，缓存驻留在 GPU 显存中；如果多个模型共享相同的硬件，竞争可能会影响性能，尽管 Bedrock 并未公开这些细节。
后续关注点
- 指标仪表板 – 密切关注
cacheReadInputTokens和整体延迟，以验证缓存是否按预期使用。 - 提示词工程 – 设计既能满足大小阈值又不会使请求臃肿的提示词，是开发者的一项新技能。
- 未来扩展 – 如果 Bedrock 延长缓存时长或放宽 Token 限制，长对话的经济效益可能会进一步提升。
核心结论： 只要能够锁定一个足够大且不可变的提示词，并将调用保持在较短的时间窗口内，提示词缓存就能为 Claude 4.6 用户提供一个切实缩减响应时间和支出的手段。对于任何重复使用相同系统指令的 GenAI 服务，该功能都值得尽早测试。