AWS Bedrock 费用比预期高通常源于使用模式、模型选择或配置设置。Bedrock 的收费依据包括处理的输入/输出 token 数量、使用的特定模型层级以及可选功能（如预置吞吐量 Provisioned Throughput）。例如，对简单任务使用 Claude-2 这样的大型模型，或者在处理大量文本时未优化 token 限制，都可能推高成本。此外，如果您的工作负载波动，预置吞吐量承诺（预付费容量）可能未被充分利用，导致浪费开支。代码中配置错误的重试逻辑也可能触发不必要的 API 调用，进一步增加费用。
要确定根本原因，请首先使用 AWS Cost Explorer 并按 Bedrock 服务进行筛选。按使用类型（例如，BedrockModelInvocationInputTokens 或 BedrockModelInvocationOutputTokens）细分成本，查看哪些模型或 token 类别占主导地位。为 Bedrock 启用 AWS CloudWatch 指标，以跟踪调用计数、token 量和随时间变化的错误。为了进行更精细的调试，请通过 AWS CloudTrail 启用 Bedrock 请求日志记录。这允许您审计单个 API 调用，包括模型 ID、输入大小和时间戳。例如，您可能会发现某个后台作业正在对非关键任务使用昂贵的 amazon.titan-text-premier 模型，而不是更便宜的 amazon.titan-text-express。在 Bedrock API 请求中标记资源（例如，Environment=Production）也有助于按团队或项目细分成本。
要优化成本，首先审查模型选择。对于基本任务，使用 Titan Embeddings 等较小的模型，而不是使用 Claude-3 Opus 进行通用文本处理。在 API 请求中实施 token 限制——例如，如果更短的响应就足够，将 maxTokens 上限设置为 500，而不是默认的 4,096。对重复查询（例如，产品描述）使用缓存，以减少 API 调用。如果使用预置吞吐量，请将承诺量与稳定工作负载对齐，并在高峰期结合按需定价。设置 AWS Budgets 警报，以便在每日 Bedrock 费用超出阈值时触发。最后，审计代码中是否存在冗余的 API 调用——一个常见问题是重试失败的请求时没有退避逻辑，这可能意外地向 Bedrock 发送大量重复任务。