Acesso Rápido a Modelos Pré-treinados para IA

O Amazon SageMaker JumpStart oferece uma biblioteca de modelos pré-treinados que abrangem diversos tipos de problemas, facilitando o início de projetos de inteligência artificial. A plataforma disponibiliza soluções para os principais casos de uso, que podem ser implantadas em endpoints de Inferência Gerenciada do SageMaker AI ou em clusters SageMaker HyperPod. Com opções de implantação pré-configuradas, os usuários conseguem transitar rapidamente da seleção do modelo até sua colocação em produção.

O Desafio das Implantações Genéricas

As implantações através do SageMaker JumpStart sempre foram rápidas e diretas. Os clientes podiam selecionar opções baseadas no número esperado de usuários simultâneos, mantendo visibilidade sobre métricas como latência P50, tempo até o primeiro token (TTFT) e vazão (tokens por segundo por usuário).

Porém, as opções de configuração de usuários simultâneos, embora úteis para cenários genéricos, não levariam em conta as características específicas das tarefas. A AWS reconheceu que clientes utilizam o SageMaker JumpStart para aplicações bastante distintas e especializadas — geração de conteúdo, resumização de textos, sistemas de perguntas e respostas, entre outras. Cada uma dessas aplicações demanda configurações particulares para otimizar desempenho.

Além disso, a definição de “desempenho” vai além da latência. Alguns clientes priorizam vazão, enquanto outros buscam minimizar o custo por token. Essas variações exigiam abordagens de implantação mais granulares e direcionadas.

Implantações Otimizadas por Caso de Uso

Respondendo a essas necessidades, a AWS anunciou o lançamento das implantações otimizadas do SageMaker JumpStart. Essa capacidade oferece configurações de implantação pré-definidas, cada uma elaborada especificamente para um caso de uso determinado, resolvendo a demanda por customização clara e direta.

Os clientes mantêm o mesmo nível de transparência sobre os detalhes de suas implantações propostas, mas agora as configurações são otimizadas para o caso de uso específico e para a restrição de desempenho desejada. Essa abordagem combina facilidade de uso com precisão técnica.

Preparação para Começar

Para utilizar as implantações otimizadas do SageMaker JumpStart, são necessários os seguintes pré-requisitos:

• Uma conta AWS
• Um domínio SageMaker Studio
• Uma função AWS Identificação e Gerenciamento de Acesso (IAM) que permita criar um modelo e um endpoint

Com esses componentes em lugar, os usuários podem começar a usar as implantações otimizadas imediatamente.

Iniciando uma Implantação Otimizada

O processo de configuração é direto. Primeiro, abre-se o SageMaker Studio e acessa-se a seção de Modelos. Em seguida, seleciona-se um dos modelos que suportam implantações otimizadas (listados na próxima seção) e clica-se em “Deploy” no canto superior direito.

A tela que se abre apresenta uma nova seção expansível denominada “Performance”, que contém as opções para implantações otimizadas. Antes de mais nada, pede-se ao usuário que escolha um caso de uso. Para modelos baseados em texto, esses casos de uso podem variar desde escrita generativa até interações em estilo de chat. Suporte para imagem e vídeo virá com futuras atualizações.

Após selecionar o caso de uso, o usuário precisa escolher uma das três otimizações de restrição: Otimizado para Custo, Otimizado para Vazão e Otimizado para Latência. Existe também uma opção Balanceada para quem busca o melhor desempenho médio entre todas as métricas registradas.

Uma vez selecionada, uma configuração de implantação pré-definida é gerada para o endpoint. Os usuários podem revisar e ajustar valores adicionais como timeouts, nomenclatura do endpoint e configurações de segurança. Após completar a configuração, basta clicar em “Deploy” no canto inferior direito para finalizar.

Modelos Disponíveis para Implantação Otimizada

As implantações otimizadas do SageMaker JumpStart estão disponíveis para o seguinte conjunto de modelos:

Modelos Meta Llama

• Llama-3.1-8B-Instruct
• Llama-2-7b-hf
• Llama-3.2-3B
• Meta-Llama-3-8B
• Llama-3.2-1B-Instruct
• Llama-3.2-1B
• Llama-3.1-70B-Instruct
• Llama-3.2-3B-Instruct
• Meta-Llama-3-8B

Modelos Microsoft Phi

• Phi-3-mini-4k-instruct

Modelos Mistral AI

• Mistral-7B-Instruct-v0.2
• Mistral-Small-24B-Instruct-2501
• Mistral-7B-v0.1
• Mistral-7B-Instruct-v0.3
• Mixtral-8x7B-Instruct-v0.1

Modelos Qwen

• Qwen3-8B
• Qwen3-32B
• Qwen3-0.6B
• Qwen2.5-7B-Instruct
• Qwen2.5-72B-Instruct
• Qwen2-VL-7B-Instruct
• Qwen2-1.5B-Instruct

Modelos Google Gemma

• gemma-7b
• gemma-7b-it
• gemma-2b

Outros Modelos

• Tiiuae Falcon3-1B-Instruct

Esses modelos formam o lançamento inicial das implantações otimizadas, e a AWS está expandindo ativamente o suporte para incluir modelos adicionais.

Próximos Passos

Usuários interessados podem começar a trabalhar com as implantações otimizadas do SageMaker JumpStart imediatamente. Basta selecionar um dos modelos de implantação otimizada disponíveis no hub de modelos do SageMaker Studio, explorar as diferentes opções de configuração e determinar qual delas melhor se adequa à aplicação em questão. A capacidade de ajustar a implantação ao caso de uso específico promete facilitar significativamente a colocação de modelos de linguagem em produção.

Fonte

Use-case based deployments on SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/use-case-based-deployments-on-sagemaker-jumpstart/)

Introdução

Implantar e escalar modelos de fundação para inferência de IA generativa apresenta desafios significativos para as organizações. Equipes frequentemente enfrentam dificuldades com configuração complexa de infraestrutura, padrões de tráfego imprevisíveis que levam ao excesso de provisionamento ou gargalos de desempenho, e overhead operacional ao gerenciar recursos de GPU de forma eficiente. Esses pontos críticos resultam em atraso no time-to-market, desempenho subótimo dos modelos e custos inflados que podem comprometer a viabilidade de iniciativas de IA em escala.

O Amazon SageMaker HyperPod oferece uma solução abrangente para esses desafios, fornecendo uma plataforma dedicada para cargas de trabalho de inferência. O serviço integra escalabilidade dinâmica, implantação simplificada e gerenciamento inteligente de recursos. As organizações que adotam essas práticas recomendadas podem reduzir o custo total de propriedade em até 40% enquanto aceleram a implantação de IA generativa da concepção à produção.

Criação de cluster com um clique

O HyperPod simplifica significativamente o processo de criação de infraestrutura. Para criar um cluster HyperPod com orquestração via Amazon Elastic Kubernetes Service (Amazon EKS), acesse o console da Amazon SageMaker AI e navegue até a página de gerenciamento de clusters.

O processo ocorre em etapas bem definidas:

• Passo 1: Selecione a opção “Criar cluster HyperPod” e escolha o modelo “Orquestrado pelo Amazon EKS”.
• Passo 2: Escolha entre configuração rápida ou personalizada. A configuração rápida cria recursos padrão, enquanto a personalizada permite integração com recursos existentes ou customização conforme necessidades específicas.
• Passo 3: Configure controladores Kubernetes e complementos (add-ons) conforme seu caso de uso, habilitando ou desabilitando cada um de acordo com os requisitos.
• Passo 4: Revise a arquitetura de alto nível que mostra como o SageMaker HyperPod funciona com o plano de controle do orquestrador Amazon EKS.

Opções de implantação

O Amazon SageMaker HyperPod agora oferece uma plataforma de inferência abrangente que combina a flexibilidade do Kubernetes com serviços gerenciados da AWS. A solução permite implantar, escalar e otimizar modelos de aprendizado de máquina com confiabilidade de produção em todo seu ciclo de vida.

A plataforma fornece interfaces de implantação flexíveis, dimensionamento automático avançado e recursos abrangentes de monitoramento. Utilizando o operador de implantação de inferência, é possível implantar modelos a partir de buckets do S3, FSx para Lustre e JumpStart sem escrever código.

• Implantação a partir do SageMaker JumpStart: Acesse exemplos de código e notebooks de amostra para começar rapidamente.
• Implantação de modelos personalizados ou ajustados do S3: Use notebooks de amostra para guiar o processo de implantação.
• Implantação a partir do FSx Lustre: Consulte os notebooks de amostra para otimizar o desempenho com armazenamento em alta velocidade.

Escalabilidade automática com KEDA e Karpenter

O Amazon SageMaker HyperPod oferece uma arquitetura de escalabilidade automática que combina KEDA (Kubernetes Event-Driven Autoscaling — Escalabilidade Automática Acionada por Eventos no Kubernetes) para escalabilidade em nível de pod e Karpenter para escalabilidade em nível de nó. Essa abordagem em duas camadas ativa uma infraestrutura dinâmica e eficiente em custos que se expande de zero para cargas de trabalho em produção conforme a demanda em tempo real.

Escalabilidade em nível de pod com KEDA

