Blog

Um Marco na Governança de IA em Nuvem

Em novembro de 2024, a Amazon Web Services (AWS) marcou presença como a primeira grande provedora de serviços em nuvem a anunciar a certificação acreditada ISO/IEC 42001 para seus serviços de inteligência artificial. Essa conquista cobriu um portfólio estratégico de soluções: Amazon Bedrock, Amazon Q Business, Amazon Textract e Amazon Transcribe.

A Auditoria de Vigilância e Seus Resultados

Um ano após essa certificação inicial, em novembro de 2025, a AWS completou com êxito sua primeira auditoria de vigilância para a norma ISO 42001:2023, que estabelece diretrizes para Sistemas de Gestão de Inteligência Artificial. O resultado notável: nenhum achado foi identificado durante o processo.

Esse resultado positivo evidencia o compromisso contínuo da AWS com práticas responsáveis no desenvolvimento e operação de tecnologias de IA. A auditoria de vigilância funciona como validação independente de que os controles implementados pela empresa estão operando adequadamente e de forma consistente.

O Que Isso Significa para os Clientes

A validação externa conquistada pela AWS oferece segurança adicional aos seus clientes. Organizações que utilizam os serviços de IA da plataforma ganham mais confiança para construir e operar aplicações de inteligência artificial de forma responsável, sabendo que o provedor subjacente foi auditado independentemente por órgãos certificadores.

Essa abordagem demonstra que a empresa leva a sério questões fundamentais como transparência, conformidade regulatória e responsabilidade no uso de IA — temas cada vez mais críticos à medida que essas tecnologias se disseminam pelas organizações.

Acessando as Certificações

Clientes interessados em consultar a lista completa de serviços da AWS certificados sob normas ISO e CSA STAR podem acessar a página de Serviços Certificados ISO e CSA STAR. As certificações também estão disponíveis diretamente no Console de Gerenciamento da AWS, por meio do AWS Artifact — um repositório centralizado para documentos de conformidade e relatórios de segurança.

Fonte

AWS successfully completed its first surveillance audit for ISO 42001:2023 with no findings (https://aws.amazon.com/blogs/security/aws-successfully-completed-its-first-surveillance-audit-for-iso-420012023-with-no-findings/)

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

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