Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Diagnostizieren Sie `InvocationLatency`Zunahmen mithilfe von Output-Token pro Sekunde (OTPS)
Die `InvocationLatency` Metrik gibt die Uhrzeit einer Inferenzanforderung an, d. h. ab dem Zeitpunkt, zu dem die Anfrage empfangen wurde, bis zu dem Zeitpunkt, zu dem das letzte Ausgabetokens erzeugt wird. Diese Metrik allein kann Ihnen nicht sagen, *warum* die Latenz zugenommen hat. Derselbe erhöhte Wert kann auf zwei verschiedene Bedingungen zurückzuführen sein:
+ Das Modell generiert Tokens langsamer — eine Änderung des dienstseitigen Durchsatzes.
+ Das Modell generiert mehr Token pro Anfrage — eine Änderung der Arbeitslast, z. B. eine längere Aufforderung, eine aktualisierte Systemaufforderung oder eine Modellaktualisierung, die zu längeren Antworten führt.
Output Tokens per Second (OTPS) isoliert die Durchsatzkomponente, sodass Sie bei einer Beeinträchtigung der Serviceseite einen Alarm auslösen können, ohne dass bei zunehmender Ausgabelänge Fehlalarme ausgegeben werden.
**Anmerkung**
Für die OTPS-Berechnung ist die `TimeToFirstToken` Metrik erforderlich, die Amazon Bedrock nur für die Streaming-API-Operationen [ConverseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_ConverseStream.html)und veröffentlicht. [InvokeModelWithResponseStream](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModelWithResponseStream.html) Die Verfahren in diesem Abschnitt gelten nur für den Datenverkehr bei diesen Vorgängen.
## Wie `InvocationLatencyTimeToFirstToken`, und OTPS zusammenhängen
Eine Inferenzanforderung durchläuft zwei rechnergestützte Phasen auf dem Modellhost:
+ **Vorfüllen.** Das Modell verarbeitet die gesamte Eingabeaufforderung in einem einzigen Vorwärtsdurchlauf und erzeugt das erste Ausgabetoken. Die Dauer dieser Phase hängt hauptsächlich von der Länge der Eingabe ab und ist der Hauptgrund dafür`TimeToFirstToken`.
+ **Decodieren.** Das Modell generiert jedes nachfolgende Ausgabetoken sequentiell, ein Token pro Vorwärtsdurchgang. Die Gesamtzeit dieser Phase skaliert mit der Anzahl der Ausgabetokens. Per-token Die Decodierungszeit ist für ein bestimmtes Modell und eine bestimmte Hostlast ziemlich stabil, was OTPS zu einem nützlichen Durchsatzsignal macht.
Diese Phasen stellen die folgende Beziehung zwischen den Amazon Bedrock-Laufzeitmetriken her:
```
InvocationLatency (ms) = TimeToFirstToken (ms) + (OutputTokenCount / OTPS) * 1000
```
Wenn Sie nach OTPS suchen, erhalten Sie die Formel, die Sie anhand veröffentlichter CloudWatch Metriken berechnen können:
```
OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000
```
Ein stabiles OTPS im Zeitverlauf weist darauf hin, dass das Modell mit dem erwarteten Durchsatz generiert, auch wenn der Durchsatz aufgrund längerer Eingabeaufforderungen oder längerer Antworten erhöht `InvocationLatency` ist. Ein Rückgang des OTPS weist auf eine modellseitige Änderung des Durchsatzes hin. Dies ist das Signal, bei dem Sie normalerweise einen Alarm auslösen möchten.
## Berechnen Sie OTPS mithilfe eines metrischen mathematischen Ausdrucks CloudWatch
Sie können OTPS in der CloudWatch Konsole grafisch darstellen, indem Sie veröffentlichte Amazon Bedrock-Laufzeitmetriken in einem metrischen mathematischen Ausdruck kombinieren. Die benötigten `InvocationLatency` Metriken `OutputTokenCount` befinden sich alle im `AWS/Bedrock` Namespace. `TimeToFirstToken` Beschreibungen dieser Metriken finden Sie unter [Amazon-Bedrock-Laufzeitmetrik](monitoring-runtime-metrics.md#runtime-cloudwatch-metrics).
1. Öffnen Sie die CloudWatch Konsole und wählen Sie **Metriken** und dann **Alle Metriken** aus.
1. Suchen Sie nach der ModelId Dimension **Nach `Bedrock`** und wählen Sie sie aus.
1. Wählen Sie `InvocationLatency``OutputTokenCount`, und `TimeToFirstToken` für die Modell-ID aus, die Sie überwachen möchten.
1. Legen Sie für jede ausgewählte Metrik **Statistik** auf `p50` und **Zeitraum** auf **5 Minuten** fest.
1. Wählen Sie **Mathematik hinzufügen** und dann **Mit leerem Ausdruck beginnen** aus.
1. Geben Sie den folgenden Ausdruck ein und beschriften Sie ihn`OTPS`. Passen Sie die Metrik-IDs (`m1`,`m2`,`m3`) so an, dass sie mit den IDs übereinstimmen`InvocationLatency`, die`OutputTokenCount`, und `TimeToFirstToken` in Ihrer Auswahl zugewiesen sind.
```
m2 / (m1 - m3) * 1000
```
Das Diagramm zeigt jetzt p50 OTPS pro 5-Minuten-Fenster für das ausgewählte Modell. Sie können diesen metrischen mathematischen Ausdruck als Grundlage für einen Alarm verwenden.
## Erstellen Sie einen CloudWatch Alarm auf OTPS
Da es sich bei OTPS eher um einen metrischen mathematischen Ausdruck als um eine veröffentlichte Metrik handelt, können Sie darauf aufmerksam machen, indem Sie einen metrischen mathematischen Alarm erstellen. Zwei Muster sind nützlich, je nachdem, ob Sie über eine festgelegte Durchsatzbasis verfügen.
### Statischer Schwellenwertalarm
Verwenden Sie einen statischen Schwellenwertalarm, wenn Sie für Ihr Modell ein Basis-OTPS festgelegt haben, z. B. durch Benchmarking oder historischen Traffic.
1. Wählen Sie aus dem mathematischen OTPS-Metrikausdruck, der im vorherigen Verfahren erstellt wurde, das Alarmsymbol aus, um einen Alarm zu erstellen.
1. Wählen Sie für **Threshold type** (Schwellenwerttyp) die Option **Static** (Statisch) aus.
1. Wählen Sie für die Alarmbedingung **Niedriger als** aus und geben Sie Ihren Schwellenwert ein. Ein üblicher Ausgangspunkt sind 80 Prozent Ihres erwarteten Ausgangswerts. Wenn Ihr Modell beispielsweise in der Regel 55 Tokens pro Sekunde erreicht, legen Sie den Schwellenwert auf 44 Tokens pro Sekunde fest.
1. Stellen Sie unter **Zusätzliche Konfiguration** die Bewertung auf **3 von 5** Datenpunktverletzungen ein, um das Rauschen aufgrund vorübergehender Einbrüche zu reduzieren.
1. Legen Sie für die Behandlung fehlender Daten die Option **Fehlende Daten als Sicherheitsverletzung behandeln** fest, wenn Lücken als Verschlechterung gewertet werden sollen, oder **Fehlende Daten als fehlend behandeln, wenn in Zeiten mit geringem Datenaufkommen mit fehlenden** Daten zu rechnen ist.
### Alarm bei Erkennung von Anomalien
Verwenden Sie einen Alarm zur Erkennung von Anomalien, wenn sich die Arbeitslastmuster im Laufe der Zeit ändern und Sie möchten, dass sich der Schwellenwert automatisch anpasst. Für die Erkennung von Anomalien sind ausreichend historische Daten (mindestens zwei Wochen) erforderlich, um ein genaues Modell zu erstellen. Beginnen Sie bei neuen Bereitstellungen mit einem statischen Schwellenwert.
1. Erstellen Sie den Alarm wie im vorherigen Verfahren anhand des mathematischen Ausdrucks der OTPS-Metrik, wählen Sie jedoch als **Schwellenwerttyp** die Option **Anomalieerkennung** aus.
1. Wählen Sie **Niedriger als das Band**. OTPS-Rückgänge, keine Spitzen, deuten auf eine Verschlechterung hin.
1. Stellen Sie den Schwellenwert für die Erkennung von Anomalien auf 2 oder 3 Standardabweichungen ein. Niedrigere Werte erzeugen einen empfindlicheren Alarm.
1. Verwenden Sie 3 von 5 Bewertungszeiträumen.
1. Stellen Sie die Behandlung fehlender Daten wie im Verfahren mit statischen Schwellenwerten beschrieben ein.
## Erstellen Sie den Alarm programmgesteuert mit dem AWS SDK für Python (Boto3)
Das folgende Python-Beispiel verwendet das AWS SDK für Python (Boto3), um den im vorherigen Abschnitt beschriebenen statischen Schwellenwertalarm zu erstellen. Ersetzen Sie `MODEL_ID``OTPS_THRESHOLD`, und `AlarmActions` durch Werte, die für Ihre Umgebung geeignet sind.
```
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.")
```