

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 `InvocationLatency`aumentos mediante tokens de salida por segundo (OTPS)
<a name="monitoring-runtime-otps"></a>

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 [ConverseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ConverseStream.html)de la API de streaming y. [InvokeModelWithResponseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModelWithResponseStream.html) Los procedimientos de esta sección se aplican únicamente al tráfico de esas operaciones.

## ¿Cómo `InvocationLatency`se relacionan `TimeToFirstToken`las OTPS y las OTPS
<a name="monitoring-runtime-otps-formula"></a>

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
<a name="monitoring-runtime-otps-metric-math"></a>

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án`InvocationLatency`, y todas `OutputTokenCount``TimeToFirstToken`, 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](monitoring-runtime-metrics.md#runtime-cloudwatch-metrics).

1. Abre la CloudWatch consola y selecciona **Métricas y, a continuación, **Todas las** métricas**.

1. Busque `Bedrock` y seleccione la ModelId dimensión **Por**.

1. Seleccione `InvocationLatency``OutputTokenCount`, y `TimeToFirstToken` para el ID del modelo que desee supervisar.

1. Para cada métrica seleccionada, defina **Estadística** en 5 minutos `p50` y **Periodo** en **5 minutos.**

1. Selecciona **Añadir matemáticas** y, **a continuación, empezar con una expresión vacía**.

1. 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 a `InvocationLatency``OutputTokenCount`, y `TimeToFirstToken` en 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
<a name="monitoring-runtime-otps-alarm"></a>

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
<a name="monitoring-runtime-otps-alarm-static"></a>

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.

1. En la expresión matemática métrica OTPS creada en el procedimiento anterior, elija el icono de alarma para crear una alarma.

1. En **Threshold type (Tipo de umbral)**, elija **Static (Estático)**.

1. 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.

1. 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.

1. 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
<a name="monitoring-runtime-otps-alarm-anomaly"></a>

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.

1. 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**.

1. Elija **Más bajo que la banda**. Las caídas de OTPS, no los picos, indican una degradación.

1. 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.

1. Utilice 3 de los 5 períodos de evaluación.

1. 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)
<a name="monitoring-runtime-otps-boto3"></a>

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.")
```