Mejores prácticas de escalado y rendimiento

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 mejores prácticas para escalar las aplicaciones de IA generativa.

Puntos de conexión de Amazon Bedrock

Amazon Bedrock admite dos puntos finales para la inferencia:

Para la mayoría de las aplicaciones nuevas, comience por. bedrock-runtime Úselo bedrock-mantle cuando necesite funciones que solo estén disponibles en ese punto final, como las herramientas del lado del servidor, la inferencia en segundo plano, los proyectos, los espacios de trabajo o un modelo que solo esté disponible en. bedrock-mantle Puede usar ambos puntos finales en la misma aplicación. Para obtener una comparación completa, consulteTerminales compatibles con Amazon Bedrock.

Por qué los dos puntos finales se comportan de manera diferente

Ambas superficies de punto final utilizan el mismo motor de inferencia subyacente, pero sus opciones de capacidad y contabilidad de cuotas son diferentes. bedrock-runtimeutiliza cuotas de fichas por modelo y, en algunos modelos, cuotas de solicitudes por minuto (RPM). bedrock-mantleno impone cuotas de RPM y usa cuotas de token de entrada y de salida independientes para los modelos que tienen cuotas publicadas. bedrock-mantleEs posible que otros modelos no tengan las cuotas por cuenta expuestas en las cuotas de servicio, pero su rendimiento sigue dependiendo de la capacidad de servicio interna.

Una cuota es un límite superior, no una garantía de que todas las solicitudes bajo demanda se atiendan de forma inmediata. Durante los períodos de alta demanda, las solicitudes pueden ponerse en cola o recibir errores de capacidad transitorios. Diseñe su aplicación para limitar la concurrencia, poner en cola el trabajo y reintentar los errores transitorios sin generar un aumento de reintentos.

punto final fundamental: rendimiento y cuotas

El bedrock-mantle punto final tiene el siguiente comportamiento de cuota:

Los valores predeterminados y las asignaciones de tu cuenta pueden variar según el modelo, la región y el historial de uso. Para ver los valores actuales, los detalles de la evaluación de las cuotas y el proceso de AWS asistencia para solicitar un aumento, consultaCuotas para el punto final entre el lecho rocoso y el manto. Consulte la sección correspondiente Modelos de un vistazo para obtener información sobre el soporte de terminales, niveles de servicio y funciones específicos para cada modelo.

punto final de ejecución básico: rendimiento y cuotas

El bedrock-runtime punto final tiene el siguiente comportamiento de cuota:

Para ver los valores de las cuotas actuales, los detalles sobre la reducción de los tokens y el proceso de aumento de las cuotas, consulte. Cuotas para el punto final de ejecución básico Consulta la sección correspondiente Modelos de un vistazo para conocer el soporte para terminales, niveles de servicio y funciones específicos de cada modelo.

Comprender las respuestas de error de HTTP

Para conocer API-specific las causas y los pasos para resolverlos, consulte. Solución de códigos de error de la API de Amazon Bedrock

Tratamiento de errores recomendado

Errores transitorios

Vuelva a intentar solo los errores que se puedan reintentar de forma segura, como los errores transitorios de limitación y capacidad. Si el servicio devuelve un Retry-After encabezado, acéptelo. De lo contrario, implementa un retroceso exponencial con una fluctuación aleatoria:

La mayoría de AWS los SDK y bibliotecas HTTP populares ofrecen soporte integrado para este patrón. Retry-setting los nombres difieren: el de botocore total_max_attempts incluye la solicitud inicial, mientras que el de los SDK de OpenAI y Anthropic solo cuenta los reintentos. max_retries Por lo tanto, los siguientes ejemplos utilizan valores numéricos diferentes para proporcionar el mismo presupuesto para seis intentos del ejemplo.

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

import anthropic

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

Configure los tiempos de espera de conexión y lectura por separado de los reintentos, en función de la duración máxima de inferencia documentada del modelo y la operación. Un tiempo de espera inferior al de una solicitud de inferencia válida de larga duración puede provocar reintentos evitables y trabajos duplicados.

Errores de capacidad sostenidos

Si recibe errores 503 o 529 persistentes, los reintentos por sí solos pueden amplificar la carga. Es posible que el servicio esté experimentando una restricción de capacidad temporal o que la carga de trabajo supere la capacidad disponible actualmente para el modelo y la región. Siga estos pasos:

Aumentando el rendimiento

On-demand la capacidad puede variar según el modelo, la región y la época. No se garantiza que todas las solicitudes dentro de una cuota tengan éxito durante los períodos de alta demanda, por lo que debe aumentarlas gradualmente al iniciar una carga de trabajo, cambiar de modelo o región o aumentar considerablemente el tráfico. Esto es especialmente importante para bedrock-mantle los modelos que no tienen una cuota de publicaciones por cuenta.

Procedimiento de aceleración recomendado

Elija el tamaño del paso y el período de observación a partir del patrón de tráfico y latencia de su carga de trabajo. No utilices el RPM como la única señal de control: el tamaño de los tokens de solicitud y la duración de las respuestas pueden cambiar considerablemente el consumo de capacidad, incluso cuando el RPM se mantiene constante.

Para aumentar las bedrock-mantle cuotas, sigaSolicitud de aumento de cuota. Parabedrock-runtime, sigueSolicitud de aumento de cuota.

Prácticas recomendadas adicionales

Disponibilidad regional e inferencia interregional

On-demand la capacidad es regional y puede variar de una región a otra. Si su carga de trabajo se dirige a una sola región, es posible que se produzcan errores de capacidad durante los períodos de gran demanda. bedrock-runtimeUtilícela Inferencia interregional global cuando el modelo y sus requisitos de residencia de datos lo respalden. Si implementas tu propia conmutación por error regional, verifica la disponibilidad del modelo en cada región de destino y aplica reintentos limitados para que la conmutación por error no genere un aumento del tráfico.

Obtener ayuda

Resumen de recomendaciones