Blog

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/)

Novos modelos Claude disponíveis no Oriente Médio

A AWS anunciou a disponibilidade de cinco modelos Claude da Anthropic através do Amazon Bedrock com suporte à inferência distribuída entre regiões para clientes operando no Oriente Médio. Os modelos Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5 e Claude Haiku 4.5 agora estão acessíveis nas regiões me-central-1 (Emirados Árabes Unidos) e me-south-1 (Bahrein), beneficiando-se do roteamento inteligente de inferência através da infraestrutura global da AWS.

Com essa expansão, organizações no Oriente Médio podem escalar suas cargas de trabalho de IA de forma contínua, melhorar a resiliência de suas aplicações e reduzir a complexidade operacional de gerenciar múltiplas regiões manualmente.

Entendendo a inferência distribuída entre regiões

O conceito de inferência distribuída entre regiões no Amazon Bedrock funciona através de um mecanismo de roteamento automático e inteligente. Quando uma solicitação é feita através de um perfil de inferência entre regiões, a requisição originária de sua região-fonte é automaticamente direcionada para uma das regiões de destino pré-configuradas no perfil.

Um aspecto importante dessa abordagem é a segurança dos dados. A transmissão ocorre através da rede global gerenciada pela AWS com criptografia de ponta a ponta. Diferentemente do que alguns poderiam supor, a inferência entre regiões não altera o local onde os dados são armazenados—os dados do cliente não residem na região de destino. Os registros gerenciados pelo cliente (como logs de invocação de modelos), bases de conhecimento e configurações armazenadas permanecem exclusivamente na região-fonte. A resposta criptografada retorna à sua aplicação na região original.

Capacidades dos modelos Claude disponibilizados

Cada variante de modelo Claude oferece características distintas para diferentes necessidades:

Claude Opus 4.6

Traz capacidades avançadas para tarefas de agentic, projetos complexos de codificação e fluxos de trabalho de nível empresarial que exigem raciocínio profundo e confiabilidade. É a opção mais potente quando se prioriza desempenho e capacidade de análise.

Claude Sonnet 4.6

Equilibra inteligência, velocidade e custo-efetividade, sendo ideal para aplicações em produção e tarefas multi-etapas onde é necessário encontrar um bom ponto de equilíbrio entre performance e recursos.

Claude Haiku 4.5

Otimizado para respostas de baixa latência, adequado para casos de uso em tempo real como assistentes de IA e geração de conteúdo em alto volume, priorizando velocidade de resposta.

Ao combinar esses modelos com a inferência distribuída entre regiões, as organizações podem dinamicamente escalar cargas de trabalho de IA entre regiões mantendo desempenho ótimo, selecionando o modelo certo conforme seus requisitos específicos.

Benefícios da inferência distribuída entre regiões

Melhor desempenho durante picos de demanda

Para organizações no Oriente Médio, a inferência distribuída fornece resiliência crítica durante períodos de pico regional—como durante o Ramadã, eventos de compras importantes ou horários comerciais de alto tráfego. O sistema automaticamente roteia requisições para regiões com capacidade disponível na infraestrutura global, garantindo que suas aplicações mantenham performance mesmo durante picos inesperados de tráfego. Esse roteamento acontece de forma transparente e é completamente gerenciado pelo Amazon Bedrock. Para aplicações críticas do negócio que servem clientes pela região do Golfo e mais amplamente na região MENAT, isso significa evitar tempo de inatividade custoso ou degradação de performance que poderia impactar receita e confiança do cliente.

Transmissão segura de dados

Os dados transmitidos durante operações entre regiões são gerenciados pelo Amazon Bedrock com criptografia em trânsito entre regiões, ajudando a atender aos requisitos rigorosos de segurança e proteção de dados importantes para organizações no Oriente Médio.

Estratégia multi-região simplificada

As organizações não precisam mais arquitetar manualmente implantações complexas em múltiplas regiões. A inferência distribuída entre regiões fornece resiliência de nível empresarial sem a sobrecarga operacional de gerenciar múltiplos endpoints regionais.

Suporte à transformação digital acelerada

