As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Práticas recomendadas de escalabilidade e taxa de transferência
Este tópico explica como os limites de taxa de transferência e a programação funcionam nos endpoints do Amazon Bedrock e fornece as melhores práticas para escalar seus aplicativos generativos de IA.
Endpoints do Amazon Bedrock
O Amazon Bedrock oferece suporte a dois endpoints para inferência:
-
bedrock-mantle.{region}.api.aws— Suporta as APIs de preenchimento e respostas de OpenAI-compatible bate-papo e a API de mensagens antrópicas. -
bedrock-runtime.{region}.amazonaws.com— Suporta as APIs Bedrock-native InvokeModel e Converse, as APIs de preenchimento e respostas de OpenAI-compatible bate-papo e a API de mensagens antrópicas.
Para a maioria dos novos aplicativos, comece combedrock-runtime. Use bedrock-mantle quando precisar de recursos que estejam disponíveis somente nesse endpoint, como ferramentas do lado do servidor, inferência em segundo plano, projetos, espaços de trabalho ou um modelo que esteja disponível somente em. bedrock-mantle Você pode usar os dois endpoints no mesmo aplicativo. Para uma comparação completa, consulteEndpoints compatíveis com o Amazon Bedrock.
Por que os dois endpoints se comportam de maneira diferente
Ambas as superfícies de endpoint usam o mesmo mecanismo de inferência subjacente, mas suas opções de contabilização de cotas e capacidade são diferentes. bedrock-runtimeusa cotas de token por modelo e, para alguns modelos, cotas de solicitações por minuto (RPM). bedrock-mantlenão impõe cotas de RPM e usa cotas separadas de token de entrada e token de saída para modelos que têm cotas publicadas. Outros modelos bedrock-mantle podem não ter cotas por conta expostas nas cotas de serviço, mas sua taxa de transferência ainda é governada pela capacidade interna do serviço.
Uma cota é um limite superior, não uma garantia de que todas as solicitações sob demanda serão atendidas imediatamente. Durante períodos de alta demanda, as solicitações podem ser colocadas em fila ou receber erros transitórios de capacidade. Projete seu aplicativo para limitar a simultaneidade, enfileirar o trabalho e repetir erros transitórios sem criar um aumento de novas tentativas.
O bedrock-mantle endpoint tem o seguinte comportamento de cota:
-
Os modelos com cotas publicadas têm cotas separadas por modelo, por região, tokens de entrada por minuto e tokens de saída por minuto.
-
O endpoint não impõe cotas de RPM. Duas cargas de trabalho com o mesmo RPM podem consumir quantidades muito diferentes de capacidade, portanto, planeje e limite a taxa por tokens e simultaneidade, em vez de apenas RPM.
-
Quando uma solicitação é admitida, a verificação do token de entrada inclui os tokens de entrada mais o valor solicitado.
max_tokensDepois que a resposta for concluída, a parte não utilizada dessa reserva será reabastecida. Definamax_tokensnão mais do que as necessidades do seu aplicativo. -
Atualmente, os modelos sem cotas de TPM publicadas não têm cotas de TPM por conta expostas em Cotas de serviço. Isso não significa que a taxa de transferência seja ilimitada; a capacidade interna de serviço e a limitação de taxa transitória ainda se aplicam.
-
A inferência em lote e a taxa de transferência provisionada estão disponíveis somente por meio de.
bedrock-runtimeService-tier e o suporte do modelo varia de acordo com o modelo.
Os valores padrão e as alocações da sua conta podem variar de acordo com o modelo, a região e o histórico de uso. Para valores atuais, detalhes da avaliação de cotas e o processo de AWS suporte para solicitar um aumento, consulte. Cotas para o endpoint rocho-mantle Consulte o aplicável Modelos em resumo para suporte a endpoints, níveis de serviço e recursos específicos do modelo.
O bedrock-runtime endpoint tem o seguinte comportamento de cota:
-
Per-model, As cotas de token por região contam os tokens de entrada e saída juntos. Os tokens de saída consomem a cota de acordo com a taxa de queima específica do modelo.
-
Alguns modelos também têm cotas de RPM, enquanto outros modelos são regidos somente por cotas simbólicas. Verifique as cotas que se aplicam ao modelo exato e ao perfil de inferência que você usa.
-
Per-minute e as cotas de token por dia são compartilhadas entre as APIs de inferência que chamam o mesmo modelo nesse endpoint. As alocações para
bedrock-runtimeebedrock-mantlesão independentes. -
Perfis de inferência personalizados, inferência em lote e taxa de transferência provisionada têm cotas separadas e estão disponíveis somente por meio de.
bedrock-runtime
Para ver os valores atuais da cota, os detalhes da queima de tokens e o processo de aumento da cota, consulte. Cotas para o endpoint básico de tempo de execução Consulte o aplicável Modelos em resumo para suporte a endpoints, níveis de serviço e recursos específicos do modelo.
Entendendo as respostas de erro HTTP
- HTTP: 429
-
Uma resposta 429 significa que a solicitação não foi admitida. Inspecione o tipo de API-specific erro em vez de confiar apenas no status HTTP. Um erro
ThrottlingExceptionde limite de taxa geralmente significa que a solicitação excedeu a cota da conta ou o limite da taxa de serviço. Algumas operações de tempo de execução também usam HTTP 429 paraModelNotReadyException. Ligadobedrock-mantle, verifique o uso do TPM de entrada e saída e omax_tokensvalor da solicitação; o endpoint não tem uma cota de RPM. Ativadobedrock-runtime, verifique as cotas de token e RPM combinadas, se o modelo tiver uma cota de RPM. - HTTP 503
-
Uma resposta 503 significa que o serviço está temporariamente incapaz de lidar com a solicitação devido à alta demanda ou a uma restrição de capacidade. Isso não indica que você excedeu a cota da conta. Tente novamente as respostas transitórias com recuo exponencial e instabilidade. Se a resposta persistir, pare de aumentar o tráfego, reduza a simultaneidade e considere uma inferência regional ou interregional diferente quando houver suporte.
- HTTP (529)
overloaded_error -
Algumas APIs de modelo retornam 529 quando o modelo está temporariamente incapaz de processar a solicitação devido à alta demanda ou à capacidade de atendimento insuficiente. Trate isso como um erro de capacidade transitório. Se a resposta incluir um
Retry-Aftercabeçalho, aguarde pelo menos essa duração antes de tentar novamente e adicione instabilidade para que os clientes não tentem novamente simultaneamente.
Para API-specific causas e etapas de resolução, consulteSolução de problemas dos códigos de erro da API do Amazon Bedrock.
Tratamento de erros recomendado
Erros transitórios
Repita somente os erros que possam ser repetidos com segurança, como limitação transitória e erros de capacidade. Se o serviço retornar um Retry-After cabeçalho, honre-o. Caso contrário, implemente o recuo exponencial com instabilidade aleatória:
Comece com um pequeno atraso (por exemplo, 1 segundo).
Aumente o atraso após cada nova tentativa e limite o atraso máximo para caber no orçamento de latência do seu aplicativo.
Adicione instabilidade aleatória e evite novas tentativas sincronizadas entre os trabalhadores.
Use um orçamento limitado de novas tentativas que atenda ao objetivo de latência do seu aplicativo. Por exemplo, limite a operação a seis tentativas totais: a solicitação inicial e até cinco novas tentativas.
A maioria dos AWS SDKs e bibliotecas HTTP populares oferecem suporte integrado para esse padrão. Retry-setting os nomes diferem: o botocore total_max_attempts inclui a solicitação inicial, enquanto os SDKs max_retries do OpenAI e do Anthropic contam apenas novas tentativas. Portanto, os exemplos a seguir usam valores numéricos diferentes para fornecer o mesmo exemplo de orçamento de seis tentativas.
exemplo Tente novamente a configuração para
import boto3 from botocore.config import Config config = Config(retries={"total_max_attempts": 6, "mode": "standard"}) client = boto3.client("bedrock-runtime", config=config)
exemplo Tente novamente a configuração para
from openai import OpenAI client = OpenAI( api_key=api_key, base_url=f"https://bedrock-mantle.{region}.api.aws/v1", max_retries=5, )
exemplo Tente novamente a configuração para
import anthropic client = anthropic.Anthropic( api_key=api_key, base_url=f"https://bedrock-mantle.{region}.api.aws/anthropic", max_retries=5, )
Configure os tempos limite de conexão e leitura separadamente das novas tentativas, com base na duração máxima da inferência documentada do modelo e da operação. Um tempo limite menor do que uma solicitação de inferência válida de longa duração pode causar novas tentativas evitáveis e trabalho duplicado.
Erros de capacidade sustentada
Se você receber erros 503 ou 529 persistentes, apenas as novas tentativas podem amplificar a carga. O serviço pode estar enfrentando uma restrição temporária de capacidade ou a carga de trabalho pode exceder a capacidade atualmente disponível para o modelo e a região. Siga as seguintes etapas:
Pare a rampa e retorne ao último nível estável de taxa de solicitação e simultaneidade.
Use simultaneidade limitada do lado do cliente, limitação de taxa e filas de solicitações.
Adie ou elimine as solicitações de prioridade mais baixa até que a capacidade se recupere.
Para
bedrock-runtime, use a inferência entre regiões quando o modelo a suportar. Para cargas de trabalho previsíveis e sustentadas, avalie a taxa de transferência provisionada.Se o problema persistir, verifique o AWS Health Dashboard e entre em contato com o AWS Suporte com IDs de solicitação e carimbos de data e hora UTC.
Aumentando a taxa de transferência
On-demand a capacidade pode variar de acordo com o modelo, a região e a hora. Nem todas as solicitações dentro de uma cota têm garantia de sucesso em períodos de alta demanda, portanto, aumente gradualmente ao lançar uma carga de trabalho, alterar modelos ou regiões ou aumentar muito o tráfego. Isso é especialmente importante para bedrock-mantle modelos que não têm uma cota por conta publicada.
Procedimento de aceleração recomendado
Estime a taxa de token alvo e a simultaneidade para cada endpoint, modelo e região. Para
bedrock-mantle, rastreie os tokens de entrada e saída separadamente e inclua omax_tokensvalor solicitado na estimativa de admissão do token de entrada.Comece com uma linha de base estável conhecida abaixo da meta. Se você não tiver uma linha de base, comece com uma pequena carga representativa em vez de enviar o volume alvo completo.
Mantenha cada nível por tempo suficiente para observar o sucesso da solicitação, erros 429/503 /529, percentis de latência, consumo de token, simultaneidade e profundidade da fila.
Aumente uma etapa controlada por vez. Altere somente uma dimensão de carga principal por vez para que você possa identificar a causa de uma regressão.
Se a limitação, os erros de capacidade ou a latência ultrapassarem seu limite, pause a rampa, honre qualquer
Retry-Aftercabeçalho e retorne ao último nível estável.Continue até atingir a meta e repita a validação para cada modelo e região que receberá tráfego de produção.
Escolha o tamanho da etapa e o período de observação a partir da latência e do padrão de tráfego da sua carga de trabalho. Não use o RPM como o único sinal de controle: os tamanhos dos tokens de solicitação e os comprimentos de resposta podem alterar substancialmente o consumo de capacidade, mesmo quando o RPM permanece constante.
Para aumentos de bedrock-mantle cotas, sigaSolicitar um aumento de cota. Parabedrock-runtime, sigaSolicitar um aumento de cota.
Melhores práticas adicionais
Use sinalizadores de recursos para fazer a transição gradual do tráfego entre os modelos, em vez de alternar todo o tráfego de uma só vez.
Distribua grandes cargas de trabalho em vários minutos e considere os padrões de horário do dia para evitar períodos de pico de uso.
Teste com distribuições representativas de tamanho de entrada, tamanho de saída, latência e simultaneidade. Evite enviar uma explosão repentina de solicitações de teste.
Use limitação de taxa do lado do cliente com reconhecimento de tokens, simultaneidade limitada e filas limitadas. Um RPM-only limitador não protege contra mudanças no tamanho da solicitação.
Para trabalhos off-line assíncronos e de alto volume, use a inferência em lote ativada.
bedrock-runtimePara modelos compatíveis e solicitações não sensíveis ao tempo que podem tolerar latência variável, considere o nível de serviço Flex.
Disponibilidade regional e inferência entre regiões
On-demand a capacidade é regional e pode variar entre regiões. Se sua carga de trabalho atingir uma única região, ela poderá encontrar erros de capacidade durante períodos de alta demanda. Com bedrock-runtime, use Inferência global entre regiões quando o modelo e seus requisitos de residência de dados o apoiarem. Se você implementar seu próprio failover regional, verifique a disponibilidade do modelo em cada região de destino e aplique novas tentativas limitadas para que o failover não crie um aumento de tráfego.
Como obter ajuda
-
Planejamento de produtividade — Estime os picos de tokens de entrada e saída, a latência de resposta, a simultaneidade e a tolerância de filas para cada modelo e região. Inclua espaço livre específico para cargas de trabalho e entre em contato com sua Conta da AWS equipe para lançamentos grandes ou essenciais para os negócios.
-
Otimização de desempenho — Monitore o tamanho do prompt, os tokens gerados
max_tokens, os percentis de latência e o uso do cache quando houver suporte. Otimize os prompts e os limites de saída para evitar a reserva ou o consumo de tokens desnecessários. -
Escalonamento de suporte — Ao abrir um caso de AWS suporte, inclua o ID do endpoint, região, modelo ou perfil de inferência, status HTTP e tipo de erro da API, IDs de solicitação, carimbos de data e hora UTC, taxa de token, taxa de solicitação, simultaneidade e seu cronograma de escalabilidade.
Resumo das recomendações
| Cenário | Recomendação |
|---|---|
| Cargas de trabalho gerais | Comece com bedrock-runtime. Use bedrock-mantle para recursos ou modelos que o exijam. Consulte Endpoints compatíveis com o Amazon Bedrock. |
| Erros transitórios 429, 503 ou 529 | Inspecione o tipo de erro da API. Para erros que podem ser repetidos, honre Retry-After e tente novamente com recuo exponencial e instabilidade dentro de um orçamento limitado para novas tentativas. |
| Erros de capacidade sustentada | Pare de acelerar, retorne ao último nível estável, limite a simultaneidade e as filas, adie o trabalho de baixa prioridade e use a inferência entre regiões quando houver suporte. |
| Planejamento de cotas | Use TPM de entrada e saída separados parabedrock-mantle. Use cotas de token combinadas, queima de tokens e RPM, quando aplicável. bedrock-runtime |
| Grande processamento off-line | Use a inferência em lote para trabalhos assíncronos. Use o nível de serviço Flex para solicitações compatíveis e não sensíveis ao tempo, que podem tolerar latência variável. |
