Meilleures pratiques en matière d'évolutivité et de débit

Cette rubrique explique comment les limites de débit et la planification fonctionnent sur les terminaux Amazon Bedrock et fournit les meilleures pratiques pour faire évoluer vos applications d'IA génératives.

Points de terminaison Amazon Bedrock

Amazon Bedrock prend en charge deux points de terminaison pour l'inférence :

Pour la plupart des nouvelles applications, commencez parbedrock-runtime. À utiliser bedrock-mantle lorsque vous avez besoin de fonctionnalités disponibles uniquement sur ce terminal, telles que des outils côté serveur, l'inférence en arrière-plan, des projets, des espaces de travail ou un modèle disponible uniquement sur. bedrock-mantle Vous pouvez utiliser les deux terminaux dans la même application. Pour une comparaison complète, voirPoints de terminaison pris en charge par Amazon Bedrock.

Pourquoi les deux terminaux se comportent différemment

Les deux surfaces de terminaison utilisent le même moteur d'inférence sous-jacent, mais leurs options de comptabilisation des quotas et de capacité diffèrent. bedrock-runtimeutilise des quotas de jetons par modèle et, pour certains modèles, des quotas de demandes par minute (RPM). bedrock-mantlen'applique pas de quotas RPM et utilise des quotas de jetons d'entrée et de jetons de sortie distincts pour les modèles qui ont publié des quotas. D'autres modèles activés n'ont bedrock-mantle peut-être pas de quotas par compte exposés dans les quotas de service, mais leur débit est toujours régi par la capacité de service interne.

Un quota est une limite supérieure et ne garantit pas que chaque demande à la demande sera traitée immédiatement. Pendant les périodes de forte demande, les demandes peuvent être mises en file d'attente ou recevoir des erreurs de capacité transitoires. Concevez votre application de manière à limiter la simultanéité, à travailler en file d'attente et à réessayer les erreurs transitoires sans créer de nouvelles tentatives.

point final du manteau rocheux : débit et quotas

Le bedrock-mantle terminal présente le comportement de quota suivant :

Les valeurs par défaut et les allocations de votre compte peuvent varier en fonction du modèle, de la région et de l'historique d'utilisation. Pour les valeurs actuelles, les détails de l'évaluation des quotas et la procédure d' AWS assistance pour demander une augmentation, consultezQuotas pour la limite entre le substrat rocheux et le manteau. Consultez les informations applicables Les modèles en un coup d'œil pour la prise en charge des terminaux, des niveaux de service et des fonctionnalités spécifiques au modèle.

point final d'exécution fondamental : débit et quotas

Le bedrock-runtime terminal présente le comportement de quota suivant :

Pour les valeurs de quota actuelles, les détails de la combustion des jetons et le processus d'augmentation des quotas, consultez. Quotas pour le paramètre d'exécution fondamental Consultez les informations applicables Les modèles en un coup d'œil pour la prise en charge des terminaux, des niveaux de service et des fonctionnalités spécifiques au modèle.

Comprendre les réponses aux erreurs HTTP

Pour connaître API-specific les causes et les étapes de résolution, consultezRésolution des codes d’erreur d’API Amazon Bedrock.

Gestion des erreurs recommandée

Erreurs transitoires

Réessayez uniquement les erreurs qui peuvent être réessayées en toute sécurité, telles que les erreurs de limitation transitoire et de capacité. Si le service renvoie un Retry-After en-tête, respectez-le. Sinon, implémentez un ralentissement exponentiel avec une gigue aléatoire :

La plupart AWS des SDK et bibliothèques HTTP populaires fournissent un support intégré pour ce modèle. Retry-setting les noms diffèrent : celui de botocore total_max_attempts inclut la demande initiale, tandis que celui des SDK max_retries OpenAI et Anthropic ne compte que les nouvelles tentatives. Les exemples suivants utilisent donc des valeurs numériques différentes pour fournir le même exemple de budget pour six tentatives.

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

Configurez les délais de connexion et de lecture séparément des nouvelles tentatives, en fonction du modèle et de la durée d'inférence maximale documentée de l'opération. Un délai d'attente plus court qu'une demande d'inférence valide de longue durée peut entraîner des tentatives évitables et des doublons.

Erreurs de capacité persistantes

Si vous recevez des erreurs 503 ou 529 persistantes, les nouvelles tentatives peuvent à elles seules amplifier la charge. Le service est peut-être confronté à une contrainte de capacité temporaire ou la charge de travail peut dépasser la capacité actuellement disponible pour le modèle et la région. Suivez les étapes suivantes:

Augmenter le débit

On-demand la capacité peut varier selon le modèle, la région et l'heure. Le succès de toutes les demandes ne dépassant pas un quota n'est pas garanti pendant les périodes de forte demande. Vous devez donc augmenter progressivement lorsque vous lancez une charge de travail, changez de modèle ou de région ou augmentez considérablement le trafic. Ceci est particulièrement important pour les bedrock-mantle modèles qui n'ont pas de quota publié par compte.

Procédure de montée en puissance recommandée

Choisissez la taille de l'étape et la période d'observation en fonction de la latence et du schéma de trafic de votre charge de travail. N'utilisez pas le RPM comme seul signal de commande : la taille des jetons de demande et la longueur des réponses peuvent modifier considérablement la consommation de capacité, même lorsque le RPM reste constant.

Pour les augmentations de bedrock-mantle quotas, suivezDemande d’augmentation de quota. Pourbedrock-runtime, suivezDemande d’augmentation de quota.

Bonnes pratiques supplémentaires

Disponibilité régionale et inférence interrégionale

On-demand la capacité est régionale et peut varier d'une région à l'autre. Si votre charge de travail cible une seule région, celle-ci peut rencontrer des erreurs de capacité pendant les périodes de forte demande. Avec bedrock-runtime, à utiliser Inférence interrégionale mondiale lorsque le modèle et vos exigences en matière de résidence des données le permettent. Si vous implémentez votre propre basculement régional, vérifiez la disponibilité du modèle dans chaque région cible et appliquez des nouvelles tentatives limitées afin que le basculement ne crée pas d'augmentation du trafic.

Obtenir de l'aide

Résumé des recommandations