Blog

Modelos base e a necessidade de personalização

Modelos de fundação entregam desempenho impressionante para tarefas genéricas, mas muitas organizações precisam de modelos que entendam suas especificidades de negócio. Quando você constrói aplicações que exigem expertise em domínios específicos, aplicação de estilos de comunicação particulares, otimização para tarefas especializadas como geração de código ou raciocínio financeiro, ou ainda conformidade com regulamentações do setor, a personalização do modelo se torna essencial para fechar a lacuna entre IA genérica e necessidades específicas.

O desafio está em como personalizar efetivamente. O refinamento supervisionado tradicional funciona, mas requer milhares de exemplos cuidadosamente rotulados mostrando não apenas a resposta final correta, mas também o caminho completo do raciocínio para chegar a ela. Para muitas aplicações reais, especialmente aquelas onde múltiplos caminhos de solução são válidos, criar essas demonstrações passo a passo pode ser dispendioso e demorado.

Uma nova abordagem: aprendizado por avaliação em vez de imitação

O refinamento com aprendizado por reforço (RFT) muda o paradigma: em vez de aprender por imitação, o modelo aprende por avaliação. Em vez de fornecer milhares de exemplos rotulados, você oferece prompts e define o que torna uma resposta final correta através de casos de teste, resultados verificáveis ou critérios de qualidade. O modelo então aprende a otimizar esses critérios através de feedback iterativo, descobrindo seus próprios caminhos para soluções corretas.

O RFT é particularmente eficaz para personalização de modelos em geração de código e raciocínio matemático, verificando outputs automaticamente e eliminando a necessidade de fornecer raciocínio detalhado passo a passo.

A AWS disponibilizou o RFT em seus serviços de IA para atender você em qualquer estágio de sua jornada: comece simples com a experiência totalmente gerenciada do Amazon Bedrock, ganhe mais controle com os SageMaker Training Jobs, dimensione para infraestrutura avançada com o SageMaker HyperPod, ou libere capacidades de ponta com o Nova Forge para conversas multi-turno e ambientes de aprendizado por reforço customizados.

Em dezembro de 2025, a Amazon lançou a família Nova 2 — os primeiros modelos da empresa com capacidades de raciocínio integradas. Diferentemente de modelos tradicionais que geram respostas diretas, modelos de raciocínio como o Nova 2 Lite engajam em decomposição de problemas passo a passo, realizando etapas de pensamento intermediário antes de produzir respostas finais. Quando combinado com RFT, essa capacidade de raciocínio se torna particularmente poderosa: o RFT pode otimizar não apenas qual resposta o modelo produz, mas como ele raciocina através de problemas, ensinando-o a descobrir caminhos de raciocínio mais eficientes enquanto reduz o uso de tokens.

Casos de uso práticos do RFT

O RFT se destaca em cenários onde você pode definir e verificar resultados corretos, mas criar demonstrações detalhadas de solução passo a passo em escala é impraticável:

• Geração de código: você deseja código não apenas correto, mas também eficiente, legível e que trate casos extremos graciosamente — qualidades que você pode verificar programaticamente através de execução de testes e métricas de desempenho.
• Atendimento ao cliente: você precisa avaliar se as respostas são úteis, mantêm a voz da marca e apresentam o tom certo para cada situação. Essas são avaliações que não podem ser reduzidas a regras simples, mas podem ser avaliadas por um juiz de IA treinado em seus padrões de comunicação.
• Outras aplicações: moderação de conteúdo, onde contexto e nuance importam; tarefas de raciocínio multi-etapas como análise financeira ou revisão de documentos legais; e uso de ferramentas, onde você precisa ensinar modelos quando e como chamar APIs ou consultar bancos de dados.
• Problemas que exploram diversas soluções: casos como jogos e estratégia, alocação de recursos e agendamento se beneficiam de abordagens onde o modelo usa diferentes estratégias e aprende com feedback.
• Cenários com dados rotulados limitados: aplicações específicas de domínio com poucos exemplos anotados por especialistas, novos domínios de problema sem padrões de solução estabelecidos, ou tarefas caras de rotular (diagnóstico médico, análise legal).

Como o RFT funciona

O RFT opera através de um processo automatizado de três estágios:

Estágio 1: Geração de respostas — O modelo ator (o modelo que você está personalizando) recebe prompts de seu conjunto de dados de treinamento e gera múltiplas respostas por prompt — tipicamente 4 a 8 variações. Essa diversidade oferece ao sistema um leque de respostas para avaliar e aprender.

Estágio 2: Cálculo de recompensas — Em vez de comparar respostas com exemplos rotulados, o sistema avalia qualidade usando funções de recompensa. Você tem duas opções: aprendizado por reforço via recompensas verificáveis (RLVR), usando verificadores baseados em regras implementados como funções AWS Lambda, perfeito para tarefas objetivas como execução de código ou verificação de problemas matemáticos; ou aprendizado por reforço de feedback de IA (RLAIF), usando juízes baseados em IA que avaliam respostas com base em critérios que você configura, ideal para tarefas subjetivas como avaliar utilidade, criatividade ou aderência à voz da marca.

Estágio 3: Treinamento do modelo ator — O sistema usa os pares prompt-resposta pontuados para treinar seu modelo através de um algoritmo de aprendizado por reforço, como Group Relative Policy Optimization (GRPO), otimizado para modelos de linguagem. O modelo aprende a maximizar a probabilidade de gerar respostas com alta recompensa enquanto minimiza respostas com baixa recompensa. Esse processo iterativo continua até que o modelo atinja seu desempenho desejado.

Benefícios principais do RFT

• Sem necessidade de datasets massivos e rotulados: RFT requer apenas prompts e uma maneira de avaliar qualidade. Se usar Bedrock RFT, você pode até aproveitar logs de invocação da API do Bedrock existentes como dados de RFT, eliminando a necessidade de datasets especialmente criados.
• Otimizado para resultados verificáveis: Diferentemente do refinamento supervisionado que requer demonstrações explícitas de como atingir respostas corretas, RFT é otimizado para tarefas onde você pode definir e verificar resultados corretos, mas múltiplos caminhos de raciocínio válidos podem existir.
• Redução no uso de tokens: Ao otimizar o processo de raciocínio do modelo, RFT pode reduzir o número de tokens necessários para realizar uma tarefa, diminuindo custo e latência em produção.
• Seguro e monitorado: Seus dados proprietários nunca deixam o ambiente seguro da AWS durante o processo de personalização, e você obtém monitoramento em tempo real de métricas de treinamento para acompanhar progresso e garantir qualidade.

Opções de implementação: do simples ao complexo

A AWS oferece múltiplos caminhos de implementação para refinamento com aprendizado por reforço com modelos Nova, variando de experiências totalmente gerenciadas até infraestrutura customizável. Essa abordagem em camadas permite corresponder sua implementação de RFT às suas necessidades específicas, expertise técnica e nível desejado de controle.

Amazon Bedrock

O Amazon Bedrock fornece um ponto de entrada para RFT com experiência totalmente gerenciada que requer expertise mínima em aprendizado de máquina. Através do console ou API do Amazon Bedrock, você pode carregar seus prompts de treinamento, configurar sua função de recompensa como uma função AWS Lambda, e iniciar seu trabalho de refinamento com aprendizado por reforço em poucos cliques. O Bedrock cuida de todo o provisionamento de infraestrutura, orquestração de treinamento e implantação de modelo automaticamente. Essa abordagem funciona bem para casos de uso diretos onde você precisa otimizar critérios específicos sem gerenciar infraestrutura.

Bedrock RFT suporta ambas as abordagens RLVR (recompensas baseadas em regras) e RLAIF (feedback baseado em IA), com ferramentas de monitoramento e avaliação integradas para acompanhar a melhoria de seu modelo. Para começar, veja o repositório Amazon Nova RFT no GitHub.

Amazon SageMaker Training Jobs

Para equipes que precisam de mais controle sobre o processo de treinamento, os Amazon SageMaker Training Jobs oferecem um meio termo flexível com computação gerenciada e capacidade de ajustar múltiplos hiperparâmetros. Você também pode salvar checkpoints intermediários e usá-los para criar fluxos de trabalho de treinamento iterativo, como encadear trabalhos de refinamento supervisionado (SFT) e RFT para refinar progressivamente seu modelo. Você tem flexibilidade para escolher entre abordagens de treinamento LoRA (adaptação de baixa classificação) e full-rank, com controle total sobre hiperparâmetros.

Essa camada é ideal para engenheiros de aprendizado de máquina e cientistas de dados que precisam de personalização além do Amazon Bedrock, mas não requerem infraestrutura dedicada. Para começar, consulte os notebooks SFT e RFT.

Amazon SageMaker HyperPod

O SageMaker HyperPod oferece infraestrutura de nível empresarial para cargas de trabalho RFT em larga escala com clusters baseados em Kubernetes persistentes otimizados para treinamento distribuído. Essa camada constrói sobre todos os recursos disponíveis em SageMaker Training Jobs em escala muito maior, com recursos de computação dedicados e configurações de rede especializadas. Para mais informações, veja avaliação baseada em RFT.

Nova Forge

O Nova Forge fornece capacidades avançadas de treinamento de feedback por reforço projetadas para equipes de pesquisa em IA e praticantes construindo aplicações agentic sofisticadas. Ao se libertar de restrições de interação de turno único e timeouts de Lambda, o Nova Forge habilita fluxos de trabalho complexos multi-turno com ambientes personalizados rodando em sua própria VPC. Essa arquitetura oferece controle completo sobre geração de trajetória, funções de recompensa e interação direta com capacidades de servidores de treinamento e inferência — essencial para aplicações de IA de ponta que os tiers RFT padrão não conseguem suportar.

Abordagem sistemática para RFT

O refinamento com aprendizado por reforço melhora progressivamente modelos pré-treinados através de iterações de aprendizado estruturadas baseadas em recompensa. Antes de iniciar RFT, avalie se seu modelo apresenta desempenho em nível minimamente aceitável. RFT requer que o modelo consiga produzir pelo menos uma solução correta entre várias tentativas durante o treinamento. Se todos os rollouts (gerações) falham consistentemente, o modelo não tem sinal positivo para aprender, tornando RFT ineficaz. Nesses casos, você deve primeiro usar refinamento supervisionado (SFT) para estabelecer capacidades básicas antes de tentar RFT.

Após validar a linha de base, identifique o dataset correto e a função de recompensa. Selecione ou crie um dataset de prompts representando os cenários que seu modelo encontrará em produção. Monitore continuamente as métricas de treinamento e rollouts de modelo ao longo do processo. O RFT é um processo iterativo — use insights de cada execução para refinar sua função de recompensa, expandir seu conjunto de prompts ou ajustar hiperparâmetros.

Caso prático: Otimização do benchmark FinQA com RFT

Neste caso prático, você caminha através de um exemplo usando FinQA, um benchmark de análise financeira, com 1000 amostras do dataset público FinQA. Os dados devem ser preparados no formato compatível com o esquema RFT, seguindo o formato conversacional OpenAI. Cada exemplo de treinamento é um objeto JSON contendo campos obrigatórios como mensagens e reference_answer, além de campos opcionais como id e custom metadata.

A função de recompensa é o componente central que avalia respostas do modelo e fornece sinais de feedback para treinamento. Ela deve ser implementada como uma função AWS Lambda que aceita respostas do modelo e retorna pontuações de recompensa. As melhores práticas incluem começar pequeno com 100-200 exemplos e poucos epochs, fazer baseline com SFT primeiro se as pontuações de recompensa forem consistentemente baixas, e desenhar funções de recompensa eficientes que executem em segundos.

Uma vez que você tem dados preparados, lance RFT usando SageMaker Training Jobs. Os dois inputs chave são o dataset de entrada e o ARN da função Lambda de recompensa. Durante o monitoramento dos trabalhos iniciados, você pode acompanhar o progresso em logs do Amazon CloudWatch para SageMaker Training Jobs observando as métricas específicas de RFT. Métricas importantes incluem distribuição de recompensas do crítico (indicando como a forma das recompensas se parece e se as recompensas estão em trajetória de aumento gradual) e métricas de comportamento exploratório do modelo (ajudando você a entender a natureza exploratória do modelo).