KEDA é um projeto de código aberto da Cloud Native Computing Foundation (CNCF) que estende o Kubernetes com recursos de escalabilidade automática acionados por eventos. O KEDA é instalado automaticamente como parte do operador de inferência do HyperPod, fornecendo escalabilidade automática de pods pronta para uso sem necessidade de instalação ou configuração separada.

Ele escala o número de pods de inferência baseado em métricas como comprimento da fila de requisições, métricas do Amazon CloudWatch (como invocações de endpoint do SageMaker), latência ou métricas customizadas do Prometheus. O KEDA pode escalar implantações para zero pods quando não há tráfego, eliminando custos durante períodos de inatividade.

Escalabilidade em nível de nó com Karpenter

Karpenter é um escalonador automático de cluster Kubernetes que provisiona ou remove nós de computação baseado em requisitos de pods pendentes. Ele funciona no plano de controle do Amazon EKS, o que significa que não há custos computacionais adicionais para executar o escalonador. Essa implantação no plano de controle gerenciado permite verdadeiras capacidades de escalabilidade para zero.

Quando o KEDA reduz pods para zero devido à falta de tráfego, o Karpenter pode remover todos os nós de trabalho, garantindo que você não incorra em custos de infraestrutura durante períodos de inatividade.

Integração entre KEDA e Karpenter

A integração entre KEDA e Karpenter cria uma experiência de escalabilidade automática eficiente. O Coletor ADOT (AWS Distro for OpenTelemetry — Distribuição AWS para OpenTelemetry) coleta métricas de pods de inferência e as envia para Amazon Managed Service para Prometheus ou CloudWatch, que o operador KEDA (instalado com o operador de inferência) consulta periodicamente e avalia em relação aos limites de gatilho configurados em seu YAML de JumpStartModel ou InferenceEndpointConfig.

Quando as métricas excedem os limites, o KEDA dispara o Horizontal Pod Autoscaler (HPA) para criar novos pods de inferência. Se esses pods permanecerem pendentes devido à capacidade insuficiente de nós, o Karpenter (executando no plano de controle) detecta essa situação e provisiona novos nós com os tipos de instância e configurações de GPU apropriadas. O agendador do Kubernetes então implanta os pods pendentes nos nós recém-provisionados, distribuindo o tráfego de inferência pela infraestrutura escalada.

Quando a demanda diminui, o KEDA reduz os pods com base nas mesmas métricas. O Karpenter consolida cargas de trabalho e remove nós subutilizados para reduzir custos de infraestrutura. Durante períodos sem tráfego, o KEDA pode reduzir para zero pods e o Karpenter remove todos os nós de trabalho, resultando em zero custos computacionais enquanto mantém a capacidade de escalar rapidamente quando o tráfego retoma. Essa arquitetura garante que você pague apenas pelos recursos computacionais enquanto servem ativamente requisições de inferência, sem custos adicionais para a infraestrutura de escalabilidade automática, já que o Karpenter funciona no plano de controle gerenciado.

Habilitando o Karpenter

Para habilitar a escalabilidade automática, verifique se a função de execução do cluster HyperPod possui as seguintes políticas: sagemaker:BatchAddClusterNodes, sagemaker:BatchDeleteClusterNodes e sagemaker:BatchPutMetrics nos recursos apropriados.

Execute o seguinte comando:

aws sagemaker update-cluster --cluster-name 'ml-cluster' --auto-scaling '{ "Mode": "Enable", "AutoScalerType": "Karpenter" }' --cluster-role 'arn:aws:iam::XXXXXXXXXXXX:role/sagemaker-ml-cluster-e3cb1e31ExecRole' --region us-east-1

Após executar este comando, você receberá uma resposta de sucesso com o ARN do cluster. Para verificar se o Karpenter foi habilitado, execute a API DescribeCluster:

aws sagemaker describe-cluster --cluster-name ml-cluster --query AutoScaling --region us-east-1

A resposta confirmará que o modo está habilitado e o tipo de escalonador automático é Karpenter.

Cache KV em camadas e roteamento inteligente

O Amazon SageMaker HyperPod agora oferece suporte a cache KV (pares chave-valor) gerenciado em camadas e roteamento inteligente para otimizar o desempenho da inferência de modelos de linguagem grande (LLM), particularmente para prompts de contexto longo e conversas multi-volta.

Cache KV gerenciado em camadas

O recurso de cache KV gerenciado em camadas aborda restrições de memória durante a inferência implementando uma estratégia de cache multi-camada. O cache de pares chave-valor é essencial para a eficiência da inferência em LLM. Ele armazena computações de atenção intermediárias de tokens anteriores, evitando recálculos redundantes e reduzindo significativamente a latência. Ao gerenciar cache em múltiplas camadas de armazenamento, o HyperPod viabiliza:

• Redução da pressão de memória nos recursos de GPU
• Suporte a janelas de contexto mais longas sem degradação de desempenho
• Gerenciamento automático de cache sem intervenção manual

Roteamento inteligente

O roteamento inteligente otimiza a inferência direcionando requisições com prefixos de prompt compartilhados para a mesma instância de inferência, maximizando a reutilização do cache KV. Essa abordagem:

• Roteia requisições estrategicamente para instâncias que já processaram prefixos similares
• Acelera o processamento reutilizando dados de KV em cache
• Reduz latência para conversas multi-volta e requisições em lote com contextos comuns

Benefícios de desempenho

Juntos, esses recursos oferecem melhorias substanciais:

• Até 40% de redução em latência para requisições de inferência
• 25% de melhoria em throughput no processamento de requisições
• 25% de economia de custos em comparação com configurações baseline sem essas otimizações

Esses recursos estão disponíveis através do operador de inferência do HyperPod, fornecendo capacidades gerenciadas prontas para uso para implantações de LLM em produção. Para mais detalhes sobre esse recurso, consulte Cache KV em camadas gerenciado e roteamento inteligente para Amazon SageMaker HyperPod.

Suporte a GPU com Multi-Instance GPU (MIG)

O SageMaker HyperPod Inference agora oferece suporte a implantações de modelos em aceleradores que foram particionados usando a tecnologia NVIDIA Multi Instance GPU (MIG). Implantar modelos pequenos em GPUs grandes pode desperdiçar recursos. Para resolver isso, o SageMaker HyperPod permite usar uma fração de GPUs que funcionam isoladamente uma da outra.

Se a GPU já foi particionada, é possível implantar diretamente o JumpStartModel ou InferenceEndpointConfig usando a solução SageMaker HyperPod Inference.

Para JumpStartModels, use spec.server.acceleratorPartitionType para definir o perfil MIG de sua escolha:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: JumpStartModel
metadata:
  name: deepseek
spec:
  sageMakerEndpoint:
    name: deepseek
  model:
    modelHubName: SageMakerPublicHub
    modelId: deepseek-llm-r1-distill-qwen-1-5b
  server:
    acceleratorPartitionType: mig-7g.40gb
    instanceType: ml.p4d.24xlarge

O JumpStartModel também conduz validação interna antes da implantação do modelo. É possível desativar essa validação usando o campo spec.server.validations.acceleratorPartitionValidation no YAML e configurando-o como false.

Para InferenceEndpointConfig, implante o modelo no perfil MIG de sua escolha usando os campos spec.worker.resources.requests e spec.worker.resources.limits:

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
....
spec:
  worker:
    resources:
      requests:
        cpu: 5600m
        memory: 10Gi
        nvidia.com/mig-4g.71gb: 1
      limits:
        nvidia.com/mig-4g.71gb: 1

Com essas configurações, é possível usar outras tecnologias suportadas pelo SageMaker HyperPod Inference juntamente com a implantação do modelo em MIG. Para informações adicionais, consulte HyperPod agora oferece suporte a GPU Multi-Instance para maximizar utilização de GPU para tarefas de IA generativa.

Observabilidade

É possível monitorar métricas do HyperPod Inference através dos recursos de observabilidade do SageMaker HyperPod. Para habilitar esses recursos, siga as instruções em Acelere desenvolvimento de modelos de fundação com observabilidade com um clique no Amazon SageMaker HyperPod.

A observabilidade do HyperPod fornece dashboards integrados no Grafana. Por exemplo, o dashboard de Inferência oferece visibilidade em métricas relacionadas à inferência como Taxa de Requisições Recebidas, Latência e Tempo até Primeiro Byte (TTFB).

Executar notebooks em clusters HyperPod

Clusters HyperPod com orquestração Amazon EKS agora oferecem suporte à criação e gerenciamento de ambientes de desenvolvimento interativos como JupyterLab e Visual Studio Code de código aberto, simplificando o ciclo de vida de desenvolvimento de ML ao fornecer ambientes gerenciados para ferramentas familiares aos cientistas de dados.

Esse recurso introduz um novo complemento chamado Amazon SageMaker Spaces que permite aos desenvolvedores de IA criar e gerenciar ambientes autocontidos para executar notebooks. Agora é possível maximizar investimentos em GPU executando tanto cargas de trabalho interativas quanto seus trabalhos de treinamento na mesma infraestrutura, com suporte a alocações fracionais de GPU para melhorar eficiência de custos.