À medida que organizações do Oriente Médio aceleram iniciativas de transformação digital alinhadas com visões nacionais (como Saudi Vision 2030 e a Estratégia de IA dos Emirados), a inferência distribuída entre regiões proporciona a escalabilidade necessária para apoiar projetos ambiciosos de IA sem limitações de capacidade.

Monitoramento simplificado

O Amazon CloudWatch e AWS CloudTrail continuam registrando entradas de log em sua região-fonte do Oriente Médio, fornecendo uma visão centralizada do desempenho de sua aplicação. Essa observabilidade simplificada significa que suas equipes podem monitorar e gerenciar aplicações de IA generativa usando ferramentas AWS familiares, independentemente de onde as requisições são processadas globalmente, tornando conformidade e gerenciamento operacional mais diretos.

Flexibilidade de cota sob demanda

A inferência distribuída entre regiões ajuda a remover as limitações impostas pelas cotas de capacidade de regiões individuais. Suas cargas de trabalho podem dinamicamente acessar recursos através da infraestrutura global da AWS, tornando simples manipular aplicações de alto volume e picos súbitos de tráfego comuns na economia digital em rápido crescimento da região.

Casos de uso práticos

A disponibilidade dos modelos Claude através de inferência distribuída entre regiões desbloqueia uma ampla gama de aplicações para clientes no Oriente Médio:

• Copilots corporativos e assistentes de IA que exigem alta disponibilidade e performance consistente
• Fluxos de trabalho agentic que orquestram raciocínio complexo e uso de ferramentas
• Ferramentas de produtividade para desenvolvedores focadas em geração, revisão e transformação de código
• Aplicações de engajamento com clientes que requerem escala elástica
• Análise avançada de dados e processamento de documentos

Gerenciamento de cotas

Para ver as cotas padrão de throughput entre regiões ao usar perfis de inferência global, consulte os valores de requisições de inferência de modelo entre regiões por minuto e tokens de inferência de modelo entre regiões por minuto nas cotas de serviço do Amazon Bedrock. Você pode solicitar, visualizar e gerenciar cotas para o perfil de inferência distribuída através do console de Cotas de Serviço ou usando comandos da Interface de Linha de Comando da AWS (CLI) em sua região-fonte.

Primeiros passos na prática

Para começar a usar os modelos Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5 ou Claude Haiku 4.5 com inferência distribuída entre regiões (por exemplo, na região me-central-1), execute os seguintes passos:

Verificar permissões de acesso

Confirme que seu usuário ou função Gerenciamento de Identidade e Acesso da AWS (IAM) possui as permissões necessárias para invocar modelos do Amazon Bedrock usando um perfil de inferência entre regiões.

Invocar o modelo através de APIs

Use as APIs do Amazon Bedrock ou SDKs (Software Development Kits) da AWS:

import boto3
import json

bedrock = boto3.client('bedrock-runtime', region_name='me-central-1')
model_id = "global.anthropic.claude-sonnet-4-6"

response = bedrock.converse(
    messages=[{"role": "user", "content": [{"text": "Explain cloud computing in 2 sentences."}]}],
    modelId=model_id,
)

print("Response:", response['output']['message']['content'][0]['text'])
print("Token usage:", response['usage'])
print("Total tokens:", response['usage']['totalTokens'])

Monitorar uso e desempenho

Você pode monitorar uso, performance e custos através do CloudWatch e AWS Cost Explorer para escalar suas aplicações conforme a demanda cresce.

Considerações finais

Com o lançamento dos modelos Claude Opus 4.6, Claude Sonnet 4.6, Claude Opus 4.5, Claude Sonnet 4.5 e Claude Haiku 4.5 usando inferência distribuída entre regiões do Amazon Bedrock, clientes no Oriente Médio podem agora construir aplicações de IA generativa altamente escaláveis e resilientes sem a sobrecarga operacional de gerenciar manualmente capacidade de inferência regional. Essa funcionalidade oferece a base infraestrutural para que organizações acelerem inovação e entreguem experiências impactantes potencializadas por IA em toda a região.

Para aprender mais detalhes técnicos, consulte o guia Primeiros passos com inferência entre regiões no Amazon Bedrock.

Fonte

