A AWS anunciou a disponibilidade geral do GPT‑5.4, da OpenAI, no Amazon Bedrock dentro da região AWS GovCloud (US-West). A novidade abre caminho para que clientes governamentais e de setores altamente regulados possam utilizar o modelo de fronteira mais avançado da OpenAI diretamente na infraestrutura do Bedrock — com todas as garantias de segurança e conformidade que o ambiente GovCloud oferece.
Para quem é essa novidade
O foco principal desta disponibilidade é o público de governo e indústrias reguladas. O AWS GovCloud (US) é uma região isolada da AWS projetada justamente para cargas de trabalho que exigem conformidade com normas governamentais americanas rigorosas. Ao trazer o GPT‑5.4 para esse ambiente, a AWS permite que organizações desse perfil utilizem IA de ponta sem abrir mão dos controles de compliance exigidos em seus segmentos.
Capacidades do GPT‑5.4 no Bedrock
O GPT‑5.4 chega ao Bedrock com um conjunto robusto de funcionalidades voltadas para uso profissional:
Uso nativo de computador (computer-use): o modelo é capaz de interagir diretamente com interfaces de computador, ampliando as possibilidades de automação.
Raciocínio profundo: suporte a tarefas complexas de programação, análise de documentos e fluxos de trabalho com múltiplas etapas em sequência (tarefas agênticas).
Motor de inferência de alta performance: o modelo roda sobre a infraestrutura de inferência do Bedrock, com filas isoladas e estado durável para cargas de trabalho tolerantes a falhas.
Privacidade dos dados: os dados permanecem dentro da partição da região e nunca são utilizados para treinar modelos.
Onde consultar a disponibilidade por região
Para verificar em quais regiões da AWS o GPT‑5.4 está disponível, a AWS indica consultar a página de regiões da AWS.
Saiba mais e comece a usar
Para quem quer se aprofundar, a AWS disponibilizou materiais de referência:
A AWS anunciou que o AWS Step Functions agora suporta a adição de etapas de raciocínio agêntico em workflows, por meio de uma integração otimizada com o harness gerenciado do Amazon Bedrock AgentCore — recurso atualmente disponível em prévia.
Contexto: o que são essas ferramentas
O AWS Step Functions é um serviço de orquestração visual que conecta serviços da AWS em fluxos de trabalho automatizados, com tratamento de erros embutido, execução paralela e suporte a etapas de aprovação humana. Já o harness do AgentCore funciona como um ambiente gerenciado onde você declara um agente via configuração — especificando o modelo, as ferramentas e o comportamento desejado — e o AgentCore cuida de executar o loop do agente do início ao fim.
O que essa integração permite fazer
Com essa novidade, equipes de desenvolvimento podem incorporar tarefas de raciocínio automatizado diretamente nos seus workflows. Alguns exemplos práticos mencionados pela AWS incluem:
Classificação automática de documentos
Extração de informações de formulários não estruturados
Além disso, é possível executar múltiplos agentes em paralelo ou em sequência em diferentes pontos de decisão de um mesmo workflow, e ainda inserir uma etapa de aprovação humana antes de ações críticas.
Observabilidade e rastreamento
O histórico de execução do workflow registra entrada, saída, consumo de tokens e duração de cada agente, com links para os detalhes de cada turno no Amazon CloudWatch. Isso permite rastrear e auditar cada decisão tomada pelo agente ao longo do fluxo.
Flexibilidade na configuração
É possível reutilizar um harness já existente ou criar um novo diretamente pelo Workflow Studio, o construtor visual do Step Functions. Com substituições por invocação — como modelo, prompt de sistema e ferramentas —, o agente pode ser adaptado ao contexto de cada workflow sem duplicar configurações. O contexto do agente também pode ser persistido entre invocações usando um ID de sessão, que funciona dentro ou entre execuções de workflow.
Disponibilidade e preços
A integração está disponível nas regiões da AWS onde a prévia do harness do AgentCore já está ativa: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Frankfurt) e Ásia-Pacífico (Sydney). A cobrança segue o modelo padrão do Step Functions para execução de workflows, sem taxas adicionais pela integração em si. Os custos de inferência de modelos e recursos do AgentCore seguem a precificação padrão do Amazon Bedrock e do AgentCore.
Continuidade nas análises de dados com o SageMaker Data Agent
A AWS anunciou uma atualização relevante para equipes de dados: o Amazon SageMaker Data Agent, disponível no SageMaker Unified Studio, passa a suportar histórico de conversas. A novidade permite que analistas e cientistas de dados mantenham o contexto de suas sessões analíticas entre diferentes momentos de trabalho, sem precisar reconstruir o raciocínio do zero a cada vez.
O que muda na prática
Antes dessa atualização, cada sessão com o agente começava do zero. Agora, profissionais podem retomar análises de múltiplas etapas exatamente de onde pararam, reutilizar código gerado pelo agente em sessões anteriores e revisitar interações de troubleshooting feitas em execuções passadas de notebooks ou no Query Editor.
O acesso ao histórico é simples: um ícone de relógio no cabeçalho do painel de chat abre uma lista rolável com todas as conversas anteriores. Cada conversa recebe automaticamente um título e um registro de data e hora, facilitando a identificação rápida da sessão desejada.
Por que isso importa para times de dados
Em ambientes onde analistas e cientistas de dados trabalham em múltiplos projetos de forma simultânea, perder o fio da meada entre sessões é um problema real. Com o histórico de conversas, o contexto fica preservado — o que significa menos retrabalho, mais agilidade e foco no que realmente importa: extrair insights dos dados.
A funcionalidade é especialmente útil em análises complexas, que naturalmente se desenvolvem ao longo de várias sessões de trabalho, e em fluxos de troubleshooting que exigem revisitar decisões tomadas anteriormente.
A AWS anunciou uma atualização relevante para quem trabalha com ciência de dados e machine learning na plataforma: o Amazon SageMaker Unified Studio agora permite agendar, parametrizar e orquestrar execuções de notebooks diretamente pela interface do notebook, sem a necessidade de gerenciar infraestrutura externa de orquestração.
Essa mudança é especialmente importante para equipes que ainda dependem de processos manuais ou de ferramentas separadas para automatizar tarefas recorrentes. Com esse recurso, fica mais fácil levar um notebook da fase de experimentação para a produção.
Principais capacidades do agendamento de notebooks
Execuções em segundo plano e agendamentos recorrentes
Agora é possível disparar execuções sob demanda em segundo plano, em um ambiente de computação dedicado, sem interromper a sessão interativa em andamento. Também é possível criar execuções agendadas ou recorrentes — ideal para tarefas como relatórios diários, verificações de qualidade de dados e retreinamento de modelos.
Parametrização de notebooks
Um dos destaques da atualização é a parametrização de notebooks. Com ela, é possível reutilizar um único notebook para diferentes entradas. O exemplo citado pela própria AWS é a geração de relatórios de desempenho de envio para múltiplas transportadoras, definindo parâmetros e substituindo seus valores a cada execução agendada ou sob demanda.
Orquestração de múltiplos notebooks
Para fluxos mais complexos, o SageMaker Unified Studio oferece o Notebook Operator, disponível na ferramenta Workflows. Com ele, é possível encadear notebooks de forma que a saída de uma execução sirva como entrada para a próxima — criando pipelines completos sem sair do ambiente.
Resolução de problemas com IA
Quando uma execução agendada ou em segundo plano falha, o SageMaker Data Agent entra em cena. Esse assistente com IA ajuda a identificar a causa raiz do problema e sugere correções diretamente no notebook, reduzindo o tempo de resolução de incidentes.
Além disso, o Data Agent também pode ser usado para criar agendamentos e iniciar execuções de notebooks via linguagem natural, sem precisar navegar pelos menus da interface.
Como começar a usar
Para experimentar o recurso, basta abrir um notebook em um projeto do SageMaker Unified Studio, clicar no menu ao lado do botão Run all e selecionar Run in background. Para criar um agendamento, é possível usar o ícone de agendamento no cabeçalho do notebook ou simplesmente pedir ao Data Agent para configurar um.
A AWS anunciou o suporte ao NEXUS — modelo de fundação (FM, do inglês Foundation Model) desenvolvido pela Fundamental — no Amazon SageMaker AI. A novidade está disponível pelo Amazon SageMaker JumpStart e representa uma abordagem diferente para um problema antigo: extrair predições confiáveis de dados estruturados corporativos.
Enquanto os Modelos de Linguagem de Grande Escala (LLMs, do inglês Large Language Models) foram projetados para texto e as abordagens tradicionais de Aprendizado de Máquina (ML, do inglês Machine Learning) exigem meses de engenharia de features e treinamento, o NEXUS foi pré-treinado em bilhões de tarefas reais de predição sobre conjuntos de dados estruturados. Isso significa que ele chega ao ambiente do cliente já sabendo como encontrar sinais relevantes nos dados — sem a necessidade de pipelines manuais complexos.
Como um Grande Modelo Tabular (LTM, do inglês Large Tabular Model), o NEXUS traz inovações técnicas importantes:
Arquitetura determinística: ao contrário de LLMs probabilísticos, que podem gerar respostas diferentes para a mesma consulta, o NEXUS produz resultados consistentes e reproduzíveis a cada predição.
Compreensão tabular nativa: treinado em bilhões de tabelas, o modelo processa nativamente números, categorias, datas e texto não estruturado — sem engenharia de features manual.
Raciocínio não sequencial: diferentemente de modelos que predizem dados sequenciais (como a próxima palavra), o NEXUS analisa relações multidimensionais em tabelas corporativas. Por exemplo, ao prever churn de clientes, ele considera simultaneamente frequência de transações, tickets de suporte e indicadores econômicos.
Por que as abordagens atuais ficam aquém
O dado mais valioso das empresas vive em tabelas: planilhas, sistemas de Planejamento de Recursos Empresariais (ERP, do inglês Enterprise Resource Planning), sistemas de Gestão de Relacionamento com o Cliente (CRM, do inglês Customer Relationship Management) e bancos de dados relacionais. Mas as ferramentas disponíveis hoje apresentam limitações sérias:
O ML tradicional exige de 3 a 6 meses para que times de cientistas de dados construam, treinem e coloquem em produção um modelo para um único caso de uso.
Os LLMs são não-determinísticos e perdem contexto numérico durante a tokenização, gerando resultados imprecisos em dados estruturados e exigindo guardrails complexos.
O NEXUS foi arquitetado especificamente para dados tabulares e oferece vantagens como:
Invariância de permutação: reconhece que mudar a ordem das colunas não muda o significado dos dados — algo que os transformers tradicionais não fazem nativamente.
Capacidade para bilhões de linhas: processa conjuntos de dados massivos sem truncamento ou amostragem.
Raciocínio entre esquemas: conecta dados relacionados entre tabelas distintas de forma automática.
Limpeza autônoma de dados: realiza predições mesmo quando há entradas incompletas ou ausentes.
Como o NEXUS funciona no Amazon SageMaker AI
O modelo roda em uma instância de GPU dedicada, de locatário único e isolada em rede, dentro do ambiente gerenciado do SageMaker AI. O fluxo de trabalho completo envolve as seguintes etapas:
Assinatura e implantação: o usuário assina o pacote do modelo NEXUS no AWS Marketplace e o implanta como um endpoint de inferência gerenciado pelo SageMaker AI em uma instância ml.p5en.48xlarge (8× GPUs NVIDIA H200).
Instalação do SDK: instala-se o SDK Python da Fundamental e conecta-o ao endpoint do SageMaker. O SDK oferece uma API compatível com scikit-learn, com os estimadores NEXUSClassifier e NEXUSRegressor.
Upload dos dados para o Amazon S3: o SDK serializa os dados tabulares e faz o upload para um bucket do Amazon Simple Storage Service (Amazon S3) na conta do usuário.
Treinamento do modelo: basta chamar clf.fit(X_train, y_train). O NEXUS cuida automaticamente da limpeza de dados e da engenharia de features, sem necessidade de pipeline manual.
Geração de predições: use clf.predict(X_test) para predições determinísticas ou clf.predict_proba(X_test) para estimativas de probabilidade. Os resultados são armazenados de volta no bucket do Amazon S3.
Todo o fluxo mantém os dados dentro do ambiente AWS do cliente. O endpoint é isolado em rede e de locatário único, tornando o NEXUS adequado para cargas de trabalho corporativas com dados sensíveis.
Casos de uso por setor
Dados tabulares são a espinha dorsal da tomada de decisão empresarial — de registros financeiros a prontuários médicos, passando por logs de cadeia de suprimentos. A seguir, alguns exemplos práticos de aplicação do NEXUS destacados pela AWS:
Serviços financeiros
Detecção de fraudes: análise de padrões de transações em milhões de contas.
Modelagem de risco de crédito: processamento de portfólios de empréstimos com extração automatizada de features.
Conformidade regulatória: extração de dados estruturados a partir de documentos regulatórios não estruturados.
Saúde
Seleção para ensaios clínicos: identificação de pacientes elegíveis em sistemas de Registros Eletrônicos de Saúde (EHR, do inglês Electronic Health Records).
Descoberta de medicamentos: análise de dados de ensaios biológicos para triagem de compostos.
Estratificação de risco de pacientes: predição de riscos de readmissão usando dados de séries temporais de Unidades de Terapia Intensiva (UTI).
Manufatura e cadeia de suprimentos
Manutenção preditiva: previsão de falhas de equipamentos a partir de dados de sensores.
Previsão de demanda: antecipação de necessidades de estoque em redes globais de distribuição.
Análise de risco de fornecedores: avaliação de confiabilidade de fornecedores com base em histórico de compras.
Varejo e e-commerce
Predição de churn: identificação de clientes em risco com base em histórico de compras e comportamento de navegação.
Precificação dinâmica: otimização de preços com base em dados de concorrentes e níveis de estoque.
Análise de abandono de carrinho: compreensão dos motivos pelos quais clientes abandonam itens no carrinho.
Por que usar o NEXUS no Amazon SageMaker AI
Implantar um modelo é apenas metade da equação. A infraestrutura onde ele roda determina a velocidade de ir da experimentação à produção. O SageMaker AI oferece um ambiente gerenciado, seguro e escalável para rodar o NEXUS em escala corporativa, com benefícios como:
Aceleração do tempo de valor: contêineres e scripts pré-configurados reduzem o tempo de implantação.
Eficiência de custos: a infraestrutura gerenciada do SageMaker AI reduz o overhead operacional.
Escalabilidade: escala automaticamente para conjuntos de dados em escala de petabytes.
Conformidade pronta: atende aos requisitos de GDPR, HIPAA e SOC 2 por padrão.
Suporte multiplex: suporta múltiplas operações de fit e predict em um único endpoint do SageMaker AI, eliminando a necessidade de recursos dedicados para cada caso de uso.
A Fundamental firmou uma parceria estratégica com a AWS para acelerar a adoção corporativa do NEXUS, com integração nativa via AWS Marketplace, infraestrutura segura e suporte de Arquitetos de Soluções AWS dedicados.
Como começar
Para experimentar o NEXUS, basta acessar o Amazon SageMaker JumpStart e buscar por “Fundamental NEXUS”. Estão disponíveis o modelo base (pré-treinado em mais de 10 bilhões de linhas tabulares) e variantes específicas para setores como finanças, saúde e manufatura.
O Amazon Bedrock já é a base de IA generativa de mais de 100.000 organizações no mundo. À medida que essas organizações expandem seus workloads — adotando múltiplos modelos fundacionais em produção — o gerenciamento operacional proativo se torna um fator crítico para manter a velocidade de inovação.
O problema é conhecido: equipes de Engenharia de Confiabilidade de Sites de IA (AI SRE, na sigla em inglês) frequentemente ficam sabendo de problemas operacionais apenas quando usuários de negócio reportam impacto. Isso força uma postura reativa, com pouco tempo para investigar antes que o problema escale. Além disso, cada novo modelo adotado exige sua própria configuração de monitoramento, e cada aumento de cota aprovado demanda recálculo manual dos limites de alarme no Amazon CloudWatch.
Para endereçar esses desafios, a AWS publicou uma solução chamada Amazon Bedrock Ops Alert: um sistema de monitoramento automatizado em três camadas que detecta problemas proativamente, ajusta limites dinamicamente, classifica alarmes por categoria e abre chamados de suporte com contexto rico — tudo sem intervenção manual.
Otimização antes de aumentar cotas
Antes de entrar na solução de monitoramento em si, o artigo original destaca que muitas necessidades de capacidade podem ser resolvidas com otimização de workload, sem precisar aumentar cotas.
O cache de prompts (prompt caching) é outro recurso que reduz latência e custos de tokens de entrada. Ao armazenar partes do contexto em cache, o modelo evita reprocessar entradas repetidas — o que pode reduzir custos em até 90% e latência em até 85%, diminuindo diretamente o consumo de tokens por minuto. O post Como usar efetivamente o cache de prompts no Amazon Bedrock detalha como estruturar prompts para maximizar os acertos de cache.
O fluxo de funcionamento é o seguinte: durante a implantação, uma função Lambda (Calculadora de Cotas) consulta a API de Cotas de Serviço para obter os valores atuais de Requisições por Minuto (RPM) e Tokens por Minuto (TPM), calculando os limites de alarme com base em percentuais configuráveis. Os limites calculados são armazenados no AWS Systems Manager Parameter Store, e os contatos de e-mail da equipe de AI SRE ficam no AWS Secrets Manager.
O Amazon Bedrock publica métricas de tempo de execução — invocações, contagens de tokens, erros, throttles e latência — no CloudWatch. A partir daí, as três camadas de monitoramento atuam de forma independente.
As três camadas de monitoramento
Camada 1: Detecção de erros críticos
A primeira camada monitora métricas de erro que indicam problemas operacionais imediatos:
Alarme ClientErrors: monitora a métrica InvocationClientErrors para identificar requisições rejeitadas por problemas do lado do cliente, como cotas excedidas, erros de validação ou parâmetros inválidos.
Alarme ServerErrors: monitora a métrica InvocationServerErrors para identificar erros do lado do serviço que podem exigir investigação.
Alarme Throttles: monitora a métrica InvocationThrottles para identificar requisições explicitamente limitadas quando o limite de taxa é atingido.
Configurar o limite de erro em zero com um único período de avaliação dispara alertas imediatos ao primeiro erro; valores mais altos oferecem tolerância a problemas transitórios.
Camada 2: Monitoramento de taxa de uso
A segunda camada monitora métricas de uso em relação a limites calculados dinamicamente, fornecendo alertas proativos antes de atingir os limites de cota:
Alarme HighInvocationRate: monitora a métrica Invocations e dispara quando a taxa de requisições da API ultrapassa o percentual configurado do limite de RPM.
Alarme HighTPMQuotaUsage: monitora a métrica EstimatedTPMQuotaUsage e dispara quando o consumo estimado de cota de TPM ultrapassa o percentual configurado (inclui tokens de escrita em cache e multiplicadores de consumo de saída).
Alarme HighLatency: monitora a métrica InvocationLatency e dispara quando o tempo de resposta ultrapassa o limite configurado.
Os limites são calculados automaticamente a partir da API de Cotas de Serviço. Por exemplo: com um percentual de 80% e uma cota de 100 RPM, o alarme de RPM dispara em 80 requisições por minuto. Para TPM, o mesmo percentual de 80% sobre uma cota de 1.000.000 TPM resulta em um limite efetivo de 800.000 tokens.
Camada 3: Detecção de anomalias
A terceira camada usa a detecção de anomalias do CloudWatch (machine learning) para identificar padrões incomuns:
InvocationAnomaly: identifica mudanças incomuns no volume de requisições.
InputTokenAnomaly: identifica uso anormal de tokens de entrada.
OutputTokenAnomaly: identifica uso anormal de tokens de saída.
LatencyAnomaly: identifica tendências de degradação de performance.
O machine learning do CloudWatch analisa dados históricos para estabelecer baselines de comportamento normal e alerta quando as métricas atuais excedem o limite superior esperado. A solução monitora apenas desvios para cima — quedas de uso são sinais positivos que não exigem intervenção. Essa abordagem detecta problemas que limites estáticos não capturariam, como aumentos graduais de consumo de cota ou picos inesperados de uso.
Gerenciamento automatizado de limites
Um dos pontos mais práticos da solução é a recalculação automática de limites de alarme. Uma regra do Amazon EventBridge dispara periodicamente uma função Lambda (Atualizadora de Alarmes) que consulta a API de Cotas de Serviço, recalcula os limites e atualiza os alarmes do CloudWatch. Os limites calculados são armazenados no Parameter Store, recurso do AWS Systems Manager, com timestamps para rastreamento de histórico.
Isso elimina o trabalho manual de recalcular e atualizar configurações de alarme toda vez que um aumento de cota é aprovado. O sistema se autocorrige.
Abertura automática de chamados de suporte
Quando um alarme composto é disparado, a solução pode criar automaticamente um chamado no AWS Support — recurso que exige plano Business ou Enterprise. O processo funciona assim:
A função Lambda consulta o estado do alarme composto e identifica quais alarmes filhos dispararam.
Ela lê os limites armazenados no Parameter Store e compara o uso de pico dos últimos 14 dias com esses limites para determinar o cenário do chamado.
O alarme é classificado como relacionado a cota ou não relacionado a cota.
A função verifica se já existe um chamado aberto da mesma categoria (janela configurável, padrão de 60 dias). Se existir, acrescenta uma comunicação ao chamado existente; caso contrário, cria um novo.
A classificação dos alarmes determina o tipo de chamado:
Alarmes específicos de RPM (HighInvocationRate, InvocationAnomaly): solicitam aumento de cota de RPM apenas.
Alarmes específicos de TPM (HighTPMQuotaUsage, InputTokenAnomaly, OutputTokenAnomaly): solicitam aumento de cota de TPM apenas.
Alarmes de cota indeterminada (Throttles, ClientErrors): solicitam aumento de ambas as cotas.
Alarmes não relacionados a cota (ServerErrors, HighLatency, LatencyAnomaly): geram um chamado de “Solicitação de Investigação” sem detalhes de aumento de cota.
Árvore de decisão para validação de uso
Antes de criar um chamado relacionado a cota, a solução compara o uso de pico dos últimos 14 dias com os limites armazenados para determinar a resposta adequada:
Modelo novo (pico de RPM = 0 e pico de TPM = 0): o chamado inclui detalhes de aumento de cota, observando que o modelo foi implantado recentemente com histórico de uso limitado.
Uso alto (pico atinge ou supera o limite): o chamado inclui dados de uso confirmando tendências sustentadas de consumo. Para severidade crítica, inclui nota indicando que o uso está se aproximando dos limites de taxa.
Uso baixo (pico abaixo do limite): a solução envia notificação por e-mail para a equipe investigar a causa raiz primeiro. O chamado inclui detalhes de aumento de cota apenas como referência, caso a investigação confirme a necessidade.
Essa validação garante que os chamados de aumento de cota reflitam padrões reais de uso, enquanto ainda fornecem contexto para o engenheiro de suporte.
Notificações e prevenção de chamados duplicados
Após o processamento do chamado, a solução envia notificações por e-mail formatadas para as partes interessadas por meio de um segundo tópico SNS. Se um chamado foi criado, o e-mail inclui o ID do caso e um link direto para o console do AWS Support. O conteúdo do e-mail é adaptado para a perspectiva da equipe de AI SRE, enquanto o conteúdo do chamado é adaptado para o engenheiro de suporte.
A detecção de duplicatas com consciência de categoria impede a criação de chamados redundantes: um chamado de solicitação de cota para um tipo de alarme não bloqueia um chamado de investigação para um tipo diferente, e vice-versa. Os parâmetros dos chamados ficam no Parameter Store e podem ser atualizados sem reimplantar a stack do CloudFormation.
Resultados esperados
Segundo a AWS, o Amazon Bedrock Ops Alert entrega os seguintes benefícios:
Maior eficiência operacional: a equipe de AI SRE migra do monitoramento manual para trabalhos de maior valor.
Classificação inteligente de alarmes: alarmes não relacionados a cota são roteados para chamados de investigação, acelerando a resolução de causa raiz.
Chamados validados por uso: a solução confirma que as solicitações de aumento de cota refletem padrões reais de uso.
Redução do tempo médio de resolução (MTTR): a criação automática de chamados reduz o esforço manual de horas para minutos.
Gestão proativa de cotas: solicitações de aumento são iniciadas antes de atingir os limites em produção.
Sem manutenção manual de limites: os alarmes permanecem precisos conforme as cotas aprovadas mudam, sem intervenção de engenheiros.
Base escalável: modelos adicionais do Bedrock podem ser monitorados implantando instâncias adicionais da stack.
O monitoramento de IA generativa é diferente do monitoramento de infraestrutura tradicional. À medida que equipes não técnicas passam a usar aplicações de IA generativa construídas sobre modelos hospedados no Amazon Bedrock, as organizações precisam repensar sua estratégia de monitoramento operacional para acompanhar essa nova realidade.
O Amazon Bedrock Ops Alert representa uma abordagem que combina detecção de erros críticos, monitoramento de taxa de uso e reconhecimento de padrões anômalos em uma única solução nativa AWS. A classificação inteligente de alarmes, a validação de uso antes de abrir chamados e a prevenção de duplicatas mantêm as investigações focadas. Juntas, essas capacidades movem as operações de um modelo reativo para um modelo proativo, reduzindo o MTTR e liberando as equipes de AI SRE para focar no que realmente importa: construir aplicações de IA generativa.
O problema com agentes que escolhem a ferramenta errada
Agentes de IA têm a capacidade de executar tarefas complexas de forma autônoma, mas tudo depende de uma condição básica: chamar a ferramenta certa no momento certo. Quando um agente seleciona a ferramenta errada, formata parâmetros incorretamente ou quebra uma cadeia de fluxo de trabalho, o impacto é imediato — tempos de execução aumentam, taxas de erro sobem e a experiência do usuário se deteriora.
À medida que mais organizações levam aplicações agênticas do piloto para a produção, garantir que o agente selecione a ferramenta adequada para cada requisição se torna essencial para uma automação confiável. A AWS publicou um guia técnico mostrando como usar duas técnicas de ajuste fino em conjunto — Ajuste Fino Supervisionado (SFT) e Otimização Direta de Preferências (DPO) — para melhorar significativamente essa precisão em um modelo de linguagem pequeno (SLM).
As duas metodologias de ajuste fino
Ajuste Fino Supervisionado (SFT)
O SFT envolve a curadoria de um conjunto de dados de alta qualidade que se alinha estreitamente com a função pretendida do modelo. Ele fornece exemplos explícitos de como o modelo deve executar determinadas tarefas ou interagir com ferramentas específicas. Esse método é particularmente eficaz para ensinar o modelo a reconhecer as nuances da linguagem, comandos e restrições específicos de cada ferramenta.
Otimização Direta de Preferências (DPO)
O DPO refina as interações incorporando feedback humano ou objetivos predefinidos diretamente no ciclo de treinamento. Ele alinha a saída do modelo com os resultados desejados ao enfatizar preferências por certos tipos de resposta ou comportamento. Os dados de treinamento no DPO seguem um formato de “prefira isso, não aquilo”, o que otimiza os mesmos objetivos do aprendizado por reforço, mas sem funções de recompensa ou modelos de recompensa. Isso reduz os requisitos de recursos e o tempo de treinamento, mantendo a qualidade.
A biblioteca TRL da HuggingFace para DPO, por exemplo, aceita amostras de treinamento no seguinte formato:
{
"prompt": ["<array of input samples>"],
"chosen": "<complete preferred response (j)>", # rated better than k
"rejected": "<complete non-preferred response (k)>" # rated worse than j
}
Esse formato é baseado na pesquisa publicada em arXiv:2305.18290 [cs.LG]. Juntos, SFT e DPO formam um framework robusto para ajustar modelos de linguagem para interagir com uma ampla variedade de ferramentas digitais.
Para entender os custos associados ao Amazon SageMaker Studio e aos jobs de treinamento do SageMaker AI, consulte a página de preços do SageMaker AI.
Visão geral da solução
O exemplo demonstra como ajustar o modelo Qwen3 1.7B usando jobs de treinamento do Amazon SageMaker AI, um serviço totalmente gerenciado que suporta configurações distribuídas com múltiplas GPUs e múltiplos nós. Com esses jobs, é possível provisionar clusters de alto desempenho sob demanda, treinar modelos com bilhões de parâmetros mais rapidamente e desligar os recursos automaticamente ao final do job. As métricas de infraestrutura e do loop de treinamento são enviadas para o MLflow no SageMaker AI para análise posterior.
Pré-requisitos
Para executar o ajuste fino de modelos de chamada de função no SageMaker AI, são necessários:
A escolha e criação do dataset correto é um passo fundamental no ajuste fino de modelos de fundação (FMs). O exemplo usa o dataset When2Call, publicado pela NVIDIA — um benchmark projetado para avaliar a tomada de decisão de chamada de ferramentas em FMs. Ele cobre cenários como: quando gerar uma chamada de ferramenta, quando fazer perguntas de acompanhamento, quando indicar que a pergunta não pode ser respondida com as ferramentas disponíveis, e o que fazer quando uma chamada de ferramenta parece necessária mas não pode ser feita. Os scripts de geração de dados sintéticos estão no repositório GitHub da NVIDIA.
O dataset é composto por três partes:
Dataset para SFT: contém 15.000 amostras.
Dataset para alinhamento de preferências (DPO): contém 9.000 amostras com colunas chosen_response e rejected_response.
Dataset de teste: inclui avaliação por Questões de Múltipla Escolha (MCQ) com 3.652 amostras e avaliação por LLM-como-juiz com 300 amostras.
É necessário pré-processar o dataset para corresponder aos formatos esperados pelo SFTTrainer e pelo DPOTrainer da biblioteca TRL. Isso inclui construir um prompt de sistema com a lista de ferramentas disponíveis e adicioná-lo às listas de mensagens do dataset original.
def generate_and_tokenize_prompt(data_point):
"""
Generates a tool using prompt based on patient information.
Args:
data_point (dict): Dictionary containing target and meaning_representation keys
Returns:
dict: Dictionary containing the formatted prompt
"""
full_prompt = f"""
You are a helpful assistant with access to the following tools or function calls.
Your task is to produce a sequence of tools or function calls necessary to generate response to the user utterance.
Use the following tools or function calls as required:
{data_point["tools"]}
"""
return {"system_prompt": full_prompt.strip()}
Para o DPO, o DPOTrainer do TRL exige colunas chamadas chosen e rejected, então é necessário renomear as colunas chosen_response e rejected_response do dataset original. Após o pré-processamento, os datasets de SFT e DPO são salvos no Amazon Simple Storage Service (Amazon S3) para ficarem disponíveis durante o treinamento.
Ajuste Fino Supervisionado (SFT) no modelo base
O repositório contém a receita de treinamento no diretório scripts, onde é possível modificar o modelo base e os parâmetros de treinamento para SFT. O exemplo usa uma receita de ajuste fino baseada em Spectrum, mas outras técnicas de Ajuste Fino Eficiente de Parâmetros (PEFT), como LoRA ou QLoRA, também podem ser utilizadas. A receita define, entre outros parâmetros:
Criando o job de treinamento com o ModelTrainer do SageMaker AI
As APIs ModelTrainer do SDK Python do SageMaker AI executam jobs de treinamento em infraestrutura totalmente gerenciada, cuidando da configuração do ambiente, do escalonamento e do gerenciamento de artefatos. É possível especificar scripts de treinamento, dados de entrada e recursos de computação sem provisionar servidores manualmente.
A seção Compute define os requisitos de infraestrutura, e a seção SourceCode define os caminhos locais para o código que será importado no job:
Para o treinamento distribuído em múltiplas GPUs, o exemplo usa o Hugging Face Accelerate com DeepSpeed ZeRO-3. O Accelerate simplifica o lançamento do treinamento distribuído, enquanto o ZeRO-3 reduz o uso de memória particionando estados do otimizador, gradientes e parâmetros entre as GPUs. O comando de lançamento tem a seguinte forma:
Otimização Direta de Preferências (DPO) no modelo ajustado com SFT
Com o artefato do modelo SFT pronto, ele é usado como modelo base para o treinamento DPO. A receita DPO é similar à do SFT, com algumas diferenças importantes nos hiperparâmetros:
beta: hiperparâmetro específico do DPO, geralmente entre 0 e 2, que controla quão agressivamente o modelo adota novas preferências. Um valor mais próximo de 0 é mais agressivo; mais próximo de 2 é mais conservador. Um ponto de partida típico é entre 0,1 e 0,5.
learning_rate: o DPO se beneficia de taxas de aprendizado mais baixas (por exemplo, 5e-7) com warmup_ratio para evitar sobreajuste. Esse valor contrasta com o 5e-5 usado no SFT.
batch_size: tamanhos de lote maiores tendem a ter melhor desempenho. O tamanho neste exemplo é intencionalmente pequeno para reduzir os requisitos de recursos.
Opcionalmente, é possível combinar diferentes valores de loss para realizar a Otimização de Preferência Mista (Mixed Preference Optimization), que permite combinar e ponderar múltiplos tipos de loss. Se apenas dados DPO estiverem disponíveis, é possível usar o tipo de loss sft para aproveitar a coluna de respostas aceitas do DPO para SFT também:
# MPO (Mixed Preference Optimization): Combines DPO (sigmoid) for preference and BCO (bco_pair) for quality
loss_type : ["sigmoid", "bco_pair", "sft"], # Loss types to combine
loss_weights : [0.8, 0.2, 1.0] # Corresponding weights, as used in the MPO paper
Entre os modelos base, o Qwen3-0.6B foi o mais forte apesar de ser o menor, superando o Qwen3-1.7B em aproximadamente 6% e o Llama-3.2-3B-Instruct em aproximadamente 1%.
Após o SFT, o Qwen3-1.7B ganhou aproximadamente 19% de acurácia e passou a superar os outros em 4–7%.
Após o DPO, o Qwen3-1.7B adicionou mais aproximadamente 10,5% de acurácia, encerrando o experimento na liderança com 8–9% de vantagem sobre os demais modelos.
No total, o Qwen3-1.7B ganhou 30% de acurácia geral e performou 9% melhor que o modelo Llama-3.2-3B, que tem quase o dobro de parâmetros.
A tabela abaixo resume os resultados:
Modelo
Técnica de Ajuste
Acc-Norm
Llama 3.2 3B Instruct
Base
46,50%
Llama 3.2 3B Instruct
Spectrum SFT
53,41%
Llama 3.2 3B Instruct
Spectrum SFT + DPO
62,67%
Qwen3-0.6B
Base
47,64%
Qwen3-0.6B
Spectrum SFT
56,10%
Qwen3-0.6B
Spectrum SFT + DPO
62,02%
Qwen3-1.7B
Base
41,57%
Qwen3-1.7B
Spectrum SFT
60,43%
Qwen3-1.7B
Spectrum SFT + DPO
71,06%
Alcançar desempenho similar ou superior com um modelo menor pode reduzir custos e melhorar o throughput na hora de hospedar o modelo.
Limpeza dos recursos
Para evitar cobranças por recursos que não são mais necessários, a AWS recomenda:
Excluir os jobs de treinamento do SageMaker AI lançados (jobs concluídos com sucesso não continuam gerando cobranças).
Remover os datasets enviados ao Amazon S3: aws s3 rm s3://<your-bucket>/datasets/nvidia_function_calling/ --recursive
Parar ou excluir a instância de notebook JupyterLab do SageMaker Studio para evitar cobranças por ociosidade.
Excluir os checkpoints do modelo armazenados no Amazon S3 que não são mais necessários.
Conclusão
A combinação de SFT e DPO no Amazon SageMaker AI representa uma abordagem robusta para melhorar a precisão de chamada de ferramentas em agentes de IA. O SFT usa datasets rotulados para refinar os parâmetros do modelo, desenvolvendo uma compreensão fundamental a partir de exemplos anotados por especialistas. O DPO então alinha as saídas do modelo com preferências humanas ou critérios de desempenho específicos por meio de feedback direto, sem a necessidade de definir funções de recompensa.
O resultado é um modelo mais preciso, mais relevante e mais alinhado com o comportamento desejado — e, como os experimentos mostram, é possível superar modelos maiores com modelos menores bem ajustados, o que representa uma vantagem real em termos de custo e latência em produção.
A AWS anunciou suporte ao SOCI snapshotter e ao índice SOCI nas Deep Learning AMIs (DLAMI) e nos AWS Deep Learning Containers. A novidade resolve um problema bastante concreto para equipes que trabalham com cargas de trabalho de inteligência artificial (IA) e aprendizado de máquina (ML) em escala: o tempo gasto fazendo o download de imagens de container gigantes antes de qualquer trabalho começar de fato.
O problema do cold start em containers de deep learning
Imagens de container para deep learning não são pequenas. É comum encontrar imagens de 15 a 20 GB comprimidas, que podem ocupar 30 a 60 GB em disco após a extração. Com o Docker padrão, todo esse conteúdo precisa ser baixado e descomprimido antes que o container possa iniciar — um processo que facilmente consome entre 4 e 7 minutos por instância.
Durante o desenvolvimento, alguns minutos de espera são toleráveis. Em produção, esse tempo se multiplica rapidamente. Alguns dos impactos mais críticos identificados pela AWS incluem:
Cold starts prolongados: pulls de imagens Docker de 15 a 20 GB podem levar de 4 a 6 minutos por instância, atrasando jobs de treinamento e endpoints de inferência durante eventos de escalonamento.
Desperdício de recursos computacionais: instâncias com GPU ficam ociosas durante o pull da imagem, consumindo horas de computação cara sem executar nenhuma carga útil.
Gargalos de escalonamento: quando picos de demanda disparam o auto scaling, o tempo lento de inicialização impede uma resposta rápida, degradando a performance ou causando perda de requisições.
Saturação de banda: múltiplas instâncias fazendo pull simultâneo de imagens pesadas podem saturar a largura de banda da rede, criando atrasos em cascata.
Perda de produtividade: cientistas de dados e engenheiros de ML perdem tempo valioso esperando containers iniciarem durante ciclos iterativos de desenvolvimento.
O que é o SOCI e como ele resolve isso
O Seekable OCI (SOCI) é uma tecnologia que permite o gerenciamento eficiente de imagens de container por meio de download seletivo de arquivos. Ele utiliza um sistema de indexação baseado em camadas para mapear a localização dos arquivos dentro da imagem, permitindo que o container inicie com apenas os arquivos necessários já carregados — o chamado lazy loading. As demais camadas são buscadas sob demanda, em segundo plano, conforme o container precisa delas.
Essa abordagem reduz o uso de largura de banda de rede e melhora significativamente o tempo de inicialização dos containers, sendo especialmente valiosa para organizações que gerenciam imagens grandes em ambientes de nuvem.
Três mecanismos de pull disponíveis
Ao fazer o pull de um container nas DLAMIs ou nos Deep Learning Containers, a AWS disponibiliza três opções: o pull padrão do Docker, o pull paralelo SOCI e o lazy loading SOCI via índice SOCI. Pense neles como uma escala de tradeoffs:
Docker pull padrão: download sequencial e descompressão sequencial. É o comportamento tradicional — lento, mas sem dependências adicionais.
SOCI parallel pull: faz o download da imagem completa antes de iniciar, mas com maior concorrência do que o Docker padrão. Ideal quando você precisa da imagem completa disponível antes de começar o trabalho.
SOCI lazy loading: inicia o container quase imediatamente, buscando apenas os arquivos necessários no momento, com o restante carregado em segundo plano sob demanda. Requer que a imagem tenha um índice SOCI no registry.
A escolha entre lazy loading e parallel pull depende da imagem, das especificações da instância e da configuração de armazenamento. Instâncias com especificações mais modestas se beneficiam do lazy loading para conservar recursos, enquanto instâncias de alta performance com múltiplos vCPUs e alta largura de banda de rede se saem melhor com o parallel pull. Em relação ao armazenamento, volumes EBS são limitados pelo IOPS provisionado e pelo tipo do volume — o que pode criar gargalos durante a descompressão —, enquanto o NVMe instance store entrega máxima performance de I/O, porém sem persistência de dados entre ciclos de stop/start da instância.
A arquitetura envolve uma instância EC2 de computação acelerada com uma DLAMI (Amazon Linux 2023 ou Ubuntu 24.04), sobre a qual os componentes SOCI (Fuse, SOCI CLI e Container Client) são instalados. Em cima dessa camada, rodam os Deep Learning Containers com suporte a SOCI — incluindo frameworks como PyTorch, TensorFlow, vLLM e sgLang.
Lazy loading na prática: de quase 7 minutos para 21 segundos
O modo de lazy loading inicia o container imediatamente, buscando apenas os dados necessários sob demanda, com as camadas restantes sendo carregadas em segundo plano conforme necessário.
Pré-requisito: índice SOCI
O lazy loading exige que a imagem de container tenha um índice SOCI armazenado no registry. Sem ele, o snapshotter recai no comportamento padrão de pull e nenhuma melhoria de performance é obtida. Os AWS Deep Learning Containers com o sufixo -soci na tag já vêm com índices SOCI pré-criados e enviados ao registry, habilitando o lazy loading imediatamente. Para imagens customizadas, é necessário criar e enviar os índices SOCI manualmente.
Ambiente de teste (lazy loading)
Tipo de instância: g5.2xlarge
EBS: 500 GiB, 3000 IOPS, 125 MB/s de throughput
AMI: Deep Learning Base OSS Nvidia Driver GPU AMI (Ubuntu 24.04) 20260413
Tamanho da imagem: 9,72 GB (comprimida), 32,7 GB (uso em disco)
Iniciando o container com Docker padrão
Com o Docker padrão, como nenhuma imagem existe localmente, o Docker faz o pull e extrai a imagem completa antes de iniciar o container. Tempo total: 6m59.099s.
#!/bin/bash
time docker run \
--gpus all \
-d \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--env "HUGGING_FACE_HUB_TOKEN=$HUGGING_FACE_HUB_TOKEN" \
-p 8000:8000 \
--ipc=host \
public.ecr.aws/deep-learning-containers/vllm:0.19.0-gpu-py312-ec2-soci \
--model mistralai/Mistral-7B-v0.1
# output
Unable to find image 'public.ecr.aws/deep-learning-containers/vllm:0.19.0-gpu-py312-ec2-soci' locally
0.19.0-gpu-py312-ec2-soci: Pulling from deep-learning-containers/vllm
340d44d2921c: Pull complete
....2001a2421bf1: Pull complete
Digest: sha256:a6344c96a33ef98a32a27f89b41b8c0529d4fbbba248eb57f811725d415f68fc
Status: Downloaded newer image for public.ecr.aws/deep-learning-containers/vllm:0.19.0-gpu-py312-ec2-soci
e12d969eb71517d9a6a23b9b11cfa22ddda26a95f6a0f0d8df00cd5c4fdfe912
real 6m59.099s
user 0m0.391s
sys 0m0.452s
Iniciando o container com SOCI snapshotter (lazy loading)
Com o nerdctl e o SOCI snapshotter, a imagem indexada permite que apenas o índice e as camadas necessárias sejam baixados para iniciar o container. As camadas restantes são carregadas sob demanda. Tempo total: 21.125s.
#!/bin/bash
time sudo nerdctl run \
--snapshotter soci \
--gpus all \
-d \
-v ~/.cache/huggingface:/root/.cache/huggingface \
--env "HUGGING_FACE_HUB_TOKEN=$HUGGING_FACE_HUB_TOKEN" \
-p 8000:8000 \
--ipc=host \
public.ecr.aws/deep-learning-containers/vllm:0.19.0-gpu-py312-ec2-soci \
--model mistralai/Mistral-7B-v0.1
# output
public.ecr.aws/deep-learning-containers/vllm:0.19.0-gpu-py312-ec2-soci: resolved |++++++++++++++++++++++++++++++++++++++|
index-sha256:a6344c96a33ef98a32a27f89b41b8c0529d4fbbba248eb57f811725d415f68fc: done |++++++++++++++++++++++++++++++++++++++|
manifest-sha256:d91ad3b46204eace6de2fb27c46d9600337fa9c124b4c82fe0f335d391017daa: done |++++++++++++++++++++++++++++++++++++++|
config-sha256:886ed36d57c44081a74a0ab052f57366d96ab2c0fe39bb3e2f8a46cc20db8ec2: done |++++++++++++++++++++++++++++++++++++++|
elapsed: 10.5s total: 48.1 K (4.6 KiB/s)
189307b7899438415f3df4288b3fbb26bcc4cd43678e88ec3b062bc6330e3e3b
real 0m21.125s
user 0m0.004s
sys 0m0.011s
O container iniciou em 21,125 segundos com SOCI lazy loading, contra 6 minutos e 59 segundos com o Docker padrão — uma melhoria de aproximadamente 20x.
Parallel pull: 2,2x mais rápido para imagens completas
Enquanto o lazy loading inicia o container imediatamente buscando apenas o necessário, o modo de parallel pull faz o download da imagem completa antes da inicialização, mas com concorrência muito maior do que o Docker padrão. Esse modo é ideal quando você precisa da imagem completa disponível no início ou quando executa cargas de trabalho intensivas em I/O.
Ambiente de teste (parallel pull)
Tipo de instância: g5.4xlarge
EBS: 500 GiB gp3, 16.000 IOPS, 1.000 MB/s de throughput
AMI: Deep Learning Base OSS Nvidia Driver GPU AMI (Ubuntu 24.04) 20260413
Tamanho da imagem: 19,32 GB (comprimida), 60,4 GB (uso em disco)
Observação: o benchmark usa uma imagem privada do ECR porque o ECR público é servido pelo Amazon CloudFront, o que limita a largura de banda de rede e afeta a performance no modo paralelo. O ECR privado é servido diretamente pelo Amazon Simple Storage Service (Amazon S3), oferecendo maior throughput.
Habilitando o modo parallel pull
O SOCI snapshotter nas DLAMIs usa lazy loading por padrão. Para habilitar o parallel pull, é necessário modificar o arquivo de configuração em /etc/soci-snapshotter-grpc/config.toml:
# Parallel Pull Mode - significantly improves image pull times for large AI/ML images
# These are conservative defaults recommended by AWS for ECR
[pull_modes.parallel_pull_unpack]
enable = true # false(default): lazy loading/true: parallel mode
max_concurrent_downloads = -1 # unlimited global cap across all images
max_concurrent_downloads_per_image = 20 # per-image download connections
concurrent_download_chunk_size = "16mb"
max_concurrent_unpacks = -1 # unlimited global cap across all images
max_concurrent_unpacks_per_image = 10 # per-image parallel unpack threads
discard_unpacked_layers = true
Após editar o arquivo, aplique a configuração reiniciando o serviço:
sudo systemctl restart soci-snapshotter.service
Dica: é possível ajustar max_concurrent_downloads_per_image e max_concurrent_unpacks_per_image conforme o tipo de instância e a largura de banda disponível. Para orientações detalhadas de tuning, consulte o post Introducing Seekable OCI Parallel Pull Mode for Amazon EKS.
Verificando se o modo paralelo está ativo
Para confirmar que o parallel pull está habilitado, monitore os logs do SOCI snapshotter durante o pull da imagem:
journalctl -u soci-snapshotter -f
Procure por entradas de log indicando pull/unpack paralelo:
Com o Docker padrão, o pull da imagem de 19,32 GB levou 4 minutos e 44 segundos. Com o SOCI em modo parallel pull, o mesmo pull foi concluído em 2 minutos e 12 segundos — uma melhoria de 2,2x na performance de download.
Resumo dos resultados
O SOCI snapshotter entrega melhorias expressivas tanto na inicialização de containers quanto no pull de imagens:
Lazy loading: melhoria de 20x no tempo de inicialização do container (de mais de 6 minutos para aproximadamente 21 segundos).
Parallel pull: melhoria de 2,2x no tempo de pull da imagem (de 4 minutos e 44 segundos para 2 minutos e 12 segundos).
A regra de escolha é direta: use o lazy loading quando precisar da inicialização mais rápida possível do container; use o parallel pull quando precisar que a imagem completa esteja disponível antes de começar o trabalho.
Se você lançou instâncias EC2 para testar o SOCI snapshotter, lembre-se de encerrá-las para evitar cobranças contínuas. Exclua também as imagens de container enviadas ao Amazon Elastic Container Registry (Amazon ECR) durante os testes e remova os índices SOCI que não forem mais necessários.
O desafio de servir múltiplos clientes com requisitos diferentes
Provedores de Software como Serviço (SaaS) que constroem aplicações de IA sobre o Amazon Bedrock AgentCore frequentemente se deparam com um problema clássico: precisam atender múltiplos clientes (tenants) com exigências de segurança completamente distintas, tudo a partir de uma infraestrutura compartilhada.
Alguns clientes precisam de acesso entre contas da Amazon Web Services (AWS). Outros, por questões regulatórias, exigem que o tráfego fique restrito a uma Nuvem Privada Virtual (VPC). Sem um controle centralizado no nível do recurso, gerenciar essa diversidade se torna complexo e propenso a erros.
A AWS documentou como o AgentCore suporta políticas baseadas em recursos — um mecanismo que oferece controle centralizado sobre quem pode acessar o AgentCore Runtime e seus endpoints, e sob quais condições. A seguir, exploramos o cenário prático e o passo a passo técnico apresentados no blog oficial.
O cenário multi-tenant
Imagine um provedor SaaS que opera uma plataforma de atendimento ao cliente com IA. Ele usa o AgentCore para implantar agentes inteligentes que respondem dúvidas de produtos, processam devoluções e escalam casos complexos para atendentes humanos. Dois clientes empresariais compartilham esse mesmo agente, mas com requisitos de segurança bem diferentes:
Tenant A — Example Corp: grande varejista operando na conta AWS 111122223333. Sua equipe de desenvolvimento e equipe de administração precisam invocar o agente diretamente da própria conta AWS, sem necessidade de compartilhamento de credenciais. Não há restrições de rede — qualquer caminho de acesso é válido, desde que as credenciais AWS sejam válidas.
Tenant B — AnyCompany: empresa de saúde operando na conta AWS 444455556666. Por exigências de conformidade com a regulação HIPAA, todo o tráfego ao agente de IA deve originar-se exclusivamente de dentro de uma VPC privada (vpc-health1234). Qualquer chamada de API feita fora desse perímetro de rede deve ser bloqueada, mesmo que venha de uma role com credenciais válidas.
O provedor SaaS opera na conta 555555555555, na região us-west-2, com um AgentCore Runtime chamado support-agent-runtime e um AgentCore Runtime endpoint padrão (DEFAULT). Ambos os tenants compartilham essa mesma infraestrutura.
Arquitetura da solução
A solução utiliza políticas baseadas em recursos aplicadas tanto ao AgentCore Runtime quanto ao AgentCore Runtime endpoint. O diagrama abaixo ilustra os dois padrões de acesso em ação:
A conta do provedor SaaS hospeda o AgentCore Runtime e o endpoint. A Example Corp acessa o agente entre contas usando roles do AWS Identity and Access Management (IAM) autenticadas com Signature Version 4 (SigV4), o protocolo padrão de assinatura de requisições AWS. A AnyCompany também acessa entre contas, mas com uma restrição adicional: todas as requisições devem passar por um endpoint de VPC para o AgentCore.
Um detalhe crítico: as políticas baseadas em recursos precisam ser aplicadas tanto no AgentCore Runtime quanto no AgentCore Runtime endpoint. Para operações InvokeAgentRuntime, a AWS avalia as políticas nos dois recursos — se qualquer um deles negar o acesso ou não tiver um Allow explícito, a requisição é bloqueada.
Implementação passo a passo
Pré-requisitos
Antes de começar, é necessário ter:
Uma conta AWS com acesso ao AgentCore e permissões para chamar PutResourcePolicy, GetResourcePolicy e DeleteResourcePolicy
Passo 1: Acesso entre contas para a Example Corp (Tenant A)
Sem políticas baseadas em recursos, habilitar acesso entre contas normalmente exigiria que as roles da Example Corp assumissem uma role na conta do provedor via encadeamento de roles IAM — adicionando complexidade operacional e criando roles adicionais que precisariam ser mantidas para cada tenant. Com políticas baseadas em recursos, as roles da Example Corp recebem acesso direto ao AgentCore Runtime e ao endpoint, sem encadeamento de roles.
Política baseada em recurso para o AgentCore Runtime — salve como runtime-policy.json:
Política baseada em identidade na conta da Example Corp — políticas baseadas em recursos sozinhas não são suficientes para acesso entre contas. A Example Corp também precisa anexar uma política baseada em identidade às roles DeveloperRole e AdminRole na conta 111122223333:
Passo 2: Acesso entre contas com restrição de VPC para a AnyCompany (Tenant B)
A AnyCompany opera sob conformidade HIPAA e exige que todo o tráfego ao agente permaneça dentro de um caminho de rede privado. Assim como a Example Corp, ela precisa de acesso entre contas — mas com uma restrição adicional: as requisições devem originar-se da VPC vpc-health1234 via endpoint de VPC de interface. Qualquer requisição fora dessa VPC é negada, mesmo que venha da ApplicationRole com credenciais válidas.
Para isso, as políticas baseadas em recursos são atualizadas com um par de declarações: um Allow para a ApplicationRole e um Deny explícito para qualquer requisição que não venha da VPC aprovada. A condição StringNotEquals sobre aws:SourceVpc garante que, se o valor não corresponder a vpc-health1234 — ou se a chave estiver ausente porque nenhum endpoint de VPC foi usado — o bloqueio entra em vigor. Como um Deny explícito sempre sobrepõe qualquer Allow, esse padrão garante que nenhuma outra política possa inadvertidamente conceder acesso de fora da VPC.
Adicione os seguintes statements ao runtime-policy-v2.json, junto com os statements da Example Corp do Passo 1:
Como o comando put-resource-policy substitui toda a política do recurso, os arquivos atualizados devem incluir tanto os statements da AnyCompany quanto os da Example Corp do Passo 1.
# Verificar política do Agent Runtime
aws bedrock-agentcore-control get-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime \
--region us-west-2
# Verificar política do Agent Runtime Endpoint
aws bedrock-agentcore-control get-resource-policy \
--resource-arn arn:aws:bedrock-agentcore:us-west-2:555555555555:runtime/support-agent-runtime/runtime-endpoint/DEFAULT \
--region us-west-2
Política baseada em identidade na conta da AnyCompany — a restrição de VPC é aplicada inteiramente na conta do provedor, por meio da condição na política baseada em recurso. Portanto, a política baseada em identidade da AnyCompany não precisa de condições de VPC, mantendo a configuração do lado do tenant simples:
As políticas apresentadas até aqui usam autenticação SigV4 com principals de roles IAM específicas. Se o AgentCore Runtime ou o AgentCore Gateway estiver configurado com autenticação OAuth, a estrutura do principal muda. Recursos autenticados via OAuth requerem um principal curinga ("Principal": "*"), pois a identidade do chamador vem de um Token Web JSON (JWT) validado antes da avaliação da política. Requisições anônimas ou não autenticadas são rejeitadas antes mesmo de a política ser avaliada, então o curinga não significa acesso aberto.
Para restringir requisições OAuth a uma VPC específica, basta combinar o principal curinga com uma condição de VPC na política baseada em recurso. Vale notar que chaves de condição baseadas em principal IAM — como aws:PrincipalAccount e aws:PrincipalOrgID — não são populadas no contexto de autenticação OAuth. Apenas chaves de condição de nível de rede (como aws:SourceVpc, aws:SourceVpce, aws:SourceIp) estão disponíveis. Veja mais detalhes em políticas baseadas em recursos para Amazon Bedrock AgentCore.
Entendendo a avaliação das políticas
Para consolidar o entendimento, vale observar como a AWS avalia as políticas em diferentes cenários:
Example Corp, qualquer rede: política de identidade permite + política do runtime permite + política do endpoint permite → Acesso concedido
AnyCompany, de dentro da VPC: política de identidade permite + condição aws:SourceVpc corresponde em ambos os recursos → Acesso concedido
AnyCompany, fora da VPC: condição aws:SourceVpc não corresponde → Deny explícito em ambos os recursos → Acesso negado
Qualquer outra role entre contas, qualquer rede: sem Allow correspondente na política do recurso → Acesso negado
Qualquer role sem política de identidade: mesmo com Allow no recurso, a ausência de política de identidade bloqueia o acesso entre contas → Acesso negado
Conclusão
O que a AWS demonstra nesse guia é uma abordagem elegante para um problema real de plataformas SaaS multi-tenant: como oferecer controles de segurança distintos para cada cliente sem duplicar infraestrutura. A Example Corp obtém integração entre contas sem complexidade de gerenciamento de credenciais. A AnyCompany obtém o isolamento de rede exigido pela sua equipe de conformidade, com a garantia de que interações envolvendo informações potencialmente sensíveis ficam dentro do perímetro de rede controlado.
Ambos os tenants compartilham o mesmo AgentCore Runtime e endpoint, mas cada um tem controles de segurança sob medida aplicados no nível do recurso. Políticas baseadas em recursos complementam as políticas baseadas em identidade do IAM, oferecendo controle em camadas sobre quais principals podem invocar quais agentes e a partir de quais caminhos de rede.
Por que a customização de LLMs é mais difícil do que parece
Grandes Modelos de Linguagem (LLMs) se saem bem em tarefas genéricas, mas frequentemente tropeçam quando o assunto envolve dados proprietários, processos internos ou vocabulário técnico específico de um setor. Para endereçar esse problema, a AWS disponibiliza o Amazon Nova Forge, plataforma que permite construir modelos de fronteira customizados a partir do Amazon Nova. Com ela, é possível partir de checkpoints iniciais do modelo, combinar dados proprietários com datasets curados pela AWS e hospedar os modelos customizados com segurança na nuvem.
Um recurso central da plataforma é o data mixing (mistura de dados), que combina os dados de treinamento do cliente com conjuntos curados pela AWS. Essa abordagem ajuda o modelo a absorver o domínio específico sem perder as capacidades gerais de raciocínio, seguimento de instruções e linguagem — evitando o chamado esquecimento catastrófico, problema clássico que sabota customizações de domínio.
A AWS publicou um guia técnico detalhado sobre como navegar esse processo no Nova Forge, cobrindo tanto as decisões estratégicas (as escolhas qualitativas) quanto a configuração científica de parâmetros (as decisões baseadas em métricas). Este artigo apresenta os pontos principais desse material.
Os três desafios fundamentais do ajuste de hiperparâmetros
Desafio 1: Esquecimento catastrófico
Quando um modelo é treinado intensamente sobre dados de um domínio estreito, ele pode sobrescrever capacidades gerais adquiridas durante o pré-treinamento. O resultado é um modelo muito especializado, mas que perde a capacidade de seguir instruções, raciocinar sobre pedidos ambíguos ou manter conversas coerentes em múltiplos turnos. O Nova Forge endereça isso via data mixing e seleção de checkpoints.
Desafio 2: Encontrar a taxa de aprendizado certa
A taxa de aprendizado (learning rate) controla o quanto os pesos do modelo mudam a cada lote de exemplos de treinamento. É o hiperparâmetro mais sensível em todas as técnicas de customização. Uma taxa muito alta desestabiliza o treinamento; uma taxa muito baixa desperdiça computação com convergência lenta. O Nova Forge fornece valores padrão calibrados para cada técnica — e desviar desses padrões ao usar data mixing é a causa mais comum de instabilidade.
Desafio 3: Restrições de desempenho base para RFT
O Ajuste Fino por Reforço (RFT — Reinforcement Fine-Tuning) funciona gerando múltiplas respostas candidatas e pontuando-as com uma função de recompensa. Ele só opera bem dentro de uma faixa específica de acurácia base: se o modelo raramente acerta antes do treino, não há exemplos bons suficientes para o aprendizado guiado por recompensa. Se já acerta quase tudo, o ganho marginal é mínimo. Para casos de baixa acurácia base, a recomendação é rodar primeiro o Ajuste Fino Supervisionado (SFT — Supervised Fine-Tuning) para estabelecer a competência mínima necessária.
O pipeline de customização do Nova Forge
O Nova Forge oferece três técnicas complementares de customização, cada uma servindo a um propósito distinto:
Pré-treinamento Continuado (CPT — Continued Pre-Training): expande o conhecimento do modelo via aprendizado auto-supervisionado em grandes volumes de dados não rotulados de um domínio. Indicado quando o modelo precisa aprender vocabulário especializado, conceitos do setor ou conhecimento organizacional que não existe no modelo base.
Ajuste Fino Supervisionado (SFT — Supervised Fine-Tuning): customiza o comportamento do modelo usando pares de entrada-saída específicos para as tarefas-alvo. Indicado quando o modelo precisa seguir formatos de resposta específicos, adotar tons particulares ou executar tarefas estruturadas como classificação ou extração. O ideal é ter entre 1.000 e 10.000 demonstrações de alta qualidade por tarefa.
Ajuste Fino por Reforço (RFT — Reinforcement Fine-Tuning): direciona as saídas do modelo para resultados preferidos usando sinais de recompensa. O Nova Forge suporta ambientes de recompensa externos via AWS Lambda, permitindo lógica de verificação customizada para avaliação de qualidade específica do domínio.
Quando os três estágios são usados em sequência (CPT, depois SFT, depois RFT), os resultados são os mais fortes. Mas cada etapa é opcional — a escolha depende da disponibilidade de dados, do tipo de tarefa e do ponto de partida.
O Amazon SageMaker AI oferece diferentes ambientes para executar esse pipeline: o SageMaker Serverless traz uma experiência visual com provisionamento automático de computação; os jobs de treinamento do SageMaker AI (SMTJ) oferecem uma experiência totalmente gerenciada sem gestão de cluster; e o Amazon SageMaker HyperPod fornece ambientes especializados para cenários avançados de treinamento distribuído.
Decisões estratégicas que importam mais do que qualquer hiperparâmetro
Seleção de checkpoint (decisão mais impactante para CPT)
Para o CPT, a escolha do checkpoint tem mais impacto do que qualquer hiperparâmetro isolado. O Nova Forge oferece três opções de checkpoint, cada uma adequada a diferentes escalas de dados:
Checkpoints pré-treinados: máxima flexibilidade e convergência mais rápida. Funcionam melhor para CPT em larga escala, com orçamentos de tokens acima de 100 bilhões. Após o CPT com esse checkpoint, é obrigatório rodar SFT para tornar o modelo utilizável em tarefas.
Checkpoints mid-trained (treinamento intermediário): equilibram flexibilidade e alinhamento. Indicados para datasets de tamanho médio e funcionam bem com treinamento de posto completo (Full Rank) em conjuntos de dados grandes e estruturados.
Checkpoints pós-treinados: os mais resistentes a novos padrões, mas preservam o seguimento de instruções e as capacidades gerais. Recomendados para CPT em menor escala e como ponto de partida para métodos de ajuste fino eficientes em parâmetros, como LoRA.
Sem data mixing, treinar apenas sobre dados de domínio estreito pode tornar o modelo instável. A recomendação da AWS é equilibrar os dados do cliente em torno de 50% do mix total para a maioria dos casos. Para SFT, sempre incluir a categoria “reasoning-instruction-following” no mix de dados Nova — essa categoria melhora significativamente o desempenho em benchmarks genéricos após o ajuste fino. Omiti-la é uma causa comum de degradação do raciocínio.
O data mixing é muito sensível à taxa de aprendizado. Desviar do padrão ao usar essa técnica é o erro mais frequente observado na prática.
Modo de treinamento: LoRA vs. Posto Completo (Full Rank)
O Nova Forge suporta dois modos de treinamento:
LoRA (Adaptação de Baixo Posto — Low-Rank Adaptation): atualiza apenas camadas adaptadoras, com menor custo computacional e iteração mais rápida. Compatível com inferência sob demanda. Alcança desempenho próximo ao Full Rank para a maioria das tarefas e é mais tolerante a hiperparâmetros subótimos. Use checkpoints pós-treinados como ponto de partida.
Full Rank (Posto Completo): atualiza todos os parâmetros do modelo, oferecendo máxima capacidade de adaptação. Exige o Amazon Bedrock Provisioned Throughput para implantação e maior computação durante o treinamento. Indicado quando o pipeline já foi validado e os requisitos de produção justificam o custo adicional.
A recomendação é começar sempre com LoRA para validar o pipeline, a qualidade dos dados e a função de recompensa (no caso do RFT), e só migrar para Full Rank quando a abordagem estiver confirmada.
Configuração de parâmetros
Taxa de aprendizado
Para CPT, começar pelos valores padrão do serviço. Para datasets muito grandes (acima de 1 trilhão de tokens), é possível usar uma taxa mais alta (como 1e-4) para acelerar a absorção de conhecimento, mas é necessário um estágio de redução gradual até aproximadamente 1e-6 antes de rodar o SFT. O parâmetro constant_steps controla quantos passos o modelo treina na taxa de pico antes desse estágio de redução.
Para SFT, manter os padrões do serviço — especialmente com data mixing. A taxa recomendada é 1e-5 para LoRA e 5e-6 para SFT de posto completo. Para RFT, começar pelos padrões e ajustar apenas em pequenos incrementos se necessário. Configurar os passos de aquecimento (warmup steps) em aproximadamente 15% do total de passos de treinamento.
Tamanho de lote e duração do treinamento
O tamanho de lote (global_batch_size) é o parâmetro de lote em todos os métodos de treinamento e ambientes. Para CPT, o alvo é de 2 a 20 milhões de tokens por passo. Processar no máximo uma época do dataset — múltiplas épocas com dados CPT limitados levam a overfitting e perda de capacidades gerais.
Para RFT, o parâmetro number_generation controla quantas respostas candidatas são geradas por prompt para pontuação pela função de recompensa. Atenção: a semântica do tamanho de lote difere entre ambientes. No SMTJ, global_batch_size significa prompts por passo (cada um gerando N candidatos). No SageMaker HyperPod, significa amostras totais (prompts multiplicados por gerações). Traduzir cuidadosamente ao mover configurações entre ambientes.
Parâmetros específicos de RFT
O RFT introduz parâmetros adicionais não presentes no CPT ou SFT:
Coeficiente de Perda KL-Divergência: restringe o quanto a política do modelo pode se afastar do comportamento original. Disponível apenas no SMTJ. Um coeficiente baixo permite exploração livre, mas arrisca atalhos que enganam a função de recompensa; um coeficiente alto impede aprendizado significativo.
Esforço de Raciocínio (Reasoning Effort): controla quanto raciocínio em cadeia de pensamento o modelo realiza antes de responder. Alto esforço produz melhor acurácia, mas aumenta latência e custo.
Limite de Concorrência Lambda (Lambda Concurrency Limit): disponível apenas no SMTJ, controla as funções Lambda paralelas para avaliação de recompensa.
Experimentos e resultados práticos
A AWS realizou uma série de experimentos de Otimização de Hiperparâmetros (HPO — Hyperparameter Optimization) usando o Amazon Nova 2.0 em benchmarks públicos, incluindo CoCoHD, MedReason e LLaVA-CoT. Os principais achados foram:
No benchmark MedReason, o SFT com LoRA usando rank 32, alpha 64, tamanho de lote 32 e taxa de aprendizado padrão (1e-5) produziu o melhor resultado: 63,54% de acurácia, uma melhora de 10,75% sobre o modelo base. Reduzir a taxa para 5e-6 prejudicou o desempenho sem proteger as capacidades gerais. Dobrar para 2 épocas na mesma taxa reduziu a acurácia para 61,42%, confirmando que o sobretreinamento em dados de domínio estreito degrada tanto o desempenho de domínio quanto o geral.
No benchmark LLaVA-CoT, onde o modelo base parte de apenas 16,22% de acurácia, a melhor configuração (rank 64, alpha 64) elevou a acurácia para 68,47% — uma melhora relativa de 322%. Para tarefas com baixa acurácia base, aumentar o rank é um ajuste de maior alavancagem do que aumentar o alpha.
A equipe de Ciência Aplicada da AWS China também demonstrou, em sua avaliação do Amazon Nova Forge, uma melhora de 17% no F1 Score em uma tarefa complexa de classificação de Voz do Cliente, mantendo pontuações MMLU próximas ao baseline.
Armadilhas comuns e como evitá-las
Pular o SFT antes do RFT: o RFT não produz melhora (ou degrada o desempenho) se o modelo não tiver competência base suficiente. Sempre rode SFT primeiro.
Desviar da taxa de aprendizado padrão com data mixing: é o erro mais comum. Instabilidade de treinamento com data mixing? A taxa de aprendizado é o primeiro suspeito.
Função de recompensa de baixa qualidade: uma função de recompensa ruim diminui a acurácia independentemente de qualquer outro ajuste. Refine a função antes de mudar qualquer parâmetro de treinamento. Valide com pelo menos dois avaliadores independentes.
Múltiplas épocas em dados CPT limitados: leva a overfitting e perda de capacidades gerais. Processe no máximo uma época.
Configurações de raciocínio incompatíveis: se treinar com raciocínio habilitado, inferir também com raciocínio habilitado.
Vale reforçar: qualidade de dados e qualidade da função de recompensa superam qualquer hiperparâmetro em importância. Antes de ajustar parâmetros de treinamento, otimize o pipeline de dados e a função de recompensa.
Métricas para monitorar o treinamento
Loss de treinamento: deve diminuir de forma constante, sem picos abruptos. Picos indicam problemas de taxa de aprendizado ou qualidade de dados.
Loss de validação: se aumenta enquanto o loss de treinamento diminui, há overfitting. Reduza as épocas, aumente a regularização ou adicione dados mais diversos.
KL Divergência (para RFT): picos súbitos indicam atualizações grandes e potencialmente instáveis. Aumente o coeficiente de perda KL se isso ocorrer.
Métricas de recompensa (para RFT): devem melhorar de forma constante. Melhora rápida seguida de platô ou queda pode indicar que o modelo está “enganando” a função de recompensa.
