Amazon Bedrock推理成本优化：四类请求参数如何改变账单
摘要：AWS给出Amazon Bedrock推理计费的工程化拆解：缓存TTL、服务层级、推理强度和maxTokens都会改变实际计费。缓存长TTL在高频复用时可降低读取成本，但写入溢价可能让低流量场景更贵；Flex适合可容忍延迟的批处理；降低推理强度可显著减少输出Token，却可能损害任务质量；maxTokens既能限制失控输出，也会压低并发并引发截断。文中结合实验数据、计费公式、CloudWatch指标与响应元数据，给出可复用的逐项压测和上线校准方法。
缓存TTL不是越长越省
Amazon Bedrock将输入、输出、缓存写入和缓存读取拆成不同计费项；推理Token则计入输出Token。缓存的核心工程目标是复用稳定前缀，包括系统提示、工具定义和长参考上下文。任何前缀变化都会造成缓存未命中并触发新写入，因此应把动态内容放在稳定内容之后，并对频繁变化的提示做版本化。
以文中给出的Claude Sonnet 5与Claude Opus 5费率为例，5分钟缓存写入成本是普通输入Token的1.25倍，1小时写入为2倍，缓存读取仅为0.1倍。设普通输入成本为 (C)，缓存写入成本为 (W)，读取成本为 (R)，请求次数为 (n)，则缓存方案相对无缓存的增量成本可写为：
[ C_{cache}(n) = W + (n-1)R ]
若每次都精确复用前缀且读取会刷新TTL，5分钟缓存在5分钟内的首次复用即可回本；请求间隔超过5分钟时，1小时缓存从每小时第二次请求开始更便宜。反过来，要胜过完全不使用缓存，1小时方案通常至少需要每小时三次请求。最终盈亏平衡点仍取决于具体模型、区域、最低缓存长度和实时费率，不能直接套用示例数字。
多租户系统还要处理数据边界问题。缓存条目按AWS账户和区域隔离，而不是按租户隔离。可在可缓存前缀中加入租户专属SHA-256哈希以减少跨租户命中，但哈希只能实现分区，不能替代授权校验；受监管场景若需要硬隔离，应使用独立AWS账户。提示缓存不支持批量推理，因此需要实时缓存收益的请求不能直接迁入Batch。
Flex服务层级适合后台任务
serviceTier: {"type": "flex"}可把支持该层级的模型请求路由到面向延迟容忍型工作负载的服务层级；default表示Standard，强行发送不支持Flex的模型会返回ValidationException。AWS测试Nova 2 Lite时，200个Standard请求与200个Flex请求处理了相同的输入、输出Token，所有请求均解析到指定层级，延迟差异没有超出可辨识噪声，而当时的Flex公开费率约为Standard的一半。
这说明Flex的主要收益来自价格，而非确定的延迟优势。但该结论不能推广到所有模型、区域和时段。生产环境应设置独立截止时间，记录响应中的实际服务层级和CloudWatch ResolvedServiceTier，并为允许降级的流量配置一次有界回退。不要对所有ValidationException盲目重试，因为请求格式错误也会触发同一异常。
推理强度是质量与Token预算的调节旋钮
支持自适应思考的Claude模型会生成独立的推理Token，并按输出Token计费。文中测试的Claude Sonnet 5和Opus 5默认采用high推理强度，因此从较早模型迁移时，即使请求未设置thinking，也可能突然增加账单。此时maxTokens限制的是思考Token与可见回复的总和，而不只是最终文本。
在Claude Opus 5工具调用智能体测试中，各档位24次运行均得到正确答案，但中位输出Token差异显著：
| 推理强度 | 正确运行 | 中位输出Token | 相对low变化 |
|---|---:|---:|---:|
| low | 24/24 | 936 | 基线 |
| medium | 24/24 | 1,484 | +59% |
| high | 24/24 | 2,521 | +169% |
| xhigh | 24/24 | 2,964 | +217% |
| max | 24/24 | 3,762 | +302% |
不过，24次运行全部成功只能说明该测试未观察到质量下降，不能证明不同档位普遍等价。另一项代码生成负载中，low与high的中位输出Token仅相差约10%，且生成程序在各档位均通过测试，说明收益高度依赖任务难度。
工程上应联合记录OutputTokenCount、调用日志、任务通过率、延迟和实际费用。常规且边界清晰的任务可从high以下开始；若任务处于模型能力边界，节省Token却增加失败和重试次数，并不构成真实降本。
maxTokens同时是费用上限与并发约束
maxTokens限制一次请求最多可生成的输出Token。Amazon Bedrock在请求启动时会从配额中扣除输入Token和完整的maxTokens预算，因此设置过大的上限会减少同一配额下可并发的请求数量，并可能掩盖提示词回归或无限循环。
文中一个直观案例将2,048 Token上限收紧至155：同一冗长提示分别生成2,048和155 Token，节省1,893 Token，但两次响应都因max_tokens停止而遭截断。因此，输出上限不能替代Guardrails，也不适合作为唯一的Responsible AI控制。对于多轮对话或智能体链，一轮截断可能使后续步骤缺少必要状态并连锁失败。
生产标定应按任务类型统计输出Token的P95和P99：P95可更积极地限制费用暴露，但增加截断概率；P99能覆盖更多长尾响应，却需要更高配额。开启自适应思考时必须重新测量，因为思考Token与最终文本共享上限。监控应重点关注stopReason == max_tokens，先排查提示和任务边界，再决定是否提高上限。
推荐的上线方法
为每个模型版本、区域和API建立能力记录，至少包含支持的缓存TTL、服务层级、推理档位、Token计数方式与输出上限。每次只改变一个参数，并沿用同一验证循环：
- 确认目标模型和参数受支持。
- 用代表性请求测量Token、延迟、费用、缓存命中和质量。
- 在响应元数据、CloudWatch指标、调用日志与账单中交叉核验。
- 以任务通过率和完成率约束降本结果，避免只比较Token数量。
- 上线后持续监控缓存未命中、
ResolvedServiceTier、Token异常增长和max_tokens停止原因。
缓存适合稳定前缀的高频复用，Flex适合可接受等待且模型支持的后台任务，低推理强度适合可通过质量回归的任务，maxTokens则应按任务输出分布设置。四项参数共同作用于单位请求成本、延迟和并发上限，任何单独优化都应放回完整业务SLO中评估。
—— 完 ——消息来源：AWS Machine Learning Blog (2026-11-12)
主题标签： #Amazon Bedrock #推理成本优化 #Prompt Caching #Adaptive Thinking #LLMOps
编辑部与事实核查说明：本篇专刊由智客前沿资讯管线根据官方技术公告、学术论文及开源工程文档整理编译，经算法实体核验与人工编辑审校后发布。若发现技术事实纰漏，欢迎依据勘误方针或一键向编辑部发送勘误反馈。
社区整体评论区