本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Bedrock 中词元的计算方式
<a name="quotas-token-burndown"></a>

当您运行模型推理时，可以处理的词元数量存在配额，具体取决于您使用的 Amazon Bedrock 模型。请查看与词元配额相关的以下术语：


****  

| 租期 | 定义 | 
| --- | --- | 
| InputTokenCount |  CloudWatch Amazon Bedrock 运行时指标，表示模型处理的输入令牌数量，不包括缓存的令牌。要根据配额确定您的输入令牌总消耗量，请求和InputTokenCount \+ CacheWriteInputTokens。 | 
| OutputTokenCount |  CloudWatch Amazon Bedrock 运行时指标，表示模型为响应请求而生成的令牌数量。 | 
| CacheReadInputTokens |  CloudWatch Amazon Bedrock 运行时指标，表示成功从缓存中检索而非模型重新处理的输入令牌的数量。如果您不使用[提示缓存](prompt-caching.md)，则此值为 0。 | 
| CacheWriteInputTokens |  CloudWatch Amazon Bedrock 运行时指标，表示成功写入缓存的输入令牌的数量。如果您不使用[提示缓存](prompt-caching.md)，则此值为 0。 | 
| 每分钟词元数（TPM） |  AWS 在模型级别为一分钟内可以使用的令牌数量（包括输入和输出）设置的配额。 | 
| 每日词元数（TPD） |  AWS 在模型级别对一天内可以使用的代币数量（包括输入和输出）设置的配额。默认情况下，此值为 TPM x 24 x 60。但是，新的配额减少 AWS 账户 了。 | 
| 每分钟请求数（RPM） |  AWS 在模型级别为你在一分钟内可以发送的请求数量设定的配额。 | 
| max\_tokens | 您在请求中提供的参数，用于设置模型可以生成的最大输出词元数。 | 
| 消耗比率 | 输入和输出词元转换为词元配额使用量的比率，用于系统节流。 | 

Anthropic Claude 模型版本 3.7 及更高版本的输出代币消耗率为 **5 倍（1 个输出代币**消耗配额中的 5 个代币）：

对于所有其他模型，消耗比率为 **1:1**（在配额中，1 个输出词元消耗 1 个词元）。

**Topics**
+ [了解词元配额管理](#quotas-token-burndown-management)
+ [了解 max\_tokens 参数的影响](#quotas-token-burndown-max-tokens)
+ [优化 max\_tokens 参数](#quotas-token-burndown-max-tokens-optimize)

## 了解词元配额管理
<a name="quotas-token-burndown-management"></a>

当您发出请求时，词元将从您的 TPM 和 TPD 配额中扣除。计算分为以下阶段：
+ **请求开始时**：假设您没有超出 RPM 配额，将从您的配额中扣除以下总额。如果您超出配额，请求会被节流。

  ```
  Total input tokens + max_tokens
  ```
+ **处理期间**：请求消耗的配额会定期调整，以涵盖生成的实际输出词元数。
+ **在请求结束时**：请求消耗的词元总数将按以下方式计算，所有未使用的词元将补充到您的配额：

  ```
  InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)
  ```

  `CacheReadInputTokens`不要参与此计算，也不会计入您的配额。如果不使用[提示缓存](prompt-caching.md)，则`CacheWriteInputTokens`和都`CacheReadInputTokens`将为 0。

**注意**  
您只需根据词元的实际使用量付费。  
例如，如果您使用 Anthropic Claude Sonnet 4 并发送一个包含 1000 个输入词元的请求，而该模型生成一个等效于 100 个词元的响应：  
系统会从您的 TPM 和 TPD 配额中扣除 **1500 个词元**（1000 \+ 100 x 5）。
您只需为 **1100 个词元**付费。

## 了解 max\_tokens 参数的影响
<a name="quotas-token-burndown-max-tokens"></a>

`max_tokens` 值将在每次请求开始时从您的配额中扣除。如果您比预期更早达到 TPM 配额上限，请尝试降低 `max_tokens`，使其更接近您实际生成内容的规模。

以下场景提供了一些示例，用来说明在使用输出词元消耗比率为 5 倍的模型时，对于已完成的请求，将如何计算配额扣除。

### 场景 1：max\_tokens 值过高
<a name="quotas-token-burndown-max-tokens-too-high"></a>

参数设置如下：
+ **InputTokenCount:** 3,000
+ **CacheReadInputTokens:** 4,000
+ **CacheWriteInputTokens:** 1,000
+ **OutputTokenCount:** 1,000
+ **max\_tokens：**32000

配额扣除情况如下：
+ **提出申请时的初始扣除额：**36,000（= 3,000 \+ 1,000 \+ 32,000）
+ **生成响应后的最终调整扣除额：**9000（= 3000 \+ 1000 \+ 1000 x 5）

在本场景中，由于 `max_tokens` 参数设置过高，可发起的并发请求数量减少。这会降低请求并发度、吞吐量和配额使用量，因为可以很快达到 TPM 配额容量。

### 场景 2：max\_tokens 值经过优化
<a name="quotas-token-burndown-max-tokens-optimized"></a>

参数设置如下：
+ **InputTokenCount:** 3,000
+ **CacheReadInputTokens:** 4,000
+ **CacheWriteInputTokens:** 1,000
+ **OutputTokenCount:** 1,000
+ **max\_tokens：**1250

配额扣除情况如下：
+ **提出申请时的初始扣除额：**5,250（= 3,000 \+ 1,000 \+ 1,250）
+ **生成响应后的最终调整扣除额：**9000（= 3000 \+ 1000 \+ 1000 x 5）

在本场景中，`max_tokens` 参数经过优化，因为初始扣除额仅略高于最终调整后扣除额。这有助于提高请求并发度、吞吐量和配额使用量。

## 优化 max\_tokens 参数
<a name="quotas-token-burndown-max-tokens-optimize"></a>

通过优化`max_tokens`参数，您可以高效地使用分配的配额容量。为了帮助您就此参数做出决定，您可以使用亚马逊，它会自动从 AWS 服务中收集指标 CloudWatch，包括Amazon Bedrock中的代币使用数据。

词元记录在 `InputTokenCount` 和 `OutputTokenCount` 运行时指标中（有关更多指标，请参阅 [Amazon Bedrock 运行时指标](monitoring.md#runtime-cloudwatch-metrics)）。

要使用 CloudWatch 监控来告知您对`max_tokens`参数的决定，请在中执行以下操作 AWS 管理控制台：

1. 登录 Amazon CloudWatch 控制台，网址为[https://console.aws.amazon.com/cloudwatch](https://console.aws.amazon.com/cloudwatch)。

1. 从左侧导航窗格中选择**控制面板**。

1. 选择**自动控制面板**选项卡。

1. 选择 **Bedrock**。

1. 在**按模型统计的词元数**控制面板中，选择展开图标。

1. 为指标选择持续时间和范围参数，以便应对峰值使用量。

1. 在标记为**总和**的下拉菜单中，您可以选择不同的指标来观察词元使用情况。查看这些指标可以为设置 `max_tokens` 值提供依据。