As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Diagnostique InvocationLatencyaumentos usando tokens de saída por segundo (OTPS)
A InvocationLatency métrica relata o tempo de espera de uma solicitação de inferência, desde o momento em que a solicitação é recebida até quando o último token de saída é produzido. Por si só, essa métrica não pode dizer por que a latência aumentou. O mesmo valor elevado pode resultar de duas condições diferentes:
-
O modelo está gerando tokens mais lentamente — uma mudança na taxa de transferência do lado do serviço.
-
O modelo está gerando mais tokens por solicitação — uma alteração na carga de trabalho, como uma solicitação mais longa, uma solicitação atualizada do sistema ou uma atualização do modelo que produz respostas mais longas.
Os tokens de saída por segundo (OTPS) isolam o componente de taxa de transferência, para que você possa alertar sobre a degradação do lado do serviço sem produzir falsos positivos quando o comprimento da saída aumentar.
nota
O cálculo do OTPS requer a TimeToFirstToken métrica, que o Amazon Bedrock publica somente para as operações da API de streaming e. ConverseStreamInvokeModelWithResponseStream Os procedimentos desta seção se aplicam somente ao tráfego nessas operações.
Como InvocationLatency, TimeToFirstToken, e OTPS se relacionam
Uma solicitação de inferência passa por dois estágios vinculados à computação no host do modelo:
-
Pré-preenchimento. O modelo processa todo o prompt de entrada em uma única passagem direta e produz o primeiro token de saída. A duração desse estágio varia principalmente com o comprimento da entrada e é o principal fator de
TimeToFirstToken. -
Decodificar. O modelo gera cada token de saída subsequente sequencialmente, um token por passagem direta. O tempo total desse estágio é dimensionado com o número de tokens de saída. Per-token o tempo de decodificação é bastante estável para um determinado modelo e carga do host, o que torna o OTPS um sinal de taxa de transferência útil.
Esses estágios produzem a seguinte relação entre as métricas de tempo de execução do Amazon Bedrock:
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000
A solução para OTPS fornece a fórmula que você pode calcular a partir de métricas publicadas CloudWatch :
OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000
Um OTPS estável ao longo do tempo indica que o modelo está gerando a taxa de transferência esperada, mesmo que InvocationLatency seja elevada devido a solicitações mais longas ou respostas mais longas. Uma queda no OTPS indica uma alteração na taxa de transferência do lado do modelo, que é o sinal que você normalmente deseja ativar.
Calcular OTPS usando uma expressão matemática CloudWatch métrica
Você pode representar graficamente o OTPS no CloudWatch console combinando métricas de tempo de execução publicadas do Amazon Bedrock em uma expressão matemática métrica. As métricas necessárias estãoInvocationLatency,OutputTokenCount, eTimeToFirstToken, todas no AWS/Bedrock namespace. As descrições completas dessas métricas estão disponíveis em Métricas de runtime do Amazon Bedrock.
-
Abra o CloudWatch console e escolha Métricas, depois Todas as métricas.
-
Pesquise
Bedrocke selecione a ModelId dimensão Por. -
Selecione
InvocationLatencyOutputTokenCount, eTimeToFirstTokenpara o ID do modelo que você deseja monitorar. -
Para cada métrica selecionada, defina Estatística como
p50e Período como 5 minutos. -
Escolha Adicionar matemática e, em seguida, Iniciar com uma expressão vazia.
-
Insira a expressão a seguir e rotule-a
OTPS. Ajuste os IDs de métrica (m1m2,,m3) para corresponder aos IDs atribuídos aInvocationLatencyOutputTokenCount, eTimeToFirstTokenem sua seleção.m2 / (m1 - m3) * 1000
O gráfico agora mostra p50 OTPS por janela de 5 minutos para o modelo selecionado. Você pode usar essa expressão matemática métrica como base para um alarme.
Crie um CloudWatch alarme no OTPS
Como o OTPS é uma expressão matemática métrica em vez de uma métrica publicada, você o alerta criando um alarme matemático métrico. Dois padrões são úteis, dependendo se você tem uma linha de base de produtividade estabelecida.
Alarme de limite estático
Use um alarme de limite estático quando tiver um OTPS de linha de base estabelecido para seu modelo, por exemplo, a partir de benchmarking ou histórico de tráfego.
-
Na expressão matemática métrica OTPS criada no procedimento anterior, escolha o ícone de alarme para criar um alarme.
-
Em Tipo de limite, escolha Estático.
-
Para a condição de alarme, escolha Inferior a e insira seu limite. Um ponto de partida comum é 80% da linha de base esperada. Por exemplo, se seu modelo normalmente atinge 55 tokens por segundo, defina o limite para 44 tokens por segundo.
-
Em Configuração adicional, defina a avaliação para 3 em cada 5 pontos de dados violados para reduzir o ruído causado por quedas transitórias.
-
Defina o tratamento de dados ausentes como Tratar os dados perdidos como violação se quiser que as lacunas sejam contabilizadas como degradação, ou Tratar os dados perdidos como perdidos se houver expectativa de dados perdidos durante períodos de baixo tráfego.
Alarme de detecção de anomalias
Use um alarme de detecção de anomalias quando os padrões de carga de trabalho variarem com o tempo e você quiser que o limite se adapte automaticamente. A detecção de anomalias requer dados históricos suficientes (pelo menos duas semanas) para criar um modelo preciso. Para novas implantações, comece com um limite estático.
-
Crie o alarme a partir da expressão matemática métrica OTPS, como no procedimento anterior, mas para Tipo de limite, escolha Detecção de anomalias.
-
Escolha Menor que a banda. Quedas de OTPS, não picos, indicam degradação.
-
Defina o limite de detecção de anomalias para 2 ou 3 desvios padrão. Valores mais baixos produzem um alarme mais sensível.
-
Use 3 dos 5 períodos de avaliação.
-
Defina o tratamento de dados faltantes conforme descrito no procedimento de limite estático.
Crie o alarme programaticamente com o AWS SDK para Python (Boto3)
O exemplo de Python a seguir usa o AWS SDK para Python (Boto3) para criar o alarme de limite estático descrito na seção anterior. Substitua MODEL_IDOTPS_THRESHOLD,, e AlarmActions por valores apropriados para seu 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.")