面向中台/平台使能团队的 high-level 落地指南 —— 聚焦 Claude 模型,讲清楚缓存的工作逻辑、成本账、决策取舍与常见坑,便于向业务侧团队做能力赋能。
当同一段"长且重复"的上下文被反复送进模型时,每次都要重新计算,既慢又贵。提示词缓存把这段前缀存起来,后续请求直接复用。
命中缓存的 token 按约 标准输入的 1/10 计费,重复上下文越长、复用越频繁,省得越多。
跳过前缀重算,显著降低首个 token 的响应时间(TTFT),长文档场景体感最明显。
缓存命中的 token 不占用速率限制(rate limit),高并发场景更从容。
长且在多次请求间保持不变的上下文:文档问答、超长系统提示 / 大量少样本示例、多轮对话、Agent 多次工具调用、把整个代码库 / 手册作为背景。共同特征是——前缀稳定、后缀变化。
Bedrock 用"缓存检查点(cache checkpoint)"标记出你希望缓存的连续前缀。请求到来时先比对前缀是否已缓存。
前缀累计 token 未达模型下限时,请求照常成功,但不会真正缓存——这是最隐蔽的"以为省了其实没省"陷阱。
门槛看的是缓存点之前的前缀 token 数(从提示开头到该检查点为止),会跨 tools → system → messages 累加,而非每段单独计。
聚焦每个家族的最新一代模型。门槛与 TTL 支持并不一致,且与 Anthropic 直连 API 的数值可能不同。这张表是选型和调参的基准。
| 家族 | 模型 | Bedrock 模型 ID | 最小缓存 token | 最大检查点数 | 支持 TTL |
|---|---|---|---|---|---|
| Opus | Claude Opus 4.8 | anthropic.claude-opus-4-8 | 1,024 | 4 | 5 分钟 1 小时 |
| Sonnet | Claude Sonnet 5 | anthropic.claude-sonnet-5 | 1,024 | 4 | 5 分钟 1 小时 |
| Haiku | Claude Haiku 4.5 | anthropic.claude-haiku-4-5-20251001-v1:0 | 4,096 | 4 | 5 分钟 1 小时 |
三款模型的可缓存字段均为 system / messages / tools。以上为文档时点数值,上线前请以模型卡(model card)与 Bedrock 定价页为准。
原始文档:Amazon Bedrock User Guide — Prompt caching · Anthropic — Models overview
Bedrock 对 Claude 提供两档控制粒度。先厘清一个常见误解:Bedrock 不支持"顶层全自动缓存",但支持下面的"简化缓存管理"。
只在静态内容末尾放一个检查点。系统会自动向前回看约 20 个内容块,寻找最长可命中前缀,无需你精确预测边界。
适用:大多数场景,尤其是多轮对话逐渐增长时。约束:若静态内容超出约 20 个块的回看范围,需改用多检查点或重排结构。
最多设 4 个检查点,把不同变更频率的内容分层缓存(如:工具定义几乎不变、系统提示每天变、上下文每次变)。
适用:需要对"缓存到哪一层"精确掌控,或存在多档更新节奏的复杂 prompt。
Converse / ConverseStream 用 cachePoint 对象作为检查点;InvokeModel(Claude)用 cache_control 字段。两者都可在 tools / system / messages 中放置。控制台 Playground 打开开关后可自动创建检查点用于试验。
缓存命中率几乎完全取决于 prompt 的排布方式。核心口诀:稳的在前,变的在后,断点压在稳定内容的末尾。
检查点按此顺序链式处理。改动靠前的段落,会让其后所有段落的缓存一起失效——例如改了 tools,system 和 messages 的缓存都作废。因此把最稳定的内容(工具、系统提示)放前面,把每次都变的用户输入放最后。
缓存不是免费的:写入比普通输入更贵,读取则便宜得多。是否划算取决于"写一次能被读多少次"。
| 计费项 | 相对标准输入价 | 说明 |
|---|---|---|
| 普通输入(未缓存) | 1.0× | 基准价 |
| 缓存写入(5 分钟) | ≈ 1.25× | 首次创建缓存,比普通输入略贵 |
| 缓存写入(1 小时) | ≈ 2.0× | 延长存活期,写入更贵 |
| 缓存读取 / 命中 | ≈ 0.1× | 复用缓存,极低价 |
| 输出 token | — | 不受缓存影响,照常计费 |
写入多花约 0.25× 的一次性成本,而每次命中省下约 0.9×。粗略地说:同一段缓存只要被再命中约 1 次以上就开始净赚,命中越多收益越大。反之,若一段昂贵的前缀几乎不被复用(写完就过期),缓存反而略微增加成本——所以只对"确实会被反复读"的内容开缓存。
值得开缓存的信号:①前缀长(达到并远超模型 token 门槛);②在 TTL 窗口内会被多次复用;③前缀在多请求间逐字节稳定。三者同时满足才推荐默认开启。具体单价请以 Bedrock 定价页对应模型为准,本表为倍率量级参考。
TTL 是缓存的存活期,窗口内每次命中都免费续期。默认 5 分钟;部分模型支持 1 小时(写入更贵)。
同一请求里可同时用 1 小时和 5 分钟缓存,但存活更长的检查点必须排在更短的之前——即 1 小时的 cachePoint 要出现在任何 5 分钟检查点之前。
缓存是按 Region 存储的,而 CRIS 会把请求路由到不同 Region。理解两者的相互作用,是保住命中率的关键。
CRIS 是 Bedrock 的托管能力:用一个推理配置文件 ID(inference profile ID)替代普通模型 ID 发起调用,Bedrock 会在配置的多个 Region 间自动路由,以提升吞吐、缓解限流、增强可用性。分两类:
数据在 AWS 骨干网内加密传输、不经公网;推理计算可能发生在其他 Region,但日志等静态数据始终留在源 Region。
缓存写在实际执行推理的那个 Region。正常负载下,CRIS 倾向把同一工作负载路由回同一 Region(尽力而为的亲和性),因此缓存能持续命中。但在高需求 / 流量突增时,为保吞吐会把请求分流到其他 Region——那里没有你的缓存,于是产生额外的 cache write、命中率下降、成本回升。这是官方明确提示的行为,且没有可配置的"强制黏在某 Region"开关。
cacheWriteInputTokens 在流量高峰周期性抬升,基本可判定是被路由到了无缓存的 Region(见下节)。缓存按 AWS 账户 + Region 双重隔离——即使 prompt 完全相同,不同 account 也各自独立存缓存。因此在多账户架构下:
缓存"看起来开了"和"真的命中了"是两回事。上线后必须用指标验证,否则可能长期在按写入价而非读取价付费。
cacheReadInputTokenscacheWriteInputTokenscacheDetails注意:开启缓存后,inputTokens 只统计未缓存部分。总输入 = inputTokens + cacheReadInputTokens + cacheWriteInputTokens。
给业务方最实用的是"我的场景该怎么排 prompt、断点放哪里"。
| 场景 | 缓存什么 | 断点放法 |
|---|---|---|
| 文档 / 知识库问答 | 整篇长文档 / 手册作为前缀 | 文档末尾放一个检查点,用户问题跟在后面(每次变) |
| 多轮对话 | 系统提示 + 历史对话 | 用简化缓存单断点,随对话增长自动向前回看命中 |
| Agent / 工具调用 | 工具定义 + 系统指令 | 工具与系统提示前置各设检查点,迭代调用间稳定命中 |
| 代码助手 | 代码库上下文 + 规范示例 | 把稳定的代码 / 规范前置缓存,当前改动放最后 |
| 大量少样本示例 | 20+ 高质量示例 | 示例集末尾设检查点,真实输入不进入缓存前缀 |
这些是文档里分散、但客户上线后最容易踩的点,建议中台在规范里明确写出。
提示词缓存仅支持按需(on-demand)推理端点,Batch inference API 不支持。做批处理选型时要提前知晓。
缓存是 Region 级的,CRIS 高峰期分流会导致命中率下降与额外写入成本。详见第 08 节的取舍与多账户路由建议。
tools → system → messages 链式处理,改前面必然让后面失效。把易变内容尽量下沉到 messages 末尾。
缓存按 AWS 账户(account)级隔离:同一 account 下的调用可命中共享缓存,跨 account 不共享。涉及数据驻留 / 多租户合规时,这是安全边界的关键。
中台交付给业务团队时,可直接作为验收项逐条打勾。