Bedrock推理降本的四个请求参数

提示词调过了，模型也没换，Amazon Bedrock 的账单仍可能继续涨。AWS 这篇文章把目光放在四个请求级选择上：缓存时长、服务档位、推理强度和 maxTokens。它们分别影响重复输入的计费方式、Token 单价、思考开销和单次输出上限。

对接模型 API 的程序员来说，最有用的不是照抄参数，而是学会核账：先确认模型支持，再改一个变量，用响应元数据、日志、账单和任务通过率判断是否划算。

缓存留多久，要看同一段内容多久用一次

系统指令、工具定义和参考资料反复发送，会产生重复输入成本。显式提示词缓存允许指定生存时间（TTL），但可选时长取决于模型：受支持的 Anthropic 模型提供 5 分钟和 1 小时，受支持的 GPT-5.6 模型最低 TTL 为 30 分钟。

Converse API 用 {"cachePoint":{"type":"default","ttl":"1h"}} 请求 1 小时缓存；受支持的 Anthropic 模型通过 InvokeModel 调用时，把同样的 ttl 放进 cache_control。隐式缓存则由服务尽力复用符合条件的前缀，不保证命中，不能直接套用这里的时长选择。

缓存也有写入成本。原文给出的 Claude Sonnet 5、Claude Opus 5 费率是：5 分钟写入为普通输入的 1.25 倍，1 小时写入为 2 倍，读取为 0.1 倍。

假设每次复用完全相同的前缀，且每次读取都会刷新 TTL：

• 5 分钟内首次复用，5 分钟缓存就能回本。
• 请求间隔超过 5 分钟、但在 1 小时内重复，1 小时缓存在第二次请求时就比反复写入短缓存便宜。
• 与完全不用缓存相比，1 小时缓存需要每小时至少 3 次请求才更便宜。

长缓存是否省钱，取决于复用间隔和写入价格。

实现时，把稳定内容放在动态内容之前，满足模型的缓存检查点最小长度，并使用按需推理；提示词缓存不支持批量推理。检查点按 tools、system、messages 的顺序评估，前面变化会让后面的缓存失效。作者在 Claude Sonnet 5 上调用 6 次，分别修改一次系统提示词和工具定义，两次都出现零缓存读取和重新写入。

多租户还要留心边界：缓存按 AWS 账户和 Region 隔离，不按应用租户隔离。在可缓存前缀前加租户专属 SHA-256 哈希，可以区分缓存条目，但授权必须在组装提示词之前完成。需要硬数据边界时，原文建议每个租户使用独立 AWS 账户。

后台任务可以试 Flex，但必须核对实际档位

后台评测、夜间摘要和历史数据补跑，通常可以接受更宽松的延迟要求。受支持的模型可用 {"serviceTier":{"type":"flex"}} 请求 Flex；Standard 对应的参数值是 default，不是 standard，也可以省略 serviceTier。

原文列出的支持情况很具体：Amazon Nova 2 Lite、OpenAI gpt-oss-120b 支持 Flex，Claude Sonnet 5、Claude Opus 5 不支持。不支持时会返回 ValidationException，不会自动改用 Standard。作者对 Sonnet 5 的请求验证了这一点。

允许回退的应用，可以只捕获「不支持该档位」的错误，再以 default 重试一次。不能对所有 ValidationException 都重试，因为请求格式错误也会触发它。应用层重试要设上限，SDK 的有界重试负责处理限流和暂时性错误。

作者对 Nova 2 Lite 交错发送了 200 次 default 和 200 次 flex 请求。两组输入、输出 Token 总量相同，400 次请求全部落到指定档位，延迟中位数差异小到无法与噪声区分。原文写作时，us-west-2 的 Flex 公布价格为 Standard 的一半，账单也体现了这个差异。

这组结果说明该测试负载省了钱，不能证明 Flex 在高峰期也有相同延迟。交互请求仍应优先使用 default；Flex 要设自己的截止时间，并从响应或 CloudWatch ResolvedServiceTier 核对实际档位。

