

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Bagaimana token dihitung di Amazon Bedrock
<a name="quotas-token-burndown"></a>

Saat Anda menjalankan inferensi model, ada kuota pada jumlah token yang dapat diproses tergantung pada model Amazon Bedrock yang Anda gunakan. Tinjau terminologi berikut yang terkait dengan kuota token:


****  

| Jangka Waktu | Definisi | 
| --- | --- | 
| InputTokenCount | Metrik runtime CloudWatch Amazon Bedrock yang mewakili jumlah token dalam permintaan yang diberikan sebagai input ke model. | 
| OutputTokenCount | Metrik runtime CloudWatch Amazon Bedrock yang mewakili jumlah token yang dihasilkan oleh model dalam menanggapi permintaan. | 
| CacheReadInputTokens | Metrik runtime CloudWatch Amazon Bedrock yang mewakili jumlah token input yang berhasil diambil dari cache alih-alih diproses ulang oleh model. Nilai ini adalah 0 jika Anda tidak menggunakan [caching prompt](prompt-caching.md). | 
| CacheWriteInputTokens | Metrik runtime CloudWatch Amazon Bedrock yang mewakili jumlah token input yang berhasil ditulis ke dalam cache. Nilai ini adalah 0 jika Anda tidak menggunakan [caching prompt](prompt-caching.md). | 
| Token per menit (TPM) | Kuota yang ditetapkan oleh AWS pada tingkat model pada jumlah token (termasuk input dan output) yang dapat Anda gunakan dalam satu menit. | 
| Token per hari (TPD) | Kuota yang ditetapkan oleh AWS pada tingkat model pada jumlah token (termasuk input dan output) yang dapat Anda gunakan dalam satu hari. Secara default, nilai ini adalah TPM x 24 x 60. Namun, baru Akun AWS telah mengurangi kuota. | 
| Permintaan per menit (RPM) | Kuota yang ditetapkan oleh AWS pada tingkat model pada jumlah permintaan yang dapat Anda kirim dalam satu menit. | 
| max\$1tokens | Parameter yang Anda berikan dalam permintaan Anda untuk menetapkan jumlah maksimum token keluaran yang dapat dihasilkan model. | 
| Tingkat burndown | Tingkat di mana token input dan output diubah menjadi penggunaan kuota token untuk sistem throttling. | 

Tingkat burndown untuk model Anthropic Claude versi 3.7 dan yang lebih baru adalah **5x untuk token keluaran (1 token keluaran mengkonsumsi 5 token** dari kuota Anda):

Untuk semua model lainnya, tingkat burndown adalah **1:1 (1** token keluaran mengkonsumsi 1 token dari kuota Anda).

