Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Mejores prácticas de escalado y rendimiento
<a name="scaling-throughput-best-practices"></a>

En este tema se explica cómo funcionan los límites de rendimiento y la programación en los puntos de enlace de Amazon Bedrock y se proporcionan las prácticas recomendadas para escalar sus aplicaciones de IA generativa.

## Puntos de conexión de Amazon Bedrock
<a name="scaling-endpoints"></a>

Amazon Bedrock admite dos puntos de enlace para la inferencia:
+ `bedrock-mantle.{region}.api.aws`— Admite la finalización y respuesta de chats (de OpenAI) y los mensajes (de Anthropic).
+ `bedrock-runtime.{region}.amazonaws.com`— Es compatible con Bedrock-native las API (Invoke and Converse), las API de chat y las API de mensajes.

Para obtener más información sobre estos puntos de conexión y cómo elegir entre ellos, consulte. [Puntos de enlace compatibles con Amazon Bedrock](endpoints.md)

### Por qué los dos puntos finales se comportan de forma diferente
<a name="scaling-endpoint-differences"></a>

En muchos servicios tradicionales de múltiples inquilinos, la arquitectura está diseñada en torno a cuotas por cuenta para gestionar el acceso equitativo a los recursos compartidos. Este es el enfoque que se utiliza con. [`bedrock-runtime`](endpoints.md)

Con [`bedrock-mantle`](endpoints.md), se utiliza un enfoque diferente. Este punto final está diseñado con mecanismos avanzados de programación y colas de trabajo que permiten una distribución equitativa y, al mismo tiempo, admiten límites de rendimiento iniciales más altos. Este diseño también permite `bedrock-mantle` alojar un amplio conjunto de modelos y ofrecer toda la gama de funciones disponibles en el catálogo de modelos. En la mayoría de los casos, las solicitudes se atienden inmediatamente. En algunos casos, es posible que una solicitud quede en cola durante un breve periodo de espera mientras se completan las cargas de trabajo en vuelo y se dispone de capacidad de procesamiento. En las siguientes secciones se explica cómo gestionar estos escenarios.

## punto final `fundamental: rendimiento` y cuotas
<a name="scaling-mantle-quotas"></a>

Todos los modelos disponibles `bedrock-mantle` comparten un único límite estricto de 10 000 RPM por cuenta y región. Existen algunas diferencias en el comportamiento del rendimiento y las cuotas de Claude con respecto a otros modelos, como se muestra a continuación.


|   | Claude 4.7\+ | Todos los demás modelos | 
| --- | --- | --- | 
| TPM de entrada | 10 M\* | Sin límite de TPM por cliente o modelo | 
| TPM de salida | 2 M | Sin límite de TPM por cliente o modelo | 
| RPM | 10 000 (compartidos entre todos los modelos de este terminal) | 10 000 (compartidos entre todos los modelos de este punto final) | 
| On-demand niveles | Standard | Estándar, Priority, Flex (algunas excepciones): consulte las páginas de detalles del modelo para ver la disponibilidad | 
| Lote | No | Sí, para los modelos compatibles: consulte las páginas de detalles del modelo para ver la disponibilidad | 
| Capacidad reservada | Ninguno | Ninguno | 

