Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Mendiagnosis `InvocationLatency`peningkatan menggunakan token keluaran per detik (OTPS)
`InvocationLatency`Metrik melaporkan waktu jam dinding dari permintaan inferensi, dari saat permintaan diterima hingga saat token keluaran terakhir diproduksi. Dengan sendirinya, metrik ini tidak dapat memberi tahu Anda *mengapa* latensi meningkat. Nilai tinggi yang sama dapat dihasilkan dari dua kondisi yang berbeda:
+ Model ini menghasilkan token lebih lambat — perubahan throughput sisi layanan.
+ Model ini menghasilkan lebih banyak token per permintaan — perubahan beban kerja seperti prompt yang lebih lama, prompt sistem yang diperbarui, atau pembaruan model yang menghasilkan respons yang lebih lama.
Token keluaran per detik (OTPS) mengisolasi komponen throughput, sehingga Anda dapat alarm pada degradasi sisi layanan tanpa menghasilkan positif palsu saat panjang output bertambah.
**catatan**
Perhitungan OTPS memerlukan `TimeToFirstToken` metrik, yang diterbitkan Amazon Bedrock hanya untuk operasi API streaming dan. [ConverseStream[InvokeModelWithResponseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModelWithResponseStream.html)](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ConverseStream.html) Prosedur di bagian ini hanya berlaku untuk lalu lintas pada operasi tersebut.
## Bagaimana `InvocationLatency`, `TimeToFirstToken`, dan OTPS berhubungan
Permintaan inferensi melewati dua tahap terikat komputasi pada host model:
+ **Isi terlebih dahulu.** Model memproses seluruh prompt input dalam satu pass maju dan menghasilkan token keluaran pertama. Durasi skala tahap ini terutama dengan panjang input dan merupakan pendorong utama`TimeToFirstToken`.
+ **Mendekode.** Model menghasilkan setiap token keluaran berikutnya secara berurutan, satu token per pass maju. Total waktu tahap ini berskala dengan jumlah token keluaran. Per-token waktu decode cukup stabil untuk model dan beban host tertentu, yang membuat OTPS sinyal throughput yang berguna.
Tahapan ini menghasilkan hubungan berikut antara metrik runtime Amazon Bedrock:
```
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000
```
Memecahkan OTPS memberikan rumus yang dapat Anda hitung dari metrik yang dipublikasikan CloudWatch :
```
OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000
```
OTPS yang stabil dari waktu ke waktu menunjukkan bahwa model menghasilkan pada throughput yang diharapkan, bahkan jika `InvocationLatency` meningkat karena permintaan yang lebih lama atau respons yang lebih lama. Penurunan OTPS menunjukkan perubahan throughput sisi model, yang merupakan sinyal yang biasanya ingin Anda aktifkan.
## Hitung OTPS menggunakan ekspresi matematika CloudWatch metrik
Anda dapat membuat grafik OTPS di CloudWatch konsol dengan menggabungkan metrik runtime Amazon Bedrock yang dipublikasikan dalam ekspresi matematika metrik. Metrik yang dibutuhkan adalah`InvocationLatency`,, dan `OutputTokenCount``TimeToFirstToken`, semuanya ada di `AWS/Bedrock` namespace. Untuk deskripsi metrik ini, lihat [Metrik runtime Amazon Bedrock](monitoring-runtime-metrics.md#runtime-cloudwatch-metrics).
1. Buka CloudWatch konsol dan pilih **Metrik**, lalu **Semua metrik**.
1. Cari `Bedrock` dan pilih ModelId Dimensi **Berdasarkan**.
1. Pilih`InvocationLatency`,`OutputTokenCount`, dan `TimeToFirstToken` untuk ID model yang ingin Anda pantau.
1. Untuk setiap metrik yang dipilih, atur **Statistik** ke `p50` dan **Periode** menjadi **5 menit**.
1. Pilih **Tambahkan matematika**, lalu **Mulai dengan ekspresi kosong**.
1. Masukkan ekspresi berikut dan beri label`OTPS`. Sesuaikan ID metrik (`m1``m2`,,`m3`) agar sesuai dengan ID yang ditetapkan`InvocationLatency`,`OutputTokenCount`, dan `TimeToFirstToken` dalam pilihan Anda.
```
m2 / (m1 - m3) * 1000
```
Grafik sekarang menunjukkan p50 OTPS per jendela 5 menit untuk model yang dipilih. Anda dapat menggunakan ekspresi matematika metrik ini sebagai dasar untuk alarm.
## Buat CloudWatch alarm di OTPS
Karena OTPS adalah ekspresi matematika metrik daripada metrik yang diterbitkan, Anda mengkhawatirkannya dengan membuat alarm matematika metrik. Dua pola berguna, tergantung pada apakah Anda memiliki baseline throughput yang mapan.
### Alarm ambang statis
Gunakan alarm ambang statis saat Anda memiliki OTPS dasar yang ditetapkan untuk model Anda, misalnya dari pembandingan atau lalu lintas historis.
1. Dari ekspresi matematika metrik OTPS yang dibuat dalam prosedur sebelumnya, pilih ikon alarm untuk membuat alarm.
1. Untuk **Jenis ambang batas**, pilih **Statis**.
1. Untuk kondisi alarm, pilih **Lebih rendah dari** dan masukkan ambang batas Anda. Titik awal yang umum adalah 80 persen dari garis dasar yang Anda harapkan. Misalnya, jika model Anda biasanya mencapai 55 token per detik, tetapkan ambang batas menjadi 44 token per detik.
1. Di bawah **Konfigurasi tambahan**, atur evaluasi ke **3 dari 5 titik** data yang melanggar untuk mengurangi kebisingan dari penurunan sementara.
1. Tetapkan perlakuan data yang **hilang untuk Memperlakukan data yang hilang sebagai pelanggaran** jika Anda ingin celah dihitung sebagai degradasi, atau **Perlakukan data yang hilang sebagai hilang jika data** yang hilang diharapkan selama periode lalu lintas rendah.
### Alarm deteksi anomali
Gunakan alarm deteksi anomali saat pola beban kerja bervariasi dari waktu ke waktu dan Anda ingin ambang batas beradaptasi secara otomatis. Deteksi anomali membutuhkan data historis yang cukup (setidaknya dua minggu) untuk membangun model yang akurat. Untuk penerapan baru, mulailah dengan ambang batas statis.
1. **Buat alarm dari ekspresi matematika metrik OTPS seperti pada prosedur sebelumnya, tetapi untuk **tipe Threshold**, pilih Deteksi anomali.**
1. Pilih yang **lebih rendah dari band**. OTPS turun, bukan paku, menunjukkan degradasi.
1. Atur ambang deteksi anomali ke 2 atau 3 standar deviasi. Nilai yang lebih rendah menghasilkan alarm yang lebih sensitif.
1. Gunakan 3 dari 5 periode evaluasi.
1. Atur perlakuan data yang hilang seperti yang dijelaskan dalam prosedur ambang batas statis.
## Buat alarm secara terprogram dengan AWS SDK untuk Python (Boto3)
Contoh Python berikut menggunakan AWS SDK for Python (Boto3) untuk membuat alarm ambang statis yang dijelaskan di bagian sebelumnya. Ganti`MODEL_ID`,`OTPS_THRESHOLD`, dan `AlarmActions` dengan nilai-nilai yang sesuai untuk lingkungan Anda.
```
import boto3
cw = boto3.client("cloudwatch", region_name="us-east-1")
MODEL_ID = "us.anthropic.claude-sonnet-4-5-20250929-v1:0"
ALARM_NAME = "Bedrock-OTPS-Low"
OTPS_THRESHOLD = 44 # tokens/s; set to ~80% of your expected baseline
cw.put_metric_alarm(
AlarmName=ALARM_NAME,
AlarmDescription="Fires when Bedrock OTPS drops below threshold, indicating model-side throughput degradation.",
Metrics=[
{
"Id": "m1",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Bedrock",
"MetricName": "InvocationLatency",
"Dimensions": [{"Name": "ModelId", "Value": MODEL_ID}],
},
"Period": 300,
"Stat": "p50",
},
"ReturnData": False,
},
{
"Id": "m2",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Bedrock",
"MetricName": "OutputTokenCount",
"Dimensions": [{"Name": "ModelId", "Value": MODEL_ID}],
},
"Period": 300,
"Stat": "p50",
},
"ReturnData": False,
},
{
"Id": "m3",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Bedrock",
"MetricName": "TimeToFirstToken",
"Dimensions": [{"Name": "ModelId", "Value": MODEL_ID}],
},
"Period": 300,
"Stat": "p50",
},
"ReturnData": False,
},
{
"Id": "otps",
"Expression": "m2 / (m1 - m3) * 1000",
"Label": "OTPS",
"ReturnData": True,
},
],
ComparisonOperator="LessThanThreshold",
Threshold=OTPS_THRESHOLD,
EvaluationPeriods=5,
DatapointsToAlarm=3,
TreatMissingData="ignore",
AlarmActions=[], # add SNS ARN, for example "arn:aws:sns:us-east-1:123456789012:my-topic"
)
print(f"Alarm '{ALARM_NAME}' created.")
```