影响 Amazon Bedrock 成本的四个推理选项

即使你优化了提示词和应用逻辑，Amazon Bedrock 推理账单仍可能持续攀升。请求层面的选择依然会改变服务处理的 token 数量以及适用的费率。缓存时长、服务层级、推理强度以及 maxTokens 都能在不更改模型或提示词的情况下影响成本。

每项选择都取决于模型和工作负载。本文展示我们如何测试每项选择，以及如何从响应元数据、日志和账单数据中验证其效果。

要自行尝试这些设置，请从 Amazon Bedrock Samples 的 notebook Mixed TTL Caching 和 Tenant Isolation with Prompt Caching 开始。关于 maxTokens 和推理强度，请参阅 sample-code-for-genai-cost-management-workshop GitHub 仓库的 01-low-effort 文件夹。每个示例都设置了自己的模型 ID，因此请将其和推理参数更改为与你调用的模型相匹配。关于各 AWS 区域的模型可用性，请参阅 Models at a glance。关于模型选择、批量推理、路由和蒸馏等更广泛的决策，请参阅 Effective cost optimization strategies for Amazon Bedrock。

推理成本从何而来

每个 Amazon Bedrock 响应都带有用量元数据。输入和输出 token 按处理该请求的模型和层级的费率计费。缓存读取和写入使用单独的 token 计数器，推理 token 计为输出 token。

提示词缓存时长

重复的系统指令、工具定义或参考上下文，如果缓存在下一次请求之前过期，就会被重新处理。Prompt caching for faster model inference 指南列出了受支持的 Anthropic 模型的 5 分钟和 1 小时生存时间（TTL）值。它还列出了受支持的 GPT-5.6 模型 30 分钟的最低 TTL。支持情况和 API 字段因模型而异，因此选择时长前请查看当前的支持矩阵。

对于受支持的模型，Amazon Bedrock 还提供 implicit prompt caching，它会在你的请求中没有缓存控制的情况下尝试复用符合条件的提示词前缀。由于隐式缓存是尽力而为，并不保证缓存命中，因此本节中的时长选择适用于显式缓存。

以下 Converse API 签名在支持该功能的模型上请求 1 小时的条目：

{ "cachePoint": { "type": "default", "ttl": "1h" } }

对于受支持的 Anthropic 模型，InvokeModel 将相同的 ttl 值放入 cache_control。

更长的时长并不自动意味着更便宜。Amazon Bedrock Pricing 页面列出了 5 分钟写入、1 小时写入和缓存读取的单独费率。对于 Amazon Bedrock 上的 Anthropic Claude Sonnet 5 和 Anthropic Claude Opus 5，5 分钟写入的成本是输入费率的 1.25 倍。1 小时写入的成本是 2 倍，缓存读取的成本是 0.1 倍。

这些费率设定了盈亏平衡点，假设每个请求都复用完全相同的前缀，且每次缓存读取都会刷新 TTL。5 分钟缓存在 5 分钟内的首次复用时即可回本。当同一前缀的请求间隔超过 5 分钟到达时，每次请求都会以 1.25 倍的价格重写。此时 1 小时缓存在一小时内从第二次请求起就更便宜。

缓存费率和检查点最低值因模型而异。请查看你所调用模型的 Amazon Bedrock Pricing 页面和 prompt caching guide。针对你的模型重新运行比较，然后在部署后通过缓存读取和写入 token 进行确认。

将稳定内容放在动态内容之前，满足模型的检查点最低要求，并使用按需推理，因为提示缓存不适用于批量推理。

更改已缓存的 prefix（包括系统指令或工具定义）会导致缓存未命中并产生新的写入。检查点按工具、系统、消息的顺序评估，因此较早部分的更改也会使后面的部分失效。对经常更改的提示进行版本管理，使每个版本都有自己的缓存条目。我们在 Claude Sonnet 5 上使用 1 小时检查点运行了六次调用，更改了一次系统提示和一次工具定义。每次更改都产生了零次缓存读取和一次新的写入。