\* El límite de TPM de entrada depende de su historial de uso con Amazon Bedrock. Consulte la página de [cuotas](https://console.aws.amazon.com/bedrock/home#/model-quotas) de la consola de Amazon Bedrock para ver su asignación real.

## punto final `fundamental del tiempo de ejecución: rendimiento` y cuotas
<a name="scaling-runtime-quotas"></a>

En la siguiente tabla se resumen el rendimiento y las cuotas de. `bedrock-runtime`


|   | Claude 4.7\+ | Todos los demás modelos | 
| --- | --- | --- | 
| TPM de entrada | 15 M\* | Varía \* | 
| TPM de salida | Combinado con el TPM de entrada. Se aplica Burndown. | Ninguna. Se aplica Burndown. | 
| RPM | 10 000 (compartidos en todos los modelos) | Varía \* | 
| On-demand niveles | Standard | Estándar, Priority, Flex (algunas excepciones): consulte las páginas de detalles del modelo para ver la disponibilidad | 
| Lote | No | Sí, para los modelos compatibles: consulte las páginas de detalles del modelo para ver la disponibilidad | 
| Capacidad reservada | Ninguno |  Tier/Provisioned Capacidad reservada | 

\* Las cuotas de estos modelos varían según el uso. Consulte las asignaciones en la página de [cuotas](https://console.aws.amazon.com/bedrock/home#/model-quotas) de la consola de Amazon Bedrock.

## Comprenda las respuestas a los errores de HTTP
<a name="scaling-http-errors"></a>

HTTP 429  
Una respuesta de 429 significa que has superado el límite de RPM de tu cuenta. Reduce la tasa de envío de solicitudes. Si necesita una asignación de RPM más alta, solicite un aumento a través de la [consola de Service Quotas](https://console.aws.amazon.com/servicequotas/home) o póngase en contacto con su Cuenta de AWS equipo.

HTTP 503  
Una respuesta 503 significa que hay una mayor demanda de Amazon Bedrock en esta región. Debe reducir el porcentaje de solicitudes y, a continuación, volver a intentarlo con un retraso exponencial o distribuir el tráfico entre las regiones.

## Tratamiento de errores recomendado
<a name="scaling-error-handling"></a>

### Errores transitorios (503 respuestas ocasionales)
<a name="scaling-transient-errors"></a>

Implemente un retroceso exponencial con fluctuaciones aleatorias:
+ Comience con un breve retraso (por ejemplo, 1 segundo).
+ Duplique el retraso después de cada intento fallido.
+ Limite los reintentos a 6 intentos.

La mayoría de AWS los SDK y las bibliotecas HTTP más populares ofrecen compatibilidad integrada con este patrón.

**Example `Vuelva a intentar la configuración para 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)
```

**Example Vuelva a intentar la configuración de `bedrock-mantle (SDK para OpenAI`)**  

```
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 `Vuelva a intentar la configuración para bedrock-mantle (SDK de Anthropic)`**  

```
import anthropic

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

### Errores sostenidos (503 respuestas persistentes)
<a name="scaling-sustained-errors"></a>

Si recibes 503 errores continuos, volver a intentarlo por sí solo no resolverá el problema. La tasa de solicitudes supera el rendimiento disponible. Siga estos pasos:
+ Reduzca la velocidad a la que su solicitud envía nuevas solicitudes.
+ Implemente la limitación de la velocidad por parte del cliente o la creación de colas de solicitudes.
+ Elimine las solicitudes de menor prioridad hasta que se recupere el rendimiento.

## Incrementar el rendimiento
<a name="scaling-ramp-up"></a>

Al consumir el rendimiento bajo demanda en el [`bedrock-mantle`](endpoints.md)punto final, el rendimiento disponible se amplía con el tiempo. No se garantiza que todas las solicitudes que se ajusten a su cuota se ejecuten correctamente durante los períodos de alta demanda, por lo que es importante aumentarlas gradualmente.

### Procedimiento de aceleración recomendado
<a name="scaling-ramp-procedure"></a>

1. Comience con el volumen de solicitudes objetivo, por ejemplo, 500 RPM.

1. Si recibes 503 respuestas, reduce tu ratio, por ejemplo, en un 50%.

1. Continúa reduciendo esa tasa hasta que alcances un estado estable en el que las solicitudes se tramiten de forma constante.

1. Manténgalo en ese estado estable durante un período corto, por ejemplo, 15 minutos.

1. Vuelva a aumentar el rendimiento, por ejemplo, un 50%, y manténgalo así durante otros 15 minutos.

1. Repite hasta que alcances el volumen objetivo.

Por ejemplo, si tu objetivo es de 2000 RPM pero recibes 503 errores, redúcelo a 1000 RPM. Si los errores persisten, redúzcalos a 500 RPM. Una vez que las solicitudes se realicen correctamente a 500 RPM, manténgalas presionadas durante 15 minutos, luego escale a 750, luego a 1125, y así sucesivamente.

Las velocidades de rampa no son ajustables. Para solicitar una asignación de RPM más alta, utilice la [consola Service Quotas](https://console.aws.amazon.com/servicequotas/home).

## Prácticas recomendadas adicionales
<a name="scaling-additional-best-practices"></a>
+ Utilice indicadores de funciones para transferir gradualmente el tráfico entre modelos, en lugar de cambiar todo el tráfico a la vez.
+ Distribuya las grandes cargas de trabajo en varios minutos y tenga en cuenta los patrones de hora del día para evitar los períodos de mayor consumo.
+ Comience a realizar pruebas con lotes pequeños y amplíe gradualmente. Evite enviar miles de solicitudes de prueba simultáneamente.
+ Para el procesamiento de datos fuera de línea de gran tamaño, utilice la [API Batch](batch-inference.md) o [Flex Tier](service-tiers-inference.md) si su aplicación puede procesar las respuestas de forma asíncrona.

## Disponibilidad regional e inferencia entre regiones
<a name="scaling-regional-availability"></a>

On-demand El rendimiento se asigna a nivel regional y varía de una región a otra. Si su carga de trabajo se dirige a una sola región, es posible que reciba 503 respuestas durante los períodos de alta demanda. Para maximizar la disponibilidad y, si la está utilizando [`bedrock-runtime`](endpoints.md), utilice[Inferencia global interregional](global-cross-region-inference.md).

## Obtener ayuda
<a name="scaling-getting-help"></a>
+ **Planificación del rendimiento**: póngase en contacto con su Cuenta de AWS equipo para obtener una previsión del rendimiento. Planifique un rendimiento máximo de 2 a 3 veces durante los eventos de escalado.
+ **Optimización del rendimiento**: supervise la eficiencia del uso de los tokens, optimice las solicitudes para reducir el consumo de tokens y seleccione los modelos en función de los requisitos de su caso de uso.
+ **Escalación de soporte**: al abrir un caso de AWS soporte por problemas de rendimiento, incluya lo siguiente: códigos de error específicos, ID de solicitud, patrones de tráfico (RPM/TPM) y su cronograma de escalado.

## Resumen de las recomendaciones
<a name="scaling-summary"></a>


| Escenario | Recomendación | 
| --- | --- | 
| Cargas de trabajo generales | Utilice el [`bedrock-mantle`punto final](endpoints.md) siempre que sea posible. | 
| Errores 503 ocasionales | Vuelva a intentarlo con un retroceso y una fluctuación exponenciales. | 
| Se produjeron 503 errores | Reduzca la tasa de envío de solicitudes. Implemente una limitación de la velocidad por parte del cliente. | 
| Errores 429 | Reduzca la tasa de solicitudes. Solicita una asignación de RPM más alta a través [de Service Quotas](https://console.aws.amazon.com/servicequotas/home). | 
| Amplio procesamiento fuera de línea | Utilice [Batch API](batch-inference.md) o [Flex Tier](service-tiers-inference.md). |