View a markdown version of this page

Best practice per scalabilità e produttività - Amazon Bedrock
Endpoint Amazon Bedrockendpoint fondamentale: produttività e quoteendpoint bedrock-runtime: throughput e quoteComprendere le risposte agli errori HTTPGestione degli errori consigliataAumento della produttivitàBest practice aggiuntiveDisponibilità regionale e inferenza interregionaleUtilizzo della guidaRiepilogo dei consigli

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best practice per scalabilità e produttività

Questo argomento spiega come funzionano i limiti di throughput e la pianificazione tra gli endpoint Amazon Bedrock e fornisce le migliori pratiche per scalare le applicazioni di intelligenza artificiale generativa.

Endpoint Amazon Bedrock

Amazon Bedrock supporta due endpoint per l'inferenza:

  • bedrock-mantle.{region}.api.aws— Supporta le API OpenAI-compatible Chat Completions and Responses e l'API Anthropic Messages.

  • bedrock-runtime.{region}.amazonaws.com— Supporta le API Bedrock-native InvokeModel e Converse, le API OpenAI-compatible Chat Completions and Responses e l'API Anthropic Messages.

Per la maggior parte delle nuove applicazioni, inizia con. bedrock-runtime Usalo bedrock-mantle quando hai bisogno di funzionalità disponibili solo su quell'endpoint, come strumenti lato server, inferenza in background, progetti, aree di lavoro o un modello disponibile solo su. bedrock-mantle È possibile utilizzare entrambi gli endpoint nella stessa applicazione. Per un confronto completo, vedereEndpoint supportati da Amazon Bedrock.

Perché i due endpoint si comportano diversamente

Entrambe le superfici degli endpoint utilizzano lo stesso motore di inferenza sottostante, ma le opzioni relative alla contabilità delle quote e alla capacità sono diverse. bedrock-runtimeutilizza quote di token per modello e, per alcuni modelli, quote di richieste al minuto (RPM). bedrock-mantlenon impone quote RPM e utilizza quote di input-token e output-token separate per i modelli che hanno quote pubblicate. In altri modelli in uso bedrock-mantle potrebbero non essere esposte le quote per account in Service Quotas, ma il loro throughput è comunque regolato dalla capacità di servizio interna.

Una quota è un limite massimo, non una garanzia che ogni richiesta su richiesta verrà soddisfatta immediatamente. Durante i periodi di forte domanda, le richieste possono essere messe in coda o ricevere errori transitori di capacità. Progetta la tua applicazione in modo da limitare la concorrenza, mettere in coda il lavoro e riprovare gli errori transitori senza creare un aumento dei tentativi.

endpoint fondamentale: produttività e quote

L'endpoint ha il seguente comportamento relativo alle quote: bedrock-mantle

  • I modelli con quote pubblicate hanno quote separate per modello, token di input al minuto per regione e token di output per minuto.

  • L'endpoint non applica le quote RPM. Due carichi di lavoro con lo stesso RPM possono consumare quantità di capacità molto diverse, pertanto la pianificazione e la velocità sono limitate in base ai token e alla concorrenza anziché ai soli RPM.

  • Quando una richiesta viene ammessa, il controllo del token di input include i token di input più il valore richiesto. max_tokens Una volta completata la risposta, la parte inutilizzata di tale prenotazione viene reintegrata. Impostare un valore max_tokens non superiore a quello richiesto dall'applicazione.

  • I modelli senza quote TPM pubblicate non hanno attualmente quote TPM per account esposte in Service Quotas. Ciò non significa che la velocità effettiva sia illimitata; si applicano ancora la capacità interna del servizio e la limitazione della velocità transitoria.

  • L'inferenza in batch e la velocità effettiva prevista sono disponibili solo tramite. bedrock-runtime Service-tier e il supporto del modello varia in base al modello.