AWS 将缓存条目的范围描述为你的账户和区域，而不是你的租户。在多租户应用程序中，将租户特定的 SHA-256 哈希前置到可缓存前缀中。Optimizing cost and latency with Amazon Bedrock prompt caching for Anthropic models 一文描述了这种模式。在构建提示之前强制执行租户授权。哈希在一个账户内划分条目。如果受监管的工作负载需要硬性数据边界，请将每个租户放在单独的 AWS 账户中。

对于频繁重用，保留 5 分钟默认值。当同一前缀每小时至少重复两次且间隔超过 5 分钟时，将其改为支持的更长持续时间。为了胜过完全不使用缓存，1 小时缓存每小时需要三次请求。

面向延迟容忍型工作负载的服务层级

后台作业、评估框架、夜间摘要和回填并不总是需要交互式请求所使用的延迟特征。对于支持 Flex 的模型，使用以下请求签名选择它：

{ "serviceTier": { "type": "flex" } }

使用 default 而不是 standard 来请求 Standard 层级。你也可以省略 serviceTier：

{ "serviceTier": { "type": "default" } }

层级支持因模型而异，因此请按确切的模型版本记录支持情况。Amazon Nova 2 Lite 和 OpenAI gpt-oss-120b 模型卡将 Flex 列为支持。Amazon Bedrock 上 Anthropic Claude Sonnet 5 和 Anthropic Claude Opus 5 的模型卡将其列为不支持。向不支持的模型发送 Flex 请求会失败并返回 ValidationException，而不是静默地在 Standard 上运行。我们向 Anthropic Claude Sonnet 5 发送的请求返回了该错误。

如果你的策略允许将 Standard 作为回退，请捕获不支持的层级错误，并使用 default 重试一次。不要对每个 ValidationException 都重试，因为格式错误的请求也会引发该错误。限制应用程序级重试次数。AWS SDK 的有界重试策略处理限流和瞬时错误。

为 Flex 请求设置你自己的截止时间。支持的响应会报告解析后的层级，你也可以使用 Amazon CloudWatch ResolvedServiceTier 进行验证。有关你调用的确切模型，请参阅 Service tiers for optimizing performance and cost 和 Amazon Bedrock Pricing 页面。

我们在 Amazon Nova 2 Lite 上测试了 Flex，发送了 200 个 default 请求和 200 个 flex 请求，以交错对的形式发送。两个层级处理的输入和输出 token 数量相同。所有 400 个请求都解析为请求的层级，中位延迟差异太小，无法与噪声区分。在撰写本文时，us-west-2 中 Nova 2 Lite 公布的 Flex 费率是 Standard 费率的一半，我们的账单反映了这一点。请查看 Amazon Bedrock Pricing 页面了解当前费率。将延迟敏感的流量保留在 default 上。

自适应思考强度

推理 token 按输出 token 计费。Claude Sonnet 5 和 Claude Opus 5 默认在 high 努力级别下使用自适应思考，即使请求省略了 thinking 字段也是如此。一个从 Claude Sonnet 4.6 迁移过来且未做任何改动的应用会开始对思考 token 计费，并且 maxTokens 现在会限制思考加响应文本的总量。Claude Haiku 5.5 默认使用 medium。这三个模型都支持 low、medium、high、xhigh 和 max。对于具有以下请求特征的任务，请降低努力级别：

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

将努力级别放在 output_config 中，而不是放在 thinking 内。每当更换模型时，请检查 自适应思考。

我们在 Claude Opus 5 上测试了一个工具调用智能体。它的三个任务遵循 Build long-horizon agents with Grok 4.7 on Amazon Bedrock 中的设计，每个任务都有一个正确答案。我们在每个努力级别下将每个任务各运行了八次。下表显示的是输出 token 的中位数：

较低努力级别下的准确率取决于模型和任务。请在与你的任务形态相似的任务上进行测量。

在 Amazon Bedrock Samples 的 Invoke Bedrock model for code generation 工作负载上，输出 token 中位数在 low 下为 676，在 high 下为 743，这一差异在运行间波动范围内。我们评分的程序在每个努力级别下都通过了。

