Blog

O modelo de IA generativa NVIDIA Nemotron agora está no SageMaker JumpStart

A AWS anunciou a disponibilidade geral do modelo NVIDIA Nemotron 3 Nano 30B, com 3 bilhões de parâmetros ativos, no catálogo de modelos do Amazon SageMaker JumpStart. Essa integração oferece aos desenvolvedores brasileiros a oportunidade de acelerar a inovação e entregar valor comercial concreto com o Nemotron 3 Nano na plataforma AWS, sem a necessidade de gerenciar complexidades de implantação de modelos.

Com as capacidades gerenciadas do SageMaker JumpStart, é possível potencializar aplicações de IA generativa com as capacidades do Nemotron. O modelo é classificado como um pequeno modelo híbrido de mistura de especialistas (Mixture of Experts — MoE), projetado para oferecer a mais alta eficiência computacional e precisão, permitindo que desenvolvedores executem tarefas de agentes altamente especializadas em escala.

Características principais do Nemotron 3 Nano 30B

O que diferencia o Nemotron 3 Nano de outras soluções disponíveis no mercado é sua arquitetura inovadora e desempenho comprovado. O modelo é totalmente aberto, com pesos de código aberto, conjuntos de dados e receitas publicados. Isso permite que desenvolvedores personalizem, otimizem e implantem o modelo em sua própria infraestrutura, atendendo requisitos específicos de privacidade e segurança.

Arquitetura e design

O Nemotron 3 Nano utiliza uma arquitetura híbrida que combina Transformer com Mamba. Uma característica importante é o suporte a orçamento de tokens, que permite alcançar precisão ótima enquanto minimiza a geração de tokens de raciocínio durante a inferência.

Desempenho em benchmarks técnicos

O modelo demonstra excelência em codificação e raciocínio, liderando em diversos benchmarks reconhecidos internacionalmente: SWE Bench Verified, GPQA Diamond, AIME 2025, Arena Hard v2 e IFBench. Em comparação com outros modelos de linguagem abertos com menos de 30 bilhões de parâmetros, o Nemotron se destaca em tarefas de codificação, raciocínio científico, matemática e compreensão de instruções.

Capacidades técnicas

O modelo oferece um contexto de até 1 milhão de tokens, funcionando como modelo de fundação baseado em texto, tanto para entradas quanto saídas. Com 30 bilhões de parâmetros totais, mas apenas 3 bilhões ativados simultaneamente, alcança uma relação impressionante entre capacidade e eficiência computacional.

Como começar com o Nemotron 3 Nano no SageMaker JumpStart

Requisitos iniciais

Para utilizar o Nemotron 3 Nano no Amazon SageMaker JumpStart, é necessário ter um domínio do Amazon SageMaker Studio provisionado.

Processo de implantação

Para testar o modelo, abra o SageMaker Studio e navegue até a seção “Models” no painel de navegação. Digite “NVIDIA” na barra de pesquisa e selecione o “NVIDIA Nemotron 3 Nano 30B”. Na página de detalhes do modelo, escolha “Deploy” e siga as instruções fornecidas para concluir a implantação. Após o modelo estar ativo em um endpoint de SageMaker AI, você poderá testá-lo imediatamente.

Acesso via linha de comando

O modelo pode ser acessado utilizando exemplos da Interface de Linha de Comando da AWS (AWS CLI). Use o identificador de modelo nvidia/nemotron-3-nano para fazer referência ao modelo.

cat > input.json << EOF
{
  "model": "${MODEL_ID}",
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant."
    },
    {
      "role": "user",
      "content": "What is NVIDIA? Answer in 2-3 sentences."
    }
  ],
  "max_tokens": 512,
  "temperature": 0.2,
  "stream": False,
  "chat_template_kwargs": {"enable_thinking": False}
}
EOF

aws sagemaker-runtime invoke-endpoint \
  --endpoint-name ${ENDPOINT_NAME} \
  --region ${AWS_REGION} \
  --content-type 'application/json' \
  --body fileb://input.json \
  > response.json

Integração com SDK do SageMaker e Boto3

Alternativamente, é possível acessar o modelo usando o SDK do SageMaker e a biblioteca Boto3. O exemplo abaixo em Python demonstra como enviar uma mensagem de texto ao Nemotron 3 Nano 30B através do SageMaker SDK:

runtime_client = boto3.client('sagemaker-runtime', region_name=region)

payload = {
  "messages": [
    {"role": "user", "content": prompt}
  ],
  "max_tokens": 1000
}

try:
  response = self.runtime_client.invoke_endpoint(
    EndpointName=self.endpoint_name,
    ContentType='application/json',
    Body=json.dumps(payload)
  )
  response_body = response['Body'].read().decode('utf-8')
  raw_response = json.loads(response_body)
  return self.parse_response(raw_response)
except Exception as e:
  raise Exception(
    f"Failed to invoke endpoint '{self.endpoint_name}': {str(e)}. "
    f"Check that the endpoint is InService and you have least-privileged IAM permissions assigned."
  )

Para exemplos adicionais de código, consulte o repositório GitHub da NVIDIA.

Disponibilidade e recursos complementares

O NVIDIA Nemotron 3 Nano agora está totalmente gerenciado no SageMaker JumpStart. Verifique a documentação do pacote de modelo para conhecer a disponibilidade em cada região da AWS. Para aprender mais sobre o serviço, consulte a página do modelo Nemotron Nano, o notebook de exemplo da NVIDIA no GitHub para o Nemotron 3 Nano 30B, e a página de preços do Amazon SageMaker JumpStart.

Desenvolvedores brasileiros que desejarem testar o modelo e compartilhar feedback podem fazê-lo através do AWS re:Post para SageMaker JumpStart ou através dos canais habituais de suporte da AWS.

Fonte

NVIDIA Nemotron 3 Nano 30B MoE model is now available in Amazon SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/nvidia-nemotron-3-nano-30b-is-now-available-in-amazon-sagemaker-jumpstart/)

O Desafio das Aplicações de IA em Produção

Quando aplicações de inteligência artificial generativa entram em produção, erros se tornam inevitáveis. Os dois mais comuns são aqueles que retornam 429 ThrottlingException (requisição rejeitada por excesso de volume) e 503 ServiceUnavailableException (serviço temporariamente indisponível). Embora a maioria desses erros seja recuperável através de tentativas subsequentes, o impacto na experiência do usuário é imediato: atrasos nas respostas, interrupções na fluidez da conversa e, potencialmente, abandono da plataforma.

O desafio fica ainda mais complexo em cenários com múltiplos usuários acessando o mesmo modelo simultaneamente. Nesse contexto, a diferença entre uma aplicação resiliente e usuários frustrados está justamente na capacidade de tratar esses erros adequadamente. Uma estratégia bem elaborada de retry, rate limiting e observabilidade pode transformar falhas transitórias em pequenos incômodos em vez de bloqueadores críticos.

Diferenças Entre os Dois Tipos de Erro

Entender a raiz de cada erro é fundamental para implementar a solução correta. O erro 503 ocorre quando o serviço Bedrock enfrenta problemas de capacidade ou infraestrutura — é uma questão de saúde do serviço. Já o 429 emerge quando a conta atinge seus limites de quota — seja em requisições por minuto (RPM – Requisições Por Minuto) ou em tokens processados por minuto (TPM – Tokens Por Minuto).

A estratégia de retry para cada um difere significativamente. Para 503, tentativas com backoff exponencial funcionam bem, pois o serviço geralmente se recupera em segundos. Para 429, é necessário sincronizar as tentativas com o ciclo de renovação de quota, que ocorre a cada 60 segundos.

Entendendo o Erro 429: ThrottlingException

Como Funciona a Limitação por Taxa de Requisição (RPM)

O erro RPM surge quando o número total de chamadas ao Bedrock por minuto ultrapassa a quota configurada para a conta. O ponto crítico é que esse limite se aplica globalmente a todos os aplicativos que chamam o serviço na mesma região, não individualmente por aplicação.

Imagine um cenário com três aplicações em produção, todas consumindo o mesmo modelo Bedrock na mesma região. A aplicação A pico em 50 requisições por minuto, assim como B e C. A quota contratada é de 150 RPM, que parecia adequada. Porém, na prática o tráfego não é perfeitamente uniforme. Durante uma promoção, a aplicação A salta para 60 RPM enquanto B e C permanecem em 50. O total chega a 160 RPM e algumas requisições começam a falhar.

Mitigar esse problema requer ação em dois frontes: no lado do cliente e no lado da quota. No cliente, implementar rate limiting por aplicação garante que uma aplicação “barulhenta” não esgote a quota de outras. Usar exponencial backoff com variação aleatória (jitter) faz com que retries não ocorram sincronizados entre múltiplas instâncias. Sincronizar finais de retry com o ciclo de 60 segundos aumenta a chance de sucesso.

No lado da quota, monitorar as métricas reais de pico via Amazon CloudWatch e solicitar aumentos através do AWS Service Quotas garante espaço para crescimento sem que surpreças de tráfego virem incidentes.

Limitação por Tokens (TPM)

Mesmo com contagem de requisições modestas, um único prompt grande ou uma resposta longa podem consumir milhares de tokens. O erro TPM ocorre quando o total de tokens (entrada + saída) por minuto excede a quota da conta.

Uma aplicação enviando 10 requisições por minuto com 15 mil tokens de entrada e 5 mil de saída cada uma consome aproximadamente 200 mil tokens por minuto — muito mais restritivo que 200 pequenos prompts. Esse cenário frequentemente se manifesta quando usuários colam documentos grandes, transcripts longos ou executam trabalhos em lote de sumarização.

Responder a isso significa monitorar proativamente o consumo de tokens através de logs do Bedrock, implementar um rate limiter que mantenha janela deslizante de 60 segundos de consumo, e quebrar tarefas grandes em chunks menores espalhados ao longo do tempo. Usar respostas em stream também ajuda, pois fornece mais controle sobre quando parar a geração.

Limitação Específica por Modelo

Às vezes o erro indica que um modelo específico está sobrecarregado — não é problema de quota da conta, mas de saturação temporária da infraestrutura compartilhada daquele modelo. Nesses casos, projetar para degradação graciosa funciona melhor que tratar como falha dura.

Implementar fallback automático para modelos alternativos (por exemplo, se Claude Sonnet está indisponível, usar Claude Haiku) combinado com failover entre regiões melhora significativamente a resiliência. Expor esse comportamento degradado nos dashboards garante visibilidade — em vez de mascarar silenciosamente o problema.

Entendendo o Erro 503: ServiceUnavailableException

Esgotamento do Pool de Conexões

