Amazon Bedrock: modelos gerenciados e escolha de modelo
A porta de entrada para IA na AWS, e como escolher modelo por custo, latência e raciocínio.
5 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
Se você quer rodar um LLM em produção na AWS sem gerenciar GPU, cluster ou contrato com cada provedor de modelo, o Amazon Bedrock é sua porta de entrada. Uma API unificada, serverless, pay-per-token, e a decisão mais importante que você vai tomar não é 'usar Bedrock ou não', mas sim 'qual modelo escolher e por quê'.
O que é o Amazon Bedrock
O Bedrock é um serviço gerenciado que expõe modelos de fundação de múltiplos provedores: Anthropic (Claude), Meta (Llama), Mistral, Amazon (Titan, Nova) e outros, através de uma única API chamada Converse. Você não provisiona nada: não há instância EC2, não há contêiner, não há endpoint permanente para manter vivo.
A analogia que uso: o Bedrock é para modelos o que o S3 é para armazenamento. Você chama a API, paga pelo que usa, e a AWS cuida de toda a infraestrutura por baixo, escalabilidade, disponibilidade, patches, isolamento de tenant.
A API Converse é o detalhe mais importante do ponto de vista de arquitetura. Ela padroniza o contrato de chamada independente do modelo: você manda uma lista de mensagens, recebe uma resposta. Trocar de Claude para Llama é mudar um parâmetro modelId, não reescrever a integração. Isso tem valor real quando você precisa comparar modelos ou migrar por custo.
O meu próprio site usa Bedrock em produção, o assistente que responde perguntas sobre minha trajetória e conteúdo roda sobre Claude via Converse API, sem nenhum servidor dedicado. O custo é proporcional ao uso real, o que faz sentido para um site pessoal com tráfego variável.
Como o Bedrock se encaixa na arquitetura
Seu app nunca fala diretamente com Anthropic, Meta ou Mistral. Ele chama a Converse API do Bedrock e o serviço roteia para o modelo escolhido. O app só precisa de IAM e endpoint regional.
- App / Lambda · Business logic
- IAM Role · Least privilege
- Converse API · modelId param
- Model Router · Serverless dispatch
- Claude (Anthropic) · Raciocínio / Reasoning
- Amazon Nova · Custo / Cost
- Llama (Meta) · Open weights
- Mistral · Latência / Latency
Na prática, o maior erro que vejo é escolher o modelo mais poderoso disponível por padrão, geralmente Claude Opus ou equivalente, e só perceber o custo quando a fatura chega. Minha regra: comece pelo modelo mais barato que resolve o problema. Suba de tier só quando os evals mostrarem que o modelo menor falha. Isso não é frugalidade, é engenharia.
Por que serverless e pay-per-token combinam com FinOps
No modelo serverless do Bedrock, você paga por token de entrada e por token de saída. Não há custo de idle, se ninguém usa o sistema às 3h da manhã, você não paga nada. Isso muda completamente o cálculo de TCO comparado a hospedar um modelo em EC2 ou EKS, onde a instância corre 24/7.
O impacto prático: para cargas de trabalho com tráfego irregular, um assistente interno que só é usado em horário comercial, um pipeline de processamento de documentos que roda em batch, o modelo on-demand do Bedrock é quase sempre mais barato que infraestrutura dedicada.
Quando o tráfego é alto e previsível, existe a opção de inferência provisionada: você reserva capacidade de modelo e paga por hora, independente do uso. O break-even depende do volume, mas para a maioria dos casos de uso iniciais, on-demand é o ponto de partida correto.
O outro ângulo de FinOps é o custo por token varia muito entre modelos. Um modelo de raciocínio pesado pode custar 10–50× mais por token que um modelo leve. Se sua tarefa é classificar sentimento em reviews curtos, usar o modelo mais caro é desperdício puro. A escolha de modelo é a alavanca de custo mais poderosa que você tem.
Como escolher o modelo certo no Bedrock
Claude Haiku / Nova Micro
- Custo muito baixo por token
- Latência baixa, bom para streaming em tempo real
- Suficiente para classificação, extração simples, resumo curto
- Raciocínio limitado em tarefas complexas
- Janela de contexto menor em alguns modelos
Ponto de partida padrão. Use até os evals mostrarem falha.
Claude Sonnet / Nova Pro
- Equilíbrio forte entre custo e capacidade
- Bom raciocínio, contexto longo, tool calling robusto
- Cobre a maioria dos casos de uso de agentes
- Mais caro que modelos leves
- Latência maior que Haiku em respostas longas
Tier de produção para agentes e RAG com complexidade média.
Claude Opus / modelos de raciocínio
- Máxima capacidade de raciocínio e instrução complexa
- Melhor para análise profunda, código complexo, decisões críticas
- Custo por token significativamente mais alto
- Latência mais alta, ruim para UX interativo
Reserve para tarefas onde raciocínio profundo é comprovadamente necessário.
Llama / Mistral (open weights)
- Custo competitivo, sem lock-in de provedor proprietário
- Opção para fine-tuning e customização
- Capacidade de instrução geralmente abaixo dos modelos Anthropic/Amazon no mesmo tier de custo
- Ecossistema de tool calling menos maduro em alguns modelos
Válido para casos com restrição de custo extrema ou necessidade de fine-tuning.
Os quatro critérios que dominam a escolha de modelo
Toda escolha de modelo no Bedrock gira em torno de quatro variáveis. Entender o trade-off entre elas é o que separa uma decisão de arquitetura de um chute.
Raciocínio é a capacidade do modelo de seguir instruções complexas, encadear passos lógicos e usar ferramentas corretamente. Para agentes com múltiplos tool calls e lógica condicional, raciocínio fraco quebra o fluxo. Para classificação binária, raciocínio avançado é desperdício.
Custo é medido em dólares por milhão de tokens, e o delta entre modelos pode ser de uma ordem de magnitude. Como vimos na aula de FinOps (aula 19), o custo de tokens domina o TCO de sistemas de IA em escala. Escolher o modelo certo é a decisão de custo mais impactante que você toma.
Latência importa para UX. Streaming ajuda a esconder latência de tempo-até-primeiro-token, mas modelos maiores ainda são mais lentos. Para um chatbot interativo, latência percebida acima de 2–3 segundos degrada a experiência. Para um pipeline batch noturno, latência não é critério.
Janela de contexto define quanto texto o modelo consegue processar em uma única chamada. Para RAG com documentos longos ou agentes com histórico extenso (aula 12), uma janela pequena força chunking e aumenta complexidade. Modelos com janelas de 200k tokens resolvem problemas que modelos de 8k simplesmente não conseguem.
A matriz de decisão acima resume onde cada família de modelos se encaixa. Use-a como ponto de partida, e valide com evals reais (aula 9).
O que fixar desta aula
Perguntas frequentes
Preciso de conta especial ou aprovação para usar modelos no Bedrock?
Alguns modelos exigem que você solicite acesso explicitamente no console do Bedrock (Model Access). É um processo simples, mas precisa ser feito antes de chamar a API. Modelos Amazon geralmente ficam disponíveis imediatamente; modelos de terceiros como Claude podem exigir aceite de termos do provedor.
Os dados que envio para o Bedrock são usados para treinar modelos?
Não, por padrão. A AWS garante que prompts e respostas em inferência on-demand não são usados para melhorar modelos base. Isso é um diferencial importante para casos de uso com dados sensíveis. Verifique sempre a documentação e o BAA se estiver em contexto regulado (HIPAA, etc.).
Qual a diferença entre Bedrock e SageMaker para rodar modelos?
Bedrock é para consumir modelos de fundação prontos, sem gerenciar infraestrutura. SageMaker é para treinar, fine-tunar e hospedar modelos customizados com controle total de infraestrutura. Para a maioria dos casos de uso de aplicações com LLMs, Bedrock é a escolha certa. SageMaker entra quando você precisa de fine-tuning ou de modelos que não estão disponíveis no catálogo do Bedrock.
Minha opinião direta
O Bedrock resolve o problema certo: ele tira da sua frente a complexidade de infraestrutura de modelo e te deixa focar no que importa, a lógica da aplicação. A API Converse é bem desenhada, o modelo serverless é honesto com os custos, e o catálogo de modelos é suficientemente amplo para cobrir praticamente qualquer caso de uso. O risco real não é técnico, é arquitetural: escolher o modelo errado por falta de critério e pagar 10× mais do que precisaria. Use a matriz de decisão, rode evals cedo, e trate a escolha de modelo como uma decisão de engenharia revisável, não uma escolha permanente.