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.
# Bewährte Methoden für Skalierung und Durchsatz
In diesem Thema wird erklärt, wie Durchsatzbeschränkungen und Planung auf Amazon Bedrock-Endpunkten funktionieren, und es werden bewährte Methoden für die Skalierung Ihrer generativen KI-Anwendungen vorgestellt.
## Amazon-Bedrock-Endpunkte
Amazon Bedrock unterstützt zwei Endpunkte für Inferenz:
+ `bedrock-mantle.{region}.api.aws`— Unterstützt Chat-Abschlüsse und -Antworten (von OpenAI) und Nachrichten (von Anthropic).
+ `bedrock-runtime.{region}.amazonaws.com`— Unterstützt Bedrock-native APIs (Invoke und Converse), Chat-Abschlüsse und Nachrichten-APIs.
Weitere Informationen zu diesen Endpunkten und zur Auswahl zwischen ihnen finden Sie unter. [Von Amazon Bedrock unterstützte Endgeräte](endpoints.md)
### Warum verhalten sich die beiden Endpunkte unterschiedlich
Bei vielen traditionellen Multi-Tenant-Diensten ist die Architektur auf Kontingenten pro Konto ausgelegt, um einen fairen Zugriff auf gemeinsam genutzte Ressourcen zu gewährleisten. Dies ist der Ansatz, der bei verwendet wird. [`bedrock-runtime`](endpoints.md)
Bei [`bedrock-mantle`](endpoints.md)wird ein anderer Ansatz verwendet. Dieser Endpunkt ist mit fortschrittlichen Planungs- und Warteschlangenmechanismen ausgestattet, die eine faire Verteilung ermöglichen und gleichzeitig höhere anfängliche Durchsatzgrenzen unterstützen. Dieses Design ermöglicht es auch, eine breite Palette von Modellen `bedrock-mantle` zu hosten und die gesamte Bandbreite der Funktionen bereitzustellen, die im gesamten Modellkatalog verfügbar sind. In den meisten Fällen werden Anfragen sofort bearbeitet. In einigen Fällen kann es vorkommen, dass eine Anfrage kurzzeitig in die Warteschlange gestellt wird, während die laufenden Arbeitslasten abgeschlossen sind und der Durchsatz verfügbar ist. In den folgenden Abschnitten wird erklärt, wie mit diesen Szenarien umgegangen werden kann.
## Endpunkt im `Grundgefüge: Durchsatz` und Kontingente
Für alle Modelle gilt ein `bedrock-mantle` einheitliches festes Limit von 10.000 U/min pro Konto und Region. Es gibt einige Unterschiede im Verhalten von Durchsatz und Kontingenten bei Claude im Vergleich zu anderen Modellen, wie unten dargestellt.
| | Claude 4,7\+ | Alle anderen Modelle |
| --- | --- | --- |
| Geben Sie TPM ein | 10 M \* | Kein TPM-Limit pro Kunde oder Modell |
| TPM ausgeben | 2 M | Kein TPM-Limit pro Kunde oder Modell |
| RPM | 10.000 (wird von allen Modellen an diesem Endpunkt gemeinsam genutzt) | 10.000 (wird von allen Modellen auf diesem Endpunkt gemeinsam genutzt) |
| On-demand Stufen | Standard | Standard, Priority, Flex (einige Ausnahmen) — Informationen zur Verfügbarkeit finden Sie auf den Modelldetailseiten |
| Batch | Nein | Ja für unterstützte Modelle — Informationen zur Verfügbarkeit finden Sie auf den Modelldetailseiten |
| Reservierte Kapazität | Keine | Keine |
\* Ihr TPM-Eingabelimit hängt von Ihrer Nutzungshistorie bei Amazon Bedrock ab. Auf der Seite [Kontingente](https://console.aws.amazon.com/bedrock/home#/model-quotas) in der Amazon Bedrock-Konsole finden Sie Ihre tatsächliche Zuteilung.
## `Bedrock-Runtime-Endpunkt`: Durchsatz und Kontingente
In der folgenden Tabelle sind der Durchsatz und die Kontingente für zusammengefasst. `bedrock-runtime`
| | Claude 4,7\+ | Alle anderen Modelle |
| --- | --- | --- |
| Geben Sie TPM ein | 15 M \* | Variiert \* |
| Ausgabe TPM | Kombiniert mit Eingabe-TPM. Burndown gilt. | Keine. Burndown gilt. |
| RPM | 10.000 (auf alle Modelle verteilt) | Variiert \* |
| On-demand Stufen | Standard | Standard, Priority, Flex (einige Ausnahmen) — Informationen zur Verfügbarkeit finden Sie auf den Modelldetailseiten |
| Batch | Nein | Ja für unterstützte Modelle — Informationen zur Verfügbarkeit finden Sie auf den Modelldetailseiten |
| Reservierte Kapazität | Keine | Reservierte Tier/Provisioned Kapazität |
\* Die Kontingente für diese Modelle variieren je nach Nutzung. Auf der Seite [Kontingente](https://console.aws.amazon.com/bedrock/home#/model-quotas) in der Amazon Bedrock-Konsole finden Sie Ihre Zuweisungen.
## Grundlegendes zu HTTP-Fehlerantworten
HTTP 429
Eine 429-Antwort bedeutet, dass Sie das RPM-Limit für Ihr Konto überschritten haben. Reduzieren Sie die Einreichungsrate Ihrer Anfragen. Wenn Sie eine höhere RPM-Zuteilung benötigen, fordern Sie eine Erhöhung über die [Service Quotas Quota-Konsole](https://console.aws.amazon.com/servicequotas/home) an oder wenden Sie sich an Ihr AWS-Konto Team.
HTTP 503
Eine Antwort von 503 bedeutet, dass in dieser Region eine erhöhte Nachfrage nach Amazon Bedrock besteht. Sie sollten Ihre Anforderungsrate reduzieren und es dann entweder mit exponentiellem Backoff erneut versuchen oder den Traffic auf mehrere Regionen verteilen.
## Empfohlene Fehlerbehandlung
### Vorübergehende Fehler (gelegentlich 503-Antworten)
Implementieren Sie einen exponentiellen Backoff mit zufälligem Jitter:
+ Beginnen Sie mit einer kurzen Verzögerung (z. B. 1 Sekunde).
+ Verdoppeln Sie die Verzögerung nach jedem fehlgeschlagenen Versuch.
+ Beschränken Sie die Wiederholungsversuche auf 6 Versuche.
Die meisten AWS SDKs und gängigen HTTP-Bibliotheken bieten integrierte Unterstützung für dieses Muster.
**Example `Versuchen Sie erneut, die Konfiguration für Bedrock-Runtime zu konfigurieren (`AWS SDK//boto3)**
```
import boto3
from botocore.config import Config
config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)
```
**Example Konfiguration für `Bedrock-Mantle` erneut versuchen (OpenAI SDK)**
```
from openai import OpenAI
client = OpenAI(
api_key=api_key,
base_url=f"https://bedrock-mantle.{region}.api.aws/v1",
max_retries=6,
timeout=60.0,
)
```
**Example `Versuchen Sie erneut, die Konfiguration für Bedrock-Mantle (Anthropic SDK) zu konfigurieren`**
```
import anthropic
client = anthropic.Anthropic(
api_key=api_key,
base_url=f"https://bedrock-mantle.{region}.api.aws",
max_retries=6,
timeout=60.0,
)
```
### Anhaltende Fehler (persistente 503-Antworten)
Wenn Sie anhaltende 503-Fehler erhalten, kann das Problem durch einen erneuten Versuch allein nicht behoben werden. Ihre Anforderungsrate übersteigt den verfügbaren Durchsatz. Gehen Sie dazu wie folgt vor:
+ Reduzieren Sie die Rate, mit der Ihre Anwendung neue Anfragen einreicht.
+ Implementieren Sie eine clientseitige Ratenbegrenzung oder Anforderungswarteschlangen.
+ Löschen Sie Anfragen mit niedrigerer Priorität, bis der Durchsatz wiederhergestellt ist.
## Steigerung des Durchsatzes
Wenn der On-Demand-Durchsatz auf dem [`bedrock-mantle`](endpoints.md)Endpunkt genutzt wird, steigt der verfügbare Durchsatz mit der Zeit. Es ist nicht garantiert, dass alle Anfragen innerhalb Ihres Kontingents in Zeiten hoher Nachfrage erfolgreich sind. Daher ist eine schrittweise Erhöhung wichtig.
### Empfohlenes Verfahren zur Inbetriebnahme
1. Beginnen Sie mit Ihrem Zielvolumen für Anfragen, z. B. 500 U/min.
1. Wenn Sie 503 Antworten erhalten, reduzieren Sie Ihre Rate, beispielsweise um 50%.
1. Reduzieren Sie weiter um diese Rate, bis Sie einen stabilen Zustand erreicht haben, in dem Anfragen durchweg erfolgreich sind.
1. Halten Sie diesen stabilen Zustand für eine kurze Zeit, sagen wir 15 Minuten, aufrecht.
1. Erhöhen Sie den Durchsatz erneut, beispielsweise um 50%, und halten Sie ihn für weitere 15 Minuten.
1. Wiederholen Sie den Vorgang, bis Sie Ihr Zielvolumen erreicht haben.
Wenn Ihr Ziel beispielsweise 2.000 U/min ist, Sie aber 503 Fehler erhalten, reduzieren Sie es auf 1.000 U/min. Wenn die Fehler weiterhin bestehen, reduzieren Sie die Geschwindigkeit auf 500 U/min. Sobald Anfragen bei 500 U/min konsistent erfolgreich sind, halten Sie den Vorgang 15 Minuten lang gedrückt und skalieren Sie dann auf 750, dann auf 1.125 usw.
Die Rampenraten sind nicht einstellbar. Verwenden Sie die [Service Quotas Quotas-Konsole](https://console.aws.amazon.com/servicequotas/home), um eine höhere RPM-Zuteilung anzufordern.
## Weitere bewährte Methoden
+ Verwenden Sie Feature-Flags, um den Verkehr schrittweise zwischen Modellen zu verlagern, anstatt den gesamten Verkehr auf einmal umzuschalten.
+ Verteilen Sie große Workloads auf mehrere Minuten und berücksichtigen Sie Tageszeitmuster, um Spitzennutzungsperioden zu vermeiden.
+ Beginnen Sie mit Tests in kleinen Chargen und skalieren Sie diese schrittweise. Vermeiden Sie es, Tausende von Testanfragen gleichzeitig zu senden.
+ Verwenden Sie für die Verarbeitung großer Offline-Daten die [Batch-API](batch-inference.md) oder [Flex Tier](service-tiers-inference.md), wenn Ihre Anwendung Antworten asynchron verarbeiten kann.
## Regionale Verfügbarkeit und regionsübergreifende Inferenz
On-demand Der Durchsatz wird auf regionaler Ebene zugewiesen und ist von Region zu Region unterschiedlich. Wenn Ihr Workload auf eine einzelne Region abzielt, können Sie in Zeiten hoher Nachfrage auf 503 Antworten stoßen. Um die Verfügbarkeit zu maximieren, und wenn Sie verwenden [`bedrock-runtime`](endpoints.md), verwenden Sie[Globale regionsübergreifende Inferenz](global-cross-region-inference.md).
## Hilfe erhalten
+ **Durchsatzplanung** — Wenden Sie sich an Ihr AWS-Konto Team, um Durchsatzprognosen zu erhalten. Planen Sie bei Skalierungsereignissen den 2- bis 3-fachen Spitzendurchsatz ein.
+ **Leistungsoptimierung** — Überwachen Sie die Effizienz der Token-Nutzung, optimieren Sie die Eingabeaufforderungen, um den Token-Verbrauch zu reduzieren, und wählen Sie Modelle auf der Grundlage Ihrer Anwendungsfallanforderungen aus.
+ **Support-Eskalation** — Wenn Sie eine AWS Support-Anfrage für Durchsatzprobleme eröffnen, geben Sie Folgendes an: spezifische Fehlercodes, Anfrage-IDs, Verkehrsmuster (RPM/TPM) und Ihren Skalierungszeitplan.
## Zusammenfassung der Empfehlungen
| Szenario | Empfehlung |
| --- | --- |
| Allgemeine Arbeitsbelastungen | Verwenden Sie den [`bedrock-mantle`Endpunkt](endpoints.md) wann immer möglich. |
| Gelegentliche 503-Fehler | Versuchen Sie es erneut mit exponentiellem Backoff und Jitter. |
| Anhaltende 503-Fehler | Reduzieren Sie die Rate der Einreichung von Anfragen. Implementieren Sie eine clientseitige Ratenbegrenzung. |
| 429 Fehler | Reduzieren Sie die Anforderungsrate. Fordern Sie über [Service Quotas](https://console.aws.amazon.com/servicequotas/home) eine höhere RPM-Zuteilung an. |
| Umfangreiche Offline-Verarbeitung | Verwenden Sie [Batch-API](batch-inference.md) oder [Flex Tier](service-tiers-inference.md). |