RFT versus refinamento supervisionado: quando usar cada um

O refinamento supervisionado (SFT) funciona melhor para tarefas bem definidas com outputs claros desejados — fornece conhecimento factual direto e é ideal quando você tem pares prompt-resposta de alta qualidade. Sua força está em fornecer estruturas de output consistentes e específicas, mas requer exemplos explicitamente rotulados e pode se debater em tarefas envolvendo soluções ambíguas ou múltiplas válidas.

O RFT é mais adequado para cenários onde uma função de recompensa pode ser definida, mesmo que exista apenas uma solução válida. Seus pontos fortes incluem otimização de tarefas complexas de raciocínio, geração eficiente de dados de treinamento reduzindo a necessidade por muitos exemplos rotulados manualmente, e permitir balanceamento de objetivos concorrentes. Sua limitação principal é que requer que o modelo produza pelo menos uma solução correta entre várias tentativas — se o modelo falha consistentemente em gerar soluções corretas, RFT sozinho não será eficaz.

Conclusão

Com RFT você pode realizar personalização de modelo através de aprendizado baseado em avaliação, requerendo apenas prompts e critérios de qualidade em vez de datasets massivos rotulados. Para implementação totalmente gerenciada, comece com Amazon Bedrock. Se precisar de controle mais flexível, mude para SageMaker Training Jobs. Para cargas de trabalho em escala empresarial, o SageMaker HyperPod fornece a infraestrutura necessária. Alternativamente, explore o Nova Forge para aplicações agentic multi-turno com ambientes de aprendizado por reforço customizados.

Fonte

