使用 Amazon Bedrock 提示缓存优化成本与延迟

判断

这改变的是高频调用团队的开支决定：跑 agent、系统提示很长且每分钟都在重复同一段上下文的，把 prompt caching 打开；一周只调几次的先别改，重复次数不够，省下的输入成本盖不住为缓存多付的那一次。

依据

AWS Machine Learning Blog 在《Optimizing cost and latency with Amazon Bedrock prompt caching》里说，把反复出现的前缀放进缓存，能压输入成本也压延迟（latency，就是从发出请求到收到第一个字之间的等待）。省钱只发生在重复的那一段：同一段系统提示、同一份工具说明被一次次重新送进去，命中缓存的部分才按折扣算，策展点评给的上限是最高省九成输入成本。判断对象因此是调用频次，不是模型能力——一个每天被同一段长提示调用上万次的客服 agent，和一个一周只跑几次的脚本，面对同一个九成，前者能把为缓存多付的那一次摊回来，后者摊不回来。低频调用者的收益有限，不是因为缓存无效，而是因为它省钱的那段上下文在账单里本来就不占几行。