**Topics**
+ [Memahami manajemen kuota token](#quotas-token-burndown-management)
+ [Memahami dampak parameter max\$1tokens](#quotas-token-burndown-max-tokens)
+ [Mengoptimalkan parameter max\$1tokens](#quotas-token-burndown-max-tokens-optimize)

## Memahami manajemen kuota token
<a name="quotas-token-burndown-management"></a>

Saat Anda mengajukan permintaan, token dikurangkan dari kuota TPM dan TPD Anda. Perhitungan terjadi pada tahap-tahap berikut:
+ **Pada awal permintaan** — Dengan asumsi bahwa Anda belum melebihi kuota RPM Anda, jumlah berikut dipotong dari kuota Anda. Permintaan dibatasi jika Anda melebihi kuota.

  ```
  Total input tokens + max_tokens
  ```
+ **Selama pemrosesan** - Kuota yang dikonsumsi oleh permintaan disesuaikan secara berkala untuk memperhitungkan jumlah sebenarnya dari token keluaran yang dihasilkan.
+ **Di akhir permintaan** — Jumlah total token yang dikonsumsi oleh permintaan akan dihitung sebagai berikut dan token yang tidak digunakan diisi ulang ke kuota Anda:

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

  Jika Anda tidak menggunakan [caching prompt](prompt-caching.md), `CacheWriteInputTokens` akan menjadi 0. `CacheReadInputTokens`Jangan berkontribusi pada perhitungan ini.

**catatan**  
Anda hanya ditagih untuk penggunaan token Anda yang sebenarnya.  
Misalnya, jika Anda menggunakan Anthropic Claude Sonnet 4 dan mengirim permintaan yang berisi 1.000 token masukan dan menghasilkan respons yang setara dengan 100 token:  
**1.500 token** (1.000 \$1 100 x 5) akan habis dari kuota TPM dan TPD Anda.
Anda hanya akan ditagih untuk **1.100 token**.

## Memahami dampak parameter max\$1tokens
<a name="quotas-token-burndown-max-tokens"></a>

`max_tokens`Nilai dipotong dari kuota Anda di awal setiap permintaan. Jika Anda mencapai kuota TPM lebih awal dari yang diharapkan, coba kurangi `max_tokens` untuk memperkirakan ukuran penyelesaian Anda dengan lebih baik.

Skenario berikut memberikan contoh bagaimana pengurangan kuota akan bekerja pada permintaan yang diselesaikan menggunakan model yang memiliki tingkat burndown 5x untuk token keluaran::

### Skenario 1: Nilai max\$1token tinggi
<a name="quotas-token-burndown-max-tokens-too-high"></a>

Asumsikan parameter berikut:
+ **InputTokenCount:** 3.000
+ **CacheReadInputTokens:** 4.000
+ **CacheWriteInputTokens:** 1.000
+ **OutputTokenCount:** 1.000
+ **max\$1tokens**: 32.000

Pengurangan kuota berikut terjadi:
+ **Pengurangan awal saat permintaan dibuat:** 40.000 (= 3.000 \$1 4.000 \$1 1.000 \$1 32.000)
+ **Pengurangan akhir yang disesuaikan setelah respons dihasilkan:** 9.000 (= 3.000 \$1 1.000 \$1 1.000 x 5)

Dalam skenario ini, lebih sedikit permintaan bersamaan dapat dibuat karena `max_tokens` parameter disetel terlalu tinggi. Hal ini mengurangi konkurensi permintaan, throughput, dan pemanfaatan kuota, karena kapasitas kuota TPM akan tercapai dengan cepat.

### Skenario 2: Nilai max\$1tokens yang dioptimalkan
<a name="quotas-token-burndown-max-tokens-optimized"></a>

Asumsikan parameter berikut:
+ **InputTokenCount:** 3.000
+ **CacheReadInputTokens:** 4.000
+ **CacheWriteInputTokens:** 1.000
+ **OutputTokenCount:** 1.000
+ **max\$1token**: 1.250

Pengurangan kuota berikut terjadi:
+ **Pengurangan awal saat permintaan dibuat:** 9.250 (= 3.000 \$1 4.000 \$1 1.000 \$1 1.250)
+ **Pengurangan akhir yang disesuaikan setelah respons dihasilkan:** 9.000 (= 3.000 \$1 1.000 \$1 1.000 x 5)

Dalam skenario ini, `max_tokens` parameter dioptimalkan, karena deduksi awal hanya sedikit lebih tinggi dari deduksi akhir yang disesuaikan. Ini membantu meningkatkan konkurensi permintaan, throughput, dan pemanfaatan kuota.

## Mengoptimalkan parameter max\$1tokens
<a name="quotas-token-burndown-max-tokens-optimize"></a>

Dengan mengoptimalkan `max_tokens` parameter, Anda dapat memanfaatkan kapasitas kuota yang dialokasikan secara efisien. Untuk membantu menginformasikan keputusan Anda tentang parameter ini, Anda dapat menggunakan Amazon CloudWatch, yang secara otomatis mengumpulkan metrik dari AWS layanan, termasuk data penggunaan token di Amazon Bedrock.

Token dicatat dalam metrik `InputTokenCount` dan `OutputTokenCount` runtime (untuk metrik lainnya, lihat. [Metrik runtime Amazon Bedrock](monitoring.md#runtime-cloudwatch-metrics)

Untuk menggunakan CloudWatch pemantauan untuk menginformasikan keputusan Anda tentang `max_tokens` parameter, lakukan hal berikut di Konsol Manajemen AWS:

1. Masuk ke CloudWatch konsol Amazon di [https://console.aws.amazon.com/cloudwatch](https://console.aws.amazon.com/cloudwatch).

1. Dari panel navigasi kiri, pilih **Dasbor**.

1. Pilih tab **Dasbor otomatis**.

1. Pilih **Bedrock**.

1. Di dasbor **Token Counts by Model**, pilih ikon perluas.

1. Pilih parameter durasi dan rentang waktu untuk metrik yang akan diperhitungkan untuk penggunaan puncak.

1. Dari menu tarik-turun berlabel **Sum**, Anda dapat memilih metrik yang berbeda untuk mengamati penggunaan token Anda. Periksa metrik ini untuk memandu keputusan Anda dalam menetapkan `max_tokens` nilai Anda.