# ADR: Seleção de Modelo no Amazon Bedrock — Claude vs Nova vs Llama vs Fine-tune Decisão arquitetural sobre qual modelo de fundação adotar em uma feature GenAI enterprise no Amazon Bedrock, avaliando qualidade, custo por token, latência, governança de dados, suporte a pt-BR e janela de contexto. A conclusão é um roteamento por tipo de tarefa — nenhum modelo único vence em todos os eixos. - URL: https://fernando.moretes.com/studies/adr-selecao-de-modelo-no-bedrock - Markdown: https://fernando.moretes.com/studies/adr-selecao-de-modelo-no-bedrock/study.md?lang=pt - Type: Decisão (ADR) - Company: Feature GenAI enterprise (cenário) - Domain: IA - Status: proposed - Date: 2026-02-25 - Tags: bedrock, llm, model-selection, genai, aws, cost-optimization, pt-BR, adr - Reading time: 9 min --- Escolher um modelo de linguagem para produção não é uma decisão de benchmark — é uma decisão de engenharia com consequências diretas em custo operacional, latência percebida, conformidade de dados e capacidade de evolução do produto. Neste ADR, avalio quatro famílias de modelos disponíveis no Amazon Bedrock para uma feature GenAI enterprise com requisitos multilíngues (pt-BR obrigatório), volume estimado de dezenas de milhões de tokens por mês e restrições de dados que impedem envio de PII a APIs externas sem controle contratual explícito. A recomendação final não é um modelo único: é uma estratégia de roteamento por tipo de tarefa. ## Contexto do Cenário - **Sistema:** Feature GenAI enterprise (cenário composto, representativo de casos reais) - **Domínio:** Inteligência Artificial / Processamento de Linguagem Natural - **Plataforma de IA:** Amazon Bedrock (managed inference, sem gerenciamento de GPU) - **Modelos avaliados:** Claude 3.5 Sonnet / Haiku (Anthropic), Amazon Nova Pro / Lite / Micro, Llama 3.x (Meta), fine-tune próprio via Bedrock Custom Model - **Requisitos linguísticos:** pt-BR obrigatório; en-US e es-419 desejáveis - **Volume estimado:** ~50–150 M tokens/mês (estimativa de projeto; varia por caso) - **Restrições de dados:** PII de clientes; LGPD aplicável; dados não podem sair da região AWS sem DPA - **Região AWS primária:** us-east-1 (Bedrock GA); sa-east-1 como região de dados - **Tipos de tarefa:** Sumarização de documentos longos, extração estruturada (JSON), geração de rascunhos, classificação de intenção, Q&A sobre base de conhecimento ## Forças em Jogo Toda decisão de modelo em produção envolve pelo menos cinco tensões simultâneas que raramente apontam para a mesma direção. **Qualidade vs. custo por token.** Modelos frontier como Claude 3.5 Sonnet entregam qualidade de raciocínio e coerência textual em pt-BR que modelos menores simplesmente não alcançam em zero-shot. Mas a diferença de preço entre Sonnet e um modelo custo-otimizado como Nova Micro pode ser de duas ordens de magnitude. Para tarefas de classificação binária ou extração de campos simples, pagar pelo Sonnet é desperdício mensurável. **Latência vs. janela de contexto.** Documentos longos — contratos, laudos, transcrições de chamadas — exigem janelas de contexto de 100k+ tokens. Claude 3.5 Sonnet suporta 200k tokens de contexto. Modelos menores frequentemente têm janelas de 8k–32k, forçando chunking e lógica de retrieval adicional que introduz latência e complexidade operacional. A escolha do modelo afeta diretamente a arquitetura de ingestão. **Governança e residência de dados.** No Bedrock, a inferência ocorre na região AWS configurada e a Anthropic, Meta e Amazon assinaram os termos de não-uso de dados de clientes para treinamento. Isso resolve o problema contratual básico. Porém, fine-tuning com dados proprietários exige que esses dados sejam armazenados em S3 e processados pelo serviço de customização do Bedrock — o que amplia a superfície de auditoria e requer controles adicionais de acesso (IAM, KMS, VPC endpoints). **Multilíngue pt-BR.** Esta é uma força frequentemente subestimada em avaliações feitas com benchmarks em inglês. Claude 3.x e Nova Pro têm desempenho documentado em pt-BR. Llama 3.1/3.2 melhorou significativamente o suporte multilíngue, mas ainda apresenta degradação perceptível em tarefas de geração livre em português comparado ao inglês. Fine-tuning em corpus pt-BR pode compensar essa lacuna, mas cria um ciclo de manutenção. **Velocidade de evolução do produto.** Modelos gerenciados (Claude, Nova) recebem atualizações sem intervenção do time de engenharia. Um fine-tune próprio congela o comportamento base e exige re-treinamento periódico para acompanhar melhorias de modelo — custo de MLOps que precisa estar no denominador da decisão. ## Comparativo de Modelos no Amazon Bedrock (referência de preços: on-demand, us-east-1, 2025) | Critério | Modelo | Input ($/1M tokens) | Output ($/1M tokens) | Contexto máx. | pt-BR | | --- | --- | --- | --- | --- | --- | | Claude 3.5 Sonnet | $3,00 | $15,00 | 200k | Excelente | Média-alta (~2–5s TTFT) | | Claude 3.5 Haiku | $0,80 | $4,00 | 200k | Boa | Baixa (~0,5–1,5s TTFT) | | Amazon Nova Pro | $0,80 | $3,20 | 300k | Boa | Média (~1–3s TTFT) | | Amazon Nova Lite | $0,06 | $0,24 | 300k | Razoável | Baixa (~0,3–1s TTFT) | | Amazon Nova Micro | $0,035 | $0,14 | 128k | Limitada | Muito baixa (<0,5s TTFT) | | Llama 3.1 70B Instruct | $0,99 | $0,99 | 128k | Razoável (degradação em geração livre) | Média (~1–3s TTFT) | | Fine-tune próprio (base: Nova/Llama) | Variável + custo de treino (estimativa: $500–5k/run) | Variável | Herdado do modelo base | Alta (se corpus pt-BR for usado) | Depende do modelo base | ## Por que Nenhum Modelo Único Resolve Tudo A tentação natural em qualquer projeto GenAI é escolher o melhor modelo disponível e usá-lo para tudo. Isso elimina complexidade de roteamento, simplifica prompts e reduz superfície de teste. O problema é que essa abordagem otimiza para o pior caso de custo. Considere o mix de tarefas deste cenário. Classificação de intenção — determinar se uma mensagem é uma reclamação, uma solicitação de informação ou um elogio — é uma tarefa que um modelo de 8B parâmetros com bom prompt resolve com F1 acima de 0,90. Usar Claude 3.5 Sonnet para isso é como usar um bisturi para cortar pão. A extração estruturada de campos em documentos padronizados (CPF, CNPJ, valores monetários) é igualmente resolvível com modelos menores e prompts bem construídos. Por outro lado, sumarização de documentos jurídicos longos em pt-BR com preservação de nuances técnicas, ou geração de rascunhos de comunicação que precisam soar naturais e formais ao mesmo tempo, são tarefas onde a diferença entre Sonnet e Haiku é perceptível para um revisor humano. Aqui, economizar no modelo é economizar na qualidade do produto. A janela de contexto adiciona outra dimensão. Nova Pro suporta 300k tokens — maior que o Sonnet — a um custo de input de $0,80/1M tokens contra $3,00/1M do Sonnet. Para sumarização de documentos muito longos onde o contexto completo precisa estar disponível, Nova Pro é uma alternativa séria que precisa ser avaliada com dados reais de pt-BR antes de ser descartada. O argumento para Llama no Bedrock é diferente: não é primariamente custo, é auditabilidade de pesos. Setores regulados (financeiro, saúde) às vezes precisam demonstrar que entendem o modelo que estão usando. Open-weight não significa que você vai re-treinar — significa que você pode inspecionar, que existe literatura acadêmica sobre o comportamento do modelo, e que a dependência de fornecedor é estruturalmente menor. Esse argumento tem peso real em comitês de compliance. ## Opções Avaliadas ### Opção A — Claude 3.5 Sonnet para tudo **Pros** - Qualidade máxima em raciocínio e geração em pt-BR - 200k tokens de contexto; zero chunking para maioria dos documentos - Arquitetura simples: um modelo, um endpoint, um conjunto de prompts - Menor risco de regressão por mudança de modelo **Cons** - Custo 40–85x maior que Nova Micro para tarefas simples - TTFT mais alto impacta UX em features de baixa latência - Dependência total de fornecedor único (Anthropic via AWS) **Verdict:** Viável para MVPs e volumes baixos; insustentável em escala com mix de tarefas simples ### Opção B — Amazon Nova Pro para tudo **Pros** - 300k tokens de contexto — maior da categoria - Custo input ~73% menor que Sonnet; output ~79% menor - AWS nativo: residência de dados, integração com IAM/KMS sem fricção - Roadmap alinhado com serviços AWS (Agents, Knowledge Bases) **Cons** - Qualidade de geração livre em pt-BR inferior ao Sonnet em tarefas complexas (avaliação empírica necessária) - Modelo mais recente: menos literatura de comportamento disponível - Ainda superdimensionado para classificação e extração simples **Verdict:** Forte candidato para tarefas de média-alta complexidade; requer benchmark em pt-BR antes de substituir Sonnet ### Opção C — Llama 3.1 70B para tarefas de menor custo **Pros** - Open-weight: auditável, sem lock-in de pesos - Preço flat input/output ($0,99/1M) — previsível para workloads output-heavy - Comunidade ampla; fine-tuning externo possível se necessário **Cons** - pt-BR com degradação perceptível em geração livre vs. modelos treinados com mais dados em português - 128k de contexto — chunking necessário para documentos muito longos - Custo maior que Nova Lite/Micro para tarefas simples **Verdict:** Melhor justificativa em contextos regulados que exigem auditabilidade de pesos; não é a escolha de custo-benefício padrão ### Opção D — Fine-tune próprio no Bedrock **Pros** - Comportamento especializado no domínio: terminologia, tom, formato de saída - Potencial de redução de tokens via prompts mais curtos (comportamento implícito) - Controle total sobre o corpus de treinamento **Cons** - Custo e tempo de treinamento + avaliação + versionamento (MLOps real) - Modelo base congela: melhorias de frontier não são herdadas automaticamente - Superfície de auditoria ampliada: dados de treino em S3, pipeline de customização, versionamento de pesos - Risco de overfitting em domínio estreito; generalização reduzida **Verdict:** Justificado apenas quando existe lacuna mensurável que nenhum modelo gerenciado resolve e volume suficiente para amortizar o custo de MLOps ## Decisão Arquitetural **Status:** proposed **Contexto** Feature GenAI enterprise com mix heterogêneo de tarefas (classificação simples a sumarização complexa), requisito obrigatório de pt-BR, restrições LGPD, e volume que torna o custo de inferência um item de orçamento relevante. Nenhum modelo único oferece o melhor custo-benefício em todos os tipos de tarefa. **Decisão** Adotar roteamento por tipo de tarefa com três rotas primárias no Amazon Bedrock: (1) Claude 3.5 Sonnet para tarefas de alta complexidade — sumarização de documentos longos, geração de rascunhos que requerem qualidade editorial, raciocínio multi-etapa; (2) Amazon Nova Pro ou Claude 3.5 Haiku para tarefas de média complexidade — Q&A sobre base de conhecimento, extração estruturada de documentos não-padronizados, geração de respostas conversacionais; (3) Amazon Nova Lite ou Nova Micro para tarefas de baixa complexidade — classificação de intenção, extração de campos padronizados, triagem e roteamento de mensagens. Fine-tune próprio é explicitamente descartado neste momento por ausência de lacuna mensurável que justifique o custo de MLOps. A decisão entre Nova Pro e Claude 3.5 Haiku na rota intermediária deve ser resolvida por benchmark empírico em pt-BR com dados reais do domínio antes do go-live. **Consequências** - POSITIVO: Redução estimada de 60–75% no custo de inferência vs. uso exclusivo de Sonnet para volume de 100M tokens/mês (estimativa de projeto baseada em mix típico de tarefas) - POSITIVO: Qualidade preservada nas tarefas onde impacta o produto; sem degradação perceptível para o usuário final - POSITIVO: Arquitetura de roteamento permite troca de modelo por rota sem refatoração global — evolução independente - NEGATIVO: Complexidade operacional aumentada: três conjuntos de prompts, três configurações de modelo, observabilidade por rota obrigatória - NEGATIVO: Lógica de classificação de tarefa é um novo componente que precisa ser testado, versionado e monitorado - NEUTRO: Benchmark empírico pt-BR na rota intermediária é pré-requisito para go-live — adiciona ~2 semanas ao cronograma ## Governança de Dados e LGPD no Contexto do Bedrock Uma questão que frequentemente paralisa decisões de GenAI em empresas brasileiras é a conformidade com a LGPD quando dados de clientes transitam por modelos de terceiros. O Amazon Bedrock resolve parte desse problema de forma estrutural, mas não toda. **O que o Bedrock garante por design:** A inferência ocorre dentro da infraestrutura AWS na região configurada. A AWS, Anthropic e Meta assinaram termos contratuais (disponíveis no Bedrock service terms) de que dados de clientes enviados para inferência não são usados para treinar ou melhorar modelos base. Isso é diferente de usar a API pública da Anthropic ou OpenAI diretamente, onde os termos padrão podem permitir uso de dados para melhoria do serviço. Para efeitos de LGPD, o Bedrock se qualifica como operador de dados com DPA (Data Processing Agreement) disponível via AWS. **O que ainda precisa ser gerenciado:** Mesmo com Bedrock, PII que entra no prompt precisa ser tratada. A recomendação é implementar uma camada de sanitização antes da chamada ao modelo — substituindo CPF, CNPJ, nomes e dados sensíveis por tokens ou pseudônimos quando a tarefa não requer os valores reais (ex: classificação de intenção não precisa do CPF real; sumarização de contrato pode pseudonimizar partes). Isso reduz o risco residual e simplifica a auditoria. **Fine-tune e o problema do dado de treino:** Se a decisão de fine-tune for revisitada no futuro, o dado de treino armazenado em S3 para o job de customização do Bedrock passa a ser um ativo de dados sensível com ciclo de vida próprio. Retenção, criptografia com KMS customer-managed key, controle de acesso com IAM least-privilege, e auditoria via CloudTrail são obrigações — não opcionais. O custo de conformidade do fine-tune vai além do custo de computação do treinamento. **Região e latência:** O Bedrock com suporte completo a Claude e Nova está disponível primariamente em us-east-1 e us-west-2. Para dados que não podem sair do Brasil, a arquitetura precisa de uma camada de sanitização em sa-east-1 antes de rotear para us-east-1 para inferência — ou aguardar disponibilidade de modelos em sa-east-1, que está em expansão. Essa restrição de região é um item de roadmap que precisa estar no radar do time de arquitetura. ## Arquitetura de Roteamento por Tipo de Tarefa no Amazon Bedrock Fluxo de inferência com roteamento inteligente: a requisição entra, é sanitizada, classificada por complexidade de tarefa, e roteada para o modelo adequado no Bedrock. Fallback automático garante qualidade mínima. ### 👤 Client Layer - Client App (Web/Mobile/API) (user) ### 🔒 API & Security Layer (sa-east-1) - API Gateway + WAF (edge) - PII Sanitizer (Lambda) Macie scan (security) - Cognito / IAM AuthZ (security) ### 🧠 Routing Layer (Lambda / ECS — us-east-1) - Task Router (Lambda) Classifica complexidade (compute) - Intent Classifier Nova Micro (bootstrap) (ai) - Fallback Logic Conf. threshold < 0.85 → escala (compute) ### 🤖 Amazon Bedrock — Model Routes (us-east-1) - Claude 3.5 Sonnet Rota Alta Complexidade 200k ctx | $3/$15 per 1M (ai) - Nova Pro / Haiku Rota Média Complexidade 300k ctx | $0.80/$3.20 (ai) - Nova Lite / Micro Rota Baixa Complexidade 300k ctx | $0.06/$0.24 (ai) ### 📊 Observability & Data (sa-east-1 / us-east-1) - CloudWatch Métricas por rota Custo por tarefa (data) - S3 + Athena Audit logs Prompt traces (storage) - Knowledge Base Bedrock KB (OpenSearch) (data) ### Fluxos - client -> apigw: HTTPS request - apigw -> authz: AuthN/AuthZ - apigw -> sanitizer: Sanitiza PII - sanitizer -> router: Payload limpo - router -> classifier: Classifica tarefa - classifier -> fallback: Score de confiança - fallback -> sonnet: Alta complexidade - fallback -> haiku_nova: Média complexidade - fallback -> nova_lite: Baixa complexidade - haiku_nova -> kb: RAG lookup - sonnet -> kb: RAG lookup - router -> cloudwatch: Métricas de rota - sonnet -> s3_logs: Audit trace - haiku_nova -> s3_logs - nova_lite -> s3_logs ## Avaliação pelo AWS Well-Architected Framework - **security**: PII sanitizada antes de atingir o modelo; IAM least-privilege por rota; KMS CMK para logs e dados em S3; VPC endpoints para Bedrock eliminam tráfego pela internet pública; CloudTrail habilitado para todas as chamadas de API Bedrock. - **reliability**: Fallback por threshold de confiança previne degradação silenciosa; retry com jitter em chamadas Bedrock; circuit breaker recomendado para rotas de alta frequência; Knowledge Base com OpenSearch em múltiplas AZs. - **sustainability**: Uso de modelos menores para tarefas simples reduz consumo computacional; evitar over-provisioning de contexto (não enviar 200k tokens quando 10k resolvem) é tanto otimização de custo quanto de energia. > **Minha Perspectiva Sênior:** O erro mais comum que vejo em projetos GenAI enterprise não é escolher o modelo errado — é não ter uma estratégia de roteamento desde o início. Times escolhem o melhor modelo disponível para o MVP (geralmente Sonnet ou GPT-4), o produto funciona bem, e quando o volume escala, o custo de inferência vira um problema de CFO, não de engenharia. Aí a pressão para trocar de modelo é enorme, os prompts foram escritos para o modelo caro, e a migração é dolorosa. Minha recomendação prática: comece com roteamento desde a primeira semana, mesmo que inicialmente todas as rotas apontem para o mesmo modelo. A abstração de roteamento não custa nada em complexidade no início e vale muito quando você precisa trocar. É o mesmo princípio de escrever código contra uma interface, não contra uma implementação. Sobre o debate Nova vs. Claude Haiku na rota intermediária: eu não decidiria no papel. Bedrock tem uma API de avaliação de modelos (Model Evaluation) que permite rodar um conjunto de prompts do seu domínio e comparar outputs com critérios definidos. Para pt-BR especificamente, eu montaria um golden dataset com 50–100 exemplos representativos do domínio, rodaria ambos os modelos, e avaliaria com uma combinação de métricas automáticas (ROUGE para sumarização, exact match para extração) e avaliação humana para geração livre. Essa decisão deve ser empírica, não baseada em benchmarks gerais em inglês. Sobre fine-tune: a pergunta certa não é 'fine-tune vai melhorar a qualidade?' — a resposta quase sempre é sim. A pergunta certa é 'o ganho de qualidade justifica o custo de MLOps recorrente?' Na maioria dos casos que vi, a resposta é não — especialmente quando o modelo base evolui rapidamente. Fine-tune faz sentido quando você tem um vocabulário muito específico de domínio, um formato de saída rígido que prompt engineering não consegue garantir, ou quando a redução de tokens via comportamento implícito tem impacto financeiro material. Fora desses casos, é complexidade sem retorno proporcional. Por fim: monitore custo por tipo de tarefa desde o dia um. Isso não é só otimização financeira — é o sinal mais honesto de que seu roteamento está funcionando. ## Veredicto A decisão de modelo no Amazon Bedrock não é uma escolha binária — é uma estratégia de portfólio. Para uma feature GenAI enterprise com mix heterogêneo de tarefas e requisito de pt-BR, a arquitetura de roteamento por tipo de tarefa é a única abordagem que equilibra qualidade, custo e governança de forma sustentável em escala. Claude 3.5 Sonnet permanece a referência de qualidade para tarefas complexas em português e deve ser a escolha padrão quando a qualidade da geração é crítica para o produto. Amazon Nova Pro e Claude 3.5 Haiku competem diretamente na faixa intermediária — a decisão entre eles deve ser empírica, com benchmark em dados reais do domínio em pt-BR. Amazon Nova Lite e Micro são as escolhas óbvias para tarefas de classificação e extração simples, onde o ganho de qualidade dos modelos maiores não é perceptível pelo usuário final. Fine-tune próprio é uma decisão de MLOps, não de qualidade de modelo — e deve ser tratada como tal. O custo recorrente de manutenção de um modelo customizado raramente se justifica quando os modelos gerenciados evoluem na velocidade atual. Revisitar essa decisão quando existir uma lacuna mensurável e volume suficiente para amortização. A complexidade operacional do roteamento é real mas gerenciável: abstração de roteamento como interface, prompts versionados, observabilidade por rota, e um golden dataset de avaliação pt-BR são os quatro artefatos que transformam essa arquitetura de um experimento em um sistema de produção confiável. ## Referências - [Amazon Bedrock — Supported Foundation Models](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html) - [Amazon Bedrock — Pricing](https://aws.amazon.com/bedrock/pricing/) - [Amazon Nova Models — AWS Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/amazon-nova.html) - [Anthropic Claude on Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-anthropic-claude-messages.html) - [Amazon Bedrock — Model Evaluation](https://docs.aws.amazon.com/bedrock/latest/userguide/model-evaluation.html) - [Amazon Bedrock — Custom Model Fine-tuning](https://docs.aws.amazon.com/bedrock/latest/userguide/custom-models.html) - [Amazon Bedrock — Data Protection and Privacy](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html) - [Meta Llama 3 on Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters-meta.html) ## Fontes do caso - [Amazon Bedrock — Supported foundation models](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html) - [Amazon Bedrock — Pricing](https://aws.amazon.com/bedrock/pricing/)