Optimizing cost and latency with Amazon Bedrock prompt caching
AWS Machine Learning Blog 发布文章，介绍 Amazon Bedrock 的 prompt caching 能力：在反复向基础模型发送相同上下文时，输入 token 成本最多可降低 90%。文章基于 Converse API 给出六个实践场景：message content、system prompt、tool definition、mixed TTL、tenant isolation 与 LangChain 集成。
Development
- First ReportOptimizing cost and latency with Amazon Bedrock prompt cachingAWS Machine Learning Blog
- Current Assessment把 prompt caching 作为托管 API 的一等能力，反映推理侧竞争正从单纯模型能力转向单位任务成本与延迟。对平台方而言，缓存可降低重复上下文的算力开销；对应用方而言，成本结构变化可能改变长系统提示与工具定义的使用意愿。证据仅来自 AWS 官方博客，尚无第三方基准佐证 90% 这一上限。Agent Pulse · analysis
AWS 官方博客以「Optimizing cost and latency with Amazon Bedrock prompt caching」为题，说明 Bedrock 的 prompt caching 在重复发送相同上下文时可将输入 token 成本最多降低 90%。文章围绕 Converse API 展开六个落地场景：对 message content、system prompt、tool definition 做缓存，使用 mixed TTL 管理不同存活期，通过 tenant isolation 处理多租户隔离，并给出 LangChain 集成方式。证据未披露具体模型、区域可用性或定价数字。
从场景划分看，缓存粒度覆盖消息内容、系统提示与工具定义，说明其设计目标是复用长且稳定的前缀，而非缓存整段对话；mixed TTL 与 tenant isolation 被单列，暗示缓存键需要显式处理过期与租户边界。可验证的下一信号是官方文档是否给出缓存命中判定规则、最小可缓存 token 长度与 TTL 上限。
把 prompt caching 作为托管 API 的一等能力，反映推理侧竞争正从单纯模型能力转向单位任务成本与延迟。对平台方而言，缓存可降低重复上下文的算力开销；对应用方而言，成本结构变化可能改变长系统提示与工具定义的使用意愿。证据仅来自 AWS 官方博客，尚无第三方基准佐证 90% 这一上限。
对使用 Bedrock 构建应用的企业，重复上下文场景下的输入成本与首 token 延迟存在下降空间，尤其利好固定系统提示、多工具定义与多租户 SaaS 形态。但 90% 为上限表述，实际收益取决于命中率与 TTL 设置，需以自身流量做 A/B 计费验证后再纳入成本模型。
若该能力在更多区域与模型上开放，长上下文应用的输入成本模型可能被重估。可观察的下一信号是其他托管推理平台是否跟进同类缓存语义，以及是否出现跨厂商的缓存命中率与计费口径对比。