Reinforcement fine-tuning for Amazon Nova: Teaching AI through feedback (https://aws.amazon.com/blogs/machine-learning/reinforcement-fine-tuning-for-amazon-nova-teaching-ai-through-feedback/)

O Desafio da Inferência em Grande Escala

O deployment de grandes modelos de linguagem (LLMs) enfrenta um desafio crescente de custo e desempenho impulsionado pelo aumento do número de tokens processados. O contagem de tokens, que está diretamente relacionada à quantidade de palavras, tamanho de imagens e outros fatores de entrada, determina tanto os requisitos computacionais quanto os custos operacionais. Contextos mais longos traduzem-se em despesas maiores por requisição de inferência.

Esse desafio intensificou-se conforme os modelos de ponta passaram a suportar até 10 milhões de tokens para acomodar demandas crescentes de contexto provenientes de sistemas de Geração Aumentada por Recuperação (RAG – Retrieval Augmented Generation) e agentes de código que necessitam acessar extensas bases de código e documentação.

Contudo, pesquisas do setor revelam que uma parcela significativa dos tokens processados em cargas de trabalho de inferência é repetitiva. Os mesmos documentos e trechos de texto aparecem frequentemente em múltiplos prompts. Essas “zonas quentes” de dados representam uma oportunidade clara. Ao cachear conteúdo frequentemente reutilizado, as organizações podem alcançar reduções de custos e melhorias de desempenho em suas cargas de trabalho de inferência com contexto longo.

Atualizações do Contêiner LMI

A AWS lançou recentemente atualizações significativas no contêiner de Inferência de Grandes Modelos (LMI – Large Model Inference), entregando melhorias abrangentes de desempenho, suporte expandido para modelos e capacidades simplificadas de deployment para clientes que hospedam LLMs na AWS. Essas liberações focam em reduzir a complexidade operacional enquanto entregam ganhos mensuráveis de desempenho em arquiteturas de modelo populares.

Suporte a LMCache: Transformando Inferência de Contexto Longo

Uma das capacidades mais significativas introduzidas nas versões mais recentes do LMI é o suporte abrangente a LMCache. O LMCache é uma solução de código aberto para cachear chaves-valores (KV caching) que extrai e armazena caches KV gerados por motores LLM modernos, compartilhando esses caches entre motores e consultas para melhorar o desempenho da inferência.

Diferentemente de sistemas tradicionais que apenas cacheiam prefixos, o LMCache reutiliza caches KV de texto repetido — não necessariamente apenas prefixos — dentro de uma instância de motor de atendimento. O sistema funciona no nível de fragmentos, identificando trechos de texto repetidos comumente em documentos ou conversas e armazenando seu cache KV pré-computado.

Essa abordagem permite armazenamento em múltiplas camadas abrangendo memória GPU, memória CPU e backends em disco ou remotos, com cacheing inteligente que mantém um índice interno mapeando sequências de tokens para entradas KV cacheadas. As versões mais recentes do LMI introduzem configuração automática de LMCache, simplificando o deployment e otimização do cache KV. Essa interface de baixo código/sem código (LCNC – Low-Code No-Code) ajuda clientes a habilitarem esse recurso de desempenho avançado sem configurações manuais complexas.

Ao descarregar cache KV da memória GPU para RAM CPU ou armazenamento NVMe, o LMCache permite lidar eficientemente com cenários de contexto longo enquanto entrega melhorias de latência. Ao implementar roteamento aderente baseado em sessão no Amazon SageMaker AI, as organizações maximizam as taxas de acerto do cache, garantindo que requisições da mesma sessão sejam roteadas consistentemente para instâncias com conteúdo relevante cacheado.

Benchmarks de Desempenho do LMCache

Testes abrangentes em vários tamanhos de modelo e comprimentos de contexto revelam melhorias de desempenho que transformam a experiência para cargas de trabalho de inferência com contexto longo. A metodologia de teste adaptou o benchmark LMCache Long Doc QA para funcionar com o contêiner LMI, consistindo em três rodadas: pré-aquecimento para inicialização de início frio, uma rodada de aquecimento para popular armazenamento LMCache, e uma rodada de consulta para medir desempenho ao recuperar do cache.

Os benchmarks foram realizados em instâncias p4de.24xlarge (8× GPUs A100, 1,1 TB RAM, SSD NVMe) usando modelos Qwen com 46 documentos de 10.000 tokens cada (460.000 tokens totais) e 4 requisições concorrentes.

Para cargas de trabalho com contexto repetido, o LMCache alcança Tempo até Primeiro Token (TTFT – Time to First Token) mais rápido ao processar contextos de múltiplos milhões de tokens:

• Offloading de CPU: Entrega melhorias de desempenho com aceleração de 2,18x em latência total de requisição (52,978s → 24,274s) e TTFT 2,65x mais rápido (1,161s → 0,438s).
• Armazenamento NVMe com O_DIRECT habilitado: Aproxima-se do desempenho de CPU (0,741s TTFT) enquanto suporta capacidade de cacheing em escala TB, alcançando aceleração de 1,84x em latência total de requisição e TTFT 1,57x mais rápido.

Esses resultados demonstram redução de 62% em TTFT e redução de 54% em latência de requisição, alinhando-se estritamente com benchmarks publicados de LMCache. Essas reduções de latência traduzem-se diretamente em economia de custos, pois a redução de 54% no tempo de processamento de requisição permite que a mesma infraestrutura processe mais do dobro do volume de requisições, efetivamente reduzindo à metade os custos de computação por requisição.

As características de desempenho variam significativamente por tamanho de modelo devido a diferenças nos requisitos de memória de cache KV por token. Modelos maiores requerem substancialmente mais memória por token (Qwen2.5-1.5B: 28 KB/token, Qwen2.5-7B: 56 KB/token, Qwen2.5-72B: 320 KB/token), significando que esgotam a capacidade de cache KV da GPU em comprimentos de contexto muito mais curtos. O Qwen 2.5-1.5B consegue armazenar cache KV para até 2,6M tokens em memória GPU, enquanto Qwen 2.5-72B atinge seu limite em 480K tokens. Isso significa que o LMCache entrega valor em contextos mais curtos para modelos maiores. Um modelo de 72B pode se beneficiar de offloading de CPU começando em torno de 500K tokens com acelerações de 4-6x, enquanto modelos menores apenas requerem offloading em comprimentos de contexto extremos além de 2,5M tokens.

Configurando LMCache

Métodos de Configuração

Existem dois métodos principais para configurar LMCache conforme definido na documentação do GitHub. O primeiro é uma abordagem de configuração manual, e o segundo é uma configuração automatizada disponível em novas versões do LMI.

Configuração Manual

Para configuração manual, clientes criam sua própria configuração LMCache e a especificam em propriedades, arquivos ou variáveis de ambiente:

option.lmcache_config_file=/path/to/your/lmcache_config.yaml# OROPTION_LMCACHE_CONFIG_FILE=/path/to/your/lmcache_config.yaml

Essa abordagem oferece aos clientes controle sobre configurações de LMCache, permitindo customização de backends de armazenamento de cache, tamanhos de fragmentos e outros parâmetros avançados de acordo com seus requisitos específicos.

Configuração Automática

Para deployments simplificados, clientes podem habilitar configuração automática de LMCache similarmente:

option.lmcache_auto_config=True# OROPTION_LMCACHE_AUTO_CONFIG=True

A auto-configuração gera automaticamente uma configuração LMCache baseada no espaço disponível de CPU/disco na máquina host. Essa opção de deployment apenas suporta deployments com Tensor Parallelism, assume que /tmp está montado em armazenamento NVMe para cacheing baseado em disco, e requer maxWorkers=1. Essas configurações são assumidas com auto-configuração, que é projetada para servir um modelo único por instância de contêiner. Para servir múltiplos modelos ou cópias de modelo, clientes devem usar componentes de inferência do Amazon SageMaker AI, que facilitam isolamento de recursos entre modelos e cópias de modelo.

O recurso de configuração automática simplifica o deployment de cache KV ao eliminar a necessidade de arquivos de configuração YAML manual, permitindo que clientes comecem rapidamente com otimização LMCache.

Recomendações de Deployment

Baseado em resultados abrangentes de benchmarking e experiência de deployment, várias recomendações emergem para deployment optimal de LMI:

• Configure offloading de CPU quando RAM da instância permitir, entregando desempenho optimal para a maioria das cargas de trabalho
• Use NVMe com O_DIRECT habilitado para cargas de trabalho que requerem capacidade de cache além da RAM disponível
• Implemente roteamento aderente baseado em sessão no SageMaker AI para maximizar taxas de acerto do cache e facilitar desempenho consistente
• Considere a arquitetura do modelo ao configurar thresholds de offloading, pois modelos com diferentes configurações de cabeça KV terão configurações optimal diferentes
• Use configuração automática de LMCache para simplificar deployment e reduzir complexidade operacional

Decodificação Especulativa EAGLE

As versões mais recentes do LMI entregam melhorias de desempenho através de suporte para técnicas de decodificação especulativa EAGLE (Extrapolation Algorithm for Greater Language-model Efficiency – Algoritmo de Extrapolação para Maior Eficiência em Modelos de Linguagem). O EAGLE acelera a decodificação de grandes modelos de linguagem ao prever tokens futuros diretamente das camadas ocultas do modelo. Essa abordagem gera tokens rascunho que o modelo primário valida em paralelo, ajudando a reduzir a latência geral de geração enquanto mantém a qualidade da saída.

Configurar decodificação especulativa EAGLE é simples, requerendo apenas a especificação do caminho do modelo rascunho e número de tokens especulativos em sua configuração de deployment. Isso permite que organizações alcançem melhor desempenho para cargas de trabalho de hosting de LLM com benefícios para deployments de produção de alta concorrência e modelos focados em raciocínio.

Suporte Expandido a Modelos e Capacidades Multimodais

As versões mais recentes do LMI entregam suporte abrangente para modelos de código aberto de ponta, incluindo DeepSeek v3.2, Mistral Large 3, Ministral 3 e a série Qwen3-VL. Otimizações de desempenho melhoram tanto throughput quanto Tempo até Primeiro Token (TTFT) para servicing de modelos em larga escala através dessas arquiteturas.

Capacidades multimodais expandidas incluem suporte a FlashAttention ViT, agora servindo como o backend padrão para modelos visão-linguagem. Melhorias de decodificação especulativa EAGLE trazem suporte multi-etapa de gráfico CUDA e suporte multimodal com Qwen3-VL, permitindo inferência mais rápida para cargas de trabalho visão-linguagem. Com essas potencializações, organizações conseguem fazer deployment e escalar modelos foundation (FMs) mais rápido e eficientemente, ajudando a reduzir o tempo para produção enquanto diminuem a complexidade operacional.

Melhorias no Hosting de Adaptadores LoRA

As versões mais recentes do LMI trazem potencializações notáveis para hosting de múltiplos adaptadores LoRA no SageMaker AI. Adaptadores LoRA agora são carregados “preguiçosamente” (lazy loaded) — ao criar um componente de inferência, o componente do adaptador torna-se disponível quase imediatamente, mas o carregamento atual dos pesos do adaptador e registro com o motor de inferência ocorre na primeira invocação. Essa abordagem ajuda a reduzir tempo de deployment enquanto mantém flexibilidade para cenários multi-tenant.

Scripts de pré-processamento de entrada e pós-processamento de saída personalizados agora são suportados tanto para modelos base quanto adaptadores, com cada componente de inferência hosting adaptadores LoRA podendo ter scripts diferentes. Isso permite lógica de formatação específica do adaptador sem modificar código de inferência central, suportando deployments multi-tenant onde diferentes adaptadores aplicam regras de formatação distintas ao mesmo modelo subjacente.

Formatadores de saída personalizados proporcionam um mecanismo flexível para transformar respostas do modelo antes de serem retornadas para clientes, permitindo que organizações padronizem formatos de saída, adicionem metadados customizados ou implementem lógica de formatação específica do adaptador. Esses formatadores podem ser definidos no nível do modelo base para aplicar aos responses por padrão, ou no nível do adaptador para sobrescrever comportamento do modelo base para adaptadores LoRA.

Casos de uso comuns incluem adicionar timestamps de processamento e metadados personalizados, transformar texto gerado com prefixos ou formatação, calcular e injetar métricas customizadas, implementar esquemas de saída específicos do adaptador para diferentes aplicações cliente, e padronizar formatos de resposta entre deployments de modelo heterogêneos.

Próximos Passos

As versões mais recentes do LMI representam passos significativos adiante em capacidades de inferência de grandes modelos. Organizações podem fazer deployment de LLMs de ponta com maior desempenho e flexibilidade através de:

• Suporte abrangente a LMCache nas releases
• Decodificação especulativa EAGLE para inferência acelerada
• Suporte expandido a modelos incluindo capacidades multimodais de ponta
• Hosting melhorado de adaptadores LoRA

As opções configuráveis do contêiner proporcionam flexibilidade para fine-tune de deployments de acordo com necessidades específicas, seja otimizando para latência, throughput ou custo. Com as capacidades abrangentes de sistema do Amazon SageMaker AI, organizações podem focar em entregar soluções alimentadas por IA que ajudem a impulsionar valor para o negócio em vez de gerenciar infraestrutura.

Explore essas capacidades hoje ao fazer deployment de seus modelos de IA generativa na AWS e aproveite as melhorias de desempenho e experiência simplificada de deployment para ajudar a acelerar suas cargas de trabalho em produção.

Fonte

Large model inference container – latest capabilities and performance enhancements (https://aws.amazon.com/blogs/machine-learning/large-model-inference-container-latest-capabilities-and-performance-enhancements/)

O Desafio da Subutilização de GPU com Múltiplos Modelos

Organizações que executam vários modelos de inteligência artificial customizados enfrentam um problema prático: quando modelos individuais não recebem tráfego suficiente para saturar um endpoint dedicado, há desperdício significativo de capacidade de GPU. Modelos recentes da família de Mistura de Especialistas (Mixture of Experts — MoE) amplificam esse desafio.

A AWS, em parceria com a comunidade vLLM, desenvolveu uma abordagem eficiente para servir múltiplos modelos adaptados usando Multi-Low-Rank Adaptation (Multi-LoRA), resolvendo o problema de subutilização. A solução permite que, por exemplo, cinco clientes utilizando apenas 10% de uma GPU dedicada sejam servidos a partir de uma única GPU compartilhada.

Como Funciona a Multi-LoRA para Modelos de Mistura de Especialistas

Entendendo os Modelos MoE

Modelos de Mistura de Especialistas contêm múltiplas redes neurais especializadas chamadas especialistas. Um roteador direciona cada token de entrada para os especialistas mais relevantes, cujas saídas são então agregadas. Essa arquitetura esparsa permite processar modelos maiores com menos recursos computacionais, pois apenas uma fração dos parâmetros totais é ativada por token.

Cada especialista é uma pequena rede de propagação direta que processa o estado oculto de um token em dois estágios. Primeiro, a projeção gate_up expande o estado oculto compacto (por exemplo, 4.096 dimensões) em um espaço intermediário maior (por exemplo, 11.008 dimensões). Essa expansão é necessária porque as características no espaço compacto estão fortemente interligadas — o espaço maior oferece lugar para separar, transformar e seletivamente ativar quais características importam. Em seguida, a projeção down comprime o resultado de volta à dimensão original, mantendo compatibilidade com o resto do modelo.

O Papel da Multi-LoRA

Multi-LoRA é uma abordagem popular para adaptar modelos sem retreinar pesos inteiros. Em vez disso, mantém os pesos originais congelados e injeta pequenos adaptadores treináveis nas camadas do modelo. No tempo de inferência, múltiplos modelos customizados compartilham a mesma GPU, com apenas os adaptadores sendo alternados por requisição.

Para uma projeção com pesos base W de dimensão h_in × h_out, LoRA treina duas matrizes pequenas: A com dimensão h_in × r e B com dimensão r × h_out, onde r é o rank LoRA (tipicamente 16-64). A saída adaptada torna-se y = xW + xAB. Cada adaptador LoRA adiciona duas operações a uma projeção: a operação de redução computa z=xA, reduzindo a entrada de h_in dimensões para r dimensões, e a operação de expansão projeta o resultado de r dimensões de volta para h_out dimensões multiplicando z por B.

Em uma configuração de Multi-LoRA servindo múltiplos adaptadores simultaneamente para diferentes usuários ou tarefas, o sistema deve gerenciar eficientemente essas quatro operações por especialista, por adaptador, por requisição — um gargalo chave de performance para modelos MoE.

Implementação Técnica no vLLM

A AWS utilizava a comunidade vLLM para criar um novo kernel chamado fused_moe_lora que integra operações LoRA ao kernel fused_moe existente. Este novo kernel realiza GEMMs (Multiplicações Gerais de Matrizes) de redução e expansão LoRA para as projeções gate_up e down.

Dois desafios técnicos demandaram soluções especializadas: vLLM não possuía um kernel para realizar LoRA em camadas MoE, pois os kernels Multi-LoRA densos existentes não gerenciam roteamento de especialistas. Além disso, MoE LoRA combina duas fontes de esparsidade — roteamento de especialistas e seleção de adaptadores — exigindo design de kernel especializado.

Com essa implementação inicial, foi possível executar Multi-LoRA com o modelo GPT-OSS 20B em uma GPU H200, alcançando 26 OTPS (Tokens de Saída Por Segundo) e 1.053 ms TTFT (Tempo Até o Primeiro Token) no dataset Sonnet com comprimento de entrada 1.600, comprimento de saída 600 e concorrência de 16.

Otimizações de Performance do vLLM

Otimizações em Nível de Execução

Análises de performance inicial revelaram que TTFT estava 10x pior que o modelo base. Usando ferramentas de profiling, identificou-se que o compilador Triton tratava variáveis dependentes do comprimento de entrada como constantes de tempo de compilação, causando recompilação do kernel fused_moe_lora a partir do zero para cada novo comprimento de contexto em vez de reutilizar uma versão em cache. Isso foi resolvido adicionando uma dica de compilador do_not_specialize, instruindo Triton a compilar o kernel uma vez e reutilizá-lo em todos os comprimentos de contexto.

O profiling também revelou que o kernel fused_moe_lora era lançado com a mesma sobrecarga elevada independentemente de a requisição usar apenas o modelo base, adaptadores somente de atenção ou adaptadores LoRA completos. Adicionou-se lógica de saída antecipada para pular o kernel fused_moe_lora em camadas sem adaptadores LoRA, evitando execução desnecessária.

Os kernels de redução e expansão executavam sequencialmente, criando gaps entre execuções. Implementou-se Programmatic Dependent Launch (PDL) para permitir que o kernel dependente comece a lançar antes do kernel primário terminar. Isso permite que o kernel de expansão pré-carregue pesos em memória compartilhada e cache L2 enquanto o kernel de redução executa.

Adicionou-se também suporte para decodificação especulativa com CudaGraph para LoRA, corrigindo um problema onde o vLLM capturava CudaGraphs diferentes para modelo base e adaptador. CudaGraphs são importantes para eficiência pois capturam sequências de operações GPU, reduzindo sobrecarga de kernel.

Com essas otimizações de execução, OTPS melhorou para 50/100 sem/com decodificação especulativa e TTFT melhorou para 150 ms para GPT-OSS 20B.

Otimizações em Nível de Kernel

Split-K é uma estratégia de decomposição de trabalho que melhora balanceamento de carga para matrizes estreitas. Redução LoRA computa xA onde x tem dimensão 1×h_in e A tem dimensão h_in×r. Cada um dos r elementos de saída requer somar h_in multiplicações. Kernels GEMM padrão atribuem diferentes grupos de threads a diferentes elementos de saída, mas cada grupo calcula sua soma sequencialmente. Com r na dezena e h_in na casa dos milhares, há poucos elementos de saída para paralelizar enquanto cada um requer uma longa soma sequencial. Split-K resolve isso dividindo a soma sobre a dimensão interna K de um GEMM entre múltiplos grupos de threads, que calculam somas parciais em paralelo e combinam resultados.

Cooperative Thread Array (CTA) swizzling reordena o agendamento para que grupos de threads trabalhando em colunas próximas executem simultaneamente, aumentando reutilização de cache L2. Esta técnica foi aplicada à operação de redução LoRA.

Removeu-se mascaramento desnecessário e operações de produto escalar dos kernels LoRA de redução e expansão. Kernels Triton carregam dados em blocos de tamanho fixo, mas dimensões de matrizes podem não se dividir uniformemente nesses tamanhos de bloco. Mascaramento previne acessos ilegais à memória, mas essas verificações condicionais executam em cada operação de carregamento, adicionando sobrecarga. Introduziu-se um parâmetro EVEN_K que verifica se K se divide uniformemente por BLOCK_SIZE_K — quando verdadeiro, carregamentos são válidos e mascaramento pode ser completamente ignorado.

Por fim, fundiu-se a adição dos pesos LoRA aos pesos do modelo base no kernel de expansão LoRA, reduzindo sobrecarga de lançamento de kernel. Essas otimizações de kernel alcançaram 144 OTPS e 135 ms TTFT para GPT-OSS 20B.

Ajuste de Configurações para Amazon SageMaker AI e Amazon Bedrock

Kernels Triton requerem ajuste de parâmetros como tamanhos de bloco (BLOCK_SIZE_M, BLOCK_SIZE_N, BLOCK_SIZE_K) que controlam como a computação de matriz se divide entre grupos de threads. Parâmetros avançados incluem GROUP_SIZE_M, que controla ordem de grupos de threads para localidade de cache, e SPLIT_K, que paraleliza somas sobre a dimensão de matriz interna.

Descobriu-se que os kernels MoE LoRA usando configurações padrão otimizadas para MoE fundido padrão tinham performance ruim para serviço Multi-LoRA. Os padrões não contabilizavam a dimensão de grade adicional correspondente ao índice LoRA e a esparsidade composta de múltiplos adaptadores.

Adicionou-se suporte para usuários carregarem configurações ajustadas customizadas fornecendo um caminho de pasta. Clientes da AWS SageMaker AI e Bedrock agora têm acesso a essas configurações ajustadas, carregadas automaticamente e alcançando 171 OTPS e 124 ms TTFT para GPT-OSS 20B — melhorias subsequentes em relação às 144 OTPS e 135 ms TTFT da versão anterior.

Resultados e Impacto

Através da colaboração com a comunidade vLLM, a AWS implementou e disponibilizou em código aberto Multi-LoRA serving para modelos MoE incluindo GPT-OSS, Qwen3 MoE, DeepSeek, e Llama MoE. As otimizações resultaram em melhorias impressionantes: 454% de aumento em OTPS e 87% de redução em TTFT para GPT-OSS 20B comparando vLLM 0.15.0 versus vLLM 0.11.1rc3.

Algumas otimizações, particularmente ajuste de kernel e CTA swizzling, também melhoraram performance para modelos densos — OTPS do Qwen3 32B melhorou 99%.

Para aproveitar este trabalho em deployments locais, utilize vLLM 0.15.0 ou versões posteriores. Otimizações específicas da AWS, disponíveis no Amazon SageMaker AI e Amazon Bedrock, entregam melhorias adicionais de latência em modelos, por exemplo 19% mais rápido em OTPS e 8% melhor em TTFT versus vLLM 0.15.0 para GPT-OSS 20B.

Como Começar

Para começar com hosting de modelos customizados na AWS, consulte a documentação de Amazon SageMaker AI hosting e Amazon Bedrock.

O repositório vLLM contém as implementações e pode ser explorado para entender melhor as otimizações técnicas por trás dessas melhorias de performance.

Fonte

Efficiently serve dozens of fine-tuned models with vLLM on Amazon SageMaker AI and Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/efficiently-serve-dozens-of-fine-tuned-models-with-vllm-on-amazon-sagemaker-ai-and-amazon-bedrock/)

O Desafio de Assistentes para Eventos em Escala

Grandes conferências e eventos geram volumes esmagadores de informações. Centenas de sessões, workshops, perfis de palestrantes, mapas de locais e cronogramas em constante atualização criam uma experiência complexa para os participantes. Embora assistentes de IA básicos consigam responder perguntas simples sobre logística, a maioria não oferece a orientação personalizada e consciência contextual que os participantes realmente necessitam para navegar efetivamente em conferências de múltiplos dias.

O verdadeiro desafio, porém, não está apenas em prototipar essas soluções. Transformar uma prova de conceito em um sistema production-ready — com segurança corporativa, escalabilidade para milhares de usuários simultâneos e desempenho confiável — tipicamente exige meses de desenvolvimento infraestrutural. É neste cenário que a AWS apresenta uma abordagem integrada usando os componentes do Amazon Bedrock AgentCore.

Arquitetura da Solução

A proposta da AWS combina três pilares técnicos fundamentais para construir um assistente de eventos production-ready:

• Amazon Bedrock AgentCore Memory: mantém contexto de conversa e preferências de longo prazo sem necessidade de soluções de armazenamento customizadas
• Amazon Bedrock AgentCore Identity: fornece autenticação segura multi-IDP (Provedor de Identidade)
• Amazon Bedrock AgentCore Runtime: oferece escalabilidade serverless com isolamento de sessão
• Amazon Bedrock Knowledge Bases: gerencia recuperação aumentada de dados de eventos (RAG)

Juntos, esses componentes permitem implantar um assistente que cresce em utilidade a cada interação — funcionando como um guia proativo que garante aos participantes descobrir suas sessões mais valiosas. O sistema consegue servir milhares de participantes simultâneos com segurança e confiabilidade de nível corporativo, sem exigir gerenciamento de infraestrutura.

Como a Solução Funciona

Autenticação e Recuperação de Identidade

O usuário efetua login na aplicação utilizando Amazon Cognito — embora AgentCore Identity também suporte outros provedores como Okta, Auth0 e IDPs compatíveis com OIDC. Ao autenticar com sucesso, o Cognito gera um bearer token contendo informações do usuário, que será utilizado ao longo de todo o fluxo para autenticação e recuperação de dados específicos do usuário.

Invocação e Inicialização do Agente

Quando o usuário interage com a aplicação e submete uma consulta, a aplicação invoca o Amazon Bedrock AgentCore Runtime com três parâmetros-chave: a consulta do usuário, um ID de sessão (por exemplo, SessionA) e o bearer token do Cognito. Isso estabelece uma ligação entre as interações e tanto o usuário quanto sua sessão atual.

O AgentCore Identity autentica e autoriza o usuário antes de permitir acesso ao agente. Na primeira interação, o Strands Agent é inicializado dentro do Runtime e recupera quaisquer preferências de usuário disponíveis no armazenamento de longo prazo do Amazon Bedrock AgentCore Memory, preparando-se com contexto personalizado. Para interações subsequentes na mesma sessão, o agente continua a conversa usando o contexto já estabelecido.

Processamento de Mensagens

O agente armazena tanto mensagens do usuário quanto do assistente no armazenamento de curto prazo do Memory, contendo tanto o actor_id quanto o session_id. O actor_id é a declaração de identificador do sujeito (sub) extraída do bearer token do Cognito. O contexto da conversa permanece privado e disponível apenas para o usuário específico dentro de sua sessão atual.

Nos bastidores, o Memory emprega um pipeline de transformação que processa automaticamente esses eventos de conversa através de estratégias de memória configuradas. Cada estratégia utiliza reconhecimento de padrões e compreensão de linguagem natural para analisar os dados brutos da conversa, identificando tipos específicos de informação valiosa — como preferências do usuário — e extraindo insights significativos que merecem retenção de longo prazo. O sistema então estrutura essa informação extraída em registros de memória padronizados, marca-os com metadados relevantes e os armazena em namespaces dedicados dentro da memória de longo prazo, permitindo que o agente construa uma compreensão cada vez mais refinada dos usuários através de múltiplas sessões.

Recuperação de Conhecimento e Memória

Para cumprir a solicitação do usuário, o agente pode ativar ferramentas especializadas. Pode invocar uma base de conhecimento do Bedrock para recuperar detalhes de eventos atualizados, como descrições de sessões, cronogramas ou biografias de palestrantes.

Geração de Resposta

O agente processa a consulta enriquecida com três camadas de contexto: insights da memória de longo prazo (histórico personalizado do participante), contexto da memória de curto prazo (mensagens recentes na sessão) e dados atuais de eventos da base de conhecimento. Com isso, gera uma resposta contextualizada e personalizada.

Essa arquitetura transforma uma consulta simples como “Quais sessões devo assistir amanhã?” em uma experiência personalizada — o agente relembra os tópicos que o usuário gostou ontem, considera a conversa atual e responde com recomendações específicas alinhadas aos interesses e histórico do usuário.

Componentes da Solução

O Agente: Runtime e Integração de Identidade

No coração da solução está o Amazon Bedrock AgentCore Runtime, um componente que fornece um ambiente seguro e serverless para hospedar o agente. O Runtime gerencia o ciclo de vida completo das interações do usuário através de sessões isoladas — cada uma executando em microVMs dedicadas com recursos separados de CPU, memória e sistema de arquivos. Esse isolamento de sessão garante que milhares de participantes da conferência possam interagir simultaneamente com instâncias personalizadas do agente sem contaminação de dados entre sessões.

Segurança e autenticação são tratadas através do Amazon Bedrock AgentCore Identity, que se integra perfeitamente com o Cognito (e outros provedores de identidade). Quando um participante envia uma consulta ao assistente de eventos, o Identity valida o bearer token do Cognito antes de permitir que a interação prossiga. O bearer token é propagado através de cabeçalhos, e o agente recupera esse token para chamar o servidor de descoberta do Cognito, extraindo o sub do usuário e outras informações relacionadas.

Neste caso de uso, o sub do usuário é utilizado como o actor_id para informações de sessão, permitindo que o agente mantenha contexto específico do usuário e entregue recomendações personalizadas. Essa consciência de identidade garante que as preferências, histórico de conversa e dados de sessão de cada participante permaneçam privados e seguros. Ao combinar a infraestrutura escalável do Runtime com a estrutura de autenticação do Identity, o assistente de eventos consegue servir conferências maciças de forma mais segura, enquanto entrega orientação consistentemente personalizada a cada participante individual.

Memória do Agente: Contexto que Evolui

O Amazon Bedrock AgentCore Memory fornece a consciência contextual crítica que transforma o assistente de eventos de uma simples ferramenta de perguntas e respostas em um guia verdadeiramente personalizado. O serviço é composto por memória de curto prazo e de longo prazo, que trabalham juntas para viabilizar relacionamentos contínuos e evoluindo entre participantes e o assistente.

Memória de curto prazo: capturando a conversa

É onde as interações começam. À medida que conversas se desenrolam, o agente armazena sincronamente cada troca de mensagens como um evento imutável na memória de curto prazo. Esses eventos são organizados hierarquicamente por actor_id e session_id. Lembre-se de que o actor_id é extraído do bearer token do Cognito (o sub do usuário), enquanto o session_id vem do identificador de sessão do Runtime.

Essa estrutura organizacional serve dois propósitos críticos. Primeiro, mantém a narrativa cronológica de cada conversa, preservando o fluxo natural do diálogo. Segundo, fornece isolamento preciso — a conversa do Ator A na Sessão A1 permanece separada da Sessão B ou de sessões de outros atores. Isso facilita privacidade e permite que o agente recupere exatamente o contexto de conversa correto sem carregar dados não relacionados. O agente consegue recuperar rapidamente mensagens recentes da memória de curto prazo para manter a continuidade da conversa. Quando um participante faz uma pergunta de acompanhamento como “Que horário é aquela sessão?”, o agente sabe qual sessão foi apenas discutida porque tem acesso imediato ao histórico de conversa.

Memória de longo prazo: construindo inteligência persistente

Enquanto a memória de curto prazo captura o que foi dito, a memória de longo prazo extrai o que importa. À medida que conversas ocorrem, o serviço AgentCore Memory processa automaticamente essas interações para identificar e armazenar insights significativos que persistem através de sessões. O agente de eventos utiliza uma estratégia de Preferências do Usuário para capturar preferências explícitas sobre formatos de sessão, tópicos ou estilos de apresentação. Por exemplo, “Prefere workshops práticos a palestras” ou “Interessado em serverless e machine learning”. Essas preferências são armazenadas em um namespace dedicado dentro da memória de longo prazo (por exemplo, /event-agent/actor-A/preferences), para organização clara e recuperação direcionada.

Orquestração entre Agente e Memória

A integração perfeita entre o Strands Agent e AgentCore Memory é suportada através de agent hooks — pontos de contato acionados por eventos que disparam automaticamente operações de memória ao longo do ciclo de vida do agente:

• O hook de evento Agent Initialized recupera preferências do usuário da memória de longo prazo quando uma sessão começa, carregando os interesses e tipos de sessão preferidos do participante para viabilizar recomendações personalizadas desde a primeira consulta
• Os hooks de evento Message Added capturam cada mensagem do usuário e do assistente, armazenando-as sincronamente na memória de curto prazo para manter o histórico de conversa

Embora AgentCore forneça um gerenciador de memória automatizado que implementa ferramentas de memória automaticamente, essa solução utiliza hooks para controle preciso sobre quando e como as operações de memória são invocadas — para otimização refinada do fluxo de trabalho específico do assistente de eventos. Além dessas operações automáticas, se não houver informação suficiente, o agente então utiliza a ferramenta Retrieve sessions data para consultar a base de conhecimento do Bedrock por detalhes de eventos atuais. Essa abordagem dual — pré-carregando contexto essencial no início e recuperando seletivamente detalhes sob demanda — entrega tanto velocidade quanto precisão sem inchar o contexto da sessão com informações desnecessárias.

Knowledge Bases: Gerenciando Volume de Dados

Enquanto AgentCore Memory mantém contexto personalizado e histórico de conversa, grandes conferências geram vastas quantidades de informação estruturada — centenas de detalhes de sessão, perfis de palestrantes, mapas de locais e atualizações de cronograma — que exigem organização e recuperação eficientes. Amazon Bedrock Knowledge Bases é um serviço totalmente gerenciado que suporta Geração Aumentada por Recuperação (RAG) ao conectar modelos de fundação aos seus dados.

Automaticamente, o serviço trata ingestão, processamento e indexação de documentos, convertendo-os em embeddings vetoriais armazenados em um banco de dados vetorial. Isso permite que agentes realizem buscas semânticas — recuperando informação baseada em significado e contexto em vez de correspondências exatas de palavras-chave.

A arquitetura implementa a base de conhecimento como uma ferramenta especializada dentro do framework Strands. Quando participantes fazem perguntas específicas sobre sessões, palestrantes ou logística de local, o agente invoca essa ferramenta para recuperar informação precisa e atualizada. A integração entre memória e base de conhecimento cria uma combinação poderosa. Quando um participante pergunta “Quais sessões de IA devo assistir?”, o agente recupera detalhes de sessão da base de conhecimento enquanto usa a memória para filtrar e priorizar recomendações com base nos interesses previamente expressos pelo participante. Isso facilita respostas que são tanto factualmente completas quanto pessoalmente relevantes, ajudando a transformar a complexidade esmagadora de grandes conferências em orientação gerenciável e personalizada.

Conclusão

A AWS demonstrou como utilizar os componentes do Amazon Bedrock AgentCore para rapidamente colocar em produção um assistente de eventos — levando-o de protótipo a implantação pronta para empresa em escala. Embora construir agentes conversacionais inteligentes seja alcançável com várias ferramentas, o verdadeiro desafio está na implantação em produção. O valor do Amazon Bedrock Knowledge Bases e Amazon Bedrock AgentCore está em fornecer serviços gerenciados que tratam autenticação, escalabilidade, gerenciamento de memória e capacidades de RAG prontas para uso — ajudando a remover meses de trabalho infraestrutural.

O resultado é um assistente de eventos que se lembra do interesse do participante em tecnologias serverless das conversas de ontem, compreende que preferem workshops práticos, e usa esse contexto para entregar recomendações relevantes do cronograma de amanhã — tudo mantendo o fluxo de conversa de uma sessão de planejamento em andamento. Essa é a diferença entre um protótipo que demonstra comportamento inteligente e um sistema production-ready que consegue oferecer experiências personalizadas a milhares de participantes de conferência simultâneos com segurança e confiabilidade corporativa.

Seja planejando um pequeno encontro corporativo ou uma conferência massiva de múltiplos dias, o Amazon Bedrock AgentCore fornece a infraestrutura gerenciada para implantar assistência inteligente em dias em vez de meses.

Próximos Passos

Para aprofundar essa solução, considere estas extensões:

• Expandir capacidades com AgentCore Gateway: o Amazon Bedrock AgentCore Gateway ajuda a conectar seu assistente de eventos a ferramentas e serviços adicionais em escala. Converta APIs existentes, funções Lambda ou serviços de terceiros em ferramentas que seu agente possa usar — seja integrando com sistemas de registro de eventos, conectando ao Slack para notificações de participantes ou vinculando ao Salesforce para rastreamento de leads
• Explorar o repositório de implementação: visite o repositório no GitHub com implementação completa, orientação passo a passo, código de exemplo e instruções de implantação para construir essa solução em sua própria conta AWS

Fonte

Building intelligent event agents using Amazon Bedrock AgentCore and Amazon Bedrock Knowledge Bases (https://aws.amazon.com/blogs/machine-learning/building-intelligent-event-agents-using-amazon-bedrock-agentcore-and-amazon-bedrock-knowledge-bases/)

O Desafio das Saídas Estruturadas em IA Generativa

A inteligência artificial generativa trouxe capacidades impressionantes de geração de texto, mas também criou um desafio crucial: como garantir que os resultados gerados por modelos de linguagem de grande escala (Modelos de Linguagem Grandes ou LLMs) sigam formatos específicos, predeterminados e validados? Esse conceito é chamado de saída estruturada.

Saídas estruturadas referem-se a respostas geradas por IA que obedecem a formatos predefinidos, com campos validados e frequentemente aplicam regras rigorosas de entrada. Isso pode incluir esquemas de dados específicos ou mapeamentos precisos de campos individuais. Para aplicações que dependem de consistência, validação e integração perfeita com sistemas posteriores, as saídas estruturadas são não-negociáveis.

Considere alguns exemplos reais: sistemas de aprovação de crédito bancário precisam gerar respostas em formato JSON com validação rigorosa de campos; sistemas de saúde precisam validar formatos de dados de pacientes e aplicar restrições de dosagem de medicamentos; sistemas de comércio eletrônico exigem geração padronizada de faturas para seus sistemas contábeis. Em cada um desses cenários, uma falha de formatação pode comprometer toda uma operação.

Este artigo explora como a CloudTroop observa a implementação do framework Outlines da Dottxt através da AWS Marketplace, funcionando dentro do Amazon SageMaker, como uma abordagem prática e confiável para implementar saídas estruturadas.

Entendendo Saídas Estruturadas: Casos de Uso e Valor de Negócio

Saídas estruturadas elevam a inteligência artificial generativa de um mecanismo ad hoc de geração de texto para uma infraestrutura de negócio confiável. Isso permite troca de dados precisa, decisões automatizadas e fluxos de trabalho que funcionam de ponta a ponta em ambientes de alto risco, onde integração é fundamental.

Ao impor esquemas e formatos previsíveis, as saídas estruturadas desbloqueiam casos de uso onde precisão, rastreabilidade e interoperabilidade são inegociáveis — desde relatórios financeiros e operações de saúde até logística de comércio eletrônico e automação de fluxos corporativos.

O que é Saída Estruturada?

Saída estruturada combina múltiplos tipos de requisitos para como os modelos devem produzir dados que sigam restrições específicas. Alguns exemplos desses mecanismos de restrição incluem:

• Restrições baseadas em esquema: JSON Schema e XML Schema definem estruturas de objetos com requisitos de tipo, campos obrigatórios, restrições de propriedades e hierarquias aninhadas. Os modelos geram saídas que correspondem exatamente a essas especificações, garantindo que campos como transaction_id (string), amount (float) e timestamp (datetime) estejam presentes e corretamente preenchidos.
• Restrições por enumeração: Expressões Enum restringem saídas a valores categóricos predefinidos. Tarefas de classificação usam enum para forçar modelos a selecionar entre opções fixas — como categorizar instrumentos musicais como Percussão, Cordas, Madeiras, Metais ou Teclados — removendo geração arbitrária de categorias.
• Restrições baseadas em padrão: Expressões regulares validam formatos específicos como endereços de email, números de telefone, datas ou identificadores customizados. Padrões regex garantem que saídas correspondam estruturas necessárias sem validação pós-processamento.
• Restrições baseadas em gramática: Gramáticas livres de contexto (CFGs) e notação EBNF definem regras sintáticas para gerar código, consultas SQL, arquivos de configuração ou linguagens específicas de domínio. Frameworks de decodificação com restrições aplicam essas regras durante a geração de tokens.
• Validação semântica: Além de restrições sintáticas, LLMs podem validar saídas contra critérios em linguagem natural — garantindo que o conteúdo seja profissional, apropriado para famílias ou construtivo — abordando requisitos subjetivos que validação baseada em regras não consegue capturar.

Onde Saídas Estruturadas Agregam Valor

Em arquiteturas modernas, modelos de IA se integram com processamento não-IA e sistemas de negócio. Essas integrações criam pontos críticos que exigem consistência, segurança de tipo e legibilidade por máquinas — ambiguidades de parsing ou desvios de formato quebrariam fluxos de trabalho inteiros.

Alguns padrões arquiteturais comuns onde a interoperabilidade entre LLMs e componentes de infraestrutura é crítica incluem:

• Integração com APIs e pipelines de dados: Processos de Extração, Transformação e Carga (ETL) e APIs REST exigem conformidade rigorosa de formato. Erros na saída do modelo podem criar falhas de parsing e comprometer inserção direta em banco de dados ou lógica de transformação perfeita.
• Chamada de ferramentas e execução de funções: Fluxos de trabalho de agentes dependem da capacidade do modelo LLM invocar funções com parâmetros corretamente tipados, permitindo automação multietapa onde cada agente consome entradas validadas.
• Extração de documentos e captura de dados: Parsing de faturas, contratos ou registros médicos exige que o modelo identifique semanticamente entidades desejadas e as retorne em formato que realmente automatize entrada de dados — extraindo nomes de fornecedores, valores e datas em esquemas predefinidos, incluindo opções de categorização específicas.
• Sistemas de decisão em tempo real: Sistemas que exigem decisões em menos de 50 milissegundos, como detecção de fraude e processamento de transações, não podem tolerar verbosidade ou retentativas na estrutura da saída. Produzir scores de risco confiáveis, flags de classificação e metadados de decisão significam que sistemas downstream conseguem consumir dados instantaneamente.

Aplicações de Negócio: Onde Saídas Estruturadas Criam Mais Valor

Em domínios de alto risco com exigências de integração, saídas estruturadas transformam modelos generativos de engines flexíveis de texto em infraestrutura de negócio confiável que entrega previsibilidade, auditabilidade e automação de ponta a ponta.

• Serviços Financeiros e Processamento de Transações: Em instituições financeiras, saídas estruturadas facilitam precisão e consistência em relatórios, auditoria e conformidade regulatória. Dados de transação, avaliações de risco e análises de portfólio devem aderir a esquemas predefinidos para suportar reconciliação em tempo real, revisões de Combate à Lavagem de Dinheiro (AML) e arquivos regulatórios. Saídas estruturadas permitem troca perfeita entre sistemas de pagamento, engines de risco e ferramentas de auditoria — reduzindo supervisão manual enquanto mantém rastreabilidade completa e integridade de dados em operações financeiras de alto risco.
• Saúde e Operações Clínicas: Conformidade regulatória exige validação rigorosa — verificação de intervalos para sinais vitais, dosagens de medicamentos e resultados de laboratório ajuda a prevenir erros críticos. Extração estruturada de documentos médicos permite codificação automatizada, precisão de faturamento e criação de auditoria para conformidade com HIPAA. Validação em tempo real de formato de dados em saúde salva vidas.
• Automação de Fluxo de Trabalho Corporativo: Sistemas legados exigem dados legíveis por máquina sem lógica de parsing customizada. Saídas estruturadas de interações de suporte ao cliente geram resumos de casos com scores de sentimento, itens de ação e metadados de roteamento que se integram diretamente em sistemas de Gestão de Relacionamento com Cliente (CRM).
• Comércio Eletrônico e Logística: Validação de endereço, verificação de pagamento e consistência de atributos de pedidos reduzem falhas de entrega e transações fraudulentas. Saídas estruturadas coordenam fluxos de trabalho multipartes onde transportadoras, armazéns e processadores de pagamento exigem formatos padronizados.
• Conformidade Regulatória e Prontidão de Auditoria: Indústrias enfrentando supervisão rigorosa se beneficiam de gerenciamento de conteúdo estruturado com trilhas de auditoria imutáveis. Repositórios em nível de componente rastreiam cada mudança com metadados (quem, quando, por quê, aprovador), permitindo que auditores verifiquem conformidade através de acesso direto ao sistema em vez de revisão manual de documentos.

Introduzindo Outlines da Dottxt na AWS

Saída estruturada pode ser alcançada de várias formas. A maioria dos frameworks focam, em essência, em validação — identificar se a saída obedece às regras e requisitos solicitados. Se a saída não está em conformidade, o framework solicita uma nova saída e continua iterando até que o modelo alcance a estrutura solicitada.

O Outlines oferece uma abordagem avançada chamada validação em tempo de geração, o que significa que a validação acontece enquanto o modelo está produzindo tokens — deslocando validação para mais cedo no processo de geração em vez de validar após conclusão. Embora não integrado com o Amazon Bedrock, entender Outlines fornece insights em técnicas de saída estruturada de ponta que informam estratégias de implementação híbrida.

Outlines, desenvolvido pela equipe da Dottxt, é uma biblioteca Python projetada para trazer estrutura determinística e confiabilidade para saídas de modelos de linguagem — abordando um desafio fundamental no deploy de LLMs para aplicações em produção. Diferente de geração livre, desenvolvedores conseguem usar Outlines para impor formatos e restrições rigorosos de saída durante geração, não apenas depois dos fatos. Essa abordagem torna possível usar LLMs para tarefas onde precisão, previsibilidade e integração com sistemas posteriores são necessárias.

Como o Outlines Funciona

Outlines aplica restrições através de três mecanismos principais:

• Compilação de gramática: Converte esquemas em máscaras de token que guiam as escolhas do modelo
• Árvores de prefixo: Poda caminhos inválidos durante busca em feixe para manter estrutura válida
• Controle de amostragem: Usa autômatos finitos para seleção válida de tokens durante geração

Durante geração, Outlines segue um fluxo de trabalho preciso:

1. O modelo de linguagem processa a sequência de entrada e produz logits de token
2. O processador de logits do Outlines define a probabilidade de tokens ilegais para 0%
3. Um token é amostrado apenas do conjunto de tokens legais de acordo com a estrutura definida
4. Esse processo se repete até que a geração esteja completa, garantindo que a saída esteja em conformidade com o formato necessário

Por exemplo, com um padrão como ^\d*(\.\d+)?$ para números decimais, Outlines converte isso em um autômato que apenas permite sequências numéricas válidas serem geradas. Se 748 foi gerado, o sistema sabe que os únicos tokens válidos seguintes são outro dígito, um ponto decimal ou o token de fim de sequência.

Benefícios de Performance

Aplicar saída estruturada durante geração oferece vantagens significativas para confiabilidade e performance em ambientes de produção:

• Overhead de inferência zero: A técnica de geração estruturada adiciona custo computacional praticamente nulo durante inferência
• Geração 5 vezes mais rápida: De acordo com a abordagem de coalescing do Dottxt Engineering, geração estruturada pode ser dramaticamente mais rápida que geração padrão
• Recursos computacionais reduzidos: Restrições simplificam tomada de decisão do modelo removendo caminhos inválidos, reduzindo requisitos gerais de processamento
• Precisão melhorada: Ao estreitar o espaço de saída, mesmo modelos base conseguem atingir precisão mais alta em tarefas estruturadas

Vantagens Comprovadas

A biblioteca Outlines demonstra benefícios mensuráveis:

• 2 vezes mais rápida que pipelines de validação baseados em regex
• 98% de aderência a esquema comparado com 76% para validação pós-geração
• Suporta restrições complexas como esquemas JSON recursivos

Primeiros Passos com Outlines

Outlines integra-se perfeitamente em fluxos de trabalho Python existentes. Um exemplo básico de definição de estrutura de dados:

from pydantic import BaseModel

# Define sua estrutura de dados
class Patient(BaseModel):
    id: int
    name: str
    diagnosis: str
    age: int

# Carrega modelo e cria gerador estruturado
model = models.transformers("microsoft/DialoGPT-medium")
generator = generate.json(model, Patient)

# Gera saída estruturada
prompt = "Create a patient record for John Smith, 45, with diabetes"
result = generator(prompt)

# Retorna instância Patient válida
print(result.name)  # "John Smith"
print(result.age)   # 45

Para esquemas mais complexos com enumerações e tipos avançados:

from enum import Enum

class Status(str, Enum):
    ACTIVE = "active"
    INACTIVE = "inactive"
    PENDING = "pending"

class User(BaseModel):
    username: str
    email: str
    status: Status
    created_at: datetime

# Gerador aplica valores enum e formato datetime
user_generator = generate.json(model, User)

Implementando Dotjson da Dottxt no Amazon SageMaker

É possível fazer deploy direto da solução Amazon SageMaker real-time inference da Dottxt para gerar saída estruturada, deploiando um dos modelos da Dottxt como DeepSeek-R1-Distill-Qwen-32B através da AWS Marketplace. O código abaixo assume que você já fez deploy de um endpoint em sua conta AWS. Um Jupyter Notebook que percorre o deploy do endpoint de ponta a ponta está disponível no repositório de produtos.

import json
import boto3

# Define isto com base no seu endpoint SageMaker
endpoint_name = "dotjson-with-DeepSeek-R1-Distill-Qwen-32B"
session = boto3.Session()

structured_data = {
    "patient_id": 12345,
    "first": "John",
    "last": "Adams",
    "appointment_date": "2025-01-27",
    "notes": "Patient presented with a headache and sore throat",
}

payload = {
    "messages": [
        {
            "role": "system",
            "content": "You are a helpful, honest, and concise assistant.",
        },
        {
            "role": "user",
            "content": f"Create a medical record from the following visit data: {structured_data}",
        },
    ],
    "response_format": {
        "type": "json_schema",
        "json_schema": {
            "name": "Medical Record",
            "schema": {
                "properties": {
                    "patient_id": {"title": "Patient Id", "type": "integer"},
                    "date": {"title": "Date", "type": "string", "format": "date-time"},
                    "diagnosis": {"title": "Diagnosis", "type": "string"},
                    "treatment": {"title": "Treatment", "type": "string"},
                },
                "required": ["patient_id", "diagnosis", "treatment"],
                "title": "MedicalRecord",
                "type": "object",
            },
        },
        "max_tokens": 1000,
    },
}

runtime = session.client("sagemaker-runtime")
response = runtime.invoke_endpoint(
    EndpointName=endpoint_name,
    ContentType="application/json",
    Accept="application/json",
    Body=json.dumps(payload).encode(),
)

body = json.loads(response["Body"].read().decode("utf-8"))

# Visualiza a saída estruturada produzida pelo modelo
msg = body["choices"][0]["message"]
content = msg["content"]
medical_record = json.loads(content)
medical_record

Essa abordagem híbrida remove a necessidade de retentativas comparado com validação após conclusão.

Alternativas para Saídas Estruturadas na AWS

Enquanto Outlines oferece consistência em tempo de geração, várias outras abordagens fornecem saídas estruturadas com diferentes compensações.

Alternativa 1: Estratégias de Saída Estruturada Baseadas em LLM

Ao usar a maioria dos LLMs modernos, como Amazon Nova, usuários conseguem definir esquemas de saída diretamente em prompts, suportando restrições de tipo, enumerações e templates estruturados dentro do ambiente AWS. O guia a seguir mostra diferentes padrões de prompt para Amazon Nova.

# Exemplo de saída estruturada Nova
import boto3
bedrock = boto3.client('bedrock-runtime')

response = bedrock.invoke_model(
    modelId='amazon.nova-pro-v1:0',
    body=json.dumps({
        "messages": [{"role": "user", "content": "Extract customer info from this text..."}],
        "inferenceConfig": {"maxTokens": 500},
        "toolConfig": {
            "tools": [{
                "toolSpec": {
                    "name": "extract_customer",
                    "inputSchema": {
                        "json": {
                            "type": "object",
                            "properties": {
                                "name": {"type": "string"},
                                "email": {"type": "string"},
                                "phone": {"type": "string"}
                            },
                            "required": ["name", "email"]
                        }
                    }
                }
            }]
        }
    })
)

Alternativa 2: Frameworks de Validação Pós-Geração

Frameworks de validação pós-geração de código aberto surgiram como camada crítica em sistemas modernos de IA generativa, fornecendo mecanismos estruturados e repetíveis para avaliar e governar saídas de modelos antes de serem consumidas por usuários ou aplicações downstream. Separando geração de validação, essas frameworks permitem equipes aplicar restrições de segurança, qualidade e política sem constantemente retreinar ou ajustar modelos base.

Language Models Query Language (LMQL) tem interface similar a SQL e fornece uma linguagem de query para LLMs, permitindo que desenvolvedores especifiquem restrições, requisitos de tipo e intervalos de valor diretamente em prompts. Particularmente eficaz para restrições múltipla-escolha e tipo.

Instructor fornece mecanismos de retentativa envolvendo saídas LLM com validação de esquema e mecanismos de retentativa automática. Integração forte com modelos Pydantic torna adequado para cenários onde validação pós-geração e correção são aceitáveis.

import boto3
import instructor
from pydantic import BaseModel

# Cria um cliente Bedrock para interações de runtime
bedrock_client = boto3.client('bedrock-runtime')

# Configura cliente instructor com cliente runtime Bedrock
client = instructor.from_bedrock(bedrock_client)

# Define o modelo de resposta estruturada
class User(BaseModel):
    name: str
    age: int

# Invoca o modelo Claude Haiku com a estrutura de mensagem correta
user = client.chat.completions.create(
    modelId="global.anthropic.claude-haiku-4-5-20251001-v1:0",
    messages=[
        {"role": "user", "content": [{"text": "Extract: Jason is 25 years old"}]},
    ],
    response_model=User,
)

print(user)
# Saída esperada:
# User "name='Jason' age=25"

Guidance oferece controle refinado de template sobre estrutura de saída e formatação, permitindo restrições em nível de token. Útil para formatação de resposta consistente e fluxos conversacionais.

Fatores de Decisão e Melhores Práticas

Selecionar a abordagem correta de saída estruturada depende de vários fatores chave que impactam diretamente complexidade de implementação e performance do sistema:

• Considerações de latência: Requisitos de tempo de resposta influenciam significativamente soluções de saída estruturada. Adicionando mecanismos de retentativa, validação pós-geração pode adicionar latência. Em comparação, abordagens como Outlines são ótimas para aplicações sensíveis a latência. Aplicar esquemas adiciona algum tempo de processamento comparado ao modelo base usado, mas ainda é muito mais rápido que estratégias pós-geração.
• Capacidades de retentativa: Capacidades de regeneração automática (como aquelas em Instructor) são essenciais para saídas estruturadas porque fornecem mecanismos de fallback quando tentativas iniciais de geração falham ao atender requisitos de esquema, melhorando confiabilidade geral sem intervenção de desenvolvedor.
• Suporte a streaming: Validação parcial JSON durante streaming permite entrega de conteúdo progressivo enquanto mantém integridade estrutural, vital para experiências responsivas em aplicações exigindo dados estruturados em tempo real.
• Complexidade de entrada: Técnicas de context trimming otimizam processamento de entradas complexas, garantindo que prompts longos ou intrincados não comprometam natureza estruturada de saídas ou excedam limitações de token.
• Estratégia de deployment: Enquanto a habilidade de acessar modelos através da API Amazon Bedrock (Converse, InvokeModel) oferece solução serverless, Outlines atualmente apenas está disponível através de AWS Marketplace no Amazon SageMaker, exigindo deploy e hospedagem do modelo.
• Seleção de modelo: A escolha do modelo impacta significativamente qualidade de saída estruturada e eficiência. Modelos base podem exigir engenharia de prompt extensiva para conformidade de estrutura, enquanto modelos especializados com capacidades de saída estruturada incorporadas oferecem confiabilidade maior e necessidades reduzidas de pós-processamento.
• Experiência do usuário: Cada opção oferece prós e contras. Validação em-processo (Outlines) captura erros cedo durante geração, aumentando velocidade quando erros ocorrem mas também aumentando latência quando saída de modelo já estava correta. Validação pós-geração fornece controle de qualidade abrangente mas exige tratamento de erro para saídas não-aderentes.
• Performance: Enquanto implementar saídas estruturadas pode aumentar precisão de modelo reduzindo alucinações e melhorando consistência de saída, alguns desses ganhos podem vir com compensações como redução de capacidades de raciocínio em alguns cenários ou introdução de overhead de token adicional.

Conclusão

Organizações conseguem usar o paradigma de saída estruturada em IA para aplicar esquemas confiávelmente, integrar com ampla gama de modelos e APIs, e equilibrar validação pós-geração versus métodos de geração direta para maior controle e consistência. Ao entender as compensações em performance, complexidade de integração e aplicação de esquema, construtores conseguem personalizar soluções para seus requisitos técnicos e de negócio, facilitando automação escalável e eficiente entre aplicações diversas.

Para aprender mais sobre implementação de saídas estruturadas com LLMs na AWS:

• Visite o AWS Machine Learning Blog para tutoriais e guias de implementação detalhados
• Explore exemplos completos de código no repositório Amazon Bedrock no GitHub
• Consulte a documentação Amazon Bedrock para melhores práticas em saídas estruturadas
• Conheça mais sobre a Dottxt em seu blog

Fonte

Generate structured output from LLMs with Dottxt Outlines in AWS (https://aws.amazon.com/blogs/machine-learning/generate-structured-output-from-llms-with-dottxt-outlines-in-aws/)

Dominando o Desafio do Aprendizado por Reforço em Larga Escala

O rápido avanço da inteligência artificial criou uma demanda crescente por modelos especializados capazes de tarefas complexas de raciocínio. Na programação competitiva, esse desafio é particularmente agudo: os modelos precisam gerar código funcional através de raciocínio algorítmico genuíno, não simples memorização de padrões.

O aprendizado por reforço (RL) oferece uma abordagem promissora nesse contexto. Diferentemente do aprendizado supervisionado tradicional, RL permite que modelos aprendam através de tentativa e erro, recebendo recompensas baseadas na execução real do código. Isso possibilita desenvolver capacidades verdadeiras de resolução de problemas em domínios algorítmicos.

Porém, implementar treinamento distribuído de RL para geração de código apresenta desafios infraestruturais significativos: orquestração de múltiplos componentes heterogêneos, coordenação de compilação paralela de código entre nós e manutenção de tolerância a falhas em processos de longa duração.

A Solução: Ray e SageMaker Integrados

Ray é um framework destacado para cargas de trabalho distribuídas que aborda esses desafios através de uma arquitetura unificada que gerencia todo o pipeline de IA. Seu design centrado em GPU e integração perfeita com ferramentas como Hugging Face Transformers e PyTorch o tornam ideal para cenários complexos.

A AWS combinou essas capacidades de Ray com a infraestrutura gerenciada do SageMaker através da solução Ray on Amazon SageMaker Training jobs. Essa integração automatiza a inicialização do cluster Ray, coordenação entre múltiplos nós e gerenciamento de recursos distribuídos, permitindo que desenvolvedores se concentrem no desenvolvimento do modelo enquanto usufruem dos recursos corporativos do SageMaker.

CodeFu-7B: Um Modelo Especializado em Programação

CodeFu-7B-v0.1 é um modelo de linguagem com 7 bilhões de parâmetros especificamente treinado para resolver problemas de programação competitiva. Construído sobre o modelo base DeepSeek-R1-Distill-Qwen-7B, demonstra como o aprendizado por reforço desenvolve capacidades de raciocínio algorítmico e geração eficiente de código C++, superando abordagens tradicionais de ajuste fino supervisionado.

O modelo foi treinado usando enunciados de problemas do dataset CodeContest da DeepMind, sem acesso a soluções corretas durante o treinamento. Essa abordagem força o modelo a aprender através de tentativa e erro baseado em feedback de execução de código, desenvolvendo capacidades genuínas de resolução de problemas em vez de memorização de padrões.

CodeFu é disponível publicamente no HuggingFace sob a licença MIT, tornando-o acessível para pesquisadores e profissionais interessados em geração de código e raciocínio algorítmico.

Arquitetura e Fluxo de Treinamento

O pipeline de treinamento do CodeFu com veRL e Ray no SageMaker segue uma sequência bem definida. Inicialmente, o dataset preprocessado do CodeContest e as configurações de treinamento são carregados. Em seguida, um job de treinamento SageMaker é submetido através da classe ModelTrainer do SDK Python do SageMaker.

Durante a execução, o progresso é monitorado em tempo real através do Ray Dashboard, com coleta opcional de métricas Prometheus, visualização Grafana e rastreamento de experimentos. Quando o treinamento é concluído, o SageMaker salva automaticamente o modelo treinado no S3, carrega logs de treinamento no CloudWatch e descomissiona o cluster de computação.

Essa arquitetura simplificada entrega uma experiência de treinamento de aprendizado por reforço completamente gerenciada, permitindo que desenvolvedores foquem no desenvolvimento do modelo enquanto Ray e SageMaker lidam com a orquestração complexa da infraestrutura distribuída — tudo dentro de um modelo de precificação pay-as-you-go que cobra apenas pelo tempo de computação efetivamente utilizado.

Otimização da Avaliação de Recompensas

O sistema de avaliação de recompensas implementa execução de código paralela através de funções remotas Ray, manipulando compilação C++ e execução de casos de teste. O framework veRL orquestra a execução distribuída através do componente main_ppo.py, coordenando três tipos principais de workers: ActorRolloutRefWorker para inferência de políticas e rollouts, CriticWorker para estimação de função de valor, e RewardModelWorker para pontuação de soluções geradas.

O algoritmo Group Relative Policy Optimization (GRPO) aprimora a otimização de política por proximidade tradicional (PPO) computando vantagens usando baselines relativos ao grupo, o que ajuda a estabilizar o treinamento reduzindo variância nas estimativas de gradiente de política.

A avaliação de recompensas segue um sistema hierárquico. Código não executável recebe penalidade severa (-1), falhas de compilação recebem penalidade moderada (-0.5), e código que excede limite de tempo recebe recompensa zero. Para soluções C++ executadas com sucesso, a recompensa é calculada como função linear baseada na fração de casos de teste privados passados, incentivando o modelo a resolver o máximo de casos possível enquanto evita overfitting aos testes públicos.

Implementação Prática no SageMaker

Para treinar CodeFu-7B usando veRL e Ray em jobs de treinamento SageMaker, utiliza-se a classe ModelTrainer do SDK Python do SageMaker. O primeiro passo é configurar a carga de trabalho de treinamento distribuída selecionando o tipo de instância apropriado — para este caso de uso recomenda-se mínimo de 2 instâncias p4de.24xlarge (cada uma com 8 GPUs NVIDIA A100), com possibilidade de escalar conforme necessário.

O treinamento usa um container Docker customizado que inclui veRL, Ray e as dependências necessárias para treinamento distribuído de RL. A classe ModelTrainer encapsula a configuração do treinamento baseado em Ray, permitindo especificar um script de entrada (entry_script) ou usar parâmetro de comando customizado para integração com frameworks especializados.

O script launcher.py funciona como ponto de entrada universal, detectando o ambiente SageMaker (nó único ou multi-nó, homogêneo ou heterogêneo) e inicializando o cluster Ray com coordenação apropriada de nó head/worker. Suas funcionalidades principais incluem setup do cluster Ray, coordenação entre nós head e worker, execução do script de treinamento especificado e conectividade com servidores Prometheus e Grafana externos para monitoramento abrangente.

Monitoramento e Observabilidade

O pipeline de treinamento CodeFu integra-se perfeitamente com Managed MLflow on Amazon SageMaker AI assim como soluções de terceiros, para rastreamento abrangente de experimentos e visualização de métricas de aprendizado por reforço.

Métricas críticas a monitorar incluem critic/reward/min (recompensa mínima — detecta falhas catastróficas), critic/reward/mean (recompensa média — indicador primário de progresso), critic/reward/max (recompensa máxima — desempenho de melhor caso), actor/ppo_kl (divergência KL entre iterações de política — deve manter-se estável), e val/test_score/code_contests (desempenho em conjunto de validação — mais importante para medir real melhoria do modelo).

Durante treinamento bem-sucedido, espera-se que critic/reward/mean melhore gradualmente, actor/ppo_kl permaneça baixo após spike inicial, e val/test_score/code_contests mostre melhoria consistente, com ambas as curvas (treinamento e validação) acompanhando proximamente, indicando aprendizado efetivo sem overfitting.

O acesso ao Ray Dashboard e habilitação de visualização Grafana durante treinamento pode ser estabelecido através de encaminhamento de porta usando AWS Systems Manager (SSM). O Ray Dashboard (porta 8265) fornece insights detalhados sobre utilização de workers, status de execução de tarefas e consumo de recursos, enquanto dashboards Grafana integrados oferecem visualização abrangente de métricas de treinamento, desempenho do sistema e saúde do cluster em tempo real.

Preparação de Dados e Configuração

O pipeline de preparação de dados transforma o dataset bruto do CodeContest em formato apropriado para treinamento de aprendizado por reforço. Filtros sistemáticos identificam problemas adequados, removendo aqueles com ratings Codeforces abaixo de 800 e implementando verificações de qualidade para casos de teste faltantes, descrições malformadas e restrições inválidas.

Problemas são categorizados em três níveis de dificuldade: Fácil (800-1000 pontos), Difícil (1100-2200 pontos) e Especialista (2300-3500 pontos). Cada problema é formatado com dois componentes: um prompt do usuário contendo o enunciado do problema, e especificação reward_model com casos de teste, limites de tempo e restrições de memória. Crucialmente, o campo ground_truth contém apenas casos de teste, sem código de solução, forçando o modelo a aprender através de sinais de recompensa em vez de memorizar soluções.

Pré-requisitos e Configuração Inicial

Antes de executar o treinamento, alguns requisitos devem ser atendidos. É necessário solicitar aumento de quota para instâncias p4de.24xlarge no console Service Quotas (mínimo de 2 para este caso de uso). Também é preciso criar uma função AWS Identity and Access Management (IAM) com políticas gerenciadas AmazonSageMakerFullAccess, AmazonS3FullAccess e AmazonSSMFullAccess.

Opcionalmente, pode-se criar um domínio Amazon SageMaker Studio para acessar Jupyter notebooks e executar o código de treinamento. Alternativamente, JupyterLab pode ser usado em setup local ou outro ambiente de desenvolvimento Python.

O código completo pode ser encontrado nos repositórios mencionados, que incluem definição completa do container Docker, scripts de entrada e configurações de treinamento.

Conclusão

A solução demonstra como treinar modelos especializados de raciocínio para programação competitiva usando veRL (Volcano Engine Reinforcement Learning) combinado com a infraestrutura gerenciada do SageMaker. Essa abordagem integrada simplifica a complexidade de orquestração de cargas de trabalho distribuídas de aprendizado por reforço, automatizando inicialização de cluster Ray, coordenação entre múltiplos nós e gerenciamento de recursos em ambientes heterogêneos.

A integração permite organizações aproveitarem capacidades avançadas de computação distribuída do Ray — incluindo suporte para arquiteturas multi-componentes complexas, alocação dinâmica de recursos e execução tolerante a falhas — enquanto usufruem da infraestrutura completamente gerenciada do SageMaker, segurança corporativa e modelo de precificação pay-as-you-go.

Para começar a implementar treinamento de aprendizado por reforço distribuído com Ray no SageMaker, visite o repositório do GitHub com a solução fundacional. A implementação completa do treinamento CodeFu-7B, incluindo integração veRL e exemplos de configuração, está disponível no repositório de exemplos da AWS.

Fonte

Train CodeFu-7B with veRL and Ray on Amazon SageMaker Training jobs (https://aws.amazon.com/blogs/machine-learning/train-codefu-7b-with-verl-and-ray-on-amazon-sagemaker-training-jobs/)

Acesso aos Modelos Anthropic Claude através da AWS no Sudeste Asiático

A AWS expandiu a disponibilidade de seus modelos de inteligência artificial generativa para países do Sudeste Asiático. Organizações na Tailândia, Malásia, Singapura, Indonésia e Taiwan conseguem agora acessar os modelos Claude Opus 4.6, Sonnet 4.6 e Haiku 4.5 da Anthropic através de uma arquitetura de inferência distribuída globalmente chamada Inferência Global entre Regiões (CRIS) no Amazon Bedrock.

Essa capacidade oferece três vantagens principais para organizações que trabalham com IA generativa: maiores limites de uso, redução de custos e roteamento inteligente de requisições entre mais de 20 regiões comerciais da AWS globalmente, permitindo casos de uso como chatbots, agentes autônomos de programação e sistemas de análise financeira.

Como Funciona a Arquitetura de Inferência Global

A CRIS é um recurso poderoso do Amazon Bedrock que permite distribuir o processamento de inferência entre múltiplas regiões da AWS sem necessidade de alterações complexas na aplicação. A tecnologia opera através dos conceitos de Região de Origem e Região de Destino. A Região de Origem é aquela a partir da qual você faz a requisição da API, enquanto a Região de Destino é para onde a AWS pode rotear a requisição para processamento.

Quando você submete uma requisição de inferência a partir de uma região de origem, o CRIS roteia inteligentemente a requisição para uma das regiões de destino configuradas no perfil de inferência através da rede gerenciada pelo Bedrock. O tráfego viaja pela rede global da AWS, e as respostas retornam à sua aplicação na região de origem.

Um ponto importante é que enquanto o processamento da inferência ocorre em outra região, os dados em repouso — incluindo logs, bases de conhecimento e configurações armazenadas — permanecem exclusivamente na sua região de origem. A AWS oferece dois tipos de perfis de inferência entre regiões: o CRIS Geográfico (que roteia dentro de uma geografia específica como EUA, Europa ou Ásia-Pacífico) e o CRIS Global (que roteia para regiões comerciais suportadas em todo o mundo).

Toda a comunicação utiliza a rede segura da AWS com criptografia de ponta a ponta para dados em trânsito e em repouso.

Regiões Disponíveis e Configuração Inicial

Clientes na Tailândia, Malásia, Singapura, Indonésia e Taiwan podem invocar os perfis de inferência global a partir das seguintes regiões de origem:

• Ásia-Pacífico (Singapura) — ap-southeast-1
• Ásia-Pacífico (Jacarta) — ap-southeast-3
• Ásia-Pacífico (Taipei) — ap-east-2
• Ásia-Pacífico (Tailândia) — ap-southeast-7
• Ásia-Pacífico (Malásia) — ap-southeast-5

Cada uma dessas regiões pode rotear requisições para mais de 20 regiões comerciais da AWS globalmente. O roteamento é gerenciado automaticamente pelo CRIS, sem intervenção manual necessária.

Configuração de Permissões com IAM

Antes de utilizar o CRIS, é necessário configurar permissões de Identidade e Acesso (IAM) que habilitem o roteamento entre regiões. A configuração requer três declarações de política porque o CRIS roteia requisições entre regiões: você chama o perfil de inferência na sua região de origem, que então invoca o modelo de base em qualquer região de destino que o CRIS selecionar.

A terceira declaração utiliza "aws:RequestedRegion": "unspecified" para conceder as permissões necessárias ao CRIS rotear suas requisições entre regiões.

Um detalhe importante: se as políticas de controle de serviço (SCPs) da sua organização negarem acesso a regiões não especificadas, o CRIS não funcionará. Recomenda-se validar sua configuração de SCP antes de implantar workloads em produção que dependam de roteamento global.

Utilizando os Perfis de Inferência entre Regiões

Os perfis de inferência global são identificados pelo prefixo global. no identificador do modelo — uma convenção de nomenclatura que você pode usar para distinguir perfis de roteamento global de IDs de modelo regionais ou de uma única região.

Use estes identificadores de perfil de inferência ao fazer chamadas de API, em vez dos IDs de modelo padrão:

• global.anthropic.claude-opus-4-6-v1 (Claude Opus 4.6)
• global.anthropic.claude-sonnet-4-5-20250929-v1:0 (Claude Sonnet 4.5)
• global.anthropic.claude-haiku-4-5-20251001-v1:0 (Claude Haiku 4.5)

Tanto a API InvokeModel quanto a API Converse suportam perfis de inferência entre regiões. A recomendação é usar a API Converse, pois oferece uma interface simplificada e formato consistente de requisição/resposta entre diferentes modelos de base.

Primeiro Teste com a API

Começar com o CRIS requer apenas poucas alterações no código existente da aplicação. Aqui está um exemplo de como invocar o Claude Opus 4.6 usando CRIS em Python com o SDK boto3:

import logging
import os
import boto3
from botocore.exceptions import ClientError

# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

# Load configuration from environment variables with defaults
REGION = os.getenv(
    "AWS_REGION", "ap-southeast-1"
)  # Singapore or Jakarta (ap-southeast-3)
MODEL_ID = os.getenv("MODEL_ID", "global.anthropic.claude-opus-4-6-v1")
MAX_TOKENS = int(os.getenv("MAX_TOKENS", "8000"))
TEMPERATURE = float(os.getenv("TEMPERATURE", "1"))
THINKING_TYPE = os.getenv("THINKING_TYPE", "adaptive")
EFFORT_LEVEL = os.getenv("EFFORT_LEVEL", "medium")

# Initialize Bedrock Runtime client for your Region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Example: Architecture trade-offs analysis
user_query = "Analyze the trade-offs between microservices and monolithic architectures for a mid-size SaaS company."

# Make inference request using Converse API with adaptive thinking
try:
    response = bedrock_runtime.converse(
        modelId=MODEL_ID,
        messages=[{"role": "user", "content": [{"text": user_query}]}],
        inferenceConfig={"maxTokens": MAX_TOKENS, "temperature": TEMPERATURE},
        additionalModelRequestFields={
            "thinking": {"type": THINKING_TYPE},
            "output_config": {"effort": EFFORT_LEVEL},
        },
    )
except ClientError as e:
    logger.error("Failed to invoke model %s: %s", MODEL_ID, e)
    raise

# Extract response content
output_message = response["output"]["message"]
has_thinking = any(block.get("type") == "thinking" for block in output_message["content"])
logger.info("Effort level: %s", EFFORT_LEVEL)
logger.info("Claude decided to think: %s", has_thinking)
for block in output_message["content"]:
    if block.get("type") == "thinking":
        thinking_tokens = len(block["thinking"].split())
        logger.info("[Thinking]: ~%d words", thinking_tokens)
    elif block.get("text"):
        logger.info("[Response]: %s", block["text"])

Um aspecto importante é que o monitoramento continua funcionando normalmente. Suas métricas do CloudWatch, logs e registros de auditoria do CloudTrail permanecem em sua região de origem, mesmo quando as requisições de inferência são processadas em outro lugar. Seus dashboards e alarmes existentes continuam funcionando exatamente como antes.

Gerenciamento de Cotas de Uso

À medida que sua aplicação escala de protótipo para produção, compreender e gerenciar cotas de serviço torna-se crítico. O Amazon Bedrock aplica cotas de serviço para garantir alocação justa de recursos e estabilidade do sistema.

Para o CRIS, as cotas são medidas em duas dimensões. Tokens por Minuto (TPM) é o número máximo de tokens (entrada + saída) que podem ser processados por minuto. Requisições por Minuto (RPM) é o número máximo de requisições de inferência que podem ser feitas por minuto.

Um detalhe técnico importante: a AWS utiliza uma taxa de consumo de tokens que pondera tokens de saída mais pesadamente que tokens de entrada. A taxa é de 5:1 — tokens de saída consomem cinco vezes mais quota que tokens de entrada, porque gerar tokens requer mais computação que processar entrada.

A fórmula é: Consumo de quota = Tokens de entrada + (Tokens de saída × 5)

Por exemplo, se sua requisição usa 10 mil tokens de entrada e gera 5 mil tokens de saída, o consumo total seria 35 mil tokens (10.000 + 5.000 × 5). Se sua aplicação processa requisições com esse padrão a 100 requisições por minuto, o consumo total de quota seria 3,5 milhões de TPM.

Ao trabalhar com seu gerenciador de conta da AWS em solicitações de aumento de quota, forneça seu volume de requisições esperado, tokens de entrada médios por requisição e tokens de saída médios para que calculem a alocação apropriada.

A recomendação é configurar alarmes do CloudWatch em 70-80% de utilização de quota para solicitar aumentos antes de atingir limites de throttling. As métricas InputTokenCount e OutputTokenCount rastreiam seu consumo em tempo real.

Para workloads não sensíveis ao tempo, o Claude Haiku 4.5 suporta inferência em lote com economia de custo de 50%. Requisições em lote são processadas de forma assíncrona dentro de 24 horas e não contam contra sua quota de TPM em tempo real.

Solicitando Aumentos de Cotas

Você pode visualizar suas cotas atuais no Console de Cotas de Serviço da AWS navegando até as cotas de serviço do Amazon Bedrock em sua região de origem.

Se seu workload requer cotas além dos limites padrão, você pode solicitar aumentos através do console. Para solicitações de grande escala ou lançamentos sensíveis ao tempo, recomenda-se trabalhar com sua equipe de contas da AWS para garantir planejamento apropriado de capacidade.

Escolhendo entre os Modelos Claude

Considere complexidade da tarefa, requisitos de latência, restrições de custo e necessidades de acurácia ao escolher entre os modelos. O Claude Opus 4.6 é recomendado para tarefas mais complexas que requerem inteligência de fronteira, como raciocínio multi-passos complexo, agentes autônomos sofisticados e análise crítica de precisão.

O Claude Sonnet 4.6 é adequado para problemas complexos que requerem planejamento e execução de agentes. O Claude Haiku 4.5 oferece desempenho próximo à fronteira com custo mais baixo, tornando-o ideal para operações de alto volume e experiências sensíveis a latência.

Para arquiteturas multi-agente, considere usar Opus 4.6 ou Sonnet 4.6 como orquestrador e Haiku 4.5 para execução paralela de workers.

Otimizações Avançadas

Cache de Prompts para Contexto Repetido

O cache de prompts oferece até 90% de redução de custos em tokens em cache e até 85% de melhoria de latência para workloads que reutilizam o mesmo contexto. Você deve cachear prompts de sistema que excedem 500 tokens, conteúdo de documentação, exemplos com poucos disparadores e definições de ferramentas. Estruture prompts com conteúdo estático primeiro, seguido por consultas dinâmicas. Consulte a documentação de cache de prompts para inferência mais rápida para detalhes de implementação.

Raciocínio Adaptativo e Estendido

O Claude Opus 4.6 suporta raciocínio adaptativo, uma evolução do raciocínio estendido que dá ao Claude liberdade para pensar se e quando determina que raciocínio é necessário. Você pode orientar quanto de raciocínio o Claude aloca usando o parâmetro de esforço, otimizando desempenho e velocidade.

Sonnet 4.6 e Haiku 4.5 suportam raciocínio estendido, onde o modelo gera etapas de raciocínio intermediárias através de decomposição de problemas, auto-correção e exploração de múltiplos caminhos de solução. Esses recursos de raciocínio oferecem melhorias de acurácia em tarefas de raciocínio complexo.

Testes de Carga para Validação de Cotas

Execute testes de carga antes do lançamento em produção para medir o consumo real de cotas sob tráfego máximo. Configure seu cliente de teste com modo de retry adaptativo, use ferramentas como Locust ou boto3 com threading para simular requisições concorrentes, e monitore as métricas do CloudWatch durante seu teste para observar padrões de consumo de TPM e RPM.

Próximos Passos

A inferência global entre regiões no Amazon Bedrock entrega os modelos Claude para organizações no Sudeste Asiático com duas vantagens principais: economia de custos comparada a perfis regionais e roteamento inteligente entre mais de 20 regiões da AWS para máxima disponibilidade e escala.

Essa infraestrutura habilita aplicações de IA generativa em produção em toda a região Sudeste Asiática, desde atendimento ao cliente em tempo real até análise financeira e assistentes autônomos de programação.

Para começar com a inferência global entre regiões, siga estes passos:

• Acesse o console do Amazon Bedrock em qualquer uma das regiões de origem listadas acima
• Configure permissões de IAM usando o modelo de política fornecido
• Faça sua primeira chamada de API usando o ID de perfil de inferência global
• Implemente cache de prompts para economia de custos em contexto repetido

Para mais informações, consulte:

• Documentação do Amazon Bedrock
• Guia do Usuário de Inferência entre Regiões
• Preços do Amazon Bedrock
• Documentação do Anthropic Claude
• Comece com Amazon Bedrock

Fonte

Global cross-Region inference for latest Anthropic Claude Opus, Sonnet and Haiku models on Amazon Bedrock in Thailand, Malaysia, Singapore, Indonesia, and Taiwan (https://aws.amazon.com/blogs/machine-learning/global-cross-region-inference-for-latest-anthropic-claude-opus-sonnet-and-haiku-models-on-amazon-bedrock-in-thailand-malaysia-singapore-indonesia-and-taiwan/)