Amazon Bedrock 推理费用四因素解析
Your Amazon Bedrock inference bill can keep climbing even after you tune prompts and application logic. Four request-level choices (cache duration, service tier, reasoning effort,
ガイド一覧 · 本文は主に簡体字中国語です。国際向けの要点は English summary をご利用ください。
## Amazon Bedrock 推理费用四因素解析
Amazon Bedrock 是 AWS 推出的服务器端托管推理服务，适合构建、部署和管理生成式 AI 应用。
对账单时，推理费用通常由 Token（令牌）数量和对应模型的单价决定。缓存时长、服务层级、推理努力 和 maxTokens 等四个请求级选项，能显著影响实际计费，即使调整提示词和应用逻辑后仍需关注。
这些因素因模型和负载而异，理解它们可帮助开发者精确控制成本，避免意外超支。以下是基于官方 2026 年 11 月 12 日博客的四因素解析，结合实际测试数据和对账验证方法。 [[1]](https://aws.amazon.com/blogs/machine-learning/four-amazon-bedrock-inference-choices-that-affect-cost/)
缓存时长（Cache Duration）
缓存时长 是控制提示缓存的关键选项。支持模型可将重复的系统指令、工具定义或参考上下文保存为缓存，缩短后续推理延迟并降低输入 Token 成本。
官方支持的 TTL 值（时效）因模型而定，例如 Anthropic 模型提供 5 分钟或 1 小时，OpenAI GPT-5.6 系列最低 30 分钟。
请求示例（Converse API）：
{
"cachePoint": {
"type": "default",
"ttl": "1h"
}
}
不支持缓存的负载（如批量推理）无法使用。
对账验证：检查响应元数据中的缓存读/写 Token 计数。缓存读单价通常为输入价的 10%，写单价为 1.25–2 倍。实际节省取决于请求间隔：5 分钟 TTL 需要请求间隔 <5 分钟才有效；1 小时 TTL 需每小时至少 3 次重用才打破平。
边界：缓存条目按账号和 Region 隔离，多租户场景需在提示前加哈希前缀。检查点顺序为工具 > 系统 > 消息，修改早期内容会失效后续缓存。
更多细节见官方提示缓存指南。 [[2]]
服务层级（Service Tier）
服务层级 决定请求的性能与成本平衡。不同负载适合不同层级：
- default / standard：默认交互请求层级，延迟敏感场景首选。
- flex：适合延迟容忍的后台任务（如评估、夜间汇总），单价通常为 standard 的 50%（以 us-west-2 Nova 2 Lite 为例）。
请求示例：
{
"serviceTier": {
"type": "flex"
}
}
不支持 flex 的模型会返回 ValidationException。
对账验证：通过 CloudWatch ResolvedServiceTier 指标或响应元数据确认实际层级。相同 Token 数量下，flex 请求成本更低，但不适用于实时交互。
决策建议：延迟要求高时选 default；批处理或非关键任务选 flex。
推理努力（Reasoning Effort）
推理努力 通过 adaptive thinking 控制模型思考过程，影响输出 Token 数量（计入输出 Token 费用）。Claude 系列默认 high 努力，Haiku 系列默认 medium。
支持 levels：low / medium / high / xhigh / max。
请求示例：
{
"thinking": { "type": "adaptive" },
"output_config": { "effort": "low" }
}
对账验证：跟踪 AWS/Bedrock OutputTokenCount + maxTokens。测试数据（Claude Opus 5 工具调用代理）：
| Effort | 正确运行 | 中位输出 Token | 较 low 增加 |
|---|---|---|---|
| low | 24/24 | 936 | baseline |
| medium | 24/24 | 1,484 | +59% |
| high | 24/24 | 2,521 | +169% |
| xhigh | 24/24 | 2,964 | +217% |
| max | 24/24 | 3,762 | +302% |
边界：低努力可能牺牲准确性，需结合任务特定测试。代码生成场景中努力对输出影响小。
决策建议：常规任务选 low/medium；质量关键场景保留 high。
maxTokens（输出 Token 上限）
maxTokens 是应用级输出上限，防止循环或回归导致无限消耗。请求发起时扣除输入 + maxTokens Token，过度值会降低并发。
请求示例：
{
"inferenceConfig": {
"maxTokens": 155
}
}
对账验证：观察响应元数据和 CloudWatch 输出 Token 计数。结合 Guardrails 作为安全补充。
决策建议：根据任务输出分布设置合理上限，避免虚假节省。
四因素对照表
| 因素 | 影响 Token 数量 | 典型成本影响 | 适用场景 | 对账验证方式 |
|---|---|---|---|---|
| 缓存时长 | 减少输入 Token | 读 0.1x 输入价 | 重复上下文负载 | 缓存读/写计数 + TTL 校验 |
| 服务层级 | 主要不影响 Token | Flex 可降至 50% 标准价 | 批处理/后台任务 | ResolvedServiceTier 指标 |
| 推理努力 | 显著增加输出 Token | 高努力可增 300%+ | 需要高精度的任务 | 输出 TokenCount + 准确率测试 |
| maxTokens | 限制输出 | 可避免超额消耗 | 循环风险高的应用 | 响应上限 + CloudWatch |
数据来源：以上基于 2026 年 11 月 12 日官方测试结果，以账号/Region 当日定价为准。建议通过 AWS Pricing Calculator 模拟具体 workload。 [[3]]
延伸阅读
风险与边界
这些因素优化能显著降低费用，但若处理不当（如缓存时长错误或 maxTokens 过高），仍可能导致账单异常上涨。对不上账单时，检查响应元数据与 CloudWatch 指标，升级模型后必挂需额外关注 Token 计数变化。
非法律意见：本文基于公开博客与官方文档总结，不构成专业咨询或法律意见。请以 AWS 官方定价页与账单元数据为准，具体以账号/Region 当日数据为准。实际应用仍建议测试后再上线。
---