Migliori pratiche di scalabilità e velocità di trasmissione

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

Endpoint Amazon Bedrock

Amazon Bedrock supporta due endpoint per l'inferenza:

Per ulteriori informazioni su questi endpoint e su come scegliere tra di essi, consulta. Endpoint supportati da Amazon Bedrock

Perché i due endpoint si comportano in modo diverso

In molti servizi multi-tenant tradizionali, l'architettura è progettata in base a quote per account per gestire l'accesso equo alle risorse condivise. Questo è l'approccio utilizzato con. bedrock-runtime

Con bedrock-mantle, viene utilizzato un approccio diverso. Questo endpoint è progettato con meccanismi avanzati di pianificazione e gestione delle code di lavoro che garantiscono una distribuzione equa, supportando al contempo limiti di throughput iniziali più elevati. Questo design consente inoltre di ospitare un'ampia gamma bedrock-mantle di modelli e di offrire l'intera gamma di funzionalità disponibili nel catalogo dei modelli. Nella maggior parte dei casi, le richieste vengono evase immediatamente. In alcuni casi, una richiesta può essere messa in coda per un breve periodo durante il completamento dei carichi di lavoro in volo e la velocità effettiva diventa disponibile. Le sezioni seguenti spiegano come gestire questi scenari.

endpoint bedrock-mantle: produttività e quote

Tutti i modelli disponibili bedrock-mantle condividono un unico limite rigido di 10.000 giri/min per account per regione. Esistono alcune differenze nel comportamento della produttività e delle quote per Claude rispetto ad altri modelli, come illustrato di seguito.

* Il limite TPM di input dipende dalla cronologia di utilizzo con Amazon Bedrock. Controlla la pagina Quotas nella console Amazon Bedrock per l'allocazione effettiva.

endpoint bedrock-runtime: velocità effettiva e quote

La tabella seguente riassume la velocità effettiva e le quote per. bedrock-runtime

* Le quote per questi modelli variano in base all'utilizzo. Consulta la pagina Quotas nella console Amazon Bedrock per le tue allocazioni.

Comprendere le risposte agli errori HTTP

Gestione degli errori consigliata

Errori transitori (risposte 503 occasionali)

Implementa il backoff esponenziale con jitter casuale:

La maggior parte degli AWS SDK e delle librerie HTTP più diffuse forniscono il supporto integrato per questo pattern.

import boto3
from botocore.config import Config

config = Config(retries={"total_max_attempts": 6, "mode": "standard"})
client = boto3.client("bedrock-runtime", config=config)

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,
)

import anthropic

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

Errori persistenti (risposte 503 persistenti)

Se ricevi errori 503 persistenti, riprovare da solo non risolverà il problema. La frequenza delle richieste supera la velocità effettiva disponibile. Utilizza le fasi seguenti:

Incrementare la produttività

Quando si utilizza la velocità effettiva su richiesta sull'bedrock-mantleendpoint, la velocità effettiva disponibile aumenta nel tempo. Non è garantito il successo di tutte le richieste che rientrano nella quota stabilita durante i periodi di forte domanda, quindi è importante aumentare gradualmente.

Procedura di accelerazione consigliata

Ad esempio, se il tuo obiettivo è 2.000 giri/min ma ricevi 503 errori, riduci a 1.000 giri/min. Se gli errori persistono, riducili a 500 giri/min. Una volta che le richieste hanno successo in modo costante a 500 giri/min, attendi per 15 minuti, quindi scala a 750, quindi a 1.125 e così via.

Le velocità di rampa non sono regolabili. Per richiedere un'allocazione RPM più elevata, utilizza la console Service Quotas.

Best practice aggiuntive

Disponibilità regionale e inferenza tra regioni

On-demand la velocità effettiva è allocata a livello regionale e varia tra le regioni. Se il carico di lavoro è destinato a una singola regione, è possibile che si verifichino 503 risposte durante i periodi di forte domanda. Per massimizzare la disponibilità e, se si utilizza, utilizzare bedrock-runtime. Inferenza globale tra regioni

Utilizzo della guida

Riepilogo dei consigli