View a markdown version of this page

Best Practices für Skalierung und Durchsatz - Amazon Bedrock
Amazon-Bedrock-EndpunkteEndpunkt: Durchsatz und KontingenteBedrock-Runtime-Endpunkt: Durchsatz und KontingenteGrundlegendes zu HTTP-FehlerantwortenEmpfohlene FehlerbehandlungErhöhung des DurchsatzesWeitere bewährte MethodenRegionale Verfügbarkeit und regionsübergreifende InferenzHilfe erhaltenZusammenfassung der Empfehlungen

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.

Best Practices für Skalierung und Durchsatz

In diesem Thema wird erklärt, wie Durchsatzbeschränkungen und Zeitplanung auf allen 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 Inferenzen:

  • bedrock-mantle.{region}.api.aws— Unterstützt die APIs für OpenAI-compatible Chat-Abschlüsse und Antworten sowie die Anthropic Messages API.

  • bedrock-runtime.{region}.amazonaws.com— Unterstützt die APIs Bedrock-native InvokeModel und Converse, die APIs für OpenAI-compatible Chat-Abschlüsse und Antworten sowie die Anthropic Messages API.

Beginnen Sie für die meisten neuen Anwendungen mit. bedrock-runtime Verwenden Sie diese Option, bedrock-mantle wenn Sie Funktionen benötigen, die nur auf diesem Endpunkt verfügbar sind, z. B. serverseitige Tools, Hintergrundinferenz, Projekte, Arbeitsbereiche oder ein Modell, das nur für verfügbar ist. bedrock-mantle Sie können beide Endpunkte in derselben Anwendung verwenden. Einen vollständigen Vergleich finden Sie unterVon Amazon Bedrock unterstützte Endpunkte.

Warum verhalten sich die beiden Endpunkte unterschiedlich

Beide Endpunktoberflächen verwenden dieselbe zugrundeliegende Inferenz-Engine, aber ihre Optionen für die Quotenberechnung und Kapazität unterscheiden sich. bedrock-runtimeverwendet Token-Kontingente pro Modell und bei einigen Modellen Quoten für Anfragen pro Minute (RPM). bedrock-mantleerzwingt keine RPM-Kontingente und verwendet separate Eingabe- und Ausgabe-Token-Kontingente für Modelle, für die Kontingente veröffentlicht wurden. Bei anderen Modellen sind die Kontingente pro Konto bedrock-mantle möglicherweise nicht in den Dienstkontingenten angegeben, aber ihr Durchsatz wird immer noch von der internen Servicekapazität bestimmt.

Ein Kontingent ist eine Obergrenze und keine Garantie dafür, dass jede On-Demand-Anfrage sofort bearbeitet wird. In Zeiten hoher Nachfrage können Anfragen in die Warteschlange gestellt werden oder es kommt zu vorübergehenden Kapazitätsfehlern. Entwerfen Sie Ihre Anwendung so, dass sie Parallelität, Arbeit in Warteschlangen und vorübergehende Fehler wiederholt, ohne dass es zu einem Anstieg der Wiederholungsversuche kommt.

Endpunkt: Durchsatz und Kontingente

Der bedrock-mantle Endpunkt hat das folgende Kontingentverhalten:

  • Modelle mit veröffentlichten Kontingenten haben separate Kontingente pro Modell, Region für Eingabe-Tokens pro Minute und für Ausgabe-Tokens pro Minute.

  • Der Endpunkt erzwingt keine RPM-Kontingente. Zwei Workloads mit derselben Drehzahl können sehr unterschiedliche Mengen an Kapazität verbrauchen. Planen und begrenzen Sie die Rate daher anhand von Tokens und Parallelität und nicht nur anhand von RPM allein.

  • Wenn eine Anforderung zugelassen wird, umfasst die Überprüfung der Eingabetoken die Eingabetokens und den angeforderten Wert. max_tokens Nach Abschluss der Antwort wird der ungenutzte Teil dieser Reservierung wieder aufgefüllt. Stellen Sie den Wert max_tokens nicht höher ein, als für Ihre Anwendung erforderlich ist.

  • Für Modelle ohne veröffentlichte TPM-Kontingente sind derzeit keine TPM-Kontingente pro Konto unter Dienstkontingente verfügbar. Dies bedeutet nicht, dass der Durchsatz unbegrenzt ist. Interne Servicekapazität und vorübergehende Ratenbegrenzungen gelten weiterhin.

  • Batch-Inferenz und Provisioned Throughput sind nur über verfügbar. bedrock-runtime Service-tier und die Modellunterstützung variiert je nach Modell.

