AWS Bedrock 按token计费常见陷阱：单位换算与实时查询方法

Bedrock 按量计价的费率结构是稳定的，但任何一张列出各模型 token 单价的表格，用不了一个季度就会过时——而且那些过时的表格比没用还糟，因为它们看起来很权威。真正稳定的是结构：单位是什么，哪四个变量影响费率，以及如何在脚本中获取当前数值。这正是本文要讲的内容。

单位与单位陷阱

Bedrock 的按量计价是按 token 收费的，输入和输出分别定价，且输出几乎总是更贵——这是出于机械原因而非商业考量，因为生成是内存带宽受限的，而 prefill 不是。

陷阱在于分母。AWS 在不同时间、不同位置发布了每千 token 和每百万 token 的 Bedrock 费率，而底层的 Price List 数据使用了自己的一套单位字符串。如果电子表格混用了这两种单位，结果就会相差一千倍——这是该服务内部成本模型中最常见的错误。每当你复制一个费率时，把它的单位也复制到同一个单元格里。

你自己的 token 数量来自响应，而非估算：每个 Converse 响应都携带 usage.inputTokens、usage.outputTokens 和 usage.totalTokens，而一个完成的批处理任务会把整个运行的 inputTokenCount 和 outputTokenCount 写入 manifest.json.out。用这些数字乘以当前费率，你得到的是实际数值而非模型估算。

决定费率的四个因素

模型。显然——但要注意，同一模型家族的不同成员价格差异很大，而你传入的 id 包含版本号。从一个旧版本升级到下一个版本，既是行为变化，也是价格变化。

区域。同一模型在不同区域的费率不同。对于跨区域推理，AWS 文档说明价格按你调用配置文件的区域计算，而非服务请求的区域——所以地理配置文件不会让你暴露于另一个区域的定价。全球配置文件据文档说明比标准定价节省约 10%。

方向。输入和输出是分开计费的。任何使用单一混合费率的成本模型，对长 prompt 短回答的场景都会定价错误——而这恰恰描述了大多数检索增强工作负载。

模式。按量计费、批量推理、预留配置和缓存读取是同一模型的不同计费项。详见下文。

批量推理、缓存与其他计费项

AWS 的 Bedrock 定价页面描述批量推理在撰写本文时比按量推理定价低 50%。这是大多数工作负载可用的最大单一杠杆，代价只有延迟——在优化其他东西之前，值得审计一下你的流量中有多少真的需要同步响应。

Prompt 缓存不是某一费的折扣，而是两项额外费率：高于正常输入费率的缓存写入费率，以及远低于它的缓存读取费率。这种费率结构意味着，只有当缓存前缀被读取多次时，缓存才是经济的。将大型系统 prompt 写入缓存一次再读取两次，可能比不缓存还贵。你的使用量块会分别报告 cacheWriteInputTokens 和 cacheReadInputTokens，这是你判断缓存是否划算所需的数据。

Guardrails 再次单独计量，按策略以文本单元计费——guardrail 评估的 usage 对象会分项列出 topicPolicyUnits、contentPolicyUnits、sensitiveInformationPolicyUnits 等。在每个回合对整个检索语料应用 guardrail 是一笔真实的成本，这也是 guardContent 作用域存在的原因。

50% 批量折扣和 10% 全球配置文件折扣是 AWS 在撰写本文时（2026 年 8 月）于 Amazon Bedrock 定价页面和跨区域推理文档中发布的数字。这两类数字都属于会变动的类型。本文故意不引用任何按模型的 token 费率——去获取它们，而不是复制它们。

通过程序获取当前数值

Bedrock 费率在 AWS Price List 中，这意味着你可以查询它们，而不是爬取营销页面。服务代码是 AmazonBedrock。

# 我可以按哪些属性筛选？
aws pricing describe-services \
  --service-code AmazonBedrock \
  --region us-east-1

# 当前按量计费费率，逐步筛选
aws pricing get-products \
  --service-code AmazonBedrock \
  --region us-east-1 \
  --filters 'Type=TERM_MATCH,Field=regionCode,Value=us-east-1' \
  --format-version aws_v1 \
  --max-results 100

两个运维注意事项。Price List API 只在少数几个区域可用，所以上面的 --region 是 API 端点，而非你要查价的区域——这正是 regionCode 过滤器的作用。而且响应是深层嵌套的 JSON，费率在 terms.OnDemand 下；先运行 describe-services 并阅读属性名称，因为它们是本季度模型如何标记的唯一可靠指引。

这样做的原因是，它把一张过时的电子表格变成了一项定期任务。一个每周拉取当前费率、乘以上周实测 token 数量、并将结果写入可见之处的脚本大约三十行，它解决的是"知道你在花什么"和"知道某人上次检查时你花了什么"之间的差别。将其与 Bedrock 支出上的 Budgets 告警配对，这样惊喜就以通知的形式到来，而不是一张发票。

token 费率之外的东西

按 token 费率不是账单。还有四样东西经常出现：

向量存储。知识库意味着一个 OpenSearch Serverless 集合或等效物，无论是否有人查询，都按容量计费。AWS 指出删除知识库不会删除向量存储，所以这个成本比创建它的东西更长寿。

ingestion 期间的 embedding 调用。每次重新摄入变更的文档都会产生 embedding token，而语义分块还会额外在摄入时使用基础模型。

预留吞吐量。从创建到删除按小时计费，无论流量如何，在承诺期内不可删除——参见盈亏平衡计算。

重试和失败的请求。你的 SDK 重试四次才成功的被限流请求，要为那些产生 token 的尝试中所消耗的内容付费。

Bedrock 按账户和按模型计费；它不知道你的哪个团队或哪个客户生成了调用。API 给你的唯一钩子是 Converse 上的 requestMetadata——最多 16 个键值对，你可以在调用日志上按其过滤——一致地使用它，是可归因支出和一个大数字之间的差别。像 Multigrid 这样的网关在更高层级做同样的工作，跨提供商按键标记和聚合，一旦 Bedrock 不是你请求的唯一去处，这就很重要了。

---