Este erro frequentemente não vem do Bedrock em si, mas da forma como o cliente está configurado. O boto3 utiliza um pool HTTP padrão relativamente pequeno (cerca de 10 conexões), facilmente saturado em workloads altamente concorrentes. Criar um novo cliente para cada requisição multiplica desnecessariamente o número de conexões abertas.

A solução é compartilhar uma única instância de cliente Bedrock e aumentar o tamanho do pool:

import boto3
from botocore.config import Config

config = Config(
    max_pool_connections=50,
    retries={'max_attempts': 3}
)
bedrock_client = boto3.client('bedrock-runtime', config=config)

Problemas Temporários de Recursos do Serviço

Quando a AWS Bedrock sinaliza indisponibilidade temporária, geralmente está lidando com pico de demanda em modelos on-demand. Nesse cenário, tratar como outage transitória e focar em retry inteligente com fallover gracioso é a estratégia adequada.

Padrões Avançados de Resiliência

O Padrão Circuit Breaker

Para sistemas críticos, simples retries não bastam. O padrão circuit breaker evita que a aplicação continue martelando um serviço já falho. Funciona em três estados: CLOSED (operação normal), OPEN (rejeitando requisições após múltiplas falhas) e HALF_OPEN (testando recuperação).

Quando Bedrock retorna 503, continuar enviando requisições piora a situação. O circuit breaker reduz a carga no serviço em dificuldade, ajudando sua recuperação mais rápida, falha rapidamente em vez de desperdiçar tempo em requisições que provavelmente falharão, e se recupera automaticamente testando periodicamente se o serviço se restabeleceu.

Failover entre Regiões com CRIS

O recurso Cross-Region Inference (CRIS) da AWS Bedrock oferece um mecanismo gerenciado de roteamento de tráfego entre regiões. Perfis CRIS globais podem enviar tráfego para regiões comerciais da AWS com melhor combinação de throughput e custo. Perfis geográficos confinam o tráfego a geografias específicas para atender requisitos rígidos de residência de dados.

Para workloads não reguladas, usar perfil global melhora significativamente disponibilidade e absorve picos regionais. Para workloads reguladas, configurar perfis geográficos alinhados com limites de compliance fornece controle necessário.

Implementação de Retry e Rate Limiting Robusto

Backoff Exponencial com Jitter

Este padrão é essencial para tratar throttling graciosamente, evitando martelar o serviço imediatamente após falha e prevenindo que múltiplas instâncias retry no mesmo momento:

import time
import random
from botocore.exceptions import ClientError

def bedrock_request_with_retry(bedrock_client, operation, **kwargs):
    """Secure retry implementation with sanitized logging."""
    max_retries = 5
    base_delay = 1
    max_delay = 60
    
    for attempt in range(max_retries):
        try:
            if operation == 'invoke_model':
                return bedrock_client.invoke_model(**kwargs)
            elif operation == 'converse':
                return bedrock_client.converse(**kwargs)
        except ClientError as e:
            if e.response['Error']['Code'] == 'ThrottlingException':
                if attempt == max_retries - 1:
                    raise
                delay = min(base_delay * (2 ** attempt), max_delay)
                jitter = random.uniform(0, delay * 0.1)
                time.sleep(delay + jitter)
                continue
            else:
                raise

Rate Limiter Consciente de Tokens

Para limitação baseada em tokens, manter janela deslizante de 60 segundos de consumo permite decidir de forma simples se é seguro enviar outra requisição:

import time
from collections import deque

class TokenAwareRateLimiter:
    def __init__(self, tpm_limit):
        self.tpm_limit = tpm_limit
        self.token_usage = deque()
    
    def can_make_request(self, estimated_tokens):
        now = time.time()
        while self.token_usage and self.token_usage[0][0] < now - 60:
            self.token_usage.popleft()
        current_usage = sum(tokens for _, tokens in self.token_usage)
        return current_usage + estimated_tokens <= self.tpm_limit
    
    def record_usage(self, tokens_used):
        self.token_usage.append((time.time(), tokens_used))

Monitoramento e Observabilidade

Não é possível gerenciar aquilo que não se consegue visualizar. O Amazon CloudWatch fornece métricas essenciais: Invocations (invocações bem-sucedidas), InvocationClientErrors (erros 4xx incluindo throttling), InvocationServerErrors (erros 5xx incluindo indisponibilidade), InvocationThrottles (erros 429 específicos), InvocationLatency (tempos de resposta) e InputTokenCount/OutputTokenCount (consumo de tokens).

Dashboards efetivos separam 429 e 503 em widgets diferentes, desagregam por ModelId e Região, e mostram comparações lado a lado do tráfego atual versus semanas anteriores para detectar tendências emergentes.

Alarmes críticos devem disparar para: múltiplos eventos de throttling em janela de 5 minutos, períodos consecutivos com throttles indicando pressão sustentada, quota utilizada acima de 80%, taxa de sucesso abaixo da SLA (por exemplo, 95% em 10 minutos), e picos súbitos de 503 correlacionados com regiões ou modelos específicos.

Use Amazon Simple Notification Service (Amazon SNS) para rotear alertas aos canais de comunicação da equipe (Slack, PagerDuty, email). Configure níveis de severidade diferentes e inclua descrições detalhadas com links para runbooks de troubleshooting.

Reunindo Tudo: Construindo Aplicações Resilientes

O sucesso ao lidar com erros do Bedrock requer compreensão de causas raiz — distinguir entre limites de quota (429) e problemas de capacidade (503). Implementar retries apropriados com parâmetros diferentes para cada tipo de erro. Desenhar para escala utilizando connection pooling, circuit breakers e failover entre regiões. Monitorar proativamente com CloudWatch e alertas bem configurados. Planejar para crescimento solicitando aumentos de quota e implementando estratégias de fallback.

Como próximo passo, identifique seus workloads Bedrock mais críticos, implemente os padrões de retry e rate limiting aqui descritos, e construa dashboards e alarmes que exponham picos reais em vez de apenas médias. Ao longo do tempo, use dados de tráfego real para refinar quotas, modelos de fallback e deployments regionais, garantindo que seus sistemas de IA permaneçam poderosos e confiáveis conforme escalam.

Para equipes buscando acelerar resolução de incidentes, a AWS oferece o AWS DevOps Agent — um agente com inteligência artificial que investiga erros do Bedrock correlacionando métricas CloudWatch, logs e alarmes assim como um engenheiro DevOps experiente faria, identificando automaticamente causas raiz e sugerindo passos de remediação.

Fonte