Die Standardwerte und die Zuweisungen Ihres Kontos können je nach Modell, Region und Nutzungsverlauf variieren. Aktuelle Werte, Einzelheiten zur Bewertung der Kontingente und das AWS Support-Verfahren zur Beantragung einer Erhöhung finden Sie unterKontingente für den Endpunkt „Bedrock-Mantle“. Informationen Modelle im Überblick zur Unterstützung von modellspezifischen Endpunkten, Service-Stufen und Funktionen finden Sie im jeweiligen Dokument.

Bedrock-Runtime-Endpunkt: Durchsatz und Kontingente

Der bedrock-runtime Endpunkt hat das folgende Kontingentverhalten:

  • Per-model, Token-Kontingente pro Region zählen Eingabe- und Ausgabetokens zusammen. Ausgangstoken verbrauchen ein Kontingent entsprechend einer modellspezifischen Burndown-Rate.

  • Einige Modelle haben auch RPM-Kontingente, während andere Modelle nur durch Token-Kontingente geregelt werden. Überprüfen Sie die Kontingente, die für genau das Modell und das Inferenzprofil gelten, das Sie verwenden.

  • Per-minute und die Token-Kontingente pro Tag werden von allen Inferenz-APIs gemeinsam genutzt, die dasselbe Modell auf diesem Endpunkt aufrufen. Die Zuweisungen für bedrock-runtime und bedrock-mantle sind unabhängig.

  • Benutzerdefinierte Inferenzprofile, Batch-Inferenz und bereitgestellter Durchsatz haben separate Kontingente und sind nur über verfügbar. bedrock-runtime

Aktuelle Kontingentwerte, Einzelheiten zum Token-Burndown und zum Prozess der Kontingenterhöhung finden Sie unter. Kontingente für den Bedrock-Runtime-Endpunkt Informationen Modelle im Überblick zur Unterstützung von modellspezifischen Endpunkten, Servicestufen und Funktionen finden Sie im jeweiligen Dokument.

Grundlegendes zu HTTP-Fehlerantworten

HTTP 429

Eine 429-Antwort bedeutet, dass die Anfrage nicht zugelassen wurde. Prüfen Sie den API-specific Fehlertyp, anstatt sich nur auf den HTTP-Status zu verlassen. Ein Fehler ThrottlingException oder ein Ratenlimit bedeutet in der Regel, dass die Anfrage ein Kontingent oder ein Serviceratlimit überschritten hat. Einige Laufzeitoperationen verwenden auch HTTP 429 für. ModelNotReadyException Wenn aktiviertbedrock-mantle, überprüfen Sie die TPM-Nutzung der Eingabe und Ausgabe sowie den max_tokens Wert der Anforderung. Der Endpunkt hat kein RPM-Kontingent. Wenn diese Option aktiviert istbedrock-runtime, überprüfen Sie die kombinierten Token-Kontingente und RPM, wenn das Modell über ein RPM-Kontingent verfügt.

HTTP: 503

Eine 503-Antwort bedeutet, dass der Dienst die Anfrage aufgrund einer hohen Nachfrage oder einer Kapazitätsbeschränkung vorübergehend nicht bearbeiten kann. Dies bedeutet nicht, dass Sie ein Kontenkontingent überschritten haben. Versuchen Sie es erneut mit transienten Reaktionen mit exponentiellem Backoff und Jitter. Wenn die Antwort weiterhin auftritt, beenden Sie die Erhöhung des Datenverkehrs, reduzieren Sie die Parallelität und ziehen Sie, sofern unterstützt, eine andere regionsübergreifende oder regionsübergreifende Inferenz in Betracht.

