Por que resiliência em inferência LLM virou prioridade de produção
Implementar padrões de resiliência para inferência de modelos de linguagem de grande escala (LLM) deixou de ser opcional. Com aplicações de IA generativa saindo dos laboratórios e chegando a ambientes produtivos, as equipes precisam garantir que a inferência permaneça disponível, responsiva e economicamente viável mesmo sob pressão.
Boas práticas clássicas — como estabilidade estática, backoffs e retentativas — ainda se aplicam. Mas a IA generativa traz novos desafios: disponibilidade de modelos específicos, cotas que mudam rapidamente, limites de tokens em múltiplos provedores e consistência com modelos recém-lançados.
O Amazon Bedrock oferece modelos de fundação totalmente gerenciados com recursos nativos de resiliência, como inferência entre regiões. Quando se projeta inferência para produção, quatro dimensões costumam guiar as decisões arquiteturais:
- Disponibilidade: manter a inferência funcionando mesmo durante falhas de modelo, região ou provedor.
- Tempo de resposta: velocidade com que o usuário recebe o output, medida pelo Tempo até o Primeiro Token (TTFT) e Tempo até o Último Token (TTLT).
- Custo: gasto por token e por requisição, e como as decisões de roteamento afetam esse valor.
- Throughput: quantas requisições simultâneas e tokens por segundo o sistema aguenta sob carga.
Essas dimensões são interligadas. Roteamento entre regiões, por exemplo, melhora disponibilidade e throughput, mas pode aumentar a latência. Os cinco padrões apresentados a seguir focam principalmente em disponibilidade — mantendo a inferência operacional por meio de failover, distribuição geográfica e isolamento de cotas.
Uma abordagem incremental: do nativo ao gateway
A progressão sugerida segue uma lógica de “engatinhar, caminhar, correr”: começa com recursos nativos do Amazon Bedrock e avança até orquestração multi-modelo via LLM Gateway. Isso permite adotar os padrões gradualmente, conforme a maturidade e os requisitos da aplicação. Os exemplos de código para cada padrão estão disponíveis no repositório GitHub oficial.
Antes de começar, é necessário verificar se o software adequado está instalado e se a conta AWS está configurada corretamente — consulte os pré-requisitos no repositório. Vale lembrar que os padrões descritos criam recursos AWS que geram cobranças, incluindo requisições de inferência no Amazon Bedrock e logs no Amazon CloudWatch.
Padrão 1: Inferência entre regiões com Amazon Bedrock (CRIS)
A Inferência Entre Regiões do Amazon Bedrock (CRIS) é um recurso nativo que serve de base para a resiliência por padrão. Com os perfis de inferência entre regiões, é possível aumentar o throughput, reduzir a chance de throttling dentro de uma única região AWS e distribuir o tráfego de modelos — sem gerenciamento manual.
O CRIS roteia automaticamente as requisições da região de origem para a região de destino mais adequada, considerando disponibilidade, latência e demanda em tempo real. Isso lida bem com picos inesperados de tráfego e reduz o impacto de cotas de serviço. Os perfis CRIS costumam estar vinculados a regiões comerciais dentro de uma mesma geografia — como EUA ou Europa — equilibrando desempenho e latência.
Para casos de uso que toleram maior latência, existe a opção dos perfis de Inferência Global Entre Regiões. Com um perfil Global, as requisições podem ser roteadas por múltiplas regiões comerciais onde o modelo está disponível, entregando throughput ainda maior do que os perfis padrão entre regiões.
No exemplo do repositório, ao enviar 10 requisições usando um perfil de inferência entre regiões, o CRIS distribui automaticamente a carga por 3 regiões AWS — demonstrando como o recurso atua de forma transparente para a aplicação.
Padrão 2: Sharding de contas AWS
Enquanto o CRIS multiplica o throughput dentro de uma conta AWS, o sharding de contas distribui requisições por múltiplas contas, cada uma com cotas independentes e perfis CRIS próprios. Isso cria fronteiras naturais de isolamento de falhas: problemas em uma conta não afetam as demais.
Essa abordagem é especialmente valiosa para arquiteturas multi-time e multi-tenant que exigem isolamento rígido entre workloads. Na demonstração do repositório, 10 requisições são enviadas para cada uma das duas contas AWS configuradas, e cada conta distribui independentemente a inferência entre regiões AWS — mostrando como o isolamento funciona na prática.
LLM Gateway: orquestração para cenários complexos
Para cenários de produção mais complexos, um LLM Gateway oferece capacidades de roteamento, failover e governança que vão além do que é possível com chamadas diretas à API. O gateway atua como um proxy inteligente entre as aplicações e os provedores de LLM, fornecendo uma camada de abstração unificada — permitindo acessar múltiplos modelos de diferentes fornecedores por uma única interface de API.
Essa padronização simplifica a integração e embute funcionalidades como salvaguardas de IA responsável, logging de auditoria, lógica automática de retry e fallback, e gerenciamento de cotas. O gateway também suporta roteamento inteligente e balanceamento de carga entre múltiplos modelos e contas, implementando rate limiting e gerenciamento de cotas com isolamento por consumidor.
Diversas opções de LLM Gateway — open source e comerciais — estão disponíveis hoje. Para as demonstrações do repositório, é utilizado o LiteLLM, uma opção leve e open source rodando localmente. Para implantações em escala, a AWS Solution for Multi-Provider Generative AI Gateway fornece uma implementação de referência que também usa LiteLLM, mas adiciona capacidades enterprise: implantação em containers no Amazon Elastic Container Service (ECS) ou no Amazon Elastic Kubernetes Service (EKS), escalabilidade automática, proteção com AWS WAF, gerenciamento de segredos e observabilidade completa via Amazon CloudWatch.
Padrão 3: Fallback automático entre modelos
O failover automático entre modelos mantém a disponibilidade mesmo quando os modelos primários atingem rate limits ou enfrentam interrupções. O padrão roteia requisições automaticamente entre modelos primários e secundários definidos pelo usuário.
Vale destacar: se a estratégia de fallback foca em otimizar qualidade e custo — e não apenas em esgotamento de cotas — o Amazon Bedrock Intelligent Prompt Routing oferece uma opção nativa, selecionando dinamicamente o modelo mais adequado para cada requisição sem necessidade de gateway externo.
Na demonstração com LiteLLM, o modelo primário tem um rate limit restritivo de 3 requisições por minuto (RPM) e o modelo de fallback tem capacidade de 25 RPM. Ao enviar 10 requisições simultâneas pelo gateway, as 3 primeiras vão para o modelo primário. Ao atingir o limite, o LiteLLM desvia automaticamente as 7 requisições restantes para o modelo de fallback — tudo sem intervenção manual ou lógica de retry no nível da aplicação. O resultado: 100% de sucesso nas 10 requisições.
Padrão 4: Balanceamento de carga entre modelos
O balanceamento de carga distribui requisições por múltiplas instâncias de modelo para otimizar a utilização de recursos e evitar gargalos. Além de maximizar o uso, a abordagem permite escalar rapidamente adicionando ou removendo instâncias conforme necessário.
Um caso de uso interessante é a avaliação de novos modelos antes do deploy completo: é possível implementar roteamento ponderado ou estratégias de A/B testing, direcionando apenas uma pequena porcentagem de requisições para o novo modelo enquanto a maioria continua usando os modelos já validados.
Na demonstração, o gateway distribui 10 requisições simultâneas por dois modelos usando uma estratégia de embaralhamento (shuffle). O balanceador roteia 3 requisições para cada um dos dois modelos primários configurados e, ao atingir o rate limit, as 4 requisições restantes são redirecionadas automaticamente para o modelo de fallback — resultando em 100% de sucesso.
Padrão 5: Isolamento de cotas em ambientes multi-tenant
O padrão de isolamento de cotas multi-tenant cria ambientes logicamente isolados, cada um com suas próprias cotas e rate limits, para gerenciar requisições em ambientes com múltiplos inquilinos. Ao implementar buckets de rate limiting independentes para cada consumidor, o padrão evita o problema do “vizinho barulhento” — onde o uso intenso de um consumidor impacta negativamente o desempenho dos demais.
Cada tenant recebe uma cota dedicada independente dos padrões de uso dos demais, garantindo alocação justa de recursos e qualidade de serviço consistente. Na demonstração, três consumidores com rate limits diferentes tentam acessar o mesmo modelo simultaneamente:
- Consumidor A: 3 RPM permitidos — ao enviar 5 requisições, apenas 3 têm sucesso e 2 são rejeitadas por rate limiting.
- Consumidor B: 10 RPM — 100% de sucesso nas 5 requisições.
- Consumidor C: 10 RPM — 100% de sucesso nas 5 requisições.
O resultado confirma que o isolamento funciona: o Consumidor A (“barulhento”) não afeta em nada a experiência dos Consumidores B e C.
Quando faz sentido aplicar esses padrões?
A resposta, como em quase tudo em arquitetura, é “depende”. Mas alguns cenários onde esses padrões claramente fazem sentido incluem:
- Alta disponibilidade: quando a aplicação não pode tolerar downtime, múltiplos modelos garantem failover automático.
- Escala além das cotas de um único modelo: usar o mesmo tipo de modelo em diferentes contas e regiões multiplica a capacidade total disponível.
- Isolamento multi-tenant: em aplicações SaaS, diferentes clientes podem usar modelos ou instâncias distintas, sem que o uso de um impacte os outros.
- Desenvolvimento vs. produção: configurações separadas para testes (modelos mais baratos e rápidos) e produção (modelos de maior qualidade) sem mudanças no código.
Conclusão
Os cinco padrões apresentados cobrem uma progressão completa para inferência LLM resiliente — desde o CRIS nativo do Amazon Bedrock até padrões mais complexos que requerem um LLM Gateway. Com essas estratégias, equipes ganham controle granular sobre disponibilidade de modelos, estratégias de failover e isolamento por consumidor ou aplicação.
O repositório GitHub traz exemplos de código e instruções passo a passo para testar cada padrão. Para uma implementação de referência completa de um LLM Gateway pronto para produção, a AWS Solution for Multi-Provider Generative AI Gateway é o ponto de partida recomendado. Para mais padrões arquiteturais e boas práticas de IA generativa, o Blog de Inteligência Artificial da AWS é uma boa fonte de consulta.
Fonte
Implementing resilience patterns with Amazon Bedrock and LLM gateway (https://aws.amazon.com/blogs/machine-learning/implementing-resilience-patterns-with-amazon-bedrock-and-llm-gateway/)
Leave a Reply