降低推理强度之前，先确认默认值变没变

推理 Token 按输出 Token 计费。原文指出，Claude Sonnet 5 和 Claude Opus 5 默认启用 high 强度的自适应思考，即使请求省略 thinking 字段也是如此。应用从 Claude Sonnet 4.6 原样迁移，也会开始计入思考 Token。Claude Haiku 5.5 默认是 medium，三者都支持 low、medium、high、xhigh、max。

下面这段请求用于降低自适应思考强度：

{
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "low" }
}

要看准 effort 所在的位置：它属于 output_config，不能塞进 thinking。

作者用 Claude Opus 5 测试了 3 个工具调用任务，每题都有唯一正确答案，每个强度下各跑 8 次，任务设计参考 Grok 4.7 的长程 Agent 示例。不过，提供的原文缺少它提到的结果表，无法据此比较各档的准确率和 Token 差异。

代码生成样例给出了可用数字：low 的输出 Token 中位数为 676，high 为 743，差异处于运行波动范围内，各档生成的程序都通过了评分。

所以，简单任务可以从低于 high 的档位开始评估，但不能承诺降档就有明显收益。要一起观察每次请求的输出 Token、CloudWatch AWS/Bedrock 下的 OutputTokenCount、调用日志和任务通过率。程序没做对，少花 Token 也没有价值。

maxTokens 既影响单次开销，也影响并发额度

maxTokens 是应用设置的输出天花板。提示词失控或生成异常时，它能限制一次请求继续花钱。Bedrock 在请求开始时会从配额中扣除输入 Token 加上 maxTokens，所以把上限一律拉满，还会减少可用并发。

下面的 Converse API 参数把单次输出限制为 155 Token：

{ "inferenceConfig": { "maxTokens": 155 } }

注意这里的 155 只是作者实验中的示例值。作者在 Claude Sonnet 5 上观察了 5 次正常输出，最高为 103 Token，于是留出余量设置了这个上限。

随后，他们关闭自适应思考，用同一个刻意要求冗长输出的提示词，对比 2,048 和 155 两个上限。实际分别生成了 2,048 和 155 Token，相差 1,893。但两次都以 max_tokens 停止，回答都被截断。

输出上限能限制损失，不能让不合适的请求变得有用。

生产环境应按任务统计 P95、P99，再加余量。P95 更严格，也更容易截断有效长回答；P99 给长尾留的空间更多。启用自适应思考时，上限同时包含思考和回答，校准也必须在开启思考的条件下进行。尤其是多轮 Agent，截断一次可能破坏后续步骤，不能只看当前请求便宜了多少。

它也不替代安全控制。原文另列 Amazon Bedrock Guardrails，用于在受支持的输入和响应上过滤内容、检测提示词攻击及检查依据一致性。

我的判断

这篇最有价值的做法，是把成本优化落到可验证的请求行为上。缓存要看读写计数，档位要看实际解析结果，推理强度和输出上限要结合完成质量，最后再对账。

但证据有边界：Flex 实验只有一个模型和一组负载；代码生成实验没有显示明确的降档收益；输出上限实验只证明能截断；推理强度的关键结果表还缺失。这些不足以支持「统一改参数就能省钱」。

它也没有与换模型、批量推理、路由、蒸馏做完整对照。请求级调整适合先试，因为改动集中、便于回滚，但不能替代更大范围的方案评估。

能拿来做什么

• 在 Node 调用层按任务记录模型版本、Region、API、Token 用量、缓存读写、实际档位和停止原因，让成本能对应到具体任务。
• 为多模型路由维护能力记录，覆盖缓存时长、服务档位、推理等级和输出上限，发送前校验，切模型时重新核对。
• 对固定系统提示词和工具定义统计复用间隔，再决定缓存 TTL；同时记录提示词版本，排查改动导致的缓存失效。
• 给后台评测试用 Flex，给有明确验收条件的代码生成任务试用较低推理强度，并按任务日志校准 P95、P99 上限；每次只改一个选择，同时检查费用和完成率。