HTTP (529) overloaded_error

Einige Modell-APIs geben 529 zurück, wenn das Modell die Anforderung aufgrund einer hohen Nachfrage oder unzureichender Bereitstellungskapazität vorübergehend nicht verarbeiten kann. Behandeln Sie es als vorübergehenden Kapazitätsfehler. Wenn die Antwort einen Retry-After Header enthält, warten Sie mindestens diese Dauer ab, bevor Sie es erneut versuchen, und fügen Sie Jitter hinzu, damit die Clients es nicht gleichzeitig erneut versuchen.

API-specific Ursachen und Lösungsansätze finden Sie unter. Beheben der API-Fehlercodes von Amazon Bedrock

Empfohlene Fehlerbehandlung

Vorübergehende Fehler

Versuchen Sie es nur bei Fehlern, bei denen ein erneuter Versuch sicher ist, z. B. vorübergehende Drosselung und Kapazitätsfehler. Wenn der Service einen Header zurückgibt, berücksichtigen Sie Retry-After ihn. Implementieren Sie andernfalls einen exponentiellen Backoff mit zufälligem Jitter:

  • Beginnen Sie mit einer kurzen Verzögerung (z. B. 1 Sekunde).

  • Erhöhen Sie die Verzögerung nach jedem erneuten Versuch und begrenzen Sie die maximale Verzögerung so, dass sie dem Latenzbudget Ihrer Anwendung entspricht.

  • Fügen Sie zufälligen Jitter hinzu und vermeiden Sie synchronisierte Wiederholungen zwischen Workern.

  • Verwenden Sie ein begrenztes Budget für Wiederholungen, das dem Latenzziel Ihrer Anwendung entspricht. Beschränken Sie den Vorgang beispielsweise auf insgesamt sechs Versuche: die erste Anfrage und bis zu fünf Wiederholungen.

Die meisten AWS SDKs und gängigen HTTP-Bibliotheken bieten integrierte Unterstützung für dieses Muster. Retry-setting Die Namen unterscheiden sich: Die von Botocore total_max_attempts enthalten die erste Anfrage, während die SDKs von OpenAI und Anthropic nur Wiederholungen zählen. max_retries In den folgenden Beispielen werden daher unterschiedliche numerische Werte verwendet, um das gleiche Beispielbudget für sechs Versuche bereitzustellen.

Beispiel Versuchen Sie erneut, die Konfiguration für bedrock-runtime () zu konfigurieren.AWS SDK (//boot3)
import boto3
from botocore.config import Config

config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)
Beispiel Versuchen Sie die Konfiguration für Bedrock-Mantle (OpenAI SDK) erneut
from openai import OpenAI

client = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/v1",
    max_retries=5,
)
Beispiel Versuchen Sie die Konfiguration für Bedrock-Mantle (Anthropic SDK) erneut 
import anthropic

client = anthropic.Anthropic(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/anthropic",
    max_retries=5,
)

Konfigurieren Sie Verbindungs- und Lesezeitüberschreitungen getrennt von Wiederholungsversuchen, basierend auf der dokumentierten maximalen Inferenzdauer des Modells und des Vorgangs. Ein Timeout, das kürzer ist als eine gültige, lang andauernde Inferenzanforderung, kann zu vermeidbaren Wiederholungen und doppelter Arbeit führen.

Anhaltende Kapazitätsfehler

