本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon Bedrock 字符的計數方式
<a name="quotas-token-burndown"></a>

當您執行模型推論時，根據您使用的 Amazon Bedrock 模型，可以處理的字符數量有配額限制。請檢閱下列與字符配額相關的術語：


****  

| 術語 | 定義 | 
| --- | --- | 
| InputTokenCount | CloudWatch Amazon Bedrock 執行時期指標，代表請求中做為模型輸入提供的字符數量。 | 
| 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\$1tokens | 您在請求中提供的參數，用於設定模型可產生的輸出字符數量上限。 | 
| 銷毀率 | 輸入和輸出字符轉換為限流系統其字符配額用量的比率。 | 

Anthropic Claude 模型 3.7 版和更新版本的縮減率**為輸出字符的 5 倍 **(1 個輸出字符從您的配額消耗 5 個字符）：

所有其他模型的銷毀率為 **1：1** (1 個輸出字符會消耗您配額中的 1 個字符)。

**Topics**
+ [了解字符配額管理](#quotas-token-burndown-management)
+ [了解 max\$1tokens 參數的影響](#quotas-token-burndown-max-tokens)
+ [最佳化 max\$1tokens 參數](#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)
  ```

  如果您不使用[提示快取](prompt-caching.md)，則 `CacheWriteInputTokens` 將為 0。`CacheReadInputTokens` 不會計入此計算中。

**注意**  
只會向您收取實際字符用量的費用。  
例如，如果您使用 Anthropic Claude Sonnet 4，並傳送一個包含 1,000 個輸入字符的請求，則會產生相當於 100 個字符的回應：  
您 TPM 和 TPD 配額中的 **1,500 個字符** (1,000 \$1 100 x 5) 將耗盡。
只會向您收取 **1,100 個字符**的費用。

## 了解 max\$1tokens 參數的影響
<a name="quotas-token-burndown-max-tokens"></a>

該 `max_tokens` 值會在每個請求開始時從您的配額中扣除。如果您比預期更早達到 TPM 配額，請嘗試減少 `max_tokens` 以更接近完成的大小。

下列情境提供範例說明如何使用銷毀率為輸出字符 5 倍的模型對已完成的請求扣除配額：

### 情境 1：高 max\$1tokens 值
<a name="quotas-token-burndown-max-tokens-too-high"></a>

假設有下列參數：
+ **InputTokenCount：**3,000
+ **CacheReadInputTokens：**4,000
+ **CacheWriteInputTokens：**1,000
+ **OutputTokenCount：**1,000
+ **max\$1tokens：**32,000

會發生下列配額扣除：
+ **提出請求時的初始扣款：**40,000 (= 3,000 \$1 4,000 \$1 1,000 \$1 32,000)
+ **產生回應後的最終調整後扣除：**9,000 (= 3,000 \$1 1,000 \$1 1,000 x 5)

在此情境中，由於 `max_tokens` 參數設定的過高，因此可以提出的並行請求數量會減少。這會減少並行請求、輸送量和配額使用率，因為很快就會達到 TPM 配額容量。

### 情境 2：最佳化 max\$1tokens 值
<a name="quotas-token-burndown-max-tokens-optimized"></a>

假設有下列參數：
+ **InputTokenCount：**3,000
+ **CacheReadInputTokens：**4,000
+ **CacheWriteInputTokens：**1,000
+ **OutputTokenCount：**1,000
+ **max\$1tokens：**1,250

會發生下列配額扣除：
+ **提出請求時的初始扣款：**9,250 (= 3,000 \$1 4,000 \$1 1,000 \$1 1,250)
+ **產生回應後的最終調整後扣除：**9,000 (= 3,000 \$1 1,000 \$1 1,000 x 5)

在此情境中，`max_tokens` 參數已最佳化，因為初始扣除僅略高於最終調整後扣除。這有助於增加請求並行、輸送量和配額使用率。

## 最佳化 max\$1tokens 參數
<a name="quotas-token-burndown-max-tokens-optimize"></a>

透過最佳化 `max_tokens` 參數，您可以有效率地利用配置的配額容量。為了協助您決定此參數，您可以使用 Amazon CloudWatch，它會自動從 AWS 服務收集指標，包括 Amazon Bedrock 中的字符用量資料。

字符會記錄在 `InputTokenCount` 和 `OutputTokenCount` 執行時期指標中 (如需更多指標，請參閱 [Amazon Bedrock 執行時期指標](monitoring.md#runtime-cloudwatch-metrics))。

若要使用 CloudWatch 監控來協助您做出 `max_tokens` 參數的決策，請在 AWS 管理主控台中執行下列動作：

1. 登入 Amazon CloudWatch 主控台，網址為 https：//[https://console.aws.amazon.com/cloudwatch](https://console.aws.amazon.com/cloudwatch)。

1. 從左側導覽窗格中，選取**儀表板**。

1. 選取**自動儀表板**索引標籤。

1. 選取 **Bedrock**。

1. 在**依模型的字符計數**儀表板中，選取展開圖示。

1. 為指標選取時間持續時間和範圍參數，以考慮尖峰用量。

1. 從標記為**總和**的下拉式功能表中，您可以選擇不同的指標來觀察字符用量。檢查這些指標，以引導您做出設定 `max_tokens` 值的決策。