本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
Amazon Bedrock 中的代币是如何计算的
运行模型推理时，根据您使用的 Amazon Bedrock 模型，可以处理的令牌数量存在配额。查看以下与代币配额相关的术语：
| 租期 | 定义 |
|---|---|
InputTokenCount |
A CloudWatch mazon Bedrock 运行时指标，表示作为模型输入提供的请求中的令牌数量。 |
OutputTokenCount |
CloudWatch Amazon Bedrock 运行时指标，表示模型为响应请求而生成的令牌数量。 |
CacheReadInputTokens |
CloudWatch Amazon Bedrock 运行时指标，表示成功从缓存中检索而非模型重新处理的输入令牌的数量。如果您不使用提示缓存，则此值为 0。 |
CacheWriteInputTokens |
CloudWatch Amazon Bedrock 运行时指标，表示成功写入缓存的输入令牌的数量。如果您不使用提示缓存，则此值为 0。 |
| 每分钟代币 (TPM) | AWS 在模型级别为一分钟内可以使用的令牌数量（包括输入和输出）设置的配额。 |
| 每日代币 (TPD) | AWS 在模型级别对一天内可以使用的代币数量（包括输入和输出）设置的配额。默认情况下，此值为 TPM x 24 x 60。但是，新的配额减少 AWS 账户 了。 |
| 每分钟请求数 (RPM) | AWS 在模型级别为你在一分钟内可以发送的请求数量设定的配额。 |
max_tokens |
您在请求中提供的参数，用于设置模型可以生成的最大输出令牌数量。 |
| 烧毁率 | 输入和输出令牌转换为限制系统的令牌配额使用量的速率。 |
以下型号的输出代币消耗率为 5 倍（1 个输出代币消耗配额中的 5 个代币）：
-
AnthropicClaude Opus4
-
Anthropic Claude Sonnet 4
-
Anthropic Claude 3.7 Sonnet
对于所有其他型号，消耗率为 1:1（1 个输出代币消耗配额中的 1 个代币）。
了解代币配额管理
当您提出请求时，代币将从您的 TPM 和 TPD 配额中扣除。计算发生在以下阶段：
-
在请求开始时 — 假设您没有超过 RPM 配额，则会从您的配额中扣除以下金额。如果您超过配额，则请求会受到限制。
Total input tokens + max_tokens -
处理期间 — 定期调整请求消耗的配额，以考虑生成的实际输出令牌数量。
-
在请求结束时 — 请求消耗的代币总数将按如下方式计算，所有未使用的代币将补充到您的配额中：
InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)如果不使用提示缓存，
CacheWriteInputTokens则为 0。CacheReadInputTokens不要为这个计算做出贡献。
注意
您只需为实际的代币使用量付费。
例如，如果您使用AnthropicClaude Sonnet 4并发送了一个包含 1,000 个输入令牌的请求，它会生成相当于 100 个令牌的响应：
-
1,500 个代币（1,000 + 100 x 5）将从你的 TPM 和 TPD 配额中耗尽。
-
您只需支付 1,100 个代币的费用。
了解 max_tokens 参数的影响
该max_tokens值将在每次请求开始时从您的配额中扣除。如果您比预期的更早达到 TPM 配额，请尝试减少配额max_tokens以更好地接近完成量。
以下场景提供了一些示例，说明使用输出代币消耗率为 5 倍的模型，配额扣除将如何处理已完成的请求：
假设以下参数：
-
InputTokenCount: 3,000
-
CacheReadInputTokens: 4,000
-
CacheWriteInputTokens: 1,000
-
OutputTokenCount: 1,000
-
最大代币：32,000
扣除的配额如下：
-
提出申请时的初始扣除额：40,000（= 3,000 + 4,000 + 32,000 + 32,000）
-
生成回复后调整后的最终扣除额：9,000（= 3,000 + 1,000 + 1,000 x 5）
在这种情况下，由于max_tokens参数设置得太高，可能会发出更少的并发请求。这会降低请求并发度、吞吐量和配额利用率，因为可以很快达到 TPM 配额容量。
假设以下参数：
-
InputTokenCount: 3,000
-
CacheReadInputTokens: 4,000
-
CacheWriteInputTokens: 1,000
-
OutputTokenCount: 1,000
-
最大代币：1,250
扣除的配额如下：
-
提出申请时的初始扣除额：9,250（= 3,000 + 4,000 + 1,000 + 1,250）
-
生成回复后调整后的最终扣除额：9,000（= 3,000 + 1,000 + 1,000 x 5）
在这种情况下，对max_tokens参数进行了优化，因为初始扣除额仅略高于最终调整后的扣除额。这有助于提高请求并发性、吞吐量和配额利用率。
优化 max_tokens 参数
通过优化max_tokens参数，您可以有效地利用分配的配额容量。为了帮助您就此参数做出决定，您可以使用亚马逊，它会自动从 AWS 服务中收集指标 CloudWatch，包括Amazon Bedrock中的代币使用数据。
令牌记录在InputTokenCount和OutputTokenCount运行时指标中（有关更多指标，请参阅Amazon Bedrock 运行时指标。
要使用 CloudWatch 监控来告知您对max_tokens参数的决定，请在中执行以下操作 AWS Management Console：
-
通过 https://console.aws.amazon.com/cloudwatch
登录亚马逊 CloudWatch 控制台。 -
在左侧导航窗格中，选择仪表板。
-
选择 “自动仪表板” 选项卡。
-
选择 B edrock。
-
在 “按型号划分的代币数量” 仪表板中，选择展开图标。
-
为指标选择持续时间和范围参数，以考虑峰值使用量。
-
从标有 Sum 的下拉菜单中，您可以选择不同的指标来观察代币的使用情况。检查这些指标，以指导您决定设定自己的
max_tokens价值。