Wenn Sie anhaltende 503- oder 529-Fehler erhalten, können Wiederholungsversuche allein die Auslastung erhöhen. Für den Service besteht möglicherweise eine vorübergehende Kapazitätsbeschränkung, oder die Arbeitslast überschreitet möglicherweise die derzeit für das Modell und die Region verfügbare Kapazität. Gehen Sie dazu wie folgt vor:

  • Stoppen Sie die Rampe und kehren Sie zur letzten stabilen Anforderungsrate und Parallelitätsstufe zurück.

  • Verwenden Sie begrenzte clientseitige Parallelität, Ratenbegrenzung und Anforderungswarteschlangen.

  • Verschieben Sie Anfragen mit niedrigerer Priorität oder verwerfen Sie sie, bis sich die Kapazität erholt hat.

  • Verwenden Sie zum bedrock-runtime Beispiel regionsübergreifende Inferenz, wenn das Modell dies unterstützt. Für vorhersehbare, anhaltende Workloads sollten Sie den bereitgestellten Durchsatz auswerten.

  • Wenn das Problem weiterhin besteht, überprüfen Sie das AWS Health Dashboard und wenden Sie sich mit den Anforderungs-IDs und UTC-Zeitstempeln an den AWS Support.

Erhöhung des Durchsatzes

On-demand Die Kapazität kann je nach Modell, Region und Zeit variieren. In Zeiten hoher Nachfrage ist nicht garantiert, dass alle Anfragen innerhalb eines Kontingents erfolgreich sind. Steigern Sie daher schrittweise, wenn ein Workload anfällt, das Modell oder die Region geändert wird oder wenn der Traffic stark zunimmt. Dies ist besonders wichtig für bedrock-mantle Modelle, für die kein Kontingent pro Konto veröffentlicht wurde.

Empfohlenes Verfahren zur Anlaufphase

  1. Schätzen Sie die Ziel-Token-Rate und Parallelität für jeden Endpunkt, jedes Modell und jede Region. Fürbedrock-mantle: Verfolgen Sie Eingabe- und Ausgabe-Tokens getrennt und beziehen Sie den angeforderten max_tokens Wert in die Schätzung der Eingabe-Token-Zulassung ein.

  2. Beginnen Sie bei einer bekannten stabilen Basislinie, die unter dem Zielwert liegt. Wenn Sie keinen Ausgangswert haben, beginnen Sie mit einer kleinen repräsentativen Ladung, anstatt das gesamte Zielvolumen zu senden.

  3. Halten Sie jedes Level lang genug, um den Erfolg der Anfrage, 429/503 /529-Fehler, Latenzprozentile, Token-Verbrauch, Parallelität und Warteschlangentiefe zu beobachten.

  4. Erhöhen Sie den Wert um einen kontrollierten Schritt nach dem anderen. Ändern Sie jeweils nur eine Hauptlastdimension, damit Sie die Ursache einer Regression ermitteln können.

  5. Wenn Drosselung, Kapazitätsfehler oder Latenz Ihren Schwellenwert überschreiten, pausieren Sie die Rampe, berücksichtigen Sie einen beliebigen Retry-After Header und kehren Sie zur letzten stabilen Stufe zurück.

  6. Fahren Sie fort, bis Sie das Ziel erreicht haben, und wiederholen Sie die Validierung für jedes Modell und jede Region, die Produktionsdatenverkehr erhalten.

Wählen Sie die Schrittgröße und den Beobachtungszeitraum anhand der Latenz und des Datenverkehrsmusters Ihres Workloads aus. Verwenden Sie RPM nicht als einziges Steuersignal: Die Größe der Anforderungstoken und die Länge der Antworten können den Kapazitätsverbrauch erheblich verändern, selbst wenn die Drehzahl konstant bleibt.

Informationen zur Erhöhung der bedrock-mantle Kontingente finden Sie im FolgendenBeantragen einer Kontingenterhöhung. Fürbedrock-runtime, folgenBeantragen einer Kontingenterhöhung.

Weitere bewährte Methoden

  • Verwenden Sie Feature-Flags, um den Verkehr schrittweise zwischen den Modellen umzuleiten, anstatt den gesamten Verkehr auf einmal umzuschalten.

  • Verteilen Sie große Workloads auf mehrere Minuten und berücksichtigen Sie Tageszeitmuster, um Spitzennutzungsperioden zu vermeiden.

  • Testen Sie mit repräsentativen Verteilungen von Eingabegröße, Ausgabegröße, Latenz und Parallelität. Vermeiden Sie das Senden einer plötzlichen Flut von Testanfragen.

  • Verwenden Sie clientseitige Ratenbegrenzung mit Token-Unterstützung, begrenzte Parallelität und begrenzte Warteschlangen. Ein RPM-only Limiter schützt nicht vor Änderungen der Anforderungsgröße.

  • Verwenden Sie für asynchrone Offline-Jobs mit hohem Volumen die Batch-Inferenz auf. bedrock-runtime

  • Für unterstützte Modelle und nicht zeitkritische Anforderungen, die eine variable Latenz tolerieren können, sollten Sie die Flex-Servicestufe in Betracht ziehen. Servicestufen zur Optimierung von Leistung und Kosten

