Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Diagnostique los InvocationLatencyaumentos mediante tokens de salida por segundo (OTPS)
La InvocationLatency métrica indica la hora que tarda una solicitud de inferencia en el reloj de pared, desde el momento en que se recibe la solicitud hasta que se genera el último token de salida. Por sí sola, esta métrica no puede indicar por qué aumentó la latencia. El mismo valor elevado puede deberse a dos condiciones diferentes:
-
El modelo genera los tokens más lentamente, lo que supone un cambio en el rendimiento del servicio.
-
El modelo genera más fichas por solicitud: un cambio en la carga de trabajo, como una solicitud más larga, una solicitud del sistema actualizada o una actualización del modelo que produce respuestas más largas.
Los símbolos de salida por segundo (OTPS) aíslan el componente de rendimiento, por lo que puede alertar sobre la degradación del lado del servicio sin producir falsos positivos cuando la longitud de la salida aumenta.
nota
El cálculo de OTPS requiere la TimeToFirstToken métrica, que Amazon Bedrock publica solo para las operaciones ConverseStreamde la API de streaming y. InvokeModelWithResponseStream Los procedimientos de esta sección se aplican únicamente al tráfico de esas operaciones.
¿Cómo InvocationLatencyse relacionan TimeToFirstTokenlas OTPS y las OTPS
Una solicitud de inferencia pasa por dos etapas vinculadas a la computación en el host del modelo:
-
Rellenar previamente. El modelo procesa toda la solicitud de entrada en una sola pasada hacia adelante y produce el primer token de salida. La duración de esta etapa varía principalmente con la longitud de entrada y es el principal impulsor de
TimeToFirstToken. -
Decodificar. El modelo genera cada token de salida subsiguiente de forma secuencial, un token por cada pase directo. El tiempo total de esta etapa aumenta con el número de fichas de salida. Per-token El tiempo de decodificación es bastante estable para un modelo y una carga de host determinados, lo que hace que el OTPS sea una señal de rendimiento útil.
Estas etapas producen la siguiente relación entre las métricas de tiempo de ejecución de Amazon Bedrock:
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000
Si busca OTPS, obtendrá la fórmula que puede calcular a partir de las métricas publicadas CloudWatch :
OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000
Un OTPS estable a lo largo del tiempo indica que el modelo se está generando con el rendimiento esperado, incluso si InvocationLatency es elevado debido a que las solicitudes o las respuestas son más largas. Una caída en el OTPS indica un cambio en el rendimiento del modelo, que es la señal que normalmente se quiere activar con la alarma.
Calcula el OTPS mediante una expresión matemática métrica CloudWatch
Puede graficar OTPS en la CloudWatch consola combinando las métricas de tiempo de ejecución de Amazon Bedrock publicadas en una expresión matemática métrica. Las métricas necesarias estánInvocationLatency, y todas OutputTokenCountTimeToFirstToken, en el AWS/Bedrock espacio de nombres. Para obtener una descripción de estas métricas, consulte Métricas en tiempo de ejecución de Amazon Bedrock.
-
Abre la CloudWatch consola y selecciona Métricas y, a continuación, Todas las métricas.
-
Busque
Bedrocky seleccione la ModelId dimensión Por. -
Seleccione
InvocationLatencyOutputTokenCount, yTimeToFirstTokenpara el ID del modelo que desee supervisar. -
Para cada métrica seleccionada, defina Estadística en 5 minutos
p50y Periodo en 5 minutos. -
Selecciona Añadir matemáticas y, a continuación, empezar con una expresión vacía.
-
Introduce la siguiente expresión y etiquétala
OTPS. Ajuste los ID de métrica (m1,m2,m3) para que coincidan con los ID asignados aInvocationLatencyOutputTokenCount, yTimeToFirstTokenen su selección.m2 / (m1 - m3) * 1000
El gráfico ahora muestra p50 OTPS por ventana de 5 minutos para el modelo seleccionado. Puede usar esta expresión matemática métrica como base para una alarma.
Cree una CloudWatch alarma en OTPS
Como OTPS es una expresión matemática métrica y no una métrica publicada, puedes crear una alarma matemática métrica para crear una alarma matemática métrica. Hay dos patrones útiles, en función de si se ha establecido una línea base de rendimiento.
Alarma de umbral estático
Utilice una alarma de umbral estática cuando tenga una OTPS de referencia establecida para su modelo, por ejemplo, a partir de una evaluación comparativa o del tráfico histórico.
-
En la expresión matemática métrica OTPS creada en el procedimiento anterior, elija el icono de alarma para crear una alarma.
-
En Threshold type (Tipo de umbral), elija Static (Estático).
-
Para la condición de alarma, elija Inferior a e introduzca su umbral. Un punto de partida común es el 80 por ciento de la línea base esperada. Por ejemplo, si tu modelo suele alcanzar 55 fichas por segundo, establece el umbral en 44 fichas por segundo.
-
En Configuración adicional, defina la evaluación en 3 de cada 5 puntos de datos que infrinjan datos para reducir el ruido provocado por las caídas transitorias.
-
Defina el tratamiento de datos faltantes de la siguiente manera: Tratar los datos faltantes como una violación si quiere que las brechas se consideren una degradación, o Tratar los datos faltantes como si se espera que falten datos durante los períodos de poco tráfico.
Alarma de detección de anomalías
Utilice una alarma de detección de anomalías cuando los patrones de carga de trabajo varíen con el tiempo y desee que el umbral se adapte automáticamente. La detección de anomalías requiere datos históricos suficientes (al menos dos semanas) para crear un modelo preciso. Para las nuevas implementaciones, comience con un umbral estático.
-
Cree la alarma a partir de la expresión matemática métrica de OTPS como en el procedimiento anterior, pero para el tipo de umbral, elija Detección de anomalías.
-
Elija Más bajo que la banda. Las caídas de OTPS, no los picos, indican una degradación.
-
Establezca el umbral de detección de anomalías en 2 o 3 desviaciones estándar. Los valores más bajos producen una alarma más sensible.
-
Utilice 3 de los 5 períodos de evaluación.
-
Establezca el tratamiento de datos faltantes como se describe en el procedimiento de umbral estático.
Cree la alarma mediante programación con el AWS SDK para Python (Boto3)
El siguiente ejemplo de Python usa el AWS SDK para Python (Boto3) para crear la alarma de umbral estática descrita en la sección anterior. Sustituya MODEL_ID OTPS_THRESHOLD y por AlarmActions los valores adecuados para su entorno.
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.")