I valori predefiniti e le allocazioni dell'account possono variare in base al modello, alla regione e alla cronologia di utilizzo. Per i valori correnti, i dettagli sulla valutazione delle quote e la procedura di AWS supporto per la richiesta di un aumento, consulta. Quote per l'endpoint del substrato roccioso Scopri il supporto applicabile I modelli a colpo d'occhio per endpoint, livello di servizio e funzionalità specifici del modello.

endpoint bedrock-runtime: throughput e quote

L'bedrock-runtimeendpoint ha il seguente comportamento relativo alle quote:

  • Per-model, le quote di token per regione contano insieme i token di input e output. I token di output consumano quote in base a una percentuale di burndown specifica del modello.

  • Alcuni modelli hanno anche quote RPM, mentre altri modelli sono regolati solo da quote di token. Verifica le quote che si applicano al modello esatto e al profilo di inferenza che utilizzi.

  • Per-minute e le quote giornaliere di token sono condivise tra le API di inferenza che richiamano lo stesso modello su questo endpoint. Le allocazioni per e sono indipendenti. bedrock-runtime bedrock-mantle

  • I profili di inferenza personalizzati, l'inferenza in batch e la velocità effettiva prevista hanno quote separate e sono disponibili solo tramite. bedrock-runtime

Per i valori correnti delle quote, i dettagli sulla riduzione dei token e il processo di aumento delle quote, consulta. Quote per l'endpoint bedrock-runtime Scopri il supporto applicabile I modelli a colpo d'occhio per endpoint, livello di servizio e funzionalità specifici del modello.

Comprendere le risposte agli errori HTTP

HTTP 429

Una risposta 429 indica che la richiesta non è stata accettata. Ispeziona il tipo di API-specific errore anziché basarti solo sullo stato HTTP. Un ThrottlingException errore relativo al limite di frequenza indica in genere che la richiesta ha superato una quota di account o un limite di tariffa di servizio. Alcune operazioni di runtime utilizzano anche HTTP 429 per. ModelNotReadyException Attivatobedrock-mantle, controlla l'utilizzo del TPM di input e output e il max_tokens valore della richiesta; l'endpoint non ha una quota RPM. Sìbedrock-runtime, seleziona le quote combinate dei token e gli RPM, se il modello ha una quota RPM.

HTTP 503

Una risposta 503 indica che il servizio non è temporaneamente in grado di gestire la richiesta a causa dell'elevata domanda o di un vincolo di capacità. Non indica che hai superato la quota di un account. Riprova le risposte transitorie con backoff e jitter esponenziali. Se la risposta persiste, interrompi l'aumento del traffico, riduci la concorrenza e considera una diversa inferenza regionale o interregionale, se supportata.

HTTP 529 () overloaded_error

Alcune API del modello restituiscono 529 quando il modello non è temporaneamente in grado di elaborare la richiesta a causa di una domanda elevata o di una capacità di servizio insufficiente. Consideralo un errore transitorio di capacità. Se la risposta include un'Retry-Afterintestazione, attendi almeno tale durata prima di riprovare e aggiungi jitter in modo che i client non riprovino contemporaneamente.

Per le API-specific cause e i passaggi per la risoluzione, consulta. Risoluzione dei problemi dei codici di errore del’API Amazon Bedrock

Gestione degli errori consigliata

Errori transitori

Riprova solo gli errori sicuri da riprovare, come la limitazione transitoria e gli errori di capacità. Se il servizio restituisce un'intestazione, rispettala. Retry-After Altrimenti, implementa il backoff esponenziale con jitter casuale:

  • Inizia con un breve ritardo (ad esempio, 1 secondo).

  • Aumenta il ritardo dopo ogni nuovo tentativo e limita il ritardo massimo in base al budget di latenza dell'applicazione.

  • Aggiungi un jitter casuale ed evita tentativi sincronizzati tra i lavoratori.

  • Utilizzate un budget limitato per i tentativi che si adatti all'obiettivo di latenza dell'applicazione. Ad esempio, limita l'operazione a sei tentativi totali: la richiesta iniziale e fino a cinque tentativi.