Regionale Verfügbarkeit und regionsübergreifende Inferenz

On-demand Die Kapazität ist regional und kann je nach Region variieren. Wenn Ihre Arbeitslast auf eine einzelne Region ausgerichtet ist, kann es in Zeiten hoher Nachfrage zu Kapazitätsfehlern kommen. Verwenden Sie mit bedrock-runtime, Globale regionsübergreifende Inferenz wenn das Modell und Ihre Anforderungen an die Datenresidenz dies unterstützen. Wenn Sie Ihr eigenes regionales Failover implementieren, überprüfen Sie die Modellverfügbarkeit in jeder Zielregion und führen Sie begrenzte Wiederholungsversuche durch, damit das Failover nicht zu einer Überlastung des Datenverkehrs führt.

Hilfe erhalten

  • Durchsatzplanung — Schätzen Sie für jedes Modell und jede Region die Spitzen der Eingabe- und Ausgangstoken, die Antwortlatenz, die Parallelität und die Warteschlangentoleranz ab. Berücksichtigen Sie den Workload-spezifischen Spielraum und wenden Sie sich bei großen oder geschäftskritischen Produkteinführungen an Ihr AWS-Konto Team.

  • Leistungsoptimierung — Überwachen Sie die Größe der Eingabeaufforderung, die generierten Token, die Latenzperzentile und die Cache-Nutzungmax_tokens, sofern dies unterstützt wird. Optimieren Sie Eingabeaufforderungen und Ausgabelimits, um zu vermeiden, dass unnötige Tokens reserviert oder verbraucht werden.

  • Support-Eskalation — Geben Sie beim Öffnen eines AWS Support-Falls den Endpunkt, die Region, das Modell oder die Inferenzprofil-ID, den HTTP-Status und den API-Fehlertyp, die Anforderungs-IDs, UTC-Zeitstempel, die Tokenrate, die Anforderungsrate, die Parallelität und Ihren Skalierungszeitplan an.

Zusammenfassung der Empfehlungen

Szenario Empfehlung
Allgemeine Arbeitsbelastungen Beginnen Sie mit bedrock-runtime. Wird bedrock-mantle für Funktionen oder Modelle verwendet, die dies erfordern. Siehe Von Amazon Bedrock unterstützte Endpunkte.
Vorübergehende 429-, 503- oder 529-Fehler Überprüfen Sie den API-Fehlertyp. Fehler, die wiederholt werden können, berücksichtigen Retry-After und versuchen Sie es erneut mit exponentiellem Backoff und Jitter innerhalb eines begrenzten Budgets für Wiederholungsversuche.
Anhaltende Kapazitätsfehler Stoppen Sie das Hochfahren, kehren Sie zur letzten stabilen Stufe zurück, begrenzen Sie Parallelität und Warteschlangen, verschieben Sie Arbeiten mit niedrigerer Priorität und verwenden Sie regionsübergreifende Inferenz, sofern dies unterstützt wird.
Planung von Kontingenten Verwenden Sie separate Eingabe- und Ausgabe-TPM fürbedrock-mantle. Verwenden Sie gegebenenfalls kombinierte Token-Kontingente, Token-Burndown und RPM für. bedrock-runtime
Umfangreiche Offline-Verarbeitung Verwenden Sie Batch-Inferenz für asynchrone Jobs. Verwenden Sie die Flex-Serviceebene für unterstützte, nicht zeitkritische Anfragen, die eine variable Latenz tolerieren können.