Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Diagnostica gli InvocationLatencyaumenti utilizzando token di output al secondo (OTPS)
La InvocationLatency metrica riporta l'ora dell'orologio da parete di una richiesta di inferenza, dal momento in cui viene ricevuta la richiesta a quando viene prodotto l'ultimo token di output. Di per sé, questa metrica non può dirti perché la latenza è aumentata. Lo stesso valore elevato può derivare da due condizioni diverse:
-
Il modello genera i token più lentamente, con una modifica del throughput sul lato dei servizi.
-
Il modello genera più token per richiesta: una modifica del carico di lavoro, ad esempio un prompt più lungo, un prompt di sistema aggiornato o un aggiornamento del modello che produce risposte più lunghe.
I token di output al secondo (OTPS) isolano il componente di throughput, in modo da poter avvisare in caso di deterioramento sul lato del servizio senza produrre falsi positivi all'aumentare della lunghezza dell'output.
Nota
Il calcolo OTPS richiede la TimeToFirstToken metrica, che Amazon Bedrock pubblica solo per le operazioni dell'API di streaming e. ConverseStreamInvokeModelWithResponseStream Le procedure in questa sezione si applicano solo al traffico relativo a tali operazioni.
Come InvocationLatencye OTPS TimeToFirstTokensi relazionano
Una richiesta di inferenza passa attraverso due fasi legate al calcolo sull'host del modello:
-
Precompilazione. Il modello elabora l'intero prompt di input in un unico passaggio in avanti e produce il primo token di output. La durata di questa fase varia principalmente in base alla lunghezza di input ed è il fattore principale di.
TimeToFirstToken -
Decodifica. Il modello genera ogni token di output successivo in sequenza, un token per passaggio in avanti. Il tempo totale di questa fase varia in base al numero di token di output. Per-token il tempo di decodifica è abbastanza stabile per un determinato modello e carico dell'host, il che rende OTPS un segnale di throughput utile.
Queste fasi producono la seguente relazione tra le metriche di runtime di Amazon Bedrock:
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000
Solving for OTPS fornisce la formula che puoi calcolare in base alle metriche pubblicate: CloudWatch
OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000
Un OTPS stabile nel tempo indica che il modello sta generando al throughput previsto, anche se InvocationLatency è elevato a causa di richieste o risposte più lunghe. Un calo dell'OTPS indica una modifica del throughput a livello di modello, che è il segnale su cui in genere si desidera attivare l'allarme.
Calcola OTPS utilizzando un'espressione matematica metrica CloudWatch
Puoi rappresentare graficamente OTPS nella CloudWatch console combinando i parametri di runtime di Amazon Bedrock pubblicati in un'espressione matematica metrica. Le metriche necessarie sonoInvocationLatency, e OutputTokenCountTimeToFirstToken, tutte nel namespace. AWS/Bedrock Per una descrizione di questi parametri, consulta Metriche di runtime Amazon Bedrock.
-
Apri la CloudWatch console e scegli Metriche, quindi Tutte le metriche.
-
Cerca
Bedrocke seleziona la dimensione Per ModelId. -
Seleziona
InvocationLatencyeOutputTokenCountTimeToFirstTokenper l'ID del modello che desideri monitorare. -
Per ogni metrica selezionata, imposta Statistica su
p50e Periodo su 5 minuti. -
Scegli Aggiungi matematica, quindi Inizia con un'espressione vuota.
-
Inserisci la seguente espressione ed etichettala.
OTPSModifica gli ID delle metriche (m1,m2,m3) in modo che corrispondano agli ID assegnati aInvocationLatencyOutputTokenCount, eTimeToFirstTokenpresenti nella selezione.m2 / (m1 - m3) * 1000
Il grafico ora mostra p50 OTPS per finestra di 5 minuti per il modello selezionato. È possibile utilizzare questa espressione matematica metrica come base per un allarme.
Crea un CloudWatch allarme su OTPS
Poiché OTPS è un'espressione matematica metrica anziché una metrica pubblicata, puoi allarmarla creando un allarme matematico metrico. Sono utili due modelli, a seconda che si disponga di una linea di base di throughput stabilita.
allarme di soglia statica
Utilizza un allarme di soglia statica quando disponi di una OTPS di base stabilita per il tuo modello, ad esempio derivante dal benchmarking o dallo storico del traffico.
-
Dall'espressione matematica metrica OTPS creata nella procedura precedente, scegli l'icona di allarme per creare un allarme.
-
For Threshold type (Tipo di soglia), scegli Static (Statica).
-
Per la condizione di allarme, scegli Inferiore a e inserisci la soglia. Un punto di partenza comune è l'80 percento della linea di base prevista. Ad esempio, se il modello raggiunge in genere 55 token al secondo, imposta la soglia su 44 token al secondo.
-
In Configurazione aggiuntiva, imposta la valutazione sulla violazione di 3 punti dati su 5 per ridurre il rumore causato dai cali transitori.
-
Imposta il trattamento dei dati mancanti su Tratta i dati mancanti come violazione se desideri che le lacune vengano conteggiate come degradazione, oppure Tratta i dati mancanti come mancanti se si prevede che i dati mancanti siano rilevati durante i periodi di traffico ridotto.
Allarme di rilevamento delle anomalie
Utilizza un allarme di rilevamento delle anomalie quando i modelli di carico di lavoro variano nel tempo e desideri che la soglia si adatti automaticamente. Il rilevamento delle anomalie richiede dati storici sufficienti (almeno due settimane) per creare un modello accurato. Per le nuove implementazioni, inizia con una soglia statica.
-
Crea l'allarme dall'espressione matematica della metrica OTPS come nella procedura precedente, ma per Tipo di soglia, scegli Rilevamento delle anomalie.
-
Scegliete Inferiore alla banda. Le cadute di OTPS, non i picchi, indicano un deterioramento.
-
Imposta la soglia di rilevamento delle anomalie su 2 o 3 deviazioni standard. Valori più bassi producono un allarme più sensibile.
-
Utilizza 3 periodi di valutazione su 5.
-
Imposta il trattamento dei dati mancanti come descritto nella procedura di soglia statica.
Crea l'allarme a livello di codice con AWS SDK per Python (Boto3)
Il seguente esempio di Python utilizza l' AWS SDK for Python (Boto3) per creare l'allarme di soglia statica descritto nella sezione precedente. Sostituisci e AlarmActions con MODEL_ID valori OTPS_THRESHOLD appropriati per il tuo ambiente.
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.")