La maggior parte degli AWS SDK e delle librerie HTTP più diffuse forniscono un supporto integrato per questo modello. Retry-setting i nomi sono diversi: quello di botocore total_max_attempts include la richiesta iniziale, mentre gli SDK OpenAI e Anthropic contano solo i tentativi. max_retries Gli esempi seguenti utilizzano quindi valori numerici diversi per fornire lo stesso budget di esempio per sei tentativi.

Esempio Riprova la configurazione per bedrock-runtime (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)
Esempio Riprova la configurazione per bedrock-mantle (OpenAI SDK)
from openai import OpenAI

client = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{region}.api.aws/v1",
    max_retries=5,
)
Esempio Riprova la configurazione per bedrock-mantle (Anthropic SDK) 
import anthropic

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

Configura i timeout di connessione e lettura separatamente dai tentativi, in base alla durata massima di inferenza documentata del modello e dell'operazione. Un timeout più breve di una richiesta di inferenza valida di lunga durata può causare tentativi evitabili e duplicazioni del lavoro.

Errori di capacità prolungati

Se ricevete errori 503 o 529 persistenti, solo i tentativi possono amplificare il carico. Il servizio potrebbe presentare una limitazione temporanea della capacità o il carico di lavoro potrebbe superare la capacità attualmente disponibile per il modello e la regione. Utilizza le fasi seguenti:

  • Interrompi la rampa e torna all'ultima percentuale di richieste e livello di concorrenza stabili.

  • Utilizza la concorrenza limitata sul lato client, la limitazione della velocità e le code di richiesta.

  • Rimanda o elimina le richieste con priorità inferiore fino al ripristino della capacità.

  • Perbedrock-runtime, usa l'inferenza interregionale quando il modello la supporta. Per carichi di lavoro prevedibili e sostenuti, valuta Provisioned Throughput. Aumenta la capacità di invocazione del modello con Provisioned Throughput in Amazon Bedrock

  • Se il problema persiste, consulta l' AWS Health Dashboard e contatta l' AWS assistenza fornendo gli ID della richiesta e i timestamp UTC.

Aumento della produttività

On-demand la capacità può variare in base al modello, alla regione e all'ora. Non è garantito il successo di tutte le richieste entro una determinata quota durante i periodi di forte domanda, quindi aumenta gradualmente quando si avvia un carico di lavoro, si cambiano modelli o regioni o si aumenta notevolmente il traffico. Ciò è particolarmente importante per bedrock-mantle i modelli che non hanno una quota pubblicata per account.

Procedura di accelerazione consigliata

  1. Stima il tasso di token target e la concorrenza per ogni endpoint, modello e regione. Perbedrock-mantle, tieni traccia dei token di input e output separatamente e includi il max_tokens valore richiesto nella stima di ammissione dei token di input.

  2. Inizia da una linea di base stabile nota al di sotto dell'obiettivo. Se non disponi di una linea di base, inizia con un piccolo carico rappresentativo invece di inviare l'intero volume di destinazione.

  3. Mantieni ogni livello abbastanza a lungo da osservare il successo della richiesta, gli errori 429/503 /529, i percentili di latenza, il consumo di token, la concorrenza e la profondità della coda.

  4. Aumenta un passaggio controllato alla volta. Modificate solo una dimensione di carico principale alla volta in modo da poter identificare la causa di una regressione.

  5. Se la limitazione, gli errori di capacità o la latenza superano la soglia, metti in pausa la rampa, rispetta qualsiasi Retry-After header e torna all'ultimo livello stabile.

  6. Continua fino a raggiungere l'obiettivo e ripeti la convalida per ogni modello e regione che riceveranno traffico di produzione.

Scegli la dimensione della fase e il periodo di osservazione in base alla latenza e al modello di traffico del carico di lavoro. Non utilizzate l'RPM come unico segnale di controllo: le dimensioni dei token di richiesta e le lunghezze di risposta possono modificare sostanzialmente il consumo di capacità anche quando l'RPM rimane costante.