Introducing Amazon Bedrock global cross-Region inference for Anthropic’s Claude models in the Middle East Regions (UAE and Bahrain) (https://aws.amazon.com/blogs/machine-learning/introducing-amazon-bedrock-global-cross-region-inference-for-anthropics-claude-models-in-the-middle-east-regions/)

Uma nova abordagem para observabilidade em nuvem

A AWS anunciou recentemente a integração de sua solução de observabilidade como Kiro Power, ampliando as capacidades oferecidas através da plataforma Kiro. Essa integração representa um avanço significativo para profissionais que trabalham com infraestrutura e aplicações em nuvem, permitindo acelerar investigações de problemas com o apoio de agentes de IA integrados ao ambiente de desenvolvimento.

Para contextualizar: Kiro Powers é um repositório curado e pré-configurado que reúne servidores de Protocolo de Contexto do Modelo (MCP), arquivos de direcionamento e hooks validados por parceiros Kiro, facilitando o desenvolvimento e implantação de soluções especializadas.

Estrutura técnica da solução

Os componentes do AWS Observability Power

O AWS Observability Power agrupa quatro servidores MCP especializados, cada um projetado para um aspecto diferente da observabilidade:

• CloudWatch MCP server — responsável por acessar dados de observabilidade
• Application Signals MCP server — fornece monitoramento de performance de aplicações
• CloudTrail MCP server — suporta análise de segurança e conformidade
• AWS Documentation MCP server — oferece acesso a referências contextuais

Essa arquitetura integrada oferece aos agentes Kiro um contexto abrangente para executar fluxos de trabalho especializados, incluindo resposta a alarmes, detecção de anomalias, rastreamento distribuído, monitoramento de SLO (Acordos de Nível de Serviço) e investigações de segurança.

Análise automatizada de lacunas de instrumentação

Além das capacidades principais, o poder inclui um mecanismo de análise automatizada de lacunas que identifica padrões ausentes na instrumentação do código. Isso abrange situações como erros não registrados, identificadores de correlação faltantes ou rastreamento distribuído ausente, fornecendo recomendações acionáveis para melhorias.

Benefícios práticos para operações

Redução do tempo de resolução de incidentes

A solução atende a dois objetivos críticos em operações de TI. Primeiro, ao investigar um alarme ativo, o poder carrega dinamicamente a orientação relevante e sinais operacionais, assegurando que os agentes de IA recebam apenas o contexto necessário para a tarefa de troubleshooting específica. Isso reduz significativamente o tempo de resolução médio (MTTR).

Melhoria proativa da pilha de observabilidade

Segundo, a análise automatizada de lacunas permite que equipes identifiquem e resolvam proativamente problemas de instrumentação antes que eles afetem a detecção de incidentes. O poder acompanha oito guias de direcionamento abrangentes cobrindo resposta a incidentes, alertas, monitoramento de performance, auditoria de segurança e análise de lacunas.

Disponibilidade e instalação

O AWS Observability Power está disponível para instalação com um clique dentro do Kiro IDE e na página de Kiro Powers, funcional em todas as regiões AWS. Cada servidor MCP subjacente opera conforme o suporte regional do serviço AWS correspondente.

Desenvolvedores podem agora acelerar o troubleshooting de aplicações distribuídas e infraestrutura diretamente em seu ambiente de desenvolvimento integrado (IDE), transformando minutos que seriam gastos em investigação manual em processos assistidos e guiados.

Para explorar mais detalhes sobre os servidores MCP de observabilidade da AWS, a documentação técnica está disponível para consulta.

Fonte

AWS Observability now available as a Kiro power (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-observability-kiro-power/)

O que é o AWS Elemental Inference

A AWS anunciou a disponibilidade geral do Elemental Inference, um serviço totalmente gerenciado de Inteligência Artificial que oferece aos broadcasters e streamers a capacidade de gerar automaticamente conteúdo otimizado para dispositivos móveis e plataformas sociais em tempo real. O diferencial está em sua arquitetura paralela: o processamento de vídeo acontece simultaneamente com a codificação, permitindo que empresas e criadores de conteúdo alcancem audiências em diversos formatos sem necessitar de conhecimento especializado em IA ou equipes dedicadas exclusivamente à produção.

Processamento de Vídeo Único, Distribuição Múltipla

Um dos pontos-chave do Elemental Inference é seu modelo de processamento: processa-se o vídeo uma única vez e o otimiza para todos os destinos. Enquanto transmissão principal é codificada, o serviço gera simultaneamente versões verticais para plataformas como TikTok, Instagram Reels, YouTube Shorts e Snapchat. Essa abordagem paralela elimina a necessidade de pipelines separados de produção.

Para exemplificar: uma emissora de esportes pode gerar automaticamente clips de destaque em formato vertical durante transmissões ao vivo e distribuí-los para redes sociais em tempo real, capturando momentos virais conforme ocorrem, em vez de horas depois.

Recursos de IA Disponíveis

O serviço foi lançado com dois recursos principais impulsionados por IA:

• Recorte de vídeo vertical: transforma automaticamente transmissões em landscape (ao vivo ou sob demanda) em formatos otimizados para dispositivos móveis
• Análise avançada de metadados: identifica momentos-chave em conteúdo ao vivo para gerar automaticamente clips de destaque

Ambos os recursos funcionam através de uma aplicação de IA que não requer prompts ou intervenção manual. O sistema adapta o conteúdo automaticamente para cada plataforma, permitindo que broadcasters escalem produção sem adicionar fluxos de trabalho manuais ou contratar mais staff.

Eficiência Operacional Comprovada

Durante a fase de testes em beta, grandes empresas de mídia relataram economia de 34% ou superior em fluxos de trabalho de vídeo ao vivo com IA, comparado ao uso de múltiplas soluções pontuais. Esse resultado reforça o valor da integração centralizada versus abordagens fragmentadas.

Disponibilidade Regional

O AWS Elemental Inference está disponível nas seguintes regiões da AWS: US East (N. Virginia), US West (Oregon), Asia Pacific (Mumbai) e Europe (Ireland).

Próximas Etapas

Para conhecer mais detalhes, a AWS recomenda consultar o AWS News Blog ou explorar a documentação do AWS Elemental Inference.

Fonte

Announcing AWS Elemental Inference (https://aws.amazon.com/about-aws/whats-new/2026/02/aws-elemental-inference-generally-avail/)

Exportação de Snapshots RDS para S3 no AWS GovCloud

A AWS anunciou a disponibilidade do recurso de Exportação de Snapshots do RDS para S3 nas regiões do AWS GovCloud (US). Essa funcionalidade permite que organizações exportem dados de snapshots em formato Apache Parquet, viabilizando cenários de análise de dados, retenção de informações e aplicações de machine learning.

Capacidades e Características Técnicas

O recurso funciona de forma abrangente e flexível. Ele suporta todos os tipos de snapshots de banco de dados: snapshots manuais, snapshots de sistema automatizados e snapshots criados via AWS Backup. Uma característica importante é que a exportação ocorre diretamente sobre o snapshot, sem impacto no desempenho da base de dados em operação.

Formato e Interoperabilidade

Os dados exportados no formato Apache Parquet podem ser analisados utilizando diversos serviços e ferramentas. Na plataforma AWS, é possível integrar com Amazon Athena, Amazon SageMaker e Amazon Redshift Spectrum. Além disso, a solução é compatível com frameworks de processamento de big data como Apache Spark, oferecendo flexibilidade para diferentes arquiteturas de análise.

Simplicidade de Uso

A criação de uma exportação de snapshot é realizada com facilidade através do Console de Gerenciamento do Amazon RDS, ou alternativamente, usando AWS SDK ou AWS CLI para automação e integração em pipelines.

Mecanismos de Banco de Dados Suportados

O recurso de exportação para S3 está disponível para os seguintes tipos de bancos de dados:

• Amazon Aurora PostgreSQL – Compatible Edition
• Amazon Aurora MySQL
• Amazon RDS para PostgreSQL
• Amazon RDS para MySQL
• Amazon RDS para MariaDB

Próximos Passos

Para implementar essa solução em seu ambiente, consulte a documentação do Aurora ou a documentação do Amazon RDS, onde você encontrará instruções detalhadas para começar a utilizar o recurso.

Fonte

Amazon RDS Snapshot Export to S3 now available in AWS GovCloud (US) Regions (https://aws.amazon.com/about-aws/whats-new/2026/02/rds-exports-s3-available-gov-cloud/)