A AWS está introduzindo uma nova capacidade para clusters do SageMaker HyperPod EKS que permite aos desenvolvedores de IA executar cargas de trabalho interativas de aprendizado de máquina diretamente no cluster HyperPod EKS. Esse recurso apresenta um novo complemento chamado Amazon SageMaker Spaces que possibilita aos desenvolvedores de IA criar e gerenciar ambientes autocontidos para execução de notebooks.

Conclusão

O Amazon SageMaker HyperPod oferece uma infraestrutura escalável e eficiente em custos para executar cargas de trabalho de inferência. Seguindo as práticas recomendadas apresentadas neste artigo, é possível utilizar as capacidades do HyperPod para implantar modelos de fundação usando integração com JumpStart em um clique, S3 e FSx para Lustre, escalabilidade automática gerenciada com Karpenter e infraestrutura unificada que se expande dinamicamente de zero para produção.

Com recursos como cache KV, roteamento inteligente e suporte a GPU Multi-Instance, é possível otimizar cargas de trabalho de inferência, reduzindo latência, aumentando throughput e diminuindo custos usando Spot Instances. Ao adotar essas práticas recomendadas, as organizações podem acelerar fluxos de trabalho de aprendizado de máquina, melhorar desempenho de modelos e atingir reduções significativas no custo total de propriedade, permitindo escalar IA generativa de forma responsável e eficiente em ambientes de produção.

Fonte

Best practices to run inference on Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/best-practices-to-run-inference-on-amazon-sagemaker-hyperpod/)

Personalização inteligente de modelos com funções de recompensa

Construir funções de recompensa eficazes possibilita a personalização de modelos Amazon Nova conforme necessidades específicas de cada organização. O AWS Lambda oferece a base escalável e econômica para essa tarefa, permitindo que arquitetos se concentrem na definição de critérios de qualidade enquanto a infraestrutura computacional é gerenciada automaticamente.

A AWS disponibiliza múltiplas abordagens de personalização. O ajuste fino com reforço (RFT) destaca-se pela capacidade de ensinar ao modelo comportamentos desejados através de feedback iterativo. Diferentemente do ajuste fino supervisionado (SFT), que requer milhares de exemplos rotulados com caminhos de raciocínio anotados, o RFT aprende a partir de sinais de avaliação nas respostas finais.

No coração do RFT encontra-se a função de recompensa — um mecanismo de pontuação que guia o modelo em direção a respostas melhores. Este conceito central permite que os modelos aprendam quais comportamentos devem ser reforçados e quais devem ser evitados, sem necessidade de exemplos exaustivos de raciocínios corretos.

Comparando Abordagens de Aprendizado por Reforço

Quando usar Aprendizado Supervisionado (SFT)

O ajuste fino supervisionado funciona bem quando a organização possui exemplos claros de entrada e saída, e deseja ensinar padrões de resposta específicos. É particularmente eficaz para tarefas como classificação, reconhecimento de entidades nomeadas, ou adaptação de modelos a terminologia e convenções de formatação específicas do domínio.

Este método produz bons resultados quando o comportamento desejado pode ser demonstrado através de exemplos, tornando-o ideal para ensinar estilo consistente, estrutura ou transferência de conhecimento factual.

Quando usar Aprendizado por Reforço (RFT)

Alguns desafios de personalização requerem uma abordagem diferente. Quando aplicações precisam que modelos equilibrem múltiplas dimensões de qualidade simultaneamente — como respostas de atendimento ao cliente que devem ser precisas, empáticas, concisas e alinhadas à marca ao mesmo tempo — ou quando criar milhares de caminhos de raciocínio anotados se torna impraticável, métodos baseados em reforço oferecem uma alternativa melhor.

O RFT aborda esses cenários aprendendo a partir de sinais de avaliação em vez de requerer demonstrações rotuladas exaustivas de processos de raciocínio corretos. Funções de recompensa baseadas em Lambda simplificam essa implementação. Ao invés de mostrar ao modelo milhares de exemplos eficazes, a organização fornece prompts e define lógica de avaliação que pontua respostas — então o modelo aprende a melhorar através de feedback iterativo.

Esta abordagem requer menos exemplos rotulados enquanto oferece controle preciso sobre comportamentos desejados. Pontuação multidimensional captura critérios de qualidade nuançados que impedem modelos de explorar atalhos, enquanto a arquitetura serverless do Lambda gerencia cargas de trabalho de treinamento variáveis sem gerenciamento de infraestrutura.

Arquitetura de Funções de Recompensa com Lambda

O RFT utiliza AWS Lambda como um avaliador de recompensa serverless que se integra ao pipeline de treinamento do Amazon Nova, criando um loop de feedback que guia o aprendizado do modelo. O processo começa quando o trabalho de treinamento gera respostas candidatas do modelo Nova para cada prompt de treinamento.

Essas respostas fluem para a função Lambda, que avalia sua qualidade através de dimensões como correção, segurança, formatação e concisão. A função retorna então pontuações numéricas escalares — típicamente na faixa de -1 a 1 como melhor prática.

Pontuações mais altas guiam o modelo a reforçar os comportamentos que as produziram, enquanto pontuações mais baixas o guiam para longe de padrões que levaram a respostas pobres. Este ciclo se repete milhares de vezes durante o treinamento, moldando progressivamente o modelo para respostas que consistentemente ganham recompensas mais altas.

Componentes da Arquitetura

A arquitetura reúne vários serviços AWS em uma solução coesa. Lambda executa a lógica de avaliação de recompensa com escalabilidade automática que gerencia demandas variáveis de treinamento sem exigir provisionamento ou gerenciamento de infraestrutura. Amazon SageMaker AI oferece opções através de Trabalhos de Treinamento do SageMaker AI e HyperPod do SageMaker AI, ambos suportando as mesmas funções de recompensa baseadas em Lambda.

Amazon CloudWatch monitora o desempenho de Lambda em tempo real, registra informações detalhadas de depuração sobre distribuições de recompensa e progresso de treinamento, e dispara alertas quando problemas surgem. No fundamento encontra-se o Amazon Nova — modelos com receitas de personalização otimizadas que respondem efetivamente aos sinais de feedback que as funções de recompensa fornecem.

Escolhendo o Mecanismo de Recompensa Adequado

O fundamento do RFT bem-sucedido é escolher o mecanismo de feedback adequado. Aprendizado por Reforço via Recompensas Verificáveis (RLVR) e Aprendizado por Reforço via Feedback de IA (RLAIF) são duas técnicas utilizadas para ajuste fino de modelos de linguagem grande após seu treinamento inicial. Sua maior diferença está em como fornecem feedback ao modelo.

RLVR — Recompensas Verificáveis

RLVR usa código determinístico para verificar correção objetiva. É projetado para domínios onde uma resposta “correta” pode ser verificada matematicamente ou logicamente — por exemplo, resolver um problema de matemática. Esta abordagem usa funções determinísticas para atribuir pontuações em vez de um modelo de recompensa aprendido.

RLVR falha para tarefas como escrita criativa ou voz de marca onde nenhuma verdade absoluta existe. É ideal para: geração de código, raciocínio matemático, tarefas de saída estruturada. Exemplos incluem executar código gerado contra casos de teste, validar respostas da API, verificar precisão de cálculos.

A vantagem está na pontuação confiável, auditável e determinística. Funções RLVR verificam programaticamente a correção contra a verdade absoluta. Um exemplo prático implementa análise de sentimento verificável através de extração determinística de respostas e comparação com valores de referência.

RLAIF — Avaliação com IA

RLAIF usa modelos de IA como juízes para avaliação subjetiva. Alcança desempenho comparável ao aprendizado por reforço com feedback humano enquanto é significativamente mais rápido e menos custoso. É ideal para: escrita criativa, sumarização, alinhamento de voz de marca, utilidade. Exemplos incluem avaliar tom de resposta, avaliar qualidade de conteúdo, julgar alinhamento de intenção do usuário.

A vantagem é julgamento escalável semelhante ao humano sem custos de rotulação manual. Funções RLAIF delegam julgamento a modelos de IA capazes como um “juiz de linguagem”. Nesta implementação, um modelo disponibilizado via Bedrock atua como juiz comparando respostas e retornando pontuações numéricas.

Implementando Funções de Recompensa Robustas

Princípios de Design Essenciais

Ao escrever funções de recompensa para RFT, comece simples. Crie uma paisagem de recompensa suave — não binária com apenas acerto ou erro. Ao invés de simples passar/falhar (0 ou 1), use sinais de recompensa suave e densos que forneçam crédito parcial por estar “no caminho certo”.

Este feedback granular ajuda o modelo a aprender a partir de melhorias incrementais em vez de esperar por uma resposta perfeita. Para tarefas complexas e multi-etapa, forneça recompensas para progresso intermediário (moldagem) em vez de apenas o resultado final (escasso).

Saiba exatamente qual é o aspecto do sucesso. Implemente múltiplas estratégias de análise que lidam graciosamente com vários formatos de resposta. Valide entradas a cada passo usando práticas de código defensivo que previnem travamentos de entradas malformadas.

Evitando Exploração de Recompensas

Uma única pontuação escalar é facilmente explorada. A recompensa deve avaliar o desempenho do modelo em múltiplas dimensões: correção, fidelidade à entrada, alinhamento com políticas de segurança, formatação e concisão. Garanta que o modelo não possa obter altas recompensas através de atalhos — por exemplo, palpites de sorte ou ações repetitivas.