Mastering Amazon Bedrock throttling and service availability: A comprehensive guide (https://aws.amazon.com/blogs/machine-learning/mastering-amazon-bedrock-throttling-and-service-availability-a-comprehensive-guide/)

A transformação dos assistentes de voz por IA

Os agentes de IA por voz estão redefinindo a forma como nos relacionamos com a tecnologia. Em atendimento ao cliente, assistência em saúde, automação residencial e produtividade pessoal, esses assistentes virtuais inteligentes ganham rapidamente espaço em diversos segmentos da indústria. Suas capacidades de processamento de linguagem natural, disponibilidade constante e sofisticação crescente os transformam em ferramentas valiosas para empresas que buscam eficiência e para indivíduos que desejam experiências digitais fluidas.

A AWS recentemente apresentou o Amazon Nova Sonic, um modelo que viabiliza conversas de voz humanas em tempo real através de uma interface de streaming bidirecional. O modelo compreende diferentes estilos de fala e gera respostas expressivas que se adaptam tanto ao conteúdo quanto à entonação das palavras pronunciadas. Com suporte para múltiplos idiomas e disponibilidade de vozes masculinas e femininas, torna-se particularmente adequado para atendimento ao cliente, campanhas de marketing, assistentes de voz e aplicações educacionais.

Comparando abordagens arquiteturais

Sistemas clássicos de chat por voz utilizam arquiteturas em cascata com processamento sequencial, enquanto modelos mais recentes como o Amazon Nova Sonic combinam compreensão e geração de fala em um único modelo ponta a ponta. A abordagem tradicional decompõe o processamento de IA por voz em componentes distintos que funcionam em sequência:

O pipeline tradicional em cascata

• Detecção de atividade de voz (VAD): Um componente de pré-processamento identifica quando o usuário faz pausa ou para de falar.
• Conversão de fala em texto (STT): As palavras pronunciadas são transformadas em formato textual através de reconhecimento automático de fala.
• Processamento com modelo de linguagem grande (LLM): O texto transcrito é processado por um LLM ou gerenciador de diálogo, que analisa a entrada e gera uma resposta textual apropriada conforme o contexto da conversa.
• Conversão de texto em fala (TTS): A resposta textual é reconvertida em áudio natural através de um modelo TTS e reproduzida ao usuário.

Os desafios da arquitetura em cascata

Embora arquiteturas em cascata ofereçam benefícios como modularidade, componentes especializados e facilidade de depuração, elas enfrentam dois grandes problemas: latência cumulativa e redução na interatividade.

O efeito cascata

Considere um assistente de voz respondendo uma consulta simples sobre o tempo. Em pipelines em cascata, cada etapa de processamento introduz latência e possibilidade de erros. Implementações de clientes demonstraram como interpretações incorretas iniciais podem se propagar através do pipeline, frequentemente resultando em respostas inadequadas. Esse efeito cascata complica a resolução de problemas e impacta negativamente a experiência do usuário.

O tempo é fundamental

Conversas naturais dependem de tempo apropriado. O processamento sequencial pode criar atrasos notáveis nos tempos de resposta. Essas interrupções no fluxo conversacional podem gerar fricção com o usuário e reduzir satisfação.

O desafio da integração

IA por voz demanda mais que apenas processamento de fala — requer padrões de interação naturais. Feedbacks de clientes evidenciaram como orquestrar múltiplos componentes dificultava o manejo de elementos dinâmicos de conversa, como interrupções ou trocas rápidas. Os recursos de engenharia frequentemente se concentravam mais em gerenciar o pipeline do que na qualidade da interação.

A realidade dos recursos

Arquiteturas em cascata exigem recursos computacionais independentes, monitoramento e manutenção para cada componente. Essa complexidade arquitetural impacta tanto a velocidade de desenvolvimento quanto a eficiência operacional. Os desafios de escalabilidade se intensificam conforme o volume de conversas aumenta, afetando confiabilidade do sistema e otimização de custos.

Como o Nova Sonic aborda esses desafios

Essas limitações conduziram decisões arquiteturais fundamentais no desenvolvimento do Nova Sonic, que busca atender à necessidade essencial de processamento de fala ponta a ponta unificado. Isso viabiliza experiências de voz naturais e responsivas sem a complexidade de gerenciar múltiplos componentes.

Análise comparativa: fala ponta a ponta versus cascata

Latência

Nova Sonic: O modelo apresenta desempenho otimizado de latência. A AWS avalia a performance usando a métrica Time to First Audio (TTFA 1.09), que mede o tempo decorrido desde a conclusão da consulta falada do usuário até o recebimento do primeiro byte de áudio de resposta. Consulte o relatório técnico e cartão do modelo para detalhes completos.

Modelos em cascata: Podem utilizar múltiplos modelos entre reconhecimento de fala, compreensão de linguagem e geração de voz, mas enfrentam latência adicional e propagação potencial de erros entre etapas. Utilizando frameworks de orquestração assíncrona modernos como Pipecat e LiveKit, é possível minimizar latência. Componentes de streaming e uso de pausas TTS ajudam a manter fluxo conversacional natural e reduzir atrasos.

Complexidade arquitetural e de desenvolvimento

Nova Sonic: Oferece arquitetura simplificada. O modelo combina conversão de fala em texto, compreensão de linguagem natural e conversão de texto em fala em uma única arquitetura, com uso de ferramentas integrado e detecção de barge-in. Disponibiliza uma arquitetura orientada por eventos para eventos de entrada e saída chave, além de uma API de streaming bidirecional que simplifica a experiência do desenvolvedor.

Modelos em cascata: Exigem seleção de modelos melhores em sua classe para cada etapa do pipeline, enquanto orquestram componentes adicionais como pipelines assincronos para agentes delegados, uso de ferramentas, pausas TTS e VAD, adicionando complexidade significativa.

Personalização e controle de modelos

Nova Sonic: Oferece menor controle granular sobre componentes individuais. O serviço permite personalização de vozes, uso integrado de ferramentas e integrações com Amazon Bedrock Knowledge Bases e Amazon Bedrock AgentCore. Porém, não oferece o mesmo nível de granularidade disponível em sistemas totalmente modulares.

Modelos em cascata: Proporcionam maior controle sobre cada etapa, permitindo ajuste individual, substituição e otimização independente de cada componente de modelo como STT, compreensão de linguagem e TTS. Isso inclui modelos do Amazon Bedrock Marketplace, Amazon SageMaker AI e modelos ajustados. Essa modularidade viabiliza flexibilidade e seleção de modelos, tornando-se ideal para capacidades complexas ou especializadas que exigem desempenho personalizado.

Estrutura de custos

Nova Sonic: Estrutura de custos simplificada através de uma abordagem integrada, utilizando modelo de consumo baseado em tokens.

Modelos em cascata: Compõem múltiplos componentes cujos custos precisam ser estimados individualmente. Isso é especialmente importante em escala e volumes elevados.

Suporte de idiomas e sotaques

Nova Sonic: Suporta idiomas específicos conforme documentação da AWS.

Modelos em cascata: Podem oferecer suporte mais amplo de idiomas através de modelos especializados, incluindo possibilidade de alternar idiomas durante a conversa.

Disponibilidade regional

Nova Sonic: Disponível nas regiões suportadas pela AWS.

Modelos em cascata: Potencialmente mais amplo suporte regional devido à diversidade de modelos disponíveis e capacidade de auto-hospedar modelos em Amazon Elastic Kubernetes Service (Amazon EKS) ou Amazon SageMaker.

Características compartilhadas entre as abordagens

Opções de telefonia e transporte

Ambas as abordagens — em cascata e ponta a ponta — suportam diversos protocolos de telefonia e transporte como WebRTC e WebSocket. Esses protocolos viabilizam streaming de áudio em tempo real e com baixa latência pela web e redes telefônicas. Facilitam troca de áudio bidirecional contínua, fundamental para experiências conversacionais naturais, permitindo que sistemas de IA por voz se integrem facilmente com infraestruturas de comunicação existentes mantendo responsividade e qualidade de áudio. A AWS oferece um guia de integração de telefonia para Nova Sonic.

Avaliação, observabilidade e testes

Ambas as abordagens de IA por voz — em cascata e ponta a ponta — podem ser sistematicamente avaliadas, observadas e testadas para comparação confiável. Investir em um sistema de avaliação e observabilidade de IA por voz é recomendado para ganhar confiança na precisão e desempenho de produção. Tal sistema deve ser capaz de rastrear todo o pipeline entrada-saída, capturando métricas e dados de conversa ponta a ponta para avaliar de forma abrangente qualidade, latência e robustez conversacional ao longo do tempo.

Frameworks para desenvolvedores

Ambas as abordagens contam com suporte de frameworks de IA por voz de código aberto líderes como Pipecat e LiveKit. Esses frameworks proporcionam pipelines modulares e flexíveis com capacidades de processamento em tempo real que desenvolvedores podem utilizar para construir, personalizar e orquestrar modelos de IA por voz de forma eficiente entre diferentes componentes e estilos de interação.

Guia prático: quando usar cada abordagem

Use fala ponta a ponta (Nova Sonic) quando:

• A simplicidade da implementação é importante
• O caso de uso se encaixa nas capacidades do Nova Sonic
• Você busca uma experiência de chat em tempo real que soe humana e ofereça baixa latência

Use modelos em cascata quando:

• Personalização de componentes individuais é necessária
• Você precisa usar modelos especializados do Amazon Bedrock Marketplace, Amazon SageMaker AI, ou modelos ajustados para seu domínio específico
• Você necessita de suporte para idiomas ou sotaques não cobertos pelo Nova Sonic
• O caso de uso requer processamento especializado em etapas específicas

Conclusão

O Amazon Nova Sonic representa uma evolução significativa na construção de assistentes de voz inteligentes. Projetado para resolver desafios enfrentados por arquiteturas em cascata, o modelo simplifica o desenvolvimento de agentes de IA por voz e oferece capacidades conversacionais genuinamente naturais.

Se sua organização opera sistemas de voz em cascata e considera melhorias, agora possui as informações necessárias para avaliar uma migração para Nova Sonic a fim de oferecer experiências conversacionais fluidas e em tempo real com uma arquitetura simplificada.

Para saber mais, consulte o Amazon Nova Sonic e contate seu time de contas para explorar como você pode acelerar suas iniciativas de IA por voz.

Recursos adicionais

• Amazon Nova Sonic Technical Report and Model Card
• Amazon Nova Sonic User Guide
• Amazon Nova Sonic and Amazon Bedrock AgentCore
• Amazon Nova Sonic Telephony Integration Guide
• Amazon Nova Sonic and Pipecat
• Amazon Nova Sonic and LiveKit

Fonte

Building real-time voice assistants with Amazon Nova Sonic compared to cascading architectures (https://aws.amazon.com/blogs/machine-learning/building-real-time-voice-assistants-with-amazon-nova-sonic-compared-to-cascading-architectures/)

O Cenário Empresarial: Da Necessidade ao Modelo Customizado

Organizações em todo o mundo vêm experimentando uma transformação estratégica: abandonar a dependência exclusiva de modelos de linguagem grandes e genéricos para desenvolver modelos de linguagem especializados (LLMs) ajustados finamente com seus próprios dados proprietários. Embora os modelos de fundação ofereçam capacidades gerais impressionantes, frequentemente ficam aquém quando aplicados às complexidades do ambiente corporativo — onde precisão, segurança, conformidade e conhecimento específico do domínio são não-negociáveis.

Para atender a essas demandas, as empresas estão adotando modelos mais eficientes, personalizados para seus dados internos e fluxos de trabalho. Ao fazer ajuste fino com documentos proprietários e terminologia específica do domínio, as organizações constroem modelos que entendem seu contexto único, resultando em respostas mais relevantes, governança de dados mais rigorosa e implantação simplificada em ferramentas internas. Esse movimento também representa uma estratégia para reduzir custos operacionais, melhorar a latência de inferência e manter maior controle sobre privacidade de dados.

Os Desafios da Escala: Quando a Complexidade Atrapalha a Inovação

Escalar o ajuste fino de LLMs para casos de uso empresariais apresenta obstáculos técnicos e operacionais genuínos. Muitas organizações enfrentam cadeias de ferramentas fragmentadas e crescente complexidade ao adotar técnicas avançadas de ajuste fino, como Low-Rank Adaptation (LoRA), QLoRA e Aprendizado por Reforço com Feedback Humano (RLHF).

Além disso, as demandas de recursos do treinamento de modelos grandes — incluindo limitações de memória e desafios de infraestrutura distribuída — frequentemente desaceleram a inovação e sobrecarregam equipes internas. Esses problemas tornam a jornada do ajuste fino uma tarefa complexa que desvia tempo e atenção do foco principal: melhorar os modelos para aplicações específicas do negócio.

A Parceria Estratégica: Simplificando a Complexidade

Para superar esses desafios, Hugging Face e Amazon SageMaker AI uniram forças com o objetivo de simplificar e escalar a personalização de modelos. Integrando as bibliotecas Transformers da Hugging Face na infraestrutura totalmente gerenciada do SageMaker, as empresas podem agora:

• Executar trabalhos de ajuste fino distribuído já configurados, com suporte integrado para métodos de ajuste eficiente de parâmetros
• Usar configurações de computação e armazenamento otimizadas que reduzem custos de treinamento e melhoram a utilização de GPU
• Acelerar o tempo para gerar valor usando bibliotecas de código aberto conhecidas em um ambiente de nível produção

Essa colaboração ajuda empresas a focar na construção de LLMs específicos do domínio e de tamanho apropriado, desbloqueando valor de IA mais rapidamente enquanto mantêm controle total sobre seus dados e modelos.

Entendendo os Conceitos Fundamentais

A Biblioteca Transformers da Hugging Face

A biblioteca Transformers é um kit de ferramentas de código aberto projetado para ajuste fino de LLMs, permitindo experimentação contínua e implantação com modelos transformadores populares. Ela oferece:

• Milhares de modelos pré-treinados — Acesso a uma vasta coleção de modelos como BERT, Meta Llama, Qwen, T5 e muitos outros, utilizáveis para tarefas como classificação de texto, tradução, sumarização, resposta a perguntas, detecção de objetos e reconhecimento de fala
• API Pipelines — Simplifica tarefas comuns como análise de sentimento, sumarização e segmentação de imagem, tratando tokenização, inferência e formatação de saída em uma única chamada
• API Trainer — Fornece uma interface de alto nível para treinamento e ajuste fino, suportando precisão mista, treinamento distribuído e integração com aceleradores de hardware populares
• Ferramentas de Tokenização — Tokenizadores eficientes e flexíveis para converter texto bruto em entradas prontas para modelo, suportando múltiplos idiomas e formatos

SageMaker Training Jobs: Infraestrutura Totalmente Gerenciada

Os SageMaker Training Jobs oferecem um serviço de aprendizado de máquina totalmente gerenciado e sob demanda que executa remotamente na infraestrutura AWS para treinar um modelo com seus dados, código e recursos computacionais escolhidos. As principais capacidades incluem:

• Totalmente gerenciado — O SageMaker controla provisionamento de recursos, escala e gerenciamento, dispensando configuração manual de servidores ou clusters
• Entrada flexível — Suporta algoritmos integrados, contêineres pré-construídos ou scripts de treinamento customizados com frameworks populares como a biblioteca Transformers
• Escalável — Suporta treinamento em nó único ou distribuído entre múltiplas instâncias, adequado para workloads pequenos e em larga escala
• Integração com múltiplas fontes de dados — Dados de treinamento podem ser armazenados em Amazon Simple Storage Service (Amazon S3), Amazon FSx e Amazon Elastic Block Store (Amazon EBS)
• Customizável — Especifique hiperparâmetros, tipos de recurso (GPU ou CPU) e outras configurações para cada trabalho
• Opções econômicas — Recursos como managed Spot Instances, flexible training plans e heterogeneous clusters ajudam a otimizar custos

Visão Geral da Solução

O fluxo de trabalho integrado segue estas etapas principais:

1. O usuário prepara o dataset formatando-o com o estilo de prompt específico do modelo selecionado
2. O usuário prepara o script de treinamento usando a biblioteca Transformers da Hugging Face, especificando a configuração para a opção de distribuição escolhida (Distributed Data Parallel ou Fully-Sharded Data Parallel)
3. O usuário submete uma requisição à API do SageMaker AI, passando a localização do script de treinamento, a URI do contêiner de Treinamento Hugging Face e as configurações necessárias
4. O SageMaker AI usa um script de lançamento de trabalho para executar o workload em um cluster de computação gerenciado, orquestrando treinamento distribuído e descomissionando automaticamente o cluster após conclusão

Pré-requisitos para Iniciar

Antes de executar o ajuste fino, é necessário completar alguns passos preparatórios, incluindo:

• Solicitar aumentos de cota do SageMaker AI (mínimo de 1 instância p4d.24xlarge com 8 GPUs NVIDIA A100). Ferramentas como Can it run LLM ajudam a determinar o tamanho correto do cluster
• No console de Service Quotas, solicitar cotas do SageMaker AI necessárias
• Criar uma função AWS Identity and Access Management (IAM) com as políticas gerenciadas AmazonSageMakerFullAccess e AmazonS3FullAccess
• (Opcional) Criar um domínio Amazon SageMaker Studio para acessar Jupyter notebooks

Para orientações sobre permissões mais granulares em produção, consulte o SageMaker Developer Guide.

Preparando os Dados e o Script de Treinamento

Carregando e Formatando o Dataset

O exemplo prático utiliza o dataset UCSC-VLAA/MedReason, um dataset de raciocínio médico de alta qualidade projetado para resolver problemas médicos com explicações fiéis em LLMs. O processo envolve carregar o dataset, aplicar o template de chat apropriado usando o método apply_chat_template do tokenizador, dividir em conjuntos de treinamento, validação e teste, e fazer upload para S3 em formato JSON.

Configuração do Treinamento com Técnicas Avançadas

O script de treinamento para meta-llama/Llama-3.1-8B utiliza a classe Trainer (ou sua especialização SFTTrainer) junto com técnicas de otimização como Fully-Sharded Data Parallel (FSDP) para distribuir o treinamento e QLoRA para quantizar o modelo a 4 bits enquanto anexa pequenos adaptadores de baixo nível.

A configuração é definida em um arquivo YAML com hiperparâmetros como taxa de aprendizado, épocas, tamanho de lote, dropout, e parâmetros FSDP específicos. O arquivo de configuração é enviado para S3 e referenciado durante a submissão do trabalho de treinamento.

Executando o Treinamento com SageMaker

Para executar o ajuste fino, usa-se a classe ModelTrainer do SDK Python, fornecendo detalhes como tipo de instância (ml.p4d.24xlarge), URI da imagem de treinamento, configuração de código fonte, canais de entrada para dados e configuração, e condições de parada.

Após configurar todos os parâmetros e submeter o trabalho via model_trainer.train(), o SageMaker gerencia toda a infraestrutura. Para o exemplo com 10.000 amostras, o treinamento de uma época leva aproximadamente 18 minutos.

Implantação e Teste do Modelo Ajustado

Após o treinamento, o modelo pode ser avaliado de várias formas: usando um trabalho adicional de treinamento com avaliação automática, implantando em um SageMaker real-time endpoint, ou usando o MedReason evaluation script para comparações detalhadas.

Na abordagem de implantação, cria-se um modelo do SageMaker usando um contêiner otimizado com configurações de vLLM (número de GPUs, tipo de dados, tamanho máximo de modelo), define-se uma configuração de endpoint especificando tipo e quantidade de instâncias, e implanta-se o modelo. Após 5-10 minutos, o endpoint está pronto para receber requisições de inferência.

Resultados Práticos

O modelo ajustado demonstra capacidades robustas de raciocínio, fornecendo explicações estruturadas e detalhadas com processos de pensamento claros antes de chegar à resposta final. Essa melhoria é resultado direto da combinação entre a biblioteca Transformers da Hugging Face, técnicas distribuídas de treinamento e a infraestrutura gerenciada do SageMaker AI.

Limpeza de Recursos

Para evitar incidentes de custo, é importante eliminar recursos não utilizados após o término dos experimentos. Isso inclui endpoints do SageMaker, domínios do Studio (se criados) e verificação de que trabalhos de treinamento não estão mais em execução.

Conclusão

A integração entre Hugging Face e Amazon SageMaker AI transforma o ajuste fino de modelos de linguagem de um processo complexo e intensivo em recursos em um fluxo contínuo, escalável e pronto para produção. Usando técnicas como FSDP e LoRA, as organizações podem reduzir tempo de treinamento e custos sem comprometer qualidade do modelo.

Essa solução aborda desafios empresariais comuns como cadeias de ferramentas fragmentadas, requisitos altos de memória e computação, e ineficiências em escala multi-nó. Para começar seu próprio projeto de ajuste fino, explore os exemplos de código disponíveis no GitHub repository. Consulte também a SageMaker Python SDK documentation para aprofundamento técnico e managed warm pools para otimizar a fase de experimentação.

Fonte

Scale LLM fine-tuning with Hugging Face and Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/scale-llm-fine-tuning-with-hugging-face-and-amazon-sagemaker-ai/)

Validação Inteligente de Respostas com Verificação de Raciocínio

A AWS publicou uma nova implementação de chatbot de código aberto que demonstra como usar feedback de verificação automatizada de raciocínio lógico para melhorar iterativamente o conteúdo gerado, formular perguntas de esclarecimento e comprovar a correção das respostas. A solução não apenas itera sobre as respostas, mas também produz um registro de auditoria completo que inclui explicações matematicamente verificáveis sobre a validade das respostas, além de uma interface de usuário que permite aos desenvolvedores visualizar todo o processo iterativo de reescrita que ocorre nos bastidores.

O Diferencial: Raciocínio Lógico vs. Intuição de Modelos

Diferentemente dos modelos de linguagem de grande escala, ferramentas de verificação automatizada de raciocínio não funcionam por predição ou estimativa probabilística. Em vez disso, utilizam dedução lógica e provas matemáticas para demonstrar automaticamente que uma afirmação está correta. Essa abordagem baseada em provas formais oferece conformidade verificável com políticas definidas — algo fundamental para ambientes regulados.

Por Que Isso Importa: Reduzindo Alucinações e Aumentando Confiabilidade

Modelos de linguagem podem gerar respostas que parecem convincentes, mas contêm erros factuais. Esse fenômeno é conhecido como alucinação. A verificação automatizada de raciocínio valida tanto as perguntas do usuário quanto as respostas geradas pelo modelo, fornecendo feedback de reescrita que identifica afirmações ambíguas, asserções muito amplas e alegações factualmente incorretas. Quando um chatbot utiliza essa validação para iterar sobre suas respostas antes de apresentá-las ao usuário, dois benefícios críticos emergem: melhor precisão, porque o sistema faz afirmações precisas que respondem diretamente às perguntas sem deixar espaço para ambiguidade, e melhor transparência, porque consegue fornecer provas matematicamente verificáveis de por que suas afirmações estão corretas. Isso torna aplicações de IA generativa auditáveis e explicáveis, mesmo em ambientes altamente regulados.

A Arquitetura da Solução de Referência

Componentes Principais da Interface

A implementação é uma aplicação Flask que expõe APIs para enviar perguntas e verificar o status das respostas. Para revelar o funcionamento interno do sistema, as APIs também permitem recuperar informações sobre o status de cada iteração, o feedback da verificação de raciocínio automatizado e o prompt de reescrita enviado ao modelo. A interface frontend em Node.js permite configurar um modelo de linguagem a partir do Amazon Bedrock para gerar respostas, selecionar uma política de verificação de raciocínio para validação e definir o número máximo de iterações para corrigir uma resposta. Quando você seleciona um thread de conversa na interface, um painel de debug abre do lado direito, exibindo cada iteração do conteúdo e o resultado da validação.

Uma vez que a verificação de raciocínio automatizado valida uma resposta, a explicação verificável dessa validade é exibida para o usuário, criando um nível de confiança explícito no resultado.

O Motor da Solução: O Loop Iterativo de Reescrita

Como Funciona a Validação

A implementação de referência de código aberto melhora automaticamente as respostas do chatbot através de iterações sobre o feedback de verificação de raciocínio e reformulação da resposta. Quando solicitada a validar uma pergunta e resposta (Q&A), a verificação de raciocínio automatizado retorna uma lista de achados. Cada achado representa uma declaração lógica independente identificada na Q&A.

Por exemplo, para a Q&A “Quanto custa o armazenamento S3? Na região US East (N. Virginia), S3 custa $0.023/GB nos primeiros 50TB; na região Asia Pacific (Sydney), S3 custa $0.025/GB nos primeiros 50TB”, a verificação de raciocínio automatizado produziria dois achados: um validando que o preço para S3 em us-east-1 é $0.023 e outro para ap-southeast-2.

Estrutura de Premissas e Alegações

Ao analisar um achado para uma Q&A, a verificação de raciocínio automatizado separa a entrada em uma lista de premissas factuais e alegações verificadas contra essas premissas. Uma premissa pode ser uma declaração factual na pergunta do usuário, como “Sou um usuário de S3 na Virgínia”, ou uma suposição apresentada na resposta, como “Para requisições enviadas para us-east-1…”. Uma alegação representa uma afirmação sendo verificada. No exemplo de preço do S3, a região seria uma premissa e o ponto de preço seria a alegação.

Tipos de Achados e Feedback

Cada achado inclui um resultado de validação (VALID, INVALID, SATISFIABLE, TRANSLATION_AMBIGUOUS, IMPOSSIBLE) junto com o feedback necessário para reformular a resposta de modo que fique VALID. O feedback muda dependendo do tipo de resultado. Achados ambíguos incluem duas interpretações do texto de entrada, achados satisfatórios incluem dois cenários que demonstram como as alegações podem ser verdadeiras em alguns casos e falsas em outros. A documentação da API oferece detalhes sobre todos os tipos de achados possíveis.

O Fluxo de Validação Inicial

Quando o usuário envia uma pergunta pela interface, a aplicação primeiro chama o Modelo de Linguagem de Grande Escala (LLM) configurado no Bedrock para gerar uma resposta, depois chama a API ApplyGuardrail para validar a Q&A. Utilizando o resultado da verificação de raciocínio automatizado na resposta do ApplyGuardrail, a aplicação entra em um loop onde cada iteração verifica o feedback da verificação de raciocínio, executa uma ação como pedir ao LLM para reformular a resposta com base no feedback e depois chama ApplyGuardrail novamente para validar o conteúdo atualizado.

O Loop Central: Priorização e Reescrita

Após a validação inicial, o sistema utiliza o resultado da verificação de raciocínio automatizado para decidir o próximo passo. Primeiro, ordena os achados por prioridade — endereçando os mais importantes primeiro: TRANSLATION_AMBIGUOUS, IMPOSSIBLE, INVALID, SATISFIABLE, VALID. Em seguida, seleciona o achado de maior prioridade e o endereça seguindo esta lógica:

Para achados TRANSLATION_AMBIGUOUS, a verificação de raciocínio automatizado retorna duas interpretações do texto de entrada. Para achados SATISFIABLE, a verificação retorna dois cenários que provam e refutam as alegações. Usando esse feedback, a aplicação pergunta ao LLM se deseja tentar reformular a resposta para esclarecer ambiguidades ou fazer perguntas de acompanhamento para reunir informações adicionais. Por exemplo, o feedback SATISFIABLE pode indicar que o preço de $0.023 é válido apenas se a região for US East (N. Virginia). O LLM pode então usar essa informação para pergunta sobre a região da aplicação.

Quando o LLM decide fazer perguntas de acompanhamento, o loop pausa e aguarda a resposta do usuário, então o LLM regenera a resposta com base nas clarificações e o loop recomeça.

Para achados IMPOSSIBLE, a verificação de raciocínio automatizado retorna uma lista de regras que contradizem as premissas — fatos aceitos no conteúdo de entrada. Usando esse feedback, a aplicação pede ao LLM para reformular a resposta evitando inconsistências lógicas.

Para achados INVALID, a verificação de raciocínio automatizado retorna as regras da política de verificação que tornam as alegações inválidas com base nas premissas e regras de política. Usando esse feedback, a aplicação pede ao LLM para reformular sua resposta de modo que seja consistente com as regras.

Para achados VALID, a aplicação sai do loop e retorna a resposta ao usuário. Após cada reescrita, o sistema envia a Q&A para a API ApplyGuardrail para validação; a próxima iteração do loop começa com o feedback dessa chamada. Cada iteração armazena os achados e prompts com contexto completo na estrutura de dados do thread, criando uma trilha de auditoria de como o sistema chegou à resposta definitiva.

Como Começar com a Implementação

Preparando o Ambiente

Para experimentar essa implementação de referência, o primeiro passo é criar uma política de verificação de raciocínio automatizado. Navegue até o Amazon Bedrock no console AWS em uma das regiões suportadas nos Estados Unidos ou regiões europeias. No menu de navegação esquerdo, acesse a página de Verificação de Raciocínio Automatizado na categoria Construir. Usando o menu suspenso do botão Criar política, escolha Criar política de amostra. Digite um nome para a política e selecione Criar política na parte inferior da página.

Uma vez criada a política, você pode baixar e executar a implementação de referência: Clone o repositório de Amostras do Amazon Bedrock. Siga as instruções no arquivo README para instalar dependências, compilar o frontend e iniciar a aplicação. Usando seu navegador preferido, navegue para http://localhost8080 e comece a fazer testes.

Arquitetura Backend: Componentes Chave

Se você está planejando adaptar essa implementação para uso em produção, esta seção aborda os componentes principais na arquitetura backend. Você encontrará esses componentes no diretório backend do repositório.

ThreadManager: Orquestração de Conversas

Orquestra o gerenciamento do ciclo de vida da conversa. Manipula a criação, recuperação e rastreamento de status dos threads de conversa, mantendo o estado adequado durante todo o processo de reescrita. O ThreadManager implementa operações thread-safe usando um lock para ajudar a prevenir condições de corrida quando múltiplas operações tentam modificar a mesma conversa simultaneamente. Também rastreia threads aguardando entrada do usuário e consegue identificar threads obsoletos que ultrapassaram um timeout configurável.

ThreadProcessor: Máquina de Estados para o Loop Iterativo

Manipula o loop de reescrita usando um padrão de máquina de estados para fluxo de controle claro e mantível. O processador gerencia transições de estado entre fases como GENERATE_INITIAL, VALIDATE, CHECK_QUESTIONS, HANDLE_RESULT e REWRITING_LOOP, progredindo a conversa corretamente através de cada estágio.

ValidationService: Integração com Guardrails do Bedrock

Integra-se com o Guardrails do Amazon Bedrock. Este serviço pega cada resposta gerada pelo LLM e a submete para validação usando a API ApplyGuardrail. Ele gerencia a comunicação com AWS, implementa lógica de retry com backoff exponencial para falhas transitórias e transforma os resultados de validação em achados estruturados.

LLMResponseParser: Interpretação de Intenções do Modelo

Interpreta as intenções do LLM durante o loop de reescrita. Quando o sistema pede ao LLM para corrigir uma resposta inválida, o modelo deve decidir se tenta uma reescrita (REWRITE), faz perguntas de esclarecimento (ASK_QUESTIONS), ou declara a tarefa impossível devido a premissas contraditórias (IMPOSSIBLE). O analisador examina a resposta do LLM procurando por marcadores específicos como “DECISION:”, “ANSWER:” e “QUESTION:”, extraindo informações estruturadas de saída em linguagem natural. Ele lida graciosamente com formatação markdown e impõe limites no número de perguntas (máximo 5).

AuditLogger: Registro e Auditoria

Escreve logs estruturados em JSON em um arquivo de log de auditoria dedicado, registrando dois tipos principais de eventos: VALID_RESPONSE quando uma resposta passa na validação e MAX_ITERATIONS_REACHED quando o sistema esgota o número definido de tentativas. Cada entrada de auditoria captura timestamp, ID do thread, prompt, resposta, ID do modelo e achados de validação. O logger também extrai e registra trocas de Q&A de iterações de esclarecimento, incluindo se o usuário respondeu ou pulou as perguntas.

Integrando os Componentes

Juntos, esses componentes criam uma fundação robusta para construir aplicações de IA confiáveis que combinam a flexibilidade dos modelos de linguagem de grande escala com o rigor da verificação matemática.

Recursos Adicionais e Aprendizado

Para orientação detalhada sobre implementação de verificação de raciocínio automatizado em produção, a AWS oferece vários recursos: um workshop sobre confiabilidade de IA generativa com verificação de raciocínio automatizado, um blog técnico sobre como minimizar alucinações de IA generativa com verificação de raciocínio automatizado do Amazon Bedrock, um blog de caso de uso sobre construção de explicabilidade verificável em workflows de serviços financeiros com verificação de raciocínio automatizado para Guardrails do Amazon Bedrock, e a documentação do Guia do Usuário Amazon Bedrock Guardrails.

Fonte

Automated Reasoning checks rewriting chatbot reference implementation (https://aws.amazon.com/blogs/machine-learning/automated-reasoning-checks-rewriting-chatbot-reference-implementation/)

O Problema do Agente Único Sobrecarregado

Os primeiros protótipos de sistemas baseados em agentes de inteligência artificial costumam compartilhar a mesma arquitetura: um único modelo grande, alguns conectores para ferramentas externas e um extenso prompt de sistema. Essa abordagem funciona razoavelmente bem enquanto os casos de uso permanecem relativamente simples e contidos. No entanto, quando a complexidade real do mundo chega à porta, o sistema começa a desmoronar.

Considere um cenário comum: construir um assistente para planejamento de viagens. As buscas de voos chegam através de uma API estruturada e previsível. As buscas de hotéis, por sua vez, precisam navegar em interfaces web dinâmicas que mudam constantemente. Instruir um único modelo para lidar com ambas as tarefas simultaneamente é como pedir que um engenheiro escreva APIs de backend enquanto também clica manualmente em um site em tempo real. Com o tempo, o modelo começa a confundir instruções, perde contexto e alucina etapas inexistentes.

Aumentar o prompt, adicionar mais ferramentas e implementar lógica de fallback não resolve o problema fundamental: o sistema foi projetado de forma inadequada. Um agente único, quando sobrecarregado com muitas responsabilidades, desacelera, perde rastreabilidade das decisões, faz escolhas inconsistentes e eventualmente colapsa sob seu próprio peso. A solução não está em melhorar o prompting — está em reimaginar a arquitetura.

Arquitetura de Múltiplos Agentes Especializados

A estratégia mais eficaz é dividir o trabalho entre agentes especializados, permitindo que cada um se concentre em uma única responsabilidade bem definida. Em vez de forçar um modelo a fazer tudo, designa-se:

• Agente Viagem: Orquestra todo o fluxo, interpreta a intenção do usuário e coordena os demais agentes
• Agente Voos: Realiza buscas estruturadas em APIs de voos, onde os dados são previsíveis e organizados
• Agente Hotéis: Navega em sites reais de hotéis, lidando com layouts dinâmicos e elementos visuais complexos

Essa separação mantém a lógica limpa e evita que agentes individuais se tornem os gargalos do sistema. Cada um executa sua função com excelência, e um simples mecanismo de passagem de mensagens coordena todo o workflow sem complicações.

Comunicação Entre Agentes

Para que essa arquitetura funcione, os agentes precisam de um mecanismo simples e robusto para se comunicar. O Agente Viagem envia uma solicitação clara ao Agente Voos, aguarda os resultados, e então dispara o Agente Hotéis com a próxima etapa. Não é necessário nada sofisticado — apenas um formato leve de mensagens estruturadas em JSON que cada agente compreenda e saiba como processar.

Quando esse loop de comunicação está em lugar, todo o workflow finalmente se sente coordenado em vez de caótico. Cada mensagem é um objeto JSON compacto contendo a ação, os dados de entrada e o destino da resposta. Essa simplicidade é o segredo para manter o sistema compreensível e manutenível conforme ele cresce.

Implementação Prática com Amazon Nova

Agente Viagem (Amazon Nova 2 Lite)

O Agente Viagem atua como o orquestrador central. Recebe a requisição do usuário em linguagem natural, interpreta a intenção usando Amazon Nova 2 Lite e decide quais agentes chamar em sequência. A tarefa pesada de raciocínio acontece aqui: o modelo quebra a entrada em etapas, identifica quando disparar o Agente Voos ou o Agente Hotéis, e mantém o registro do plano geral.

Como o Agente Viagem não toca sistemas externos diretamente, seu trabalho concentra-se em raciocinar com clareza e rotear mensagens entre os agentes especializados. Ele opera sobre Amazon Bedrock, a plataforma gerenciada da AWS para modelos fundacionais.

Aqui está uma versão simplificada de como o Agente Viagem é inicializado:

# Initialize A2A client tools provider
provider = A2AClientToolProvider(known_agent_urls=[
    "http://localhost:9000",  # Hotel Booking Expert (NovaAct)
    "http://localhost:9001"   # Flight Booking Expert
])

bedrock_model = BedrockModel(
    model_id="global.amazon.nova-2-lite-v1:0",
    region_name="us-east-1",
)

# Create client agent with A2A tools
client_agent = Agent(
    name="Travel Client",
    model=bedrock_model,
    description="Client agent that coordinates travel planning using specialized A2A agents",
    tools=provider.tools,
    system_prompt="""You are an autonomous travel planning agent. You MUST take action immediately without asking for confirmation."""
)

Na prática, o Agente Viagem recebe uma requisição em linguagem natural simples: “Encontre voos de Nova York para Tóquio em 10 de julho e um hotel até 15 de julho.” A partir daí, Amazon Nova 2 Lite reconhece que duas tarefas separadas são necessárias, gera um plano claro, envia uma mensagem ao Agente Voos, aguarda os resultados, e depois dispara o Agente Hotéis com a próxima instrução. Por fim, monta ambas as saídas em uma resposta coerente para o usuário. Essa orquestração mantém a lógica limpa e fluida.

Agente Voos (Amazon Nova 2 Lite + API)

O Agente Voos tem um escopo muito mais estreito: transformar uma requisição estruturada em opções reais de voos. Utiliza Amazon Nova 2 Lite para o raciocínio leve necessário — validar entradas, formatar a busca e decidir se chama a API de voos ao vivo ou retorna dados de fallback quando credenciais não estão disponíveis.

Após a chamada à API, o agente devolve uma resposta JSON limpa e previsível ao Agente Viagem. Como esse agente trabalha com dados estruturados, a carga de raciocínio é mínima e o trabalho do Nova 2 Lite consiste principalmente em escolher o caminho correto de execução e normalizar a saída.

@tool
def search_flights(origin: str, destination: str, departure_date: str, return_date: Optional[str] = None) -> str:
    # Nova 2 Lite handles the reasoning around which path to take
    if amadeus_configured():
        return _search_amadeus_flights(
            origin=origin,
            destination=destination,
            departure_date=departure_date,
            return_date=return_date
        )
    else:
        # Local development fallback
        return _search_flights_web(origin, destination, departure_date, return_date)

E aqui está um exemplo simplificado da resposta:

{
    "flights": [
        {
            "flight_number": "DL456",
            "price": 520,
            "duration": "14h 30m"
        },
        {
            "flight_number": "JL701",
            "price": 545,
            "duration": "13h 50m"
        }
    ],
    "source": "Amadeus API"
}

Essa separação mantém todo o pipeline previsível e evita que lógica específica de API vaze para dentro do Agente Viagem.

Agente Hotéis (Amazon Nova Act)

Hotéis são fundamentalmente diferentes de voos. Não existe uma API única e limpa para consultá-los — a maioria dos sites carrega conteúdo de formas que mudam a cada visita. É nesse cenário que Amazon Nova Act brilha.

O Agente Hotéis utiliza Nova Act para controlar um navegador real e seguir instruções em linguagem natural. Em vez de escrever código frágil de web scraping ou parsing de DOM, o agente instrui o Nova Act sobre o que precisa, e o modelo cuida da navegação, retornando dados estruturados.

@tool
def search_hotels(location: str, checkin_date: str, nights: int = 2) -> str:
    with NovaAct() as nova:
        result = nova.act(
            f"Search for hotels in {location} from {checkin_date} for {nights} nights. "
            f"Return the top 3 listings with name, price, and rating.",
            schema=HotelSearchResults.model_json_schema()
        )
    return json.dumps(result)

Aqui está um exemplo simplificado da resposta:

{
    "hotels": [
        {
            "name": "Shinjuku Grand",
            "price": "$180",
            "rating": 4.3
        },
        {
            "name": "Park Tower Tokyo",
            "price": "$210",
            "rating": 4.6
        },
        {
            "name": "Hotel Blossom",
            "price": "$155",
            "rating": 4.0
        }
    ],
    "source": "Anycompany.com via Nova Act"
}

Usar Amazon Nova Act mantém o Agente Hotéis funcionando mesmo quando os sites mudam de layout. Não há necessidade de manutenção constante ou ajustes frágeis.

Exemplo de Execução Completa

Para ilustrar como tudo funciona na prática, aqui está um fluxo de execução real:

Requisição do usuário: “Organize uma viagem para uma pessoa de Nova York a Paris em 6 de dezembro de 2025, incluindo duas noites de hospedagem em Paris.”

Agente Viagem → Agente Voos: O Agente Viagem extrai a parte de voos da requisição e a envia. O Agente Voos retorna três voos diretos e baratos de JFK para Paris, incluindo companhia aérea, horários, preço e duração.

Agente Viagem → Agente Hotéis: O Agente Viagem envia a parte de hospedagem. O Agente Hotéis, utilizando Nova Act, consulta hotéis em Paris e retorna as três opções principais com nomes, preços e notas resumidas.

Resultado final para o usuário: O Agente Viagem combina ambas as respostas e retorna um resumo claro incluindo:

• O voo recomendado
• O hotel recomendado
• Data de check-in e check-out
• Preços totais
• Uma pergunta se deseja prosseguir com a reserva

Vantagens da Abordagem Multi-Agentes

Construir um planejador de viagens com três agentes pequenos e especializados provou ser muito mais fácil de gerenciar do que um único agente monolítico. Cada agente concentra-se em uma tarefa bem definida. Amazon Nova 2 Lite realiza o raciocínio necessário para mover o trabalho de uma etapa para a próxima. Amazon Nova Act cobre as partes sem APIs, como buscas de hotéis, sem exigir código de scraping manual.

O padrão de passagem de mensagens mantém tudo conectado mas ainda direto e compreensível. Essa arquitetura não se limita a planejamento de viagens. Qualquer tarefa que misture diferentes habilidades pode usar a mesma abordagem: deixe um agente planejar o trabalho, deixe os outros executarem as partes em que são especializados, e passe mensagens pequenas entre eles. O resultado é um sistema que muda e explica-se naturalmente.

Para experimentar essa implementação, o código completo e exemplos estão disponíveis no repositório Agent to Agent com Amazon Nova no GitHub.

Fonte

Agent-to-agent collaboration: Using Amazon Nova 2 Lite and Amazon Nova Act for multi-agent systems (https://aws.amazon.com/blogs/machine-learning/agent-to-agent-collaboration-using-amazon-nova-2-lite-and-amazon-nova-act-for-multi-agent-systems/)

Expansão geográfica do Neptune Analytics

A AWS anunciou a disponibilidade do Amazon Neptune Analytics em sete regiões adicionais: Oriente Médio (Bahrain), Oriente Médio (Emirados Árabes Unidos), Israel (Tel Aviv), África (Cidade do Cabo), Canadá (Calgary), Ásia-Pacífico (Malásia) e Europa (Zurique). Com essa expansão, os usuários podem agora criar e gerenciar gráficos do Neptune Analytics nessas novas regiões, abrindo possibilidades para executar análises gráficas avançadas em geografias que antes não tinham acesso ao serviço.

Sobre o Amazon Neptune

O Neptune é um banco de dados em grafo (graph database) sem servidor que trabalha com dados conectados. A abordagem baseada em grafos traz benefícios significativos, especialmente para aplicações de inteligência artificial: ao modelar dados como um grafo, o serviço captura o contexto relacional dos dados, o que melhora a precisão e a capacidade de explicação das aplicações de IA generativa.

Um dos principais diferenciais do Neptune é a escalabilidade automática. O serviço escala instantaneamente cargas de trabalho em grafo, eliminando a necessidade de o usuário gerenciar manualmente a capacidade infraestrutura — o que reduz a carga operacional e os custos.

Capacidades e integrações para IA

A AWS integrou o Neptune com tecnologias modernas de IA. O serviço oferece GraphRAG (Retrieval-Augmented Generation com grafos) totalmente gerenciado, funcionando em conjunto com o Amazon Bedrock Knowledge Bases. Além disso, o Neptune se integra ao Strands AI Agents SDK e a ferramentas populares de memória para agentes de IA, facilitando o desenvolvimento de aplicações inteligentes.

Na dimensão de análise, o Neptune consegue processar e analisar dezenas de bilhões de relacionamentos entre dados estruturados e não estruturados em segundos, entregando insights estratégicos que seriam impraticáveis em abordagens tradicionais.

Diferencial no mercado

Segundo a AWS, o Neptune é o único banco de dados e mecanismo de análise que combina o poder dos dados conectados com as capacidades empresariais e o valor agregado do ecossistema AWS.

Como começar

Para iniciar com o Neptune Analytics, os usuários podem criar novos gráficos usando o Console de Gerenciamento da AWS ou a AWS CLI (Interface de Linha de Comando da AWS). Para detalhes sobre precificação e disponibilidade em regiões, recomenda-se consultar a página de preços do Neptune e a tabela de regiões da AWS.

Fonte

Amazon Neptune Analytics is now available in 7 additional regions (https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-neptune-analytics-in-seven-additional-regions)

Aplicações com agentes ganham velocidade com novo template completo

Aplicações inteligentes que funcionam como agentes autônomos estão transformando a forma como as empresas operam. De chatbots de atendimento ao cliente até assistentes de pesquisa, a demanda por mover protótipos para produção rapidamente nunca foi tão alta. Nesse contexto, a AWS lançou o Amazon Bedrock AgentCore, uma plataforma de desenvolvimento dedicada à construção, implantação e dimensionamento de agentes de IA em ambientes produtivos.

O AgentCore oferece componentes fundamentais como hospedagem do runtime, gerenciamento de memória, integração de ferramentas e observabilidade, tudo com segurança em nível empresarial e dimensionamento automático. Para demonstrar como todos esses componentes trabalham juntos desde o início, a AWS disponibilizou o Fullstack AgentCore Solution Template (FAST) — um projeto iniciante pronto para implantação que conecta runtime do AgentCore, gateway, memória e interpretador de código com um frontend em React e autenticação via Amazon Cognito, tudo definido com o AWS Cloud Development Kit (AWS CDK).

O FAST fornece uma arquitetura de referência completa mostrando como os componentes se integram na prática, acompanhado de uma aplicação de chat funcionando que você pode estudar e expandir conforme suas necessidades.

Entendendo a arquitetura do FAST

O template oferece uma pilha tecnológica completa para implantar agentes no Amazon Bedrock AgentCore. A solução gerencia automaticamente autenticação, hospedagem de aplicação frontend, runtime do agente, memória, observabilidade e integração de ferramentas via protocolo de contexto de modelo (Model Context Protocol — MCP) por padrão.

No núcleo da arquitetura está o Amazon Bedrock AgentCore Runtime, responsável por executar seu agente. Para segurança, os usuários se autenticam através do Amazon Cognito, que protege quatro pontos críticos de integração:

• Acesso do usuário à aplicação web frontend hospedada no Amazon CloudFront
• Autenticação baseada em token para o frontend acessar o AgentCore Runtime
• Autenticação baseada em token para que os agentes acessem o AgentCore Gateway
• Autenticação baseada em token para requisições de API ao Amazon API Gateway

O frontend é uma aplicação React que utiliza Tailwind CSS e componentes shadcn, hospedada no AWS Amplify Hosting. A comunicação com o AgentCore Runtime ocorre através de streaming HTTP em tempo real, permitindo respostas contínuas. O mecanismo de feedback integrado demonstra como realizar chamadas HTTP síncronas e autenticadas via API Gateway, armazenando dados de aplicação no DynamoDB.

Capacidades principais do AgentCore integradas

O runtime do AgentCore se conecta a diversas capacidades que potencializam o agente:

AgentCore Memory: Armazena histórico de conversas (curto prazo) e insights extraídos como preferências do usuário (longo prazo), permitindo que seu agente mantenha contexto entre sessões sem exigir trabalho customizado com banco de dados. O FAST inclui memória de curto prazo por padrão, sendo possível adicionar memória de longo prazo com pequenas modificações.

AgentCore Gateway: Expõe APIs como ferramentas compatíveis com Model Context Protocol (MCP) para seus agentes.

AgentCore Code Interpreter: Executa código Python de forma segura em ambientes isolados de sandbox.

AgentCore Observability: Envia métricas e logs compatíveis com Open Telemetry (OTEL) para o Amazon CloudWatch e rastreamentos para o AWS X-Ray.

O template inclui padrões tanto para Strands Agents quanto para LangGraph. Importante: o FAST e o AgentCore são agnósticos quanto ao framework de agentes, permitindo que você use o SDK de agentes que preferir. A infraestrutura é definida em AWS CDK, garantindo implantações repetíveis e consistentes.

Design preparado para desenvolvimento assistido por IA

O FAST foi concebido com documentação extensiva já integrada. O repositório inclui:

• Documentos de direcionamento — regras e convenções que assistentes de código seguem automaticamente
• Guias de funcionalidades — documentação detalhada sobre gateway, memória, streaming e outras integrações
• READMEs espalhados pelo código — contexto para cada componente

Quando você pede a um assistente de código que faça alterações, ele consegue ler esses documentos e seguir os padrões documentados. Esta abordagem funciona com diversos assistentes, incluindo Kiro, Cline, Claude Code, Cursor e outros. A documentação é independente de sistema específico.

Vale reforçar: o desenvolvimento assistido por IA é opcional. A mesma documentação que guia assistentes de código é igualmente útil para desenvolvedores que preferem escrever o código manualmente.

Preparando o ambiente

Antes de implantar o FAST, certifique-se de ter instalado:

• Node.js 20 ou posterior
• Python 3.11 ou posterior
• Docker
• AWS Command Line Interface (AWS CLI) configurada com as credenciais mínimas necessárias
• AWS CDK

O usuário de AWS Identity and Access Management (IAM) que você utilizar deve ter permissões para realizar as chamadas necessárias de serviço AWS e gerenciar os recursos mencionados. Ao conceder permissões, siga o princípio do menor privilégio.

Implantando o template passo a passo

Passo 1: Clonar o repositório

Comece clonando o repositório usando os comandos abaixo:

git clone https://github.com/awslabs/fullstack-solution-template-for-agentcore.git
cd fullstack-solution-template-for-agentcore

Passo 2: Configurar a implantação

Edite o arquivo infra-cdk/config.yaml para personalizar sua implantação:

stack_name_base: your-project-name
admin_user_email: admin@example.com # Opcional: cria usuário automaticamente e envia credenciais
backend:
  pattern: strands-single-agent # Disponível: strands-single-agent, langgraph-single-agent
  deployment_type: docker # Disponível: docker, zip

Passo 3: Implantar o backend com CDK

Execute os comandos para implantar o backend:

cd infra-cdk
npm install
cdk bootstrap # Necessário apenas uma vez por conta/região
cdk deploy

Este processo cria o User Pool do Cognito, constrói e envia o container do agente para o Amazon Elastic Container Registry (Amazon ECR), cria o AgentCore Runtime e configura a distribuição CloudFront. A implantação leva aproximadamente 5 a 10 minutos.

Passo 4: Implantar o frontend

Use o script para implantar a interface:

cd ..
python scripts/deploy-frontend.py

O script gera a configuração de autenticação a partir dos outputs da stack CDK, instala dependências, constrói a aplicação React e implanta no AWS Amplify Hosting. Ao finalizar, ele exibe a URL da aplicação:

✓ Deployment completed successfully!
Console: https://console.aws.amazon.com/amplify/apps
App URL: https://main.d123490abcdef.amplifyapp.com

Passo 5: Criar um usuário no Cognito

Se você informou um admin_user_email na configuração, receberá um email com credenciais temporárias. Caso contrário, crie o usuário manualmente:

• Abra o console do Amazon Cognito
• Localize seu User Pool (nomeado como {stack_name_base}-user-pool)
• Navegue até Usuários e selecione Criar usuário
• Digite um endereço de email e uma senha temporária
• Marque a opção de verificar o email
• Escolha Criar usuário

Passo 6: Acessar e testar a aplicação

Acesse a URL do Amplify Hosting (exibida no terminal após a implantação do frontend) no seu navegador. Faça login com suas credenciais do Cognito e altere sua senha temporária quando solicitado.

A aplicação de exemplo FAST é uma interface simples de chat multi-turno. A interface mantém-se minimalista propositalmente — ela foi construída para ser substituída por seu próprio frontend ou integrada a uma aplicação existente.

O agente de linha de base inclui duas ferramentas para demonstrar a arquitetura:

• Ferramenta de análise de texto: Uma ferramenta baseada em AWS Lambda por trás do AgentCore Gateway que conta palavras e analisa frequência de letras. Demonstra o padrão de integração com Gateway.
• Code Interpreter: Integração direta com o AgentCore Code Interpreter para execução Python segura em sandbox isolado.

Teste com essas consultas de exemplo para verificar se as ferramentas funcionam:

• “Analise o texto: The quick brown fox jumps over the lazy dog” — o agente deve retornar contagem de palavras e análise de frequência de letras
• “Calcule os primeiros 20 números de Fibonacci” — observe o agente escrever e executar código Python em tempo real

Lembre-se: a interface e as ferramentas fornecidas servem como ponto de partida, não como limitações. Você deve substituí-las conforme suas necessidades.

Personalizando a aplicação para seus requisitos

Alterando o padrão do agente

O template inclui dois padrões de agentes no diretório patterns/:

• strands-single-agent — agente conversacional básico usando framework Strands com integração de ferramentas MCP
• langgraph-single-agent — agente conversacional básico usando LangGraph com integração de ferramentas MCP

Para trocar de padrão, atualize backend.pattern no arquivo infra-cdk/config.yaml e reimplante com cdk deploy.

Para criar seu próprio padrão, adicione um novo diretório sob patterns/ com sua implementação de agente, um arquivo requirements.txt e um Dockerfile. Atualize a configuração para apontar para seu novo padrão.

Adicionando novas ferramentas via Gateway

O AgentCore Gateway roteia chamadas de ferramentas para uma função AWS Lambda. Para adicionar uma nova ferramenta:

• Crie uma função Lambda que implemente a lógica de sua ferramenta
• Defina o esquema da ferramenta (nome, descrição e parâmetros de entrada) na stack CDK
• Adicione a função Lambda como destino do AgentCore Gateway
• Reimplante com cdk deploy

O agente descobre ferramentas automaticamente a partir do Gateway através de MCP.

Usando o Code Interpreter

O Code Interpreter já está integrado no agente de linha de base, fornecendo execução Python segura em ambientes isolados de sandbox com persistência de sessão. Usuários podem solicitar ao agente que execute cálculos, gere dados ou execute código Python arbitrário.

Modificando o frontend

O frontend é uma aplicação React padrão no diretório frontend/. Assistentes de código como Kiro são hábeis em modificar frontends React. Descreva as mudanças que você deseja e deixe o assistente implementá-las. Após fazer alterações, reimplante com:

python scripts/deploy-frontend.py

Como o FAST utiliza AWS Amplify Hosting, você tem a opção de integrar com um sistema de controle de versão suportado para aproveitar os recursos nativos de integração e entrega contínua (CI/CD) do Amplify Hosting, que pode substituir o script deploy-frontend.py fornecido.

Além do chat: outros casos de uso

A aplicação de linha de base se concentra em interface de chat, mas o FAST suporta muitos casos de uso com agentes. Por exemplo, um agente de análise de documentos poderia adicionar um componente de envio de arquivos ao frontend, uma ferramenta Lambda que extrai texto de PDFs, e lógica de agente que resume os achados. Ou um agente de automação de fluxo poderia monitorar canais Slack e criar tickets Jira automaticamente a partir de solicitações de suporte.

A mesma arquitetura se aplica — você apenas substitui os componentes. Essas personalizações funcionam dentro da arquitetura padrão do FAST.

Flexibilidade: substituindo componentes principais

A arquitetura foi projetada deliberadamente para ser modular, permitindo substituir componentes conforme seus requisitos evoluem:

• Provedor de identidade: Substitua o Amazon Cognito por Okta, Microsoft Entra ID, Auth0 ou seu sistema OAuth 2.0 compatível existente
• Framework frontend: Troque o frontend React por Vue, Angular, ou integre o backend do agente a uma aplicação existente
• Hospedagem: Mude do AWS Amplify Hosting para Vercel, Netlify, uma distribuição CloudFront auto-gerenciada, ou sua solução preferida
• Framework de agente: Use Strands Agents, LangGraph, CrewAI ou até SDKs de agentes em outras linguagens como TypeScript ou Java

A infraestrutura modular em CDK e a arquitetura desacoplada tornam direto adaptar o template às suas necessidades específicas.

Limpando recursos

Para remover os recursos criados pelo FAST, execute:

cd infra-cdk
cdk destroy --force

Este comando deleta recursos AWS incluindo buckets do Amazon Simple Storage Service (Amazon S3) e imagens do Amazon Elastic Container Registry (Amazon ECR). Se deixar recursos em execução, você pode incorrer em cobranças. Note que o Amazon Bedrock AgentCore é faturado por uso.

Próximos passos

O FAST ajuda a reduzir o tempo para construir e implantar uma aplicação com agentes para menos de 30 minutos. Você obtém autenticação segura, um frontend funcional e capacidades integradas do AgentCore — Memória, Gateway, Code Interpreter e Observabilidade — sem precisar escrever infraestrutura do zero.

A aplicação de chat de linha de base e as ferramentas de exemplo são pontos de partida, não limitações. Você pode substituir sua própria lógica de agente, conectar suas ferramentas, modificar o frontend, ou até substituir componentes principais como o provedor de identidade ou a solução de hospedagem. A arquitetura modular se adapta aos seus requisitos.

Para começar, acesse o repositório, clone-o, implante o FAST na sua conta AWS e tenha uma aplicação com agentes funcionando em menos de 30 minutos. Depois, customize e coloque em produção algo real.

Para assistência especializada, a AWS Generative AI Innovation Center, AWS Professional Services e AWS Partners estão disponíveis para ajudar.

Fonte

Accelerate agentic application development with a full-stack starter template for Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/accelerate-agentic-application-development-with-a-full-stack-starter-template-for-amazon-bedrock-agentcore/)

Simplificação da Computação Distribuída para IA

O treinamento e implementação de grandes modelos de inteligência artificial exigem capacidades avançadas de computação distribuída. No entanto, gerenciar esses sistemas complexos não deveria ser uma tarefa complicada para cientistas de dados e profissionais de aprendizado de máquina.

A Amazon SageMaker HyperPod com orquestração Amazon Elastic Kubernetes Service (Amazon EKS) oferece uma abordagem diferente. O pacote de ferramentas — composto por interface de linha de comando (CLI) e kit de desenvolvimento de software (SDK) — permite que usuários gerenciem infraestrutura de cluster e acessem capacidades de treinamento e inferência distribuídos de forma mais intuitiva, abstraindo a complexidade subjacente dos sistemas distribuídos.

Arquitetura em Camadas para Simplicidade

A CLI e o SDK seguem uma arquitetura multi-camada compartilhada. Ambas servem como pontos de entrada para o usuário e estão construídas sobre componentes comuns, proporcionando comportamento consistente nas diferentes interfaces.

Para automação de infraestrutura, o SDK orquestra o gerenciamento do ciclo de vida do cluster através de uma combinação de provisionamento de stacks AWS CloudFormation e interações diretas com APIs da AWS. Cargas de trabalho de treinamento e inferência, além de ambientes de desenvolvimento integrados (IDEs), são expressas como Definições de Recurso Personalizado do Kubernetes (CRDs), que o SDK gerencia através da API do Kubernetes.

Instalação e Preparação

Pré-requisitos

Para utilizar as ferramentas, você precisará de:

• Uma conta da AWS com acesso a SageMaker HyperPod, Amazon Simple Storage Service (Amazon S3) e Amazon FSx for Lustre
• Cota de serviço suficiente para criar o cluster HyperPod e grupos de instâncias
• Um ambiente local (máquina local ou ambiente de computação baseado em nuvem) para executar comandos da CLI HyperPod, configurado com:
• Sistema operacional baseado em Linux ou MacOS
• Python 3.8 ou superior instalado
• AWS Command Line Interface (AWS CLI) configurada com credenciais apropriadas

Instalação da CLI HyperPod

A instalação é direta. Execute o seguinte comando a partir do seu ambiente local:

pip install sagemaker-hyperpod

Este comando configura as ferramentas necessárias para interagir com clusters SageMaker HyperPod. Para instalações existentes, certifique-se de que tem a versão mais recente do pacote (SageMaker HyperPod 3.5.0 ou posterior).

Para verificar se a CLI foi instalada corretamente, execute:

hyp

A saída exibirá todas as opções e comandos disponíveis, incluindo instruções de uso. A CLI oferece uma gama completa de comandos para gerenciar o ciclo de vida do HyperPod — desde criação de clusters até criação de endpoints, execução de jobs, monitoramento e exclusão.

Para informações detalhadas sobre uso da CLI e parâmetros disponíveis, consulte a documentação de referência da CLI.

Criação e Gerenciamento de Clusters

Inicializando uma Nova Configuração de Cluster

A AWS oferece dois caminhos para criar clusters HyperPod: através do console de gerenciamento ou da CLI. O console fornece a experiência mais guiada, enquanto a CLI é ideal para usuários que preferem automação programática.

Ambas as abordagens utilizam o mesmo modelo CloudFormation subjacente, disponível no repositório GitHub SageMaker HyperPod cluster setup. Para um passo a passo baseado em console, consulte o post sobre a nova experiência de criação de cluster.

A criação via CLI segue um fluxo baseado em configuração. Primeiro, inicialize uma nova configuração de cluster:

hyp init cluster-stack

Isso cria um arquivo config.yaml onde você especifica a configuração do cluster, além de um arquivo README.md com informações sobre o fluxo de trabalho.

Configuração do Cluster

O arquivo config.yaml contém variáveis cruciais como:

resource_name_prefix: hyp-eks-stack
hyperpod_cluster_name: hyperpod-cluster
kubernetes_version: 1.31

O parâmetro resource_name_prefix serve como identificador principal dos recursos criados. Cada implantação deve usar um prefixo único para evitar conflitos.

Você pode editar a configuração diretamente ou usar comandos da CLI como:

hyp configure --kubernetes-version 1.33

Existem duas nuances importantes ao atualizar valores de configuração: underscores (_) em nomes de variáveis no arquivo se tornam hífens (-) nos comandos CLI. Variáveis contendo listas são configuradas como JSON nos comandos CLI.

Validação e Envio

Após realizar as alterações desejadas, valide o arquivo de configuração:

hyp validate

Se bem-sucedido, o comando confirmará que a configuração é válida. Em seguida, envie o stack de criação para CloudFormation:

hyp create --region us-east-1

O comando realiza validação e injeta valores do arquivo config.yaml no modelo. Os arquivos resolvidos são salvos em um subdiretório com timestamp, fornecendo um mecanismo leve de versionamento local. Se bem-sucedido, você receberá uma ID de stack do CloudFormation.

Monitoramento da Criação

Para listar stacks CloudFormation existentes:

hyp list cluster-stack --region us-east-1

Você pode filtrar por status usando a flag --status. Para visualizar detalhes de um stack específico:

hyp describe cluster-stack <nome-do-stack> --region us-east-1

Se algum dos stacks mostrar status como CREATE_FAILED ou ROLLBACK_*, abra a página CloudFormation no console para investigar. Falhas frequentemente relacionam-se a cotas de serviço insuficientes para o cluster, grupos de instâncias ou componentes de rede como VPCs ou gateways NAT. Consulte as quotas do SageMaker HyperPod para saber mais sobre requisitos.

Conexão ao Cluster

Após o stack completar sua criação com status CREATE_COMPLETE, configure a CLI e seu ambiente Kubernetes local para interagir com o cluster:

hyp set-cluster-context --cluster-name <nome-cluster> --region us-east-1

Este comando atualiza sua configuração Kubernetes local, permitindo usar tanto a CLI HyperPod quanto utilitários como kubectl para gerenciar recursos.

Modificação de Clusters Existentes

A CLI oferece capacidade de modificar grupos de instâncias e modo de recuperação de nós através do comando:

hyp update cluster --cluster-name <nome> --region <região> --instance-groups '[{"instance_count": 2, "instance_group_name": "worker-nodes", "instance_type": "ml.m5.large"}]'

Todos os campos são necessários para executar o comando de atualização, mesmo que você esteja modificando apenas um deles. A opção --node-recovery permite configurar o comportamento de recuperação de nós (Automática ou Nenhuma). Para mais informações, consulte a documentação sobre recuperação automática de nós.

Exclusão de Clusters

Para remover um cluster HyperPod:

hyp delete cluster-stack <nome-do-stack> --region us-east-1

Esta ação é irreversível. A CLI solicitará confirmação antes de proceder. Você pode usar a flag --retain-resources para especificar recursos que deseja manter durante o processo de exclusão.

SDK Python para Controle Programático

A AWS também inclui um SDK Python para acesso programático às funcionalidades descritas. O SDK Python é utilizado pelos comandos CLI e é instalado quando você instala o pacote sagemaker-hyperpod.

A CLI é ideal para usuários que preferem uma experiência simplificada e interativa para tarefas comuns como criação de clusters, monitoramento de jobs e implantação de endpoints. É especialmente útil para prototipagem rápida, experimentação e automação de fluxos de trabalho através de scripts ou pipelines CI/CD.

O SDK, por sua vez, oferece maior controle programático e flexibilidade, sendo a escolha preferida quando você precisa incorporar funcionalidades HyperPod diretamente em sua aplicação, integrar com outros serviços da AWS ou de terceiros, ou construir fluxos de trabalho customizados e complexos.

O repositório GitHub da CLI SageMaker HyperPod mostra exemplos de como criação e gerenciamento de clusters podem ser implementados usando o SDK Python.

Próximos Passos

A CLI e o SDK do SageMaker HyperPod simplificam significativamente a criação e gerenciamento de clusters. Essas ferramentas fornecem valor através de:

• Gerenciamento simplificado do ciclo de vida — Da configuração inicial às atualizações e limpeza do cluster, as ferramentas alinham-se com como equipes gerenciam ambientes de treinamento e inferência de longa duração
• Controle declarativo — O SDK expõe o modelo de configuração subjacente, permitindo que equipes codifiquem especificações de cluster, grupos de instâncias e sistemas de armazenamento
• Observabilidade integrada — Visibilidade dos stacks CloudFormation está disponível sem trocar de ferramentas, suportando iteração suave durante desenvolvimento e operação

Se você deseja explorar como usar a CLI e o SDK para enviar jobs de treinamento e implantar modelos em seu novo cluster, consulte nosso post complementar sobre treinamento e implantação de modelos no SageMaker HyperPod.

Fonte

Manage Amazon SageMaker HyperPod clusters using the HyperPod CLI and SDK (https://aws.amazon.com/blogs/machine-learning/manage-amazon-sagemaker-hyperpod-clusters-using-the-hyperpod-cli-and-sdk/)