Per gli bedrock-mantle aumenti delle quote, segui. Richiedere un aumento della quota Perbedrock-runtime, seguiRichiedere un aumento della quota.

Best practice aggiuntive

  • Utilizza i flag di funzionalità per trasferire gradualmente il traffico tra i modelli anziché cambiare tutto il traffico contemporaneamente.

  • Distribuisci carichi di lavoro di grandi dimensioni su più minuti e considera gli schemi delle ore del giorno per evitare i periodi di picco di utilizzo.

  • Esegui i test con distribuzioni rappresentative delle dimensioni di input, delle dimensioni dell'output, della latenza e della concorrenza. Evita di inviare una serie improvvisa di richieste di test.

  • Utilizza la limitazione della velocità lato client basata sui token, la concorrenza limitata e le code limitate. Un RPM-only limitatore non protegge dalle modifiche nella dimensione delle richieste.

  • Per lavori offline asincroni ad alto volume, utilizza l'inferenza batch su. Elaborazione di più prompt con l’inferenza in batch bedrock-runtime

  • Per i modelli supportati e le richieste non sensibili al fattore tempo che possono tollerare una latenza variabile, prendi in considerazione il livello di servizio Flex. Livelli di servizio per l'ottimizzazione delle prestazioni e dei costi

Disponibilità regionale e inferenza interregionale

On-demand la capacità è regionale e può variare a seconda delle regioni. Se il carico di lavoro è destinato a una singola regione, può riscontrare errori di capacità durante i periodi di forte domanda. Con bedrock-runtime, utilizzalo Inferenza globale interregionale quando il modello e i requisiti di residenza dei dati lo supportano. Se implementi il tuo failover regionale, verifica la disponibilità del modello in ogni regione di destinazione e applica tentativi limitati in modo che il failover non crei un aumento del traffico.

Utilizzo della guida

  • Pianificazione del throughput: stima i token di input e output di picco, la latenza di risposta, la concorrenza e la tolleranza di coda per ogni modello e regione. Includi un margine di manovra specifico per i carichi di lavoro e contatta il tuo team per lanci di grandi dimensioni o critici per l'azienda. Account AWS

  • Ottimizzazione delle prestazioni: monitora le dimensioni dei prompt, i token generati, i percentili di latenza e l'utilizzo della cachemax_tokens, se supportato. Ottimizza i prompt e i limiti di output per evitare di riservare o consumare token non necessari.

  • Incremento dell'assistenza: quando apri una richiesta di AWS assistenza, includi l'endpoint, la regione, l'ID del modello o del profilo di inferenza, lo stato HTTP e il tipo di errore dell'API, gli ID delle richieste, i timestamp UTC, la frequenza dei token, la frequenza delle richieste, la concorrenza e la tempistica di scalabilità.

Riepilogo dei consigli

Scenario Raccomandazione
Carichi di lavoro generali Inizia consultando bedrock-runtime. Utilizzalo bedrock-mantle per funzionalità o modelli che lo richiedono. Consulta Endpoint supportati da Amazon Bedrock.
Errori transitori 429, 503 o 529 Ispeziona il tipo di errore API. Per eventuali errori ripetibili, rispetta Retry-After e riprova con backoff e jitter esponenziali entro un budget limitato per i tentativi.
Errori di capacità sostenuti Arresta l'aumento esponenziale, torna all'ultimo livello stabile, limita la concorrenza e le code, rimanda il lavoro con priorità inferiore e utilizza l'inferenza interregionale, se supportata.
Pianificazione delle quote Utilizza un TPM di input e output separato perbedrock-mantle. Utilizza quote di token combinate, token burndown e RPM laddove applicabile per. bedrock-runtime
Elaborazione offline di grandi dimensioni Usa l'inferenza batch per i lavori asincroni. Utilizzate il livello di servizio Flex per richieste supportate e non sensibili al fattore tempo che possono tollerare una latenza variabile.