使用按请求统计的输出 token 数、CloudWatch AWS/Bedrock OutputTokenCount、调用日志和任务通过率来评估这一选择。对于常规、边界明确的任务，从低于 high 开始。在质量测试表明任务需要时保留 high。破坏任务的 token 减少并不是节省。

输出 token 限制

maxTokens 是应用输出上限。它限制糟糕的提示、回归或循环在请求停止前可能产生的输出。配额规则记录在 How tokens are counted in Amazon Bedrock 中。Amazon Bedrock 在请求开始时扣除你的输入 token 加上 maxTokens，因此过大的值会降低并发能力。

输出上限不是安全控制措施。在生产生成式 AI 工作负载中，请将 Amazon Bedrock Guardrails 作为标准的负责任 AI 控制措施使用。Guardrails 可以过滤内容、检测提示攻击，并在支持的输入和响应上检查接地性。请参阅 Detect and filter harmful content by using Amazon Bedrock Guardrails。

在观察具有代表性的输出 token 分布后，按任务类型设置 maxTokens：

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

请求参数请参阅 Inference using Converse API。

在我们对 Claude Sonnet 5 的测试中，五个正常输出的峰值达到 103 个 token，因此我们设置了一个示例性的 155 个 token 上限并留有余量。然后我们发送了相同的故意冗长提示，并禁用自适应思考，一次在 2,048 个 token 的上限下，一次在 155 个 token 的上限下。第一个请求生成了 2,048 个输出 token，第二个生成了 155 个，因此该上限避免了 1,893 个输出 token。两者都在 max_tokens 处停止，因此两个响应都被截断。该上限限制了花费，但并不能让不合适的提示变得有用，而在多轮或智能体链中，被截断的一轮可能会破坏其后的步骤。

对于生产环境校准，请比较每种任务类型的第95和第99百分位数（P95和P99），并在所选百分位数上增加余量。开启自适应思考后，maxTokens 也会限制思考令牌数，因此请在启用思考的情况下进行校准。P95 更积极地限制暴露，但接受更高的截断风险。P99 在更高的上限下保留更多有效的长尾响应。监控 max_tokens 停止情况，并在提高任务限制之前调查该请求。

综合起来

对每项设置使用相同的测试循环：确认模型支持，更改一个请求选项，测量令牌数或成本，并跟踪质量或完成情况。如果你跨模型路由，请为每个模型版本、区域和 API 保留能力记录：支持的缓存时长、服务层级、推理级别和输出上限。在发送每个请求之前，对照该记录进行验证，然后检查响应中的已解析层级和缓存计数器。

需关注的信号

从带任务标签的应用遥测或调用日志中，为每种任务类型推导 P95 和 P99。

结论

所有四项选择都存在于推理请求中。更改模型时重新检查支持情况，然后一次更改一项设置，并在你的应用中测量结果。

使用这些资源来评估适合你工作负载的选择：

• Amazon Bedrock 控制台：console.aws.amazon.com/bedrock。
• 提示缓存：用于加快模型推理的提示缓存。
• 服务层级：用于优化性能和成本的服务层级。
• 自适应思考：自适应思考。
• 负责任 AI 控制：使用 Amazon Bedrock Guardrails 检测和过滤有害内容。
• 延伸阅读：Amazon Bedrock 的有效成本优化策略。
• 相关示例与文章：调用 Bedrock 模型进行代码生成 和 在 Amazon Bedrock 上使用 Grok 4.7 构建长时程智能体。

关于作者

Sai Pavan Kasani

Sai 是 AWS 的技术客户经理。作为技术顾问和客户代言人，他帮助客户将生成式 AI 的概念验证推进到生产环境，重点关注智能体 AI 工作负载、推理优化以及大规模成本效率。工作之余，Sai 喜欢探索新的咖啡店并与家人共度时光。

Aswath Ram Srinivasan

Aswath 是 Amazon Web Services 生成式 AI 领域的全球高级专家解决方案架构师，专注于帮助客户使用 Amazon Bedrock 构建生成式 AI 应用。他与企业团队合作设计推理架构，在性能、成本和运维简便性之间取得平衡。