Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Diagnostiquez les `InvocationLatency`augmentations à l'aide de jetons de sortie par seconde (OTPS)
La `InvocationLatency` métrique indique l'heure d'horloge murale d'une demande d'inférence, entre le moment où la demande est reçue et le moment où le dernier jeton de sortie est produit. À elle seule, cette métrique ne permet pas de savoir *pourquoi* la latence a augmenté. La même valeur élevée peut résulter de deux conditions différentes :
+ Le modèle génère des jetons plus lentement, ce qui entraîne une modification du débit côté service.
+ Le modèle génère davantage de jetons par demande, en raison d'une modification de la charge de travail, telle qu'une invite plus longue, une invite système mise à jour ou une mise à jour du modèle qui produit des réponses plus longues.
Les jetons de sortie par seconde (OTPS) isolent le composant de débit, ce qui vous permet de déclencher une alarme en cas de dégradation côté service sans produire de faux positifs lorsque la longueur de sortie augmente.
**Note**
Le calcul de l'OTPS nécessite la `TimeToFirstToken` métrique, qu'Amazon Bedrock publie uniquement pour les opérations [ConverseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ConverseStream.html)de l'API de streaming et. [InvokeModelWithResponseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModelWithResponseStream.html) Les procédures décrites dans cette section s'appliquent uniquement au trafic de ces opérations.
## Comment `InvocationLatency`et `TimeToFirstToken`OTPS sont-ils liés
Une demande d'inférence passe par deux étapes liées au calcul sur l'hôte du modèle :
+ **Pré-remplissage.** Le modèle traite l'intégralité de l'invite d'entrée en une seule passe directe et produit le premier jeton de sortie. La durée de cette étape varie principalement en fonction de la longueur d'entrée et constitue le principal facteur de`TimeToFirstToken`.
+ **Décoder.** Le modèle génère chaque jeton de sortie suivant de manière séquentielle, un jeton par passe directe. La durée totale de cette étape varie en fonction du nombre de jetons de sortie. Per-token le temps de décodage est assez stable pour un modèle et une charge d'hôte donnés, ce qui fait de l'OTPS un signal de débit utile.
Ces étapes produisent la relation suivante entre les métriques d'exécution d'Amazon Bedrock :
```
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000
```
La résolution pour OTPS donne la formule que vous pouvez calculer à partir des CloudWatch métriques publiées :
```
OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000
```
Un OTPS stable au fil du temps indique que le modèle génère au débit attendu, même s'il `InvocationLatency` est élevé en raison de demandes ou de réponses plus longues. Une baisse de l'OTPS indique une modification du débit côté modèle, signal sur lequel vous souhaitez généralement déclencher une alarme.
## Calculer l'OTPS à l'aide d'une CloudWatch expression mathématique métrique
Vous pouvez représenter graphiquement l'OTPS dans la CloudWatch console en combinant les métriques d'exécution Amazon Bedrock publiées dans une expression mathématique métrique. Les métriques nécessaires sont`InvocationLatency`, et `OutputTokenCount``TimeToFirstToken`, toutes dans l'espace de `AWS/Bedrock` noms. Pour une description de ces métriques, consultez [Métriques d’exécution Amazon Bedrock](monitoring-runtime-metrics.md#runtime-cloudwatch-metrics).
1. Ouvrez la CloudWatch console et choisissez **Metrics**, puis **All metrics**.
1. Recherchez `Bedrock` et sélectionnez la ModelId dimension **Par**.
1. Sélectionnez `InvocationLatency``OutputTokenCount`, et `TimeToFirstToken` pour l'ID du modèle que vous souhaitez surveiller.
1. Pour chaque métrique sélectionnée, définissez la **statistique** sur 5 minutes `p50` et **la période** sur **5 minutes.**
1. Choisissez **Ajouter des données mathématiques**, puis **Commencer par une expression vide**.
1. Entrez l'expression suivante et étiquetez-la`OTPS`. Ajustez les identifiants de mesure (`m1``m2`,,`m3`) pour qu'ils correspondent aux identifiants attribués à `InvocationLatency``OutputTokenCount`, et `TimeToFirstToken` dans votre sélection.
```
m2 / (m1 - m3) * 1000
```
Le graphique indique désormais p50 OTPS par fenêtre de 5 minutes pour le modèle sélectionné. Vous pouvez utiliser cette expression mathématique métrique comme base pour une alarme.
## Création d'une CloudWatch alarme sur OTPS
OTPS étant une expression mathématique métrique plutôt qu'une métrique publiée, vous pouvez créer une alarme mathématique métrique à son sujet. Deux modèles sont utiles, selon que vous disposez ou non d'une référence de débit établie.
### Alarme de seuil statique
Utilisez une alarme de seuil statique lorsque vous disposez d'un OTPS de référence établi pour votre modèle, par exemple à partir d'une analyse comparative ou d'un historique du trafic.
1. À partir de l'expression mathématique de la métrique OTPS créée dans la procédure précédente, choisissez l'icône d'alarme pour créer une alarme.
1. Pour **Threshold type** (Type de seuil), choisissez **Static** (Statique).
1. Pour l'état de l'alarme, choisissez **Inférieur** à et entrez votre seuil. Un point de départ courant est 80 % de votre niveau de référence attendu. Par exemple, si votre modèle atteint généralement 55 jetons par seconde, définissez le seuil à 44 jetons par seconde.
1. Sous **Configuration supplémentaire**, définissez l'évaluation **sur 3 points de données sur 5 franchissant une violation afin de** réduire le bruit causé par des baisses transitoires.
1. Définissez le traitement des données manquantes sur **Traiter les données manquantes comme des violations si vous** souhaitez que les lacunes soient considérées comme une dégradation, ou sur **Traitez les données manquantes comme manquantes** si des données manquantes sont attendues pendant les périodes de faible trafic.
### Alarme de détection d'anomalie
Utilisez une alarme de détection d'anomalie lorsque les modèles de charge de travail varient dans le temps et que vous souhaitez que le seuil s'adapte automatiquement. La détection des anomalies nécessite des données historiques suffisantes (au moins deux semaines) pour créer un modèle précis. Pour les nouveaux déploiements, commencez par un seuil statique.
1. Créez l'alarme à partir de l'expression mathématique de la métrique OTPS comme dans la procédure précédente, mais pour le **type de seuil**, choisissez Détection des **anomalies**.
1. Choisissez **Plus bas que le bracelet**. Les baisses d'OTPS, et non les pics, indiquent une dégradation.
1. Réglez le seuil de détection des anomalies à 2 ou 3 écarts types. Des valeurs plus faibles produisent une alarme plus sensible.
1. Utilisez 3 périodes d'évaluation sur 5.
1. Définissez le traitement des données manquantes comme décrit dans la procédure de seuil statique.
## Créez l'alarme par programmation à l'aide du AWS Kit SDK for Python (Boto3)
L'exemple Python suivant utilise le AWS SDK pour Python (Boto3) afin de créer l'alarme de seuil statique décrite dans la section précédente. Remplacez `MODEL_ID``OTPS_THRESHOLD`, et `AlarmActions` par des valeurs adaptées à votre environnement.
```
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.")
```