Para tarefas objetivas como geração de código ou matemática, use avaliadores automatizados que executem o código ou analisem tags de resposta específicas para verificar correção sem humano no loop. Quando código programático não consegue julgar a resposta — como em sumarização — use um modelo separado e capaz como um “juiz de linguagem”.

Otimização em Escala de Treinamento

Configuração de Lambda para Performance

Uma vez que a função de recompensa funciona corretamente, otimização ajuda a treinar mais rápido enquanto controla custos. Técnicas de otimização combinam seu impacto — uma função Lambda bem-configurada com dimensionamento apropriado de lotes, configurações de concorrência, mitigação de inicialização fria e tratamento de erros pode avaliar respostas dez vezes mais rápido que uma implementação ingênua enquanto custa significativamente menos e fornece melhor confiabilidade de treinamento.

Defina timeout para 60 segundos (padrão é apenas 3 segundos) fornecendo espaço livre para chamadas de juiz RLAIF ou lógica RLVR complexa. Configure memória para 512 MB (padrão é 128 MB) — CPU acelerada melhora desempenho de tempo de resposta.

Mitigação de Inicialização Fria

A inicialização fria evita picos de latência que podem desacelerar treinamento e aumentar custos. Mantenha pacotes de implantação abaixo de 50MB para minimizar tempo de inicialização — frequentemente significa excluir dependências desnecessárias e usar camadas Lambda para bibliotecas compartilhadas grandes.

Reutilize conexões entre invocações inicializando clientes como o cliente runtime de Bedrock em escopo global ao invés de dentro da função manipuladora, permitindo que o ambiente de execução de Lambda mantenha essas conexões entre invocações. Perfil da função usando Lambda Insights para identificar gargalos de performance.

Armazene em cache dados frequentemente acessados como rubrica de avaliação, regras de validação ou parâmetros de configuração em escopo global para que Lambda os carregue uma vez por container ao invés de em cada invocação. Este padrão de inicialização global com execução em nível de manipulador prova ser particularmente eficaz para funções Lambda lidando com milhares de avaliações durante treinamento.

Gerenciamento de Dependências

As dependências podem ser incluídas diretamente com código em um pacote de implantação (arquivo .zip) ou utilizar camadas Lambda para gerenciar dependências separadamente da lógica principal. Use camadas para dependências compartilhadas entre múltiplas funções e pacotes de implantação para lógica específica da função.

Para implementações RLAIF, o papel de execução da função Lambda deve ter acesso a Bedrock para chamadas de API de LLM. Seguindo o princípio de menor privilégio, escope a ARN de Resource para o modelo de fundação específico que está sendo usado como juiz em vez de usar um curinga.

Monitoramento e Depuração com CloudWatch

Visibilidade no processo de treinamento é essencial tanto para monitorar progresso quanto para troubleshooting de problemas. Informações abrangentes são automaticamente registradas em CloudWatch para cada estágio do pipeline de treinamento: métricas de cada etapa de treinamento — incluindo pontuações de recompensa por etapa e traces de execução detalhadas para cada componente do pipeline.

Este registro granular torna direto rastrear progresso de treinamento em tempo real, verificar que a função de recompensa está pontuando respostas conforme esperado, e rapidamente diagnosticar problemas quando surgem. Se o treinamento não estiver melhorando, pode-se examinar as distribuições de recompensa em CloudWatch para ver se a função está retornando principalmente zeros ou se há sinal insuficiente.

Consultas Amazon CloudWatch Insights úteis incluem: encontrar amostras com recompensas zero, calcular distribuição de recompensas em faixas, identificar avaliações lentas acima de limiares de tempo, e rastrear métricas multidimensionais como correção, formatação, segurança e concisão ao longo do tempo.

Começando com a Implementação

A abordagem de funções de recompensa baseadas em Lambda desbloqueiam personalização de Amazon Nova para organizações que precisam de controle comportamental preciso sem datasets massivos rotulados. Isto entrega vantagens significativas através de flexibilidade, escalabilidade e custo-efetividade que simplificam o processo de personalização do modelo.

A arquitetura permite RLVR para lidar com tarefas de verificação objetiva enquanto RLAIF auxilia com julgamento subjetivo para avaliações de qualidade nuançadas. Organizações podem usá-las individualmente ou combiná-las para avaliação abrangente que capture tanto precisão factual quanto preferências estilísticas.

Escalabilidade emerge naturalmente da fundação serverless, gerenciando automaticamente cargas de trabalho de treinamento variáveis desde experimentação inicial através de personalização em escala de produção. Custo-efetividade flui diretamente deste design — organizações pagam apenas por computação de avaliação real, com trabalhos de treinamento completando mais rápido devido a concorrência otimizada de Lambda e cálculo eficiente de recompensas.

A combinação de modelos de fundação Amazon Nova, escalabilidade serverless de Lambda, e infraestrutura de personalização gerenciada do Bedrock torna ajuste fino com reforço mais acessível independentemente da escala organizacional. O caminho para começar é experimentar com exemplos de código e iniciar a personalização de modelos Amazon Nova que entregam exatamente os comportamentos que as aplicações necessitam.

Fonte

How to build effective reward functions with AWS Lambda for Amazon Nova model customization (https://aws.amazon.com/blogs/machine-learning/how-to-build-effective-reward-functions-with-aws-lambda-for-amazon-nova-model-customization/)

Observabilidade Unificada no OpenSearch

A AWS expandiu as capacidades do Amazon OpenSearch Service com uma abordagem integrada para observabilidade. O serviço agora oferece uma experiência unificada que reúne métricas, logs, rastreamentos e rastreamento de agentes de IA em um único ponto de acesso. Essa mudança representa uma resposta direta a dois grandes desafios enfrentados por times de operação: os custos proibitivos de plataformas premium de observabilidade e a complexidade operacional causada pelo uso de múltiplas ferramentas desintegradas.

Capacidades Principais

Integração Nativa com Prometheus

O OpenSearch agora oferece integração nativa com o Amazon Managed Service for Prometheus, permitindo que engenheiros de confiabilidade do site, especialistas em DevOps e times de engenharia de plataforma façam consultas de métricas do Prometheus diretamente usando a sintaxe nativa PromQL (Prometheus Query Language) ao lado de logs e rastreamentos na interface de observabilidade do OpenSearch. Tudo isso ocorre sem necessidade de duplicação de dados, eliminando um dos maiores gargalos de observabilidade tradicional.

Monitoramento Avançado com RED Metrics

A solução incorpora fluxos de trabalho de monitoramento de aplicações potencializados por RED metrics (Métricas de Taxa, Erros e Duração), além de rastreamento de agentes de IA utilizando convenções semânticas OpenTelemetry para IA generativa. Isso permite que times de operação correlacionem rastreamentos lentos com logs de aplicação, sobreponham métricas do Prometheus em dashboards de serviços e rastreiem a execução de agentes LLM, tudo sem necessidade de trocar de ferramentas.

Economia de Custos e Performance

A arquitetura de consulta em tempo real entrega redução significativa de custos comparada a plataformas premium, mantendo excelência operacional. Times podem consolidar sua stack de observabilidade sem os custos de duplicação de dados ou a perda de produtividade causada pela troca constante entre múltiplas ferramentas.

Disponibilidade Regional

A nova experiência unificada de observabilidade está disponível na interface do OpenSearch em 20 regiões da AWS: US East (N. Virginia, Ohio), US West (N. California, Oregon), Asia Pacific (Hong Kong, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm), Canada (Central) e South America (São Paulo).

Próximos Passos

Para aprofundar-se sobre essa capacidade, a AWS disponibiliza documentação técnica completa. Você pode acessar a documentação de observabilidade do OpenSearch Service e a documentação sobre consultas diretas para detalhes de implementação e configuração.

Fonte

Amazon OpenSearch Service supports Managed Prometheus and agent tracing (https://aws.amazon.com/about-aws/whats-new/2026/04/opensearch-managed-prometheus-agent-tracing/)

Interatividade Bidimensional em Agentes de IA

A construção de agentes de IA oferece desafios significativos quando os fluxos de trabalho precisam pausar durante a execução para solicitar esclarecimentos ao usuário, gerar conteúdo via modelo de linguagem ou fornecer atualizações de progresso em operações de longa duração. Até recentemente, servidores MCP sem estado não conseguiam lidar com esses cenários, criando uma limitação fundamental para aplicações reais.

A AWS identificou essa lacuna e anunciou novidades importantes. O Amazon Bedrock AgentCore Runtime agora oferece suporte a três capacidades do cliente definidas na especificação MCP (Protocolo de Contexto de Modelo):

• Elicitação: solicitação de entrada do usuário durante a execução
• Amostragem: solicitação de conteúdo gerado por LLM do cliente
• Notificações de progresso: transmissão de atualizações em tempo real

Essas capacidades transformam a execução de ferramentas em sentido único em conversas bidirecionais entre o servidor MCP e os clientes.

Do Stateless ao Stateful: Uma Evolução Necessária

O Modelo Anterior: Stateless MCP

A implementação anterior do suporte MCP no AgentCore funcionava em modo sem estado: cada requisição HTTP era independente, sem contexto compartilhado entre chamadas. Esse modelo é simples de implementar e funciona bem para servidores de ferramentas que recebem entradas e retornam saídas.

Porém, possui uma restrição fundamental. O servidor não consegue manter uma conversa entre requisições, solicitar esclarecimentos do usuário durante a execução de uma ferramenta ou reportar progresso conforme o trabalho ocorre.

O Novo Paradigma: Stateful MCP

O modo stateful remove essas limitações. Quando você executa seu servidor MCP com stateless_http=False, o AgentCore Runtime provisiona uma máquina virtual dedicada para cada sessão de usuário. Essa máquina virtual persiste pela duração da sessão (até 8 horas, ou 15 minutos de inatividade conforme a configuração idleRuntimeSessionTimeout), com isolamento de CPU, memória e sistema de arquivos entre sessões.

O protocolo mantém a continuidade através de um header Mcp-Session-Id: o servidor retorna este identificador durante o handshake de inicialização, e o cliente o inclui em toda requisição subsequente para rotear de volta à mesma sessão.

A mudança de configuração para ativar o modo stateful é um único parâmetro na inicialização do servidor:

mcp.run(
    transport="streamable-http",
    host="0.0.0.0",
    port=8000,
    stateless_http=False  # Ativa modo stateful
)

Além desse parâmetro, as três capacidades do cliente ficam disponíveis automaticamente quando o cliente MCP declara suporte durante o handshake de inicialização.

Três Capacidades Essenciais para Workflows Produtivos

Elicitação: Coletando Entrada do Usuário em Tempo Real

A elicitação permite que um servidor pause a execução e solicite entrada estruturada do usuário através do cliente. A ferramenta consegue fazer perguntas direcionadas no momento certo do fluxo, coletando preferências, confirmando decisões ou reunindo valores que dependem de resultados anteriores.

O servidor envia uma requisição elicitation/create com uma mensagem e um esquema JSON opcional descrevendo a estrutura de resposta esperada. O cliente renderiza uma interface de entrada apropriada, e o usuário pode aceitar (fornecendo os dados), declinar ou cancelar.

Um exemplo prático é a ferramenta add_expense_interactive, que coleta uma despesa através de quatro etapas sequenciais de elicitação: valor, descrição, categoria e confirmação final antes de escrever no Amazon DynamoDB.

import os
from pydantic import BaseModel
from fastmcp import FastMCP, Context
from fastmcp.server.elicitation import AcceptedElicitation
from dynamo_utils import FinanceDB

mcp = FastMCP(name='ElicitationMCP')
_region = os.environ.get('AWS_REGION') or os.environ.get('AWS_DEFAULT_REGION') or 'us-east-1'
db = FinanceDB(region_name=_region)

class AmountInput(BaseModel):
    amount: float

class DescriptionInput(BaseModel):
    description: str

class CategoryInput(BaseModel):
    category: str

class ConfirmInput(BaseModel):
    confirm: str

@mcp.tool()
async def add_expense_interactive(user_alias: str, ctx: Context) -> str:
    """Interactively add a new expense using elicitation."""
    result = await ctx.elicit('How much did you spend?', AmountInput)
    if not isinstance(result, AcceptedElicitation):
        return 'Expense entry cancelled.'
    amount = result.data.amount

    result = await ctx.elicit('What was it for?', DescriptionInput)
    if not isinstance(result, AcceptedElicitation):
        return 'Expense entry cancelled.'
    description = result.data.description

    result = await ctx.elicit(
        'Select a category (food, transport, bills, entertainment, other):',
        CategoryInput
    )
    if not isinstance(result, AcceptedElicitation):
        return 'Expense entry cancelled.'
    category = result.data.category

    confirm_msg = (
        f'Confirm: add expense of ${amount:.2f} for {description}'
        f' (category: {category})? Reply Yes or No'
    )
    result = await ctx.elicit(confirm_msg, ConfirmInput)
    if not isinstance(result, AcceptedElicitation) or result.data.confirm != 'Yes':
        return 'Expense entry cancelled.'
    
    return db.add_transaction(user_alias, 'expense', -abs(amount), description, category)

if __name__ == '__main__':
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=8000,
        stateless_http=False
    )

No cliente, registrar um elicitation_handler tanto ativa o handler quanto declara suporte ao servidor durante a inicialização. Cada await ctx.elicit() suspende a ferramenta e envia uma requisição elicitation/create sobre a sessão ativa. A verificação isinstance(result, AcceptedElicitation) trata declínio e cancelamento uniformemente em cada etapa.

Use elicitação quando sua ferramenta precisa de informações que dependem de resultados anteriores, são melhor coletadas interativamente do que antecipadamente, ou variam entre usuários de forma que não pode ser parametrizada de antemão.

Amostragem: Delegando Geração de Conteúdo ao LLM do Cliente

A amostragem permite que um servidor MCP solicite uma conclusão gerada por LLM do cliente. O servidor envia uma requisição sampling/createMessage contendo uma lista de mensagens de conversa, um prompt do sistema e preferências opcionais de modelo. O cliente encaminha a requisição para seu modelo de linguagem conectado e retorna a resposta gerada.

O grande diferencial é que o servidor não precisa de chaves de API ou integração direta com modelo. O cliente retém controle total sobre qual modelo é usado, e a especificação MCP prevê uma etapa de verificação humana onde usuários podem revisar e aprovar requisições de amostragem antes do envio.

Um exemplo prático é a ferramenta analyze_spending, que recupera transações do DynamoDB, constrói um prompt com os dados estruturados e delega a análise ao LLM do cliente:

@mcp.tool()
async def analyze_spending(user_alias: str, ctx: Context) -> str:
    """Fetch expenses from DynamoDB and ask the client's LLM to analyse them."""
    transactions = db.get_transactions(user_alias)
    if not transactions:
        return f'No transactions found for {user_alias}.'
    
    lines = '\n'.join(
        f"- {t['description']} (${abs(float(t['amount'])):.2f}, {t['category']})"
        for t in transactions
    )
    prompt = (
        f'Here are the recent expenses for a user:\n{lines}\n\n'
        f'Please analyse the spending patterns and give 3 concise, '
        f'actionable recommendations to improve their finances. '
        f'Keep the response under 120 words.'
    )
    
    ai_analysis = 'Analysis unavailable.'
    try:
        response = await ctx.sample(messages=prompt, max_tokens=300)
        if hasattr(response, 'text') and response.text:
            ai_analysis = response.text
    except Exception:
        pass
    
    return f'Spending Analysis for {user_alias}:\n\n{ai_analysis}'

No cliente, o sampling_handler recebe o prompt do servidor e o encaminha a um modelo de linguagem. Registrar o handler também é como o cliente declara suporte de amostragem ao servidor durante inicialização.

Use amostragem quando sua ferramenta deve produzir saída em linguagem natural que se beneficia das capacidades de um modelo de linguagem. Um exemplo: ferramenta que coletou preferências de viagem do usuário e quer gerar uma narrativa de itinerário personalizada. Amostragem não é apropriada para operações determinísticas como consultas a banco de dados ou cálculos com saídas bem definidas — use lógica de ferramenta para esses casos.

Notificações de Progresso: Visibilidade em Tempo Real

As notificações de progresso são eventos que um servidor emite durante operações de longa duração para manter o cliente e o usuário informados sobre quanto trabalho foi concluído. await ctx.report_progress(progress, total) emite uma mensagem notifications/progress e retorna imediatamente. O servidor não espera por resposta — é fire-and-forget em ambas as direções.

O padrão é chamar report_progress em cada etapa lógica de uma operação multi-estágio, com o progresso incrementando em direção ao total. A ferramenta generate_report constrói um relatório financeiro mensal em cinco etapas, emitindo notificação de progresso no início de cada uma:

import os
from fastmcp import FastMCP, Context
from dynamo_utils import FinanceDB

mcp = FastMCP(name='Progress-MCP-Server')
_region = os.environ.get('AWS_REGION') or os.environ.get('AWS_DEFAULT_REGION') or 'us-east-1'
db = FinanceDB(region_name=_region)

@mcp.tool()
async def generate_report(user_alias: str, ctx: Context) -> str:
    """Generate a monthly financial report, streaming progress at each stage."""
    total = 5
    
    # Step 1: Fetch transactions
    await ctx.report_progress(progress=1, total=total)
    transactions = db.get_transactions(user_alias)
    
    # Step 2: Group by category
    await ctx.report_progress(progress=2, total=total)
    by_category = {}
    for t in transactions:
        cat = t['category']
        by_category[cat] = by_category.get(cat, 0) + abs(float(t['amount']))
    
    # Step 3: Fetch budgets
    await ctx.report_progress(progress=3, total=total)
    budgets = {b['category']: float(b['monthly_limit']) for b in db.get_budgets(user_alias)}
    
    # Step 4: Compare spending vs budgets
    await ctx.report_progress(progress=4, total=total)
    lines = []
    for cat, spent in sorted(by_category.items(), key=lambda x: -x[1]):
        limit = budgets.get(cat)
        if limit:
            pct = (spent / limit) * 100
            status = 'OVER' if spent > limit else 'OK'
            lines.append(f' {cat:<15} ${spent:>8.2f} / ${limit:.2f} [{pct:.0f}%] {status}')
        else:
            lines.append(f' {cat:<15} ${spent:>8.2f} (no budget set)')
    
    # Step 5: Format and return
    await ctx.report_progress(progress=5, total=total)
    total_spent = sum(by_category.values())
    
    return (
        f'Monthly Report for {user_alias}\n'
        f'{"=" * 50}\n'
        f' {"Category":<15} {"Spent":>10} {"Budget":>8} Status\n'
        f'{"-" * 50}\n'
        + '\n'.join(lines)
        + f'\n{"-" * 50}\n'
        f' {"TOTAL":<15} ${total_spent:>8.2f}\n'
    )

if __name__ == '__main__':
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=8000,
        stateless_http=False
    )

No cliente, o progress_handler recebe progresso, total e uma mensagem opcional cada vez que o servidor emite notificação. O cliente consegue renderizar uma barra de progresso ou indicador de status, mantendo o usuário informado em vez de observar uma tela em branco.

Use notificações de progresso para qualquer chamada de ferramenta que leva mais alguns segundos e envolve etapas discretas mensuráveis. Operações como buscar em múltiplas fontes de dados, executar sequências de chamadas de API, processar lotes de registros ou executar fluxos de reserva multi-etapa são bons candidatos. Uma ferramenta que completa em menos de um segundo geralmente não precisa de relatório de progresso.

Primeiros Passos na Prática

Para começar a explorar essas capacidades, a AWS disponibiliza recursos técnicos de referência. O código de exemplo no GitHub inclui configuração completa do DynamoDB e deployment no AgentCore. A documentação do Amazon Bedrock AgentCore Runtime oferece guias detalhados, enquanto a documentação de funcionalidades stateful do MCP cobre especificações técnicas. Também recomenda-se consultar a especificação completa do MCP para entender o protocolo subjacente.

A implementação dessas capacidades representa evolução significativa na construção de agentes de IA interativos, oferecendo infraestrutura gerenciada e isolada para workflows bidirecionais.

Fonte

Introducing stateful MCP client capabilities on Amazon Bedrock AgentCore Runtime (https://aws.amazon.com/blogs/machine-learning/introducing-stateful-mcp-client-capabilities-on-amazon-bedrock-agentcore-runtime/)

Por que incorporar Live View em sua aplicação

Quando você constrói aplicações com IA, uma questão fundamental emerge: como seus usuários podem confiar em agentes que navegam de forma autônoma pela web? Quando um agente interage com conteúdo web por conta própria, os usuários precisam enxergar o que está acontecendo para manter controle e confiança — capacidades que hoje faltam na maioria das implementações.

A Amazon Bedrock AgentCore Browser agora oferece uma solução para esse desafio através do componente BrowserLiveView. Este componente fornece um feed de vídeo em tempo real da sessão de navegação do agente diretamente dentro de sua aplicação React. Trata-se de um recurso que faz parte do Bedrock AgentCore TypeScript SDK, permitindo que você integre um stream de browser ao vivo com apenas três linhas de código.

O componente BrowserLiveView utiliza o protocolo Amazon DCV para renderizar a sessão do browser, criando transparência completa das ações do agente. A implementação requer apenas uma URL pré-assinada do seu servidor, sem necessidade de construir infraestrutura de streaming do zero.

Incorporar o Live View dentro de sua própria aplicação desbloqueia valor adicional para seus usuários em escala. Com o Live View embutido, seus usuários acompanham cada navegação, cada envio de formulário e cada busca conforme o agente as realiza. Eles recebem confirmação visual imediata de que o agente está na página correta, interagindo com os elementos apropriados e avançando pelo fluxo de trabalho.

Essa retroalimentação em tempo real oferece aos usuários finais visibilidade direta do comportamento do agente sem ter que esperar pelo resultado final. Usuários que delegam tarefas de navegação para um agente de IA sentem-se mais seguros quando conseguem observar o trabalho acontecendo. Observar o agente preenchendo um formulário campo por campo é mais tranquilizador do que receber apenas uma confirmação textual.

Para fluxos de trabalho regulamentados, a evidência visual das ações do agente pode atender a requisitos de auditoria. Em workflows que exigem supervisão humana — como lidar com contas de clientes e processar dados sensíveis — um supervisor pode utilizar o Live View embutido para observar o agente em tempo real e intervir se necessário, tudo sem sair de sua aplicação.

As organizações também ganham suporte a trilhas de auditoria através de evidência visual das ações do agente, valor essencial para conformidade regulatória e cenários de troubleshooting. Combinada com gravações de sessão para Amazon Simple Storage Service (Amazon S3) e replay de sessão baseado em console, você obtém tanto observação em tempo real quanto revisão posterior.

Como funciona a arquitetura

A integração possui três componentes principais:

No browser do usuário: Uma aplicação React contém o componente BrowserLiveView, que recebe uma URL pré-assinada com credenciais SigV4 e estabelece uma conexão WebSocket persistente para receber o stream de vídeo DCV da sessão de browser remoto. A aplicação React gerencia a renderização de vídeo e apresentação da interface enquanto mantém a conexão WebSocket para streaming contínuo.

No servidor de aplicação: Funciona como um agente de IA dentro do ciclo de vida da sessão Amazon Bedrock, orquestrando a conexão entre browsers do cliente e sessões de browser hospedadas na nuvem. Ele inicia sessões usando a API Amazon Bedrock AgentCore e gera URLs pré-assinadas com SigV4 que concedem acesso seguro e limitado no tempo ao stream Live View. Esta camada gerencia autenticação, autenticação e distribuição de stream.

Na nuvem AWS: Hospeda Amazon Bedrock AgentCore Browser e serviços Amazon Bedrock que fornecem as capacidades subjacentes de automação de browser e streaming. O Amazon Bedrock AgentCore hospeda as sessões de browser isoladas dentro da nuvem AWS, oferecendo tanto o endpoint de automação (usando o Playwright Chrome DevTools Protocol) quanto o endpoint de streaming Live View (DCV).

A vantagem de eficiência-chave nesta arquitetura é que o stream Live View DCV flui diretamente de Amazon Bedrock AgentCore para o browser do usuário. Ele não passa pelo seu servidor de aplicação. Seu servidor gera a URL e executa o agente, mas o stream de vídeo é uma conexão WebSocket direta da AWS para o cliente. Isso ajuda a minimizar latência e reduzir requisitos de infraestrutura.

Implementação passo a passo

Pré-requisitos

Antes de começar, verifique se você possui:

• Node.js 20 ou posterior
• Uma conta AWS em uma região AWS suportada
• Credenciais AWS com permissões Amazon Bedrock AgentCore Browser
• Acesso a um modelo de IA para dirigir o agente (este artigo usa a Amazon Bedrock Converse API com Anthropic Claude, mas Live View é agnóstico a modelo e você pode usar qualquer provedor ou framework de sua escolha)

Observação importante: Live View (Passos 1 e 2) requer apenas permissões Amazon Bedrock AgentCore. Ele não depende de Amazon Bedrock ou nenhum modelo de IA específico. O agente de IA no Passo 3 usa a Amazon Bedrock Converse API, que requer permissões adicionais de Amazon Bedrock, mas isto é específico ao nosso exemplo. Você pode substituir por um provedor de modelo ou framework de agente de sua escolha.

Use credenciais temporárias do AWS IAM Identity Center ou AWS Security Token Service (AWS STS). Não use chaves de acesso de longa duração. Siga o princípio do menor privilégio ao configurar permissões AWS Identity and Access Management (IAM).

Instale o Amazon Bedrock AgentCore TypeScript SDK:

npm install bedrock-agentcore

Para o agente de IA no Passo 3, você também precisa do AWS SDK para JavaScript:

npm install @aws-sdk/client-bedrock-runtime

O código neste artigo executa em dois ambientes: código servidor (Passos 1 e 3) executa em Node.js, e código cliente (Passo 2) executa em uma aplicação React empacotada com Vite.

Passo 1: Inicie uma sessão de browser e gere a URL Live View

No seu servidor de aplicação, use a classe Browser para iniciar uma sessão e gerar a URL pré-assinada. A API retorna um identificador de sessão e URL de streaming, que o servidor converte em uma URL pré-assinada com tempo de expiração definido (300 segundos por padrão). Ela contém credenciais SigV4 nos parâmetros de query, portanto nenhum segredo atinge o browser. Passe esta URL para seu frontend através de um endpoint de API.

import { Browser } from 'bedrock-agentcore/browser'

const browser = new Browser({ region: 'us-west-2' })

await browser.startSession({ viewport: { width: 1920, height: 1080 } })

const signedUrl = await browser.generateLiveViewUrl()

// Send signedUrl to your frontend via API

Passo 2: Renderize o componente BrowserLiveView em sua aplicação React

No seu browser, importe o componente BrowserLiveView do Bedrock AgentCore TypeScript SDK e renderize-o com a URL pré-assinada. O componente gerencia conexão WebSocket, negociação do protocolo DCV, decodificação do stream de vídeo e renderização de frames. Ele se adapta automaticamente para caber em seu container pai enquanto preserva a proporção de aspecto. Os valores remoteWidth e remoteHeight devem corresponder ao viewport definido no Passo 1. Valores incompatíveis causam corte ou barras pretas.

import { BrowserLiveView } from 'bedrock-agentcore/browser/live-view'

Após adicionar este componente, o Live View começa a fazer streaming assim que a URL pré-assinada é válida e a sessão de browser está ativa. Você deve ver o desktop do browser remoto aparecer dentro do container do componente. Se o container permanecer vazio, verifique se a URL pré-assinada não expirou e se a sessão de browser ainda está em execução.

Passo 3: Conecte um agente de IA para dirigir as ações do browser

Com o Live View já fazendo streaming, você precisa de algo interessante para observar. O exemplo a seguir usa a Amazon Bedrock Converse API, mas Live View é agnóstico a modelo. Você pode usar um modelo de IA ou framework de agente de sua escolha para dirigir o browser. O código cria um cliente PlaywrightBrowser, que inicia uma nova sessão AgentCore Browser e se conecta a ela usando o protocolo Playwright Chrome DevTools. Trata-se do mesmo tipo de sessão de browser em nuvem do Passo 1, mas acessado através da interface de automação Playwright em vez da interface Live View. O modelo decide quais ferramentas de browser chamar, incluindo navigate, click, type, getText, getHtml e pressKey. Seu servidor executa essas ferramentas e alimenta os resultados de volta ao modelo para a próxima iteração.

import { BedrockRuntimeClient, ConverseCommand } from '@aws-sdk/client-bedrock-runtime'
import { PlaywrightBrowser } from 'bedrock-agentcore/browser/playwright'

const browser = new PlaywrightBrowser({ region: 'us-west-2' })

await browser.startSession()

// Define browser tools as JSON Schema
// (navigate, click, type, getText, and more)

while (step < maxSteps) {
  const response = await bedrockClient.send(
    new ConverseCommand({
      modelId: modelId,
      system: [{ text: systemPrompt }],
      messages,
      toolConfig: browserTools,
    })
  )

  if (response.stopReason === 'tool_use') {
    // Run browser tool, add result
    // to conversation, continue loop
  } else {
    break // Final answer from model
  }
}

O modelo é configurável. Você pode usar Anthropic Claude, Amazon Nova ou outro modelo Amazon Bedrock que suporte uso de ferramentas. Cada chamada de ferramenta que o modelo faz fica visível ao seu usuário através do Live View. Ele vê o browser navegar, a caixa de busca preencher e a página de resultados carregar.

Observação: O TypeScript SDK também inclui uma integração Vercel AI SDK (BrowserTools) que envolve essas operações de browser como ferramentas nativas do framework.

Testando com a aplicação de exemplo

A AWS construiu uma aplicação de exemplo completa no GitHub que integra os Passos 1–3. A amostra inclui um dashboard React com o Live View embutido, um log de atividades mostrando raciocínio e ações do agente, e um servidor Fastify executando o agente de IA. O agente navega para Wikipedia, busca um tópico, lê o conteúdo da página e resume o que encontra enquanto você observa cada passo.

Clonando e executando a aplicação de exemplo

Siga os passos abaixo para clonar e executar a aplicação de exemplo:

Etapa 1: Clone o repositório e navegue para a pasta de exemplo.

git clone https://github.com/awslabs/bedrock-agentcore-samples-typescript.git
cd bedrock-agentcore-samples-typescript
cd use-cases/browser-live-view-agent

Etapa 2: Instale as dependências.

npm install

Etapa 3: Exporte suas credenciais AWS.

export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export AWS_SESSION_TOKEN=
export AWS_REGION=us-west-2

Importante: Use credenciais temporárias. Não faça commit de credenciais no controle de versão.

Etapa 4: Inicie a aplicação.

npm run dev

Etapa 5: Abra http://localhost:5173, digite um prompt e escolha Launch Agent.

Configuração do bundler

O componente BrowserLiveView utiliza o Amazon DCV Web Client SDK, que distribui arquivos vendored dentro do pacote npm bedrock-agentcore. Você não precisa baixar ou instalar DCV separadamente. Sua configuração Vite precisa de três adições:

• resolve.alias aponta os identificadores bare dcv e dcv-ui para os arquivos SDK vendored.
• resolve.dedupe verifica que React e dependências compartilhadas são resolvidas de seu node_modules, não do caminho vendored.
• viteStaticCopy copia os arquivos de runtime DCV (workers, decodificadores WASM) para sua saída de build.

O arquivo vite.config.ts da aplicação de exemplo possui a configuração completa pronta para usar. Para mais detalhes sobre o componente BrowserLiveView, consulte a pasta source live-view no TypeScript SDK.

Limpando recursos

Para evitar incorrer em cobranças, pare a sessão de browser e desligue a aplicação quando terminar:

• Na interface da aplicação, escolha Stop Session para encerrar a sessão Amazon Bedrock AgentCore Browser.
• No seu terminal, pressione Ctrl+C para parar os servidores de desenvolvimento.
• Se você criou funções ou políticas IAM especificamente para esta demonstração, delete-as do console IAM.

As sessões Amazon Bedrock AgentCore Browser incorrem em cobranças enquanto ativas. Para detalhes de preços, consulte a página de preços Amazon Bedrock AgentCore.

Próximos passos

Agora que você tem uma integração Live View funcional, aqui estão algumas coisas para explorar.

Para começar, clone a aplicação de exemplo, preencha suas credenciais AWS e execute npm run dev para ver a demonstração completa em ação. Para instruções, consulte a seção Como clonar e executar a aplicação de exemplo neste artigo.

A aplicação de exemplo usa Anthropic Claude por padrão, mas você pode trocar para Amazon Nova ou outro modelo Amazon Bedrock que suporte uso de ferramentas definindo a variável de ambiente BEDROCK_MODEL_ID. Para uma lista de modelos disponíveis e suas capacidades de uso de ferramentas, consulte a documentação de modelos Amazon Bedrock.

O dashboard React na aplicação de exemplo é um ponto de partida para sua própria implementação. Você pode adaptar o layout para corresponder ao seu sistema de design, integrar o Live View em uma aplicação existente ou adicionar controles que permitam aos usuários intervir no meio do fluxo de trabalho. Para orientação sobre construção de aplicações React com o AgentCore SDK, consulte a documentação do Bedrock AgentCore TypeScript SDK.

O componente BrowserLiveView suporta múltiplas instâncias na mesma página, cada uma fazendo streaming de uma sessão de browser diferente. Esta capacidade é útil para dashboards de monitoramento. O código-fonte do componente, incluindo lógica de scaling e fluxo de autenticação DCV, está disponível na pasta source live-view no TypeScript SDK.

Conclusão

Neste artigo, você aprendeu como usar o componente BrowserLiveView para incorporar uma visualização ao vivo de uma sessão Amazon Bedrock AgentCore Browser dentro de sua aplicação React. A implementação em três passos e a arquitetura que transmite vídeo diretamente da AWS para browsers do cliente tornam a visualização de agentes ao vivo acessível sem necessidade de expertise em streaming especializado.

Para uma análise mais profunda das capacidades de Amazon Bedrock AgentCore Browser, consulte a documentação Amazon Bedrock AgentCore Browser. Se tiver feedback ou perguntas, abra uma issue no repositório GitHub.

Importante: Esta aplicação de exemplo destina-se a desenvolvimento local e demonstração. Para uso em produção, adicione autenticação aos seus endpoints de API, habilite HTTPS, restrinja origens CORS, implemente rate limiting e siga o pilar de segurança da AWS Well-Architected Framework.

Fonte

Embed a live AI browser agent in your React app with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/embed-a-live-ai-browser-agent-in-your-react-app-with-amazon-bedrock-agentcore/)

Por Que Entender o Ciclo de Vida dos Modelos?

A AWS libera regularmente novas versões de modelos de fundação (FM – Foundation Models) no Bedrock, trazendo melhorias em capacidades, precisão e segurança. Para quem constrói aplicações de IA sobre essa plataforma, compreender como funcionam essas transições entre versões é fundamental. Não se trata apenas de ficar atualizado: é sobre garantir que suas aplicações continuem funcionando conforme os modelos evoluem, planejando migrações de forma estratégica e sem interrupções indesejadas.

Antes de migrar suas aplicações para novos modelos, você pode testá-los através do console do Amazon Bedrock ou via API para avaliar desempenho e compatibilidade. Este guia explora como gerenciar essas transições de forma planejada, abordando os três estados do ciclo de vida, a nova feature de acesso estendido e práticas concretas para transicionar suas aplicações sem disrupções.

Os Três Estados do Ciclo de Vida

Um modelo oferecido no Amazon Bedrock pode existir em um dos três estados: Ativo, Legado ou Fim de Vida (End-of-Life – EOL). O status atual é visível tanto no console do Amazon Bedrock quanto nas respostas das APIs. Por exemplo, quando você faz uma chamada GetFoundationModel ou ListFoundationModels, o estado do modelo aparece no campo modelLifecycle da resposta.

Estado Ativo (Active)

Modelos ativos recebem manutenção contínua, atualizações e correções de bugs dos seus fornecedores. Enquanto um modelo está neste estado, você pode utilizá-lo para inferência através de APIs como InvokeModel ou Converse, personalizá-lo caso suportado e solicitar aumentos de cota através do AWS Service Quotas.

Estado Legado (Legacy)

Quando um fornecedor de modelo transiciona para o estado Legado, a AWS notifica seus clientes com no mínimo 6 meses de antecedência em relação à data de EOL, proporcionando tempo essencial para planejar e executar a migração. Durante esse período, clientes existentes podem continuar usando o modelo, embora novos clientes possam não ter acesso. Clientes existentes podem perder acesso se suas contas ficar inativas por 15 dias ou mais sem chamar o modelo.

Organizações devem estar cientes de que criar novo throughput provisionado (provisioned throughput) por unidades de modelo deixa de estar disponível, e capacidades de customização do modelo podem sofrer restrições.

Para modelos com data de EOL após 1º de fevereiro de 2026, a AWS introduz uma fase adicional dentro do estado Legado:

Período de Acesso Estendido Público (Public Extended Access Period)

Após permanecer no mínimo 3 meses em status Legado, o modelo entra nessa fase de acesso estendido. Usuários ativos podem continuar usando por no mínimo mais 3 meses até o EOL. Durante esse período, solicitações de aumento de cota via AWS Service Quotas não devem ser aprovadas — é importante planejar suas necessidades de capacidade antes dessa fase. O preço pode ser ajustado, e você receberá notificações sobre a data de transição e qualquer mudança.

Estado Fim de Vida (End-of-Life – EOL)

Quando um modelo atinge sua data de EOL, torna-se completamente inacessível em todas as regiões da AWS, a menos que especificamente listado no EOL list. Requisições de API para modelos em EOL falharão, deixando-os indisponíveis para a maioria dos clientes, a menos que exista arranjo especial entre cliente e fornecedor. A transição para EOL requer ação proativa do cliente — a migração não ocorre automaticamente. Você deve atualizar o código da sua aplicação para usar modelos alternativos antes que a data de EOL chegue.

Cronograma Mínimo de Disponibilidade

Após o lançamento no Amazon Bedrock, um modelo permanece disponível por no mínimo 12 meses e fica em estado Legado por pelo menos 6 meses antes do EOL. Esse timeline ajuda os clientes a planejar migrações sem pressão de urgência.

Preços Durante Acesso Estendido

Durante o período de acesso estendido, o fornecedor do modelo pode ajustar preços. Se mudanças de preço estiverem planejadas, você será notificado no anúncio inicial de legado e antes que qualquer mudança entre em vigor — não haverá aumentos retroativos surpresa.

Clientes com acordos de preço privado com fornecedores ou aqueles usando throughput provisionado continuarão operando sob seus termos de preço atuais durante esse período. Isso garante que clientes que fizeram arranjos específicos com fornecedores ou investiram em capacidade provisionada não sejam afetados inesperadamente.

Como Você é Notificado sobre Mudanças

Clientes recebem notificação 6 meses antes da data de EOL de um modelo quando o fornecedor o transiciona para estado Legado. Essa abordagem proativa garante tempo suficiente para planejar e executar estratégias de migração. As notificações incluem detalhes do modelo sendo descontinuado, datas importantes, disponibilidade de acesso estendido e quando o modelo chegará ao EOL.

A AWS usa múltiplos canais para garantir que essas comunicações importantes alcancem as pessoas certas:

• Notificações por email
• Alertas no AWS Health Dashboard
• Alertas no console do Amazon Bedrock
• Acesso programático via API

Para garantir que você receba essas notificações, verifique e configure os endereços de email de contato da sua conta. Por padrão, notificações são enviadas para o email do usuário root da sua conta e para contatos alternativos (operações, segurança e billing). Você pode revisar e atualizar esses contatos na página da sua conta AWS na seção Alternate contacts.

Para adicionar recipients adicionais ou canais de entrega (como Slack ou listas de distribuição de email), acesse o console de Notificações da AWS e escolha AWS managed notifications subscriptions para gerenciar seus canais de entrega e contatos da conta. Se não estiver recebendo notificações esperadas, verifique que seus endereços de email estejam configurados corretamente e que emails de health@aws.com não estejam sendo filtrados pelo seu provedor de email.

Estratégias e Boas Práticas de Migração

Ao migrar para um novo modelo, você precisa atualizar o código da aplicação e verificar que suas cotas de serviço conseguem lidar com o volume esperado. Planejar com antecedência ajuda a transição suave com disrupção mínima.

Planejando sua Linha do Tempo de Migração

Comece a planejar assim que um modelo entra em estado Legado. O processo se desdobra em fases:

Fase de Avaliação: Avalie seu uso atual do modelo legado, incluindo quais aplicações dependem dele, padrões típicos de requisições e comportamentos ou saídas específicas que suas aplicações utilizam.

Fase de Pesquisa: Investigue o modelo de substituição recomendado, entendendo suas capacidades, diferenças em relação ao modelo legado, novas features que poderiam aprimorar suas aplicações e a disponibilidade regional do novo modelo. Revise mudanças de API e documentação.

Fase de Testes: Conduza testes minuciosos com o novo modelo e compare métricas de desempenho entre eles. Isso ajuda a identificar ajustes necessários no código da aplicação ou na engenharia de prompts.

Fase de Migração: Implemente mudanças usando uma abordagem de deployment faseado. Monitore o desempenho do sistema durante a transição e mantenha capacidade de rollback.

Fase Operacional: Após migração, monitore continuamente suas aplicações e feedback de usuários para garantir que estejam performando como esperado com o novo modelo.

Passos Técnicos de Migração

Teste sua migração minuciosamente seguindo estes passos:

Atualize referências de API: Modifique o código da sua aplicação para referenciar o novo ID do modelo. Por exemplo, mudando de anthropic.claude-3-5-sonnet-20240620-v1:0 para anthropic.claude-sonnet-4-5-20250929-v1:0 ou global cross-Region inference global.anthropic.claude-sonnet-4-5-20250929-v1:0. Atualize estruturas de prompt de acordo com as melhores práticas do novo modelo. Para orientação detalhada, consulte Migrate from Anthropic’s Claude Sonnet 3.x to Claude Sonnet 4.x on Amazon Bedrock.

Solicite aumentos de cota: Antes de migrar completamente, certifique-se de ter quotas suficientes para o novo modelo solicitando aumentos através do console AWS Service Quotas se necessário.

Ajuste prompts: Novos modelos podem responder diferentemente aos mesmos prompts. Revise e refine seus prompts de acordo com as especificações do novo modelo. Você também pode usar ferramentas como o prompt optimizer no Amazon Bedrock para ajudar a reescrever seu prompt para o modelo alvo.

Atualize tratamento de respostas: Se o novo modelo retorna respostas em formato diferente ou com características distintas, atualize sua lógica de parsing e processamento conforme necessário.

Otimize uso de tokens: Aproveite as melhorias de eficiência em modelos mais novos revisando e otimizando seus padrões de uso de tokens. Por exemplo, modelos que suportam prompt caching podem reduzir o custo e latência de suas invocações.

Estratégias de Testes

Testes minuciosos são críticos para uma migração bem-sucedida:

Comparação lado a lado: Execute as mesmas requisições contra o modelo legado e o novo para comparar saídas e identificar diferenças que possam afetar sua aplicação. Para ambientes de produção, considere shadow testing — enviando requisições duplicadas para o novo modelo junto ao modelo existente sem afetar usuários finais. Essa abordagem permite avaliar desempenho, latência, taxas de erro e outros fatores operacionais antes da migração completa.

Testes A/B: Conduza testes A/B para avaliar impacto em usuários rotacionando uma porcentagem controlada de tráfego ao vivo para o novo modelo enquanto monitora métricas-chave como engagement de usuário, taxas de conclusão de tarefas, scores de satisfação e KPIs de negócio.

Testes de desempenho: Meça tempos de resposta, uso de tokens e outras métricas de desempenho para entender como o novo modelo se compara à versão legada. Valide métricas de sucesso específicas do seu negócio.

Testes de regressão e casos extremos: Garanta que funcionalidades existentes continuam funcionando como esperado com o novo modelo. Dê atenção especial a inputs incomuns ou complexos que possam revelar diferenças em como os modelos lidam com cenários desafiadores.

Conclusão

A política de ciclo de vida de modelos no Amazon Bedrock oferece estágios bem definidos para gerenciar a evolução de modelos de fundação. Períodos de transição oferecem opções de acesso estendido, e disposições para modelos customizados ajudam a equilibrar inovação com estabilidade. Fique informado sobre estados de modelos através do AWS Health Dashboard, planeje migrações quando modelos entram em estado Legado e teste versões mais novas minuciosamente. Essas diretrizes ajudam a manter continuidade em suas aplicações de IA enquanto você aproveita as capacidades melhoradas em modelos mais recentes.

Para aprendizado continuado e suporte de implementação, explore a documentação oficial do AWS Bedrock com guias abrangentes e referências de API. Além disso, visite o AWS Machine Learning Blog e AWS Architecture Center para estudos de caso do mundo real, migration best practices e arquiteturas de referência que podem ajudar a otimizar sua estratégia de gerenciamento de ciclo de vida de modelos.

Fonte

Understanding Amazon Bedrock model lifecycle (https://aws.amazon.com/blogs/machine-learning/understanding-amazon-bedrock-model-lifecycle/)