O problema: digitalizar documentos com fotos e nomes

Imagine uma página de anuário escolar escaneada: 176 nomes impressos, 4 fotografias de retrato e zero estrutura legível por máquina que conecte um ao outro. Para digitalizar essa página de forma confiável, você precisa detectar as fotos com coordenadas precisas, extrair os nomes visíveis e, o mais difícil, descobrir qual nome pertence a qual rosto com base no layout da página.

A AWS publicou um estudo técnico detalhado mostrando como resolver esse problema de forma eficiente usando dois modelos em sequência no Amazon Bedrock: o Amazon Nova 2 Lite e o Claude Sonnet 4.6 da Anthropic.

A arquitetura: pipeline de dois estágios

A solução divide o trabalho em dois estágios bem definidos, cada um usando o modelo mais adequado para sua tarefa específica.

Estágio 1 — Amazon Nova 2 Lite: recebe a imagem da página escaneada e, em uma única chamada à API Converse, realiza três tarefas simultaneamente: detecta as fotos com bounding boxes (caixas delimitadoras) e classificações, extrai os nomes visíveis na página com suas posições aproximadas, e retorna metadados da página como títulos e categorias.

Estágio 2 — Claude Sonnet 4.6: recebe o resultado do Nova (nomes com posições e bounding boxes das fotos) e aplica raciocínio espacial para determinar qual nome corresponde a qual rosto, levando em conta a variabilidade de layouts de página.

Uma decisão de projeto importante: o Nova 2 Lite é configurado para retornar apenas os nomes visíveis, não todo o texto da página. Isso mantém o custo do primeiro estágio baixo — cerca de 1.000 tokens de saída por página, em vez dos aproximados 4.500 tokens que uma passagem completa de OCR (Reconhecimento Óptico de Caracteres) produziria.

Precificação fixa por imagem no Nova 2 Lite

Um ponto técnico relevante destacado no estudo é a mudança na forma como o Amazon Nova 2 Lite cobra entradas de imagem: agora utiliza uma taxa fixa por imagem, independentemente da resolução ou tamanho do arquivo. Isso torna o custo por página previsível em escala.

A quebra de custo por página no primeiro estágio fica assim:

• Tokens de imagem (fixos): 230 tokens a $0,30/M → $0,000069/página
• Tokens de prompt (estimado): 500 tokens a $0,30/M → $0,000150/página
• Tokens de saída (estimado): 1.000 tokens a $2,50/M → $0,0025/página
• Total do estágio 1: ~$0,0027/página

Para consultar as taxas atuais, a AWS disponibiliza a página de preços do Amazon Bedrock.

Raciocínio adaptativo do Claude para correspondência espacial

O Claude Sonnet 4.6 no Amazon Bedrock suporta o que a Anthropic chama de adaptive thinking (raciocínio adaptativo): o modelo decide internamente quanto raciocínio aplicar com base na complexidade da entrada. Para ativá-lo, basta configurar type como adaptive no campo thinking da chamada à API Converse:

response = bedrock_runtime.converse(
    modelId='us.anthropic.claude-sonnet-4-6',
    messages=[{
        'role': 'user',
        'content': [
            {'image': {'format': 'jpeg', 'source': {'bytes': image_bytes}}},
            {'text': spatial_reasoning_prompt}
        ]
    }],
    additionalModelRequestFields={
        'thinking': {
            'type': 'adaptive'
        }
    }
)

Na prática, uma grade de retratos com oito nomes organizados acima de oito rostos recebe uma resposta direta com raciocínio mínimo. Já uma página com três fotos de grupo compartilhando um bloco de legenda e nomes em uma coluna lateral dispara uma análise espacial passo a passo. No teste com 336 páginas, o Claude usou raciocínio estendido em todas as páginas, com traços de raciocínio variando de 544 a 1.658 caracteres.

Atenção ao custo do raciocínio adaptativo: tokens de raciocínio são cobrados como tokens de saída à taxa padrão ($15,00/M tokens de saída para o Claude Sonnet 4.6 via inferência entre regiões). Os traços de raciocínio aparecem na resposta da API em um bloco separado (thinking), mas não são exibidos aos usuários finais. É recomendável monitorar inputTokens e outputTokens nos metadados da resposta.

Implementação passo a passo

O código-fonte completo, imagens de exemplo e notebook Jupyter estão disponíveis no repositório AWS Samples no GitHub.

Pré-requisitos

• Conta AWS com acesso ao Amazon Bedrock em uma região onde o Nova 2 Lite e o Claude Sonnet 4.6 estejam disponíveis
• Acesso aos modelos us.amazon.nova-2-lite-v1:0 e us.anthropic.claude-sonnet-4-6 habilitado no console do Amazon Bedrock
• Perfil do Gerenciamento de Identidade e Acesso (IAM) com permissão para bedrock:InvokeModel e bedrock:Converse nos dois modelos
• Python 3.10 ou superior com o SDK boto3 instalado
• Bibliotecas rapidfuzz (para correspondência fuzzy de nomes) e Pillow (para visualização)
• Imagens escaneadas em formato JPEG ou PNG

Estágio 1: detecção de fotos e extração de nomes com o Nova 2 Lite

A chamada ao Nova 2 Lite usa a API Converse com raciocínio configurado no nível LOW (baixo), que se mostrou tão preciso quanto os níveis MEDIUM e HIGH para essa tarefa de extração estruturada, e é a opção mais barata:

def extract_photos_and_names(image_bytes):
    """Detect photos and extract visible names with Amazon Nova 2 Lite."""
    # Using the Converse API consistently for all Bedrock calls
    response = bedrock_runtime.converse(
        modelId='us.amazon.nova-2-lite-v1:0',
        # Note: cross-region inference profile (us.amazon.nova-2-lite-v1:0)
        messages=[{
            'role': 'user',
            'content': [
                {
                    'image': {
                        'format': 'jpeg',
                        'source': {'bytes': image_bytes}
                    }
                },
                {'text': PHOTO_AND_NAME_EXTRACTION_PROMPT}
            ]
        }],
        inferenceConfig={
            'maxTokens': 8000,
            'temperature': 0
        },
        additionalModelRequestFields={
            'reasoning_config': {
                'type': 'enabled',
                'level': 'LOW'
            }
        }
    )
    raw = response['output']['message']['content'][0]['text']
    return json.loads(raw)

O modelo retorna um objeto JSON com fotos e nomes, todos usando a escala de coordenadas 0–1000:

{
  "page_title": "Junior Class Officers",
  "photos": [
    {
      "bbox": [245, 180, 410, 520],
      "type": "portrait",
      "category": "class_officers",
      "summary": "Individual portrait photo"
    }
  ],
  "names": [
    {
      "text": "Cecilia Phillips",
      "bbox": [260, 540, 395, 570]
    },
    {
      "text": "John Kolander",
      "bbox": [420, 540, 555, 570]
    }
  ]
}

Os campos page_title e category também servem para indexação e filtragem — com uma única chamada à API, o Nova 2 Lite entrega detecção de fotos, nomes com posições e metadados estruturados.

Estágio 2: correspondência nome-rosto com o Claude

O Claude recebe o resultado do Nova (nomes e bounding boxes de fotos, ambos no mesmo espaço de coordenadas 0–1000) junto com a imagem original e realiza o raciocínio espacial:

spatial_prompt = f"""Given these names with page coordinates:
{json.dumps(ocr_tokens)}

And these detected photos with bounding boxes:
{json.dumps(photo_detections)}

Match each person's name to their photo based on spatial position.
Return JSON:
{{"associations": [{{"name": str, "face_idx": int, "confidence": float, "reasoning": str}}]}}}"""

response = bedrock_runtime.converse(
    modelId='us.anthropic.claude-sonnet-4-6',
    messages=[{
        'role': 'user',
        'content': [
            {'image': {'format': 'jpeg', 'source': {'bytes': image_bytes}}},
            {'text': spatial_prompt}
        ]
    }],
    additionalModelRequestFields={
        'thinking': {'type': 'adaptive'}
    }
)

Cada associação retornada inclui um campo reasoning que explica a lógica espacial usada — útil para depurar páginas onde a correspondência falha.

Estágio 3: validação e montagem dos resultados

O estágio final aplica limiares de confiança e correspondência fuzzy de nomes (usando rapidfuzz) para filtrar associações de baixa qualidade. O pipeline gera dois arquivos por página: um JSON com os dados de associação e uma imagem de visualização com linhas conectando nomes aos rostos correspondentes.

Resultados do teste com 336 páginas

O pipeline foi executado contra 336 páginas escaneadas de anuários escolares e produziu:

• 3.122 associações nome-rosto no total
• 93,3% das associações com confiança igual ou superior a 0,95
• 6,5% com confiança entre 0,90 e 0,94
• Apenas 0,3% abaixo do limiar de 0,90

Páginas com grade de retratos (282 de 336) tiveram em média 10,9 associações por página e foram tratadas de forma confiável. Páginas somente com texto foram corretamente ignoradas. Páginas com layouts mistos (retratos e fotos de grupo) produziram associações parciais.

Comparação de custos: dois modelos vs. modelo único

A divisão em dois modelos custa aproximadamente dois terços a menos por página do que enviar tudo para o Claude em uma única chamada:

• Pipeline de dois modelos: ~$0,033/página (~$3.300 por 100 mil páginas)
• Claude único (OCR + detecção + raciocínio): ~$0,10/página (~$9.800 por 100 mil páginas)

No teste real com 336 páginas, o custo total ficou em aproximadamente $10,99 ($0,91 para o Nova 2 Lite + $10,08 para o Claude).

Otimizações adicionais de custo

• Inferência em lote do Amazon Bedrock: desconto de 50% para workloads que podem ser processados de forma assíncrona. O custo do estágio Nova 2 Lite cai de ~$0,0027 para ~$0,0014 por página.
• Cache de prompt: para pipelines que usam o mesmo prompt de detecção em milhares de páginas, o cache pode reduzir o custo dos tokens de prompt em até 90%.
• Controle de orçamento de raciocínio: é possível definir um limite de budgetTokens no campo thinking do Claude para controlar o custo de raciocínio em páginas mais simples.

Latência por página

Cada página passa por duas chamadas de API sequenciais. No teste realizado, o estágio do Claude (raciocínio espacial com imagem) levou entre 20 e 30 segundos por página. O Nova 2 Lite completou em 2 a 5 segundos. Para processamento em lote, as páginas podem ser paralelizadas, pois cada uma é independente.

Além dos anuários: aplicação do padrão

O padrão descrito pela AWS vai além da digitalização de anuários escolares. Qualquer documento que combine fotos e texto associado — arquivos históricos, diretórios de pessoal, anúncios imobiliários, catálogos de produtos — precisa das mesmas capacidades: detectar elementos visuais, extrair o texto relevante e conectar os dois por meio de raciocínio espacial.

Para saber mais sobre os serviços utilizados, a AWS disponibiliza a documentação do Amazon Nova no Amazon Bedrock e do raciocínio adaptativo com Claude no Amazon Bedrock. O notebook completo com exemplos está disponível no repositório AWS Samples no GitHub.

Fonte

Pair Nova 2 Lite with Claude for cost-optimized document processing (https://aws.amazon.com/blogs/machine-learning/pair-nova-2-lite-with-claude-for-cost-optimized-document-processing/)

O problema: acervos de vídeo em baixa resolução num mundo de telas 4K

À medida que as tecnologias de exibição avançam para resoluções cada vez mais altas, organizações de todos os tamanhos enfrentam um desafio em comum: seus acervos de vídeo existentes foram produzidos em resoluções menores e aparecem pixelados ou borrados em monitores modernos de alta definição. As abordagens tradicionais de upscaling costumam tropeçar em limitações computacionais, qualidade inconsistente e dificuldade de escalar quando o volume de conteúdo é grande. Além disso, muitas soluções não conseguem restaurar detalhes finos, afiar bordas ou reduzir artefatos de ruído de forma satisfatória.

Para endereçar esse cenário, a AWS publicou um guia técnico demonstrando como implantar o SeedVR2 no Amazon SageMaker AI para realizar super resolução de vídeos de forma escalável e com controle de custos.

O que é o SeedVR2?

O SeedVR2 é um modelo open-source de restauração de vídeo desenvolvido pelo time Seed da ByteDance. Ele analisa as informações visuais quadro a quadro para reconstruir detalhes e melhorar a qualidade do vídeo, eliminando a necessidade de readquirir conteúdo em resoluções mais altas.

Tecnicamente, o SeedVR2 combina modelos de difusão e Redes Adversariais Generativas (GANs) por meio de um processo chamado diffusion adversarial post-training (APT). A arquitetura base conta com 16 bilhões de parâmetros e opera em duas etapas:

• Destilação progressiva: comprime 64 passos de inferência em apenas 1, tornando o processo muito mais eficiente.
• Treinamento com dados reais: o modelo aprende a partir de vídeos reais em alta resolução, garantindo resultados mais naturais.

A arquitetura usa um Swin Transformer para atenção adaptativa por janelas (adaptive window attention) e incorpora múltiplos mecanismos de estabilização: RpGAN relativístico (RpGAN), regularização R1/R2 e feature matching loss. A inovação central está em combinar a confiabilidade dos modelos de difusão com a eficiência das GANs, permitindo processar frames inteiros enquanto se ajusta dinamicamente às resoluções-alvo.

Casos de uso

O upscaling de vídeo tem aplicações relevantes em diversos setores:

• Preservação de patrimônio cultural: arquivos, museus e emissoras podem restaurar e digitalizar filmagens históricas em resoluções mais altas, tornando o conteúdo adequado para plataformas modernas.
• Serviços de streaming: plataformas podem fazer upscaling de séries e filmes antigos para 4K ou resoluções superiores, melhorando a experiência dos assinantes sem precisar remasterizar todo o acervo.
• Vídeos gerados por IA: um caso de uso emergente e valioso é o upscaling de vídeos sintéticos, que normalmente são gerados em resoluções menores por conta do alto custo computacional da geração direta em alta resolução. Com essa abordagem, criadores podem prototipar rapidamente em baixa resolução e depois aprimorar o resultado, reduzindo tempo e recursos no fluxo de produção de vídeo com IA.

Arquitetura da solução

A solução proposta pela AWS usa uma arquitetura de três camadas definida com o Kit de Desenvolvimento para Nuvem da AWS (AWS CDK) como infraestrutura como código. As três camadas são:

SecurityStack — fundação de segurança

Essa camada estabelece a base com configuração de Nuvem Privada Virtual da Amazon (Amazon VPC), funções de Gerenciamento de Identidade e Acesso da AWS (AWS IAM) com acesso de menor privilégio e chaves de criptografia do Serviço de Gerenciamento de Chaves da AWS (AWS KMS). Ela cria o perímetro de segurança que isola as cargas de trabalho de processamento de vídeo em sub-redes privadas, mantendo acesso seguro aos serviços AWS por meio de endpoints de VPC.

DataStack — camada de armazenamento

Implementa a camada de armazenamento com buckets do Serviço de Armazenamento Simples da Amazon (Amazon S3) com criptografia no servidor tanto para os vídeos de entrada quanto para os de saída. O bucket de entrada armazena os vídeos brutos; o de saída guarda os vídeos já processados. Ambos têm versionamento habilitado com políticas de ciclo de vida para gerenciamento de objetos.

Pipeline de processamento

O núcleo do processamento passa por uma função AWS Lambda que dispara um job de processamento do Amazon SageMaker AI. O job de processamento usa instâncias ml.g5.4xlarge que executam um container Docker customizado. Esse container empacota o modelo SeedVR2 para ComfyUI e oferece upscaling de vídeo de alta qualidade com parâmetros configuráveis de resolução e processamento em lote. O ComfyUI serve como framework de inferência, fornecendo execução otimizada para hardware.

O fluxo começa quando um vídeo é enviado ao bucket S3 de entrada. A função Lambda então cria um job de processamento no SageMaker, que puxa o container customizado do Registro de Containers Elástico da Amazon (Amazon ECR), monta os buckets S3 de entrada e saída, e executa o algoritmo de upscaling na infraestrutura com GPU. Os vídeos processados são salvos no bucket de saída. O Amazon CloudWatch fornece logs para monitoramento e resolução de problemas em todo o pipeline.

Como implantar a solução

Pré-requisitos

Antes de começar, é necessário ter instalados e configurados: Python 3.13 ou superior, a Interface de Linha de Comando da AWS (AWS CLI), Docker, AWS CDK v2, uma conta AWS com as permissões adequadas e uma solicitação de cota de serviço para ml.g5.4xlarge em jobs de processamento do SageMaker.

Passo 1: clonar o projeto e configurar o ambiente

git clone https://github.com/aws-samples/sample-sagemaker-video-upscaler.git
cd sample-sagemaker-video-upscaler
cp .env.example .env

Edite o arquivo .env com os dados da sua conta AWS:

AWS_ACCOUNT_ID=<AWS Account ID>
REGION=<AWS Region>

Passo 2: instalar dependências e inicializar o AWS CDK

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv --python 3.13 and source .venv/bin/activate
uv sync

Em seguida, faça o bootstrap do CDK na sua conta (etapa única). Se encontrar erros de permissão, verifique suas credenciais com aws sts get-caller-identity.

cdk bootstrap aws://<AWS_ACCOUNT_ID>/<REGION>

Passo 3: autenticar com o Amazon ECR

Autentique o Docker no registro ECR de containers de aprendizado profundo da AWS na região us-east-1. Isso é necessário para baixar a imagem base do PyTorch durante o build local do Docker, independentemente da região de implantação.

aws ecr get-login-password --region us-east-1 | \
docker login --username AWS --password-stdin \
763104351884.dkr.ecr.us-east-1.amazonaws.com

Passo 4: implantar a infraestrutura

Um único comando cria toda a infraestrutura: VPC, buckets S3, função Lambda, definição do job de processamento do SageMaker e repositório no ECR. O processo leva entre 15 e 20 minutos, dependendo da capacidade de computação e da velocidade de rede.

cdk deploy --all --require-approval never

Passo 5: testar o pipeline

Envie um vídeo de teste para o bucket S3 de entrada:

aws s3 cp your-video.mp4 s3://<account-id>-<region>-datastack-input-bucket/

Dispare a função Lambda para iniciar o job de processamento:

aws lambda invoke \
  --function-name SeedVrStack-ProcessingJob-Trigger-SeedVr-trigger-Lambda \
  --payload '{}' \
  output.json

O progresso pode ser acompanhado pelos logs do CloudWatch para a execução da Lambda, pelo console do SageMaker para o status do job de processamento e pelo console do S3 para verificar o vídeo aprimorado na saída. Se o job falhar, revise os logs do CloudWatch em /aws/sagemaker/ProcessingJobs.

Ajuste de performance e custos

Os parâmetros de processamento podem ser personalizados no arquivo config/config.yaml:

InstanceType: ml.g5.4xlarge # Minimum resolution: "540" # Output quality batch_size: "81" # Processing efficiency model: "seedvr2_ema_3b_fp8_e4m3fn.safetensors"

Para a lista completa de modelos disponíveis, consulte os modelos SeedVR2 para ComfyUI no Hugging Face.

Em relação a custos, a instância ml.g5.4xlarge custa aproximadamente USD 1,20 por hora (valor no momento da publicação, podendo variar por região), e a cobrança ocorre apenas pelo tempo de uso da instância. Os custos de armazenamento no S3 são mínimos para a maioria dos casos de uso.

Para conjuntos de dados maiores, é possível escalar com múltiplas instâncias paralelas alterando o parâmetro S3DataDistributionType para ShardedByS3Key na chamada boto3 de create_processing_job. Mais detalhes estão disponíveis na referência da API ProcessingS3Input.

Comparativo de qualidade: o que muda na prática

O artigo original apresenta três estágios de comparação para ilustrar os ganhos de qualidade:

Vídeo original (240p)

O material de origem é um clipe em resolução 240p. A pixelação é visível, especialmente nas bordas, e há pouco detalhe e clareza — algo que se torna ainda mais evidente em telas de alta resolução modernas.

Upscaling bicúbico (540p)

Ao aplicar o método tradicional de upscaling bicúbico para atingir 540p, há pequenas melhorias de nitidez geral. No entanto, as limitações da interpolação matemática ficam evidentes: a imagem fica maior, mas surgem artefatos como suavização excessiva de texturas. O algoritmo não consegue recriar detalhes autênticos, produzindo resultados com aparência artificial.

Upscaling com SeedVR2 (540p)

O resultado do SeedVR2 demonstra melhora visual significativa ao atingir 540p. O aprimoramento baseado em IA reconstrói detalhes finos mantendo texturas com aparência natural — melhor clareza em texturas, consistência de cores e definição de bordas. O resultado tem uma qualidade mais cinematográfica em comparação aos métodos tradicionais.

Limpeza dos recursos

Para evitar cobranças desnecessárias após os testes, o artigo recomenda seguir quatro etapas de limpeza:

Passo 1: esvaziar os buckets S3

aws s3 rm s3://<seedvr-input-bucket> --recursive
aws s3 rm s3://<seedvr-output-bucket> --recursive

Passo 2: destruir as stacks do AWS CDK

cdk destroy --all --force

Passo 3: limpar arquivos locais

rm -rf cdk.out/ .cdk.staging/
find . -type d -name "__pycache__" -delete

Passo 4: verificar a limpeza

aws cloudformation list-stacks --stack-status-filter DELETE_COMPLETE
aws s3 ls | grep seedvr
aws sagemaker list-processing-jobs --max-results 5

Conclusão

A combinação do SeedVR2 com a infraestrutura gerenciada do Amazon SageMaker AI oferece uma abordagem custo-eficiente para aprimoramento de vídeo em escala. A arquitetura sob demanda suporta uso eficiente de recursos, e o fluxo automatizado reduz intervenção manual — tornando o aprimoramento de vídeo de alta qualidade acessível a organizações de todos os tamanhos.

À medida que o conteúdo em vídeo cresce e as tecnologias de exibição avançam, soluções de upscaling eficientes se tornam cada vez mais relevantes. Essa implementação mostra como a arquitetura em nuvem pode democratizar o acesso ao processamento avançado de vídeo sem exigir grandes investimentos em infraestrutura própria.

Para começar, explore o repositório sample-sagemaker-video-upscaler no GitHub e implante a solução para o seu caso de uso. Contribuições via pull requests e abertura de issues para melhorias e correções também são bem-vindas.

Fonte

Implementing super resolution by deploying SeedVR2 on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/implementing-super-resolution-by-deploying-seedvr2-on-amazon-sagemaker-ai/)

O problema: gerenciar eventos de saúde de forma reativa

Imagine uma segunda-feira típica para uma equipe de operações em nuvem: chegam múltiplas notificações do AWS Health sobre fim de vida do Amazon Linux 2, depreciações de versões do RDS e aposentadorias de instâncias EC2 — tudo isso espalhado por mais de 50 contas. Sem uma forma eficiente de análise centralizada, a equipe fica sem resposta para perguntas simples: quais eventos afetam sistemas em produção? O que exige ação imediata versus planejamento de longo prazo? Qual é o impacto real de cada categoria?

Para piorar, as equipes ficam dependentes dos Gerentes de Conta Técnica (TAMs — Technical Account Managers) para interpretar esses eventos, criando gargalos em decisões operacionais críticas. O resultado é tempo gasto em combate a incêndios reativos, em vez de inovação.

Foi para resolver exatamente esse problema que a AWS publicou um guia mostrando como construir o Chaplin — sigla para Customer Health and Planned Lifecycle Intelligence Nexus — uma solução open source que usa agentes de IA para entregar análises de eventos de saúde de forma autônoma e conversacional.

O que é o Chaplin e como ele funciona

O Chaplin implementa análises autônomas de eventos de saúde usando IA agêntica com o Amazon Bedrock, entregues por meio do Protocolo de Contexto de Modelo (MCP — Model Context Protocol). Em vez de dashboards com esquemas predefinidos, o Chaplin expõe ferramentas com IA que clientes compatíveis com MCP podem consumir diretamente.

Na prática, equipes interagem com o Chaplin a partir de assistentes de IA como o Claude Code ou o Kiro CLI, fazendo perguntas em linguagem natural. Por exemplo:

• Quais eventos de ciclo de vida do RDS vencem nos próximos 60 dias?
• Resuma os eventos EC2 abertos, priorizados por urgência
• Quais patches de segurança afetam ambientes de produção?
• Quais janelas de manutenção podem impactar aplicações de alta prioridade?

As instruções completas de implantação estão disponíveis no repositório GitHub do Chaplin AWS Health Agentic Assistant.

Por que agentes de IA, e não RAG tradicional?

Sistemas tradicionais de Geração Aumentada por Recuperação (RAG — Retrieval-Augmented Generation) têm uma limitação crítica: são inerentemente não determinísticos quando lidam com operações numéricas e agregações. A busca por similaridade vetorial recupera conteúdo semanticamente similar, mas não garante precisão matemática. Quando perguntados para contar, somar ou agregar dados, sistemas baseados em RAG podem alucinar resultados — por exemplo, reportar 190 eventos de fim de vida quando o número real é 958.

Os eventos do AWS Health apresentam exatamente esse desafio: cada evento contém metadados estruturados (tipo de evento, serviço, recursos afetados, timestamps, severidade, IDs de conta) que exigem filtragem e agregação precisas, além de descrições não estruturadas em linguagem natural que exigem compreensão semântica e análise contextual.

Arquitetura em três camadas

A arquitetura do Chaplin é composta por três camadas principais que trabalham juntas para entregar análises inteligentes de eventos de saúde.

Camada 1 — Coleta de dados (multi-conta)

Em cada conta membro, a API do AWS Health serve como fonte dos eventos. O Amazon EventBridge fornece gatilhos orientados a eventos para captura em tempo real, e funções AWS Lambda coletam os eventos usando funções IAM cross-account com acesso de privilégio mínimo. Esses eventos fluem para uma conta de gerenciamento centralizada, onde um data lake no Amazon S3 armazena os eventos com particionamento inteligente por conta, data e tipo de evento. Quando novos eventos chegam, notificações de eventos do S3 disparam uma função Lambda que processa os eventos em formato JSON e os carrega no Amazon DynamoDB para consultas rápidas.

Essa arquitetura multi-conta suporta dois modelos de implantação: via API do AWS Organizations para implantação centralizada e automatizada, ou via implantações individuais por conta para organizações com restrições de segurança.

Camada 2 — Servidor MCP e camada de inteligência

É aqui que os dados brutos dos eventos são transformados em inteligência acionável. O Amazon DynamoDB serve como armazenamento primário para metadados estruturados, com índices otimizados por tipo de evento, severidade, data e conta.

O processamento inteligente de consultas acontece por meio de três componentes especializados:

• Agente de Linguagem Natural para Consulta Estruturada: converte perguntas em português simples em consultas precisas contra os metadados dos eventos de saúde, entendendo campos como event_type, affected_accounts e start_time.
• Agente de Análise de Impacto Contextual: processa as descrições não estruturadas dos eventos combinadas com metadados do cliente — ambientes de produção vs. não produção, unidades de negócio, tiers de aplicação e informações de ownership.
• Motor de Classificação Baseado em Padrões: categoriza eventos usando correspondência de padrões por regras, eliminando custos de processamento de IA para categorizações rotineiras.

O motor de análise com IA usa o framework Strands Agents — um framework agêntico open source desenvolvido pela AWS — com o Claude 4.5 Sonnet como modelo de linguagem padrão, podendo ser substituído por outro modelo de preferência. A solução é agnóstica de LLM, suportando Amazon Bedrock, OpenAI, Anthropic ou modelos locais como Ollama.

Camada 3 — Integração com assistente de IA (cliente MCP)

A camada de apresentação consiste em um assistente de IA compatível com MCP, como Claude Code ou Kiro CLI. Em vez de uma interface customizada, o Chaplin expõe suas capacidades como ferramentas MCP que esses clientes consomem nativamente. Os usuários interagem por linguagem natural no seu ambiente de desenvolvimento existente, e o assistente de IA orquestra chamadas ao servidor MCP do Chaplin para recuperar dados, executar análises e apresentar resultados contextualizados.

A segurança é baseada no AWS Identity and Access Management (IAM), com credenciais montadas como somente leitura. Os dados são criptografados com TLS 1.2+ em trânsito e AES-256 em repouso, e o AWS CloudTrail fornece logs de auditoria para chamadas de API.

Capacidades principais do Chaplin

Ferramentas de inteligência de saúde via MCP

O Chaplin expõe ferramentas MCP organizadas em três categorias: ferramentas de resumo (que consultam o DynamoDB diretamente e retornam instantaneamente contagens por serviço, status, categoria e região), ferramentas de detalhamento (para aprofundar em categorias específicas de eventos) e ferramentas de análise com IA (que usam o Strands Agents com Amazon Bedrock para interpretar consultas em linguagem natural e gerar insights contextuais).

Pipeline de dados multi-conta

O pipeline de dados é composto por funções Lambda para ingestão automatizada de eventos, agendadores do Amazon EventBridge com frequência configurável (diária ou por hora), funções IAM cross-account para coleta segura multi-conta, um data lake no Amazon S3 com particionamento para consultas eficientes e gerenciamento de ciclo de vida com políticas de retenção configuráveis.

Processamento analítico preciso

Para dados estruturados, o Chaplin entrega resultados numéricos exatos: contagens de eventos, análise de linha do tempo com detecção de tendências, agregações multidimensionais por conta, serviço e severidade, e breakdowns categóricos com percentuais precisos. Para dados não estruturados, fornece insights contextuais como avaliação de impacto, identificação de deficiências arquiteturais, correlação de riscos entre eventos relacionados e ações recomendadas.

Exemplo prático: análise de eventos recorrentes

Para ilustrar o poder da solução, considere a pergunta: “Quais contas têm mais notificações recorrentes de saúde e quais problemas arquiteturais estão causando isso?”

O agente de IA orquestra chamadas a múltiplas ferramentas MCP — get_health_summary, get_event_categories, get_estimated_blast_radius e get_event_type_stats — para produzir uma resposta abrangente. No exemplo com dados de amostra, o resultado revela que o ElastiCache representa 45% de todos os eventos (2.145 eventos em 140 contas), com um backlog de patches acumulado desde setembro de 2024. O VPN representa 14% dos eventos, todos relacionados a perda de redundância de túnel. O EC2 representa 7%, dominado por aposentadorias e manutenções de instâncias.

Com base nesses padrões, o Chaplin recomenda ações arquiteturais concretas: habilitar atualização automática de versão menor no ElastiCache, corrigir arquiteturas VPN com túnel único migrando para o AWS Transit Gateway, e mover cargas de trabalho sem estado para ECS no AWS Fargate ou EKS para eliminar uma classe inteira de eventos de manutenção.

Otimização de custos de IA

O Chaplin implementa otimização inteligente de custos por meio de uma abordagem de processamento que prioriza padrões: a classificação baseada em regras processa a maioria dos eventos sem incorrer em custos de IA. Visões pré-construídas e resumidas para janelas de 30, 60 e 120 dias ajudam equipes a identificar rapidamente alertas críticos. O cache inteligente reduz o processamento redundante de IA, e a precisão de consultas estruturadas usa o esquema da API do AWS Health para análise numérica exata sem custos de inferência de LLM.

Opções de implantação

O Chaplin oferece duas opções de implantação. A Opção A (instalação local) executa o servidor MCP na máquina do desenvolvedor, conectando-se diretamente ao DynamoDB e ao Bedrock usando credenciais AWS locais — ideal para avaliação individual ou rápida. Botões de instalação com um clique estão disponíveis no repositório para Kiro IDE, Cursor e VS Code. A Opção B (deploy remoto via Lambda) implanta o servidor MCP como uma função Lambda na conta AWS, com membros da equipe conectando-se via um proxy local leve — ideal para adoção em toda a equipe.

As instruções passo a passo de implantação e configuração do pipeline de dados estão disponíveis no repositório GitHub do Chaplin.

Visão de futuro: de análises autônomas a operações autônomas

A visão de longo prazo do Chaplin vai além das análises conversacionais. Como a solução é construída sobre MCP, ela se integra naturalmente com o AWS DevOps Agent — um agente de fronteira que investiga incidentes de forma autônoma, identifica causas raiz e fornece planos detalhados de mitigação. Ao registrar o servidor MCP do Chaplin como provedor de capacidades em um AWS DevOps Agent Space, as equipes de operações ganham inteligência de eventos de saúde diretamente nos fluxos de resposta a incidentes.

Essa integração cria um ciclo de feedback poderoso: quando o AWS DevOps Agent investiga um incidente, pode consultar o Chaplin para determinar se um evento de saúde relacionado — como uma aposentadoria de instância ou depreciação de serviço — está contribuindo para o problema. Melhorias futuras incluem manutenção preditiva por análise de padrões de eventos e fluxos de remediação guiada com capacidades de rollback.

Benefícios e impacto

Organizações que implementam o Chaplin podem esperar melhorias em três dimensões. Em eficiência operacional, a identificação antecipada de migrações e depreciações com 60 a 90 dias de antecedência reduz o combate a incêndios de emergência, e a categorização automatizada reduz a carga de triagem manual. Em otimização de custos, manter-se atualizado com mudanças de ciclo de vida evita migrações de emergência caras e taxas de suporte estendido. Em mitigação de riscos, a identificação proativa de patches de segurança e vulnerabilidades antes de serem explorados, combinada com análise contextual de impacto em sistemas de produção, previne interrupções.

Próximos passos

• Implante o Chaplin no seu ambiente AWS usando o repositório GitHub
• Explore o framework Strands Agents para construir agentes de IA customizados
• Leia sobre agentes de IA unificando dados estruturados e não estruturados
• Conheça mais sobre as capacidades do Amazon Bedrock
• Consulte a documentação do Amazon Bedrock e a documentação da API do AWS Health
• Saiba mais sobre a estratégia multi-conta do AWS Organizations e a especificação do Model Context Protocol (MCP)

Fonte

Build self-service AWS Health analytics to find actionable health insights with AI agents powered by Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-self-service-aws-health-analytics-to-find-actionable-health-insights-with-ai-agents-powered-by-amazon-bedrock/)

O que muda com o Blackwell no SageMaker AI

Quem treina modelos grandes hoje convive com um conjunto bem conhecido de limitações: batch sizes restritos pela memória da GPU, sequence lengths cortadas para evitar erros de falta de memória, e fragmentação de modelo (model sharding) que aumenta o overhead de comunicação conforme a escala cresce.

A Amazon SageMaker AI agora suporta instâncias P6-B200 com 8 GPUs NVIDIA Blackwell em jobs de treinamento. Essas instâncias estão disponíveis para uso geral no SageMaker AI, e a capacidade pode ser reservada via Flexible Training Plan — com acesso previsível, controle de custos e gerenciamento automatizado de recursos.

A arquitetura dual-chip do Blackwell, combinada com Tensor Cores de quinta geração, entrega ganhos mensuráveis para treinamento multi-GPU. O interconector NVLink 5 oferece até 1,8 TB/s de largura de banda bidirecional entre GPUs, enquanto a maior capacidade de Memória de Alta Largura de Banda (HBM) do B200 — 180 GB — e do B300 — 268 GB — reduz a pressão de memória em cargas de trabalho com grandes batches, sequências longas e treinamento distribuído.

Gerenciamento de memória: onde o Blackwell muda o jogo

A memória expandida do Blackwell abre espaço para otimização em três frentes: batches maiores, fragmentação de modelo simplificada e sequências mais longas.

• Batches maiores reduzem o número de etapas de sincronização de gradientes entre GPUs, aumentando o throughput geral.
• Fragmentação simplificada se torna viável porque mais memória por GPU pode eliminar ou reduzir o grau de paralelismo de modelo — menos fragmentos significam menos overhead de comunicação entre GPUs.
• Sequências mais longas permitem que o modelo processe mais contexto em uma única passagem, algo crítico para tarefas que dependem de dependências de longo alcance.

Se throughput é a prioridade, comece ajustando o batch size. Se o gargalo é comunicação, simplifique a fragmentação primeiro. Se a tarefa exige contexto longo, priorize a sequence length.

Activation Checkpointing: a troca certa entre memória e computação

Batch size e sequence length aumentam o consumo de memória juntos — encontrar um equilíbrio eficiente é fundamental. O activation checkpointing ajuda nessa balança: em vez de armazenar as ativações intermediárias durante o passo de avanço (forward pass), elas são recomputadas durante o passo de retropropagação (backward pass). Isso libera memória ao custo de mais computação — tipicamente 10 a 30% de overhead, dependendo da arquitetura.

Para ilustrar o impacto, considere três configurações de treinamento de um LLM de 1 bilhão de parâmetros com precisão MXFP8 e sequence length de 8K:

• Sem activation checkpointing (BS=1): throughput de aproximadamente 6 mil tokens/segundo, com memória de pico em 15,5 GB.
• Com activation checkpointing (BS=1): a memória cai drasticamente para 2,3 GB, mas o throughput também recua levemente pela recomputação.
• Com activation checkpointing e batch size 16: a memória liberada permite um batch muito maior, elevando o throughput para aproximadamente 51 mil tokens/segundo — cerca de 8 vezes o baseline — com memória de pico em 22,8 GB, ainda bem dentro dos limites da GPU.

A decisão de usar ou não activation checkpointing depende do tamanho do modelo:

• Modelos pequenos (até ~14B parâmetros): geralmente não precisam de activation checkpointing. A memória expandida do Blackwell acomoda a maioria desses modelos sem ele. Se houver pressão de memória na faixa superior, o checkpointing adiciona overhead de computação em troca de economia de memória que pode ser reinvestida em batches maiores.
• Modelos grandes (~14B+ parâmetros): o consumo de memória varia de 87 a 171 GB dependendo do batch size e da sequence length. Sem activation checkpointing, a maioria das configurações falha com erros de falta de memória CUDA (OOM). Com o checkpointing ativado, a memória liberada permite aumentar o batch size o suficiente para que o throughput melhore mesmo com o overhead adicional. Para modelos grandes, o checkpointing não é opcional — é um pré-requisito para treinamento estável.

Formatos de precisão: escolhendo o certo para cada workload

Os Tensor Cores de quinta geração do Blackwell oferecem aceleração em hardware para formatos de precisão reduzida: FP8, MXFP8 e NVFP4. Esses formatos são principalmente otimizações de throughput, não de economia de memória. Usar precisão menor reduz os requisitos de largura de banda de memória e aumenta o número de operações que a GPU executa por ciclo.

Porém, o treinamento com precisão reduzida é aproximadamente neutro em termos de memória por padrão — o TransformerEngine mantém os pesos primários em alta precisão para atualizações do otimizador e cópias quantizadas em paralelo. Isso significa que formatos de menor precisão não se traduzem diretamente em menor uso de memória.

O benefício líquido depende do tamanho do modelo e se o treinamento é limitado por computação ou por memória:

• Modelos pequenos (até ~14B parâmetros): FP8, MXFP8 e NVFP4 entregam melhorias modestas e similares em relação ao FP16, pois o overhead de quantização consome parte do ganho. O ajuste de batch size tende a trazer ganhos mais expressivos do que a escolha do formato de precisão. Comece com FP8 — ele tem overhead menor que MXFP8 ou NVFP4 e costuma ser um bom padrão para a maioria dos workloads com modelos pequenos.
• Modelos grandes (~14B+ parâmetros): é aqui que a precisão reduzida entrega seu maior impacto. FP8 oferece um bom equilíbrio entre throughput e eficiência de memória. MXFP8 é teoricamente mais eficiente em memória, mas o overhead de transposição parcialmente anula essa vantagem na prática. No entanto, se estabilidade de convergência ou precisão numérica for prioridade, MXFP8 pode ser a melhor escolha, pois seu esquema de quantização mais granular tende a preservar a acurácia do modelo de forma mais confiável. Para modelos grandes com memória como gargalo principal, NVFP4 pode entregar ganhos adicionais de throughput, mas exige investimento significativo de engenharia — recomenda-se usar as receitas validadas do Megatron Core.

O NVIDIA TransformerEngine lida com a complexidade de implementação: troca automática de precisão mista, kernels fundidos e escalonamento dinâmico de perda. Antes de ir para produção, valide a convergência acompanhando as curvas de perda entre os formatos para confirmar que a precisão escolhida atende aos requisitos de acurácia.

Configurando um job de treinamento no SageMaker AI com Blackwell

O Amazon SageMaker AI fornece um ambiente totalmente gerenciado para treinamento distribuído em instâncias Blackwell, cuidando do provisionamento de instâncias, orquestração de contêineres e integração com serviços AWS como Amazon Simple Storage Service (Amazon S3), Amazon CloudWatch, Amazon Elastic Container Registry (Amazon ECR) e AWS Identity and Access Management (AWS IAM).

Pré-requisitos

Antes de começar, confirme que você tem:

• Uma conta AWS com permissões para criar jobs de treinamento no SageMaker AI, acessar o ECR e criar roles de execução no IAM.
• Acesso a instâncias ml.p6-b200.48xlarge via Flexible Training Plan ou Managed Spot Training. Verifique suas Service Quotas antes de começar.
• Docker instalado localmente, Python 3.9 ou superior e o SageMaker Python SDK.
• Familiaridade com PyTorch e Paralelismo de Dados Totalmente Fragmentado do PyTorch (FSDP). Se você é novo no FSDP, consulte o guia de introdução ao treinamento distribuído.

Passo 1: Crie seu script de treinamento

Faça o download do arquivo fsdp.py do exemplo FSDP do repositório NVIDIA TransformerEngine. Esse script implementa o treinamento com FSDP e aceita hiperparâmetros como argumentos de linha de comando.

Passo 2: Crie o script de entrada

Prepare um arquivo train.sh para configurar o torchrun e iniciar o script de treinamento:

#!/bin/bash
# SageMaker passes hyperparameters as environment variables (SM_HP_)
PRECISION=${SM_HP_PRECISION:-"mxfp8"}
NUM_LAYERS=${SM_HP_NUM_LAYERS:-10}
BATCH_SIZE=${SM_HP_BATCH_SIZE:-8}
SEQ_LENGTH=${SM_HP_SEQ_LENGTH:-2048}
NUM_GPUS=$(nvidia-smi --list-gpus | wc -l)

torchrun --standalone --nnodes=1 --nproc-per-node="$NUM_GPUS" \
  fsdp.py --no-defer-init --precision "$PRECISION" \
  --num-layers "$NUM_LAYERS" --checkpoint-layer "transformerlayer" \
  --batch-size "$BATCH_SIZE" --seq-length "$SEQ_LENGTH"

Passo 3: Construa e envie seu contêiner

Construa um contêiner Docker personalizado que estenda os AWS Deep Learning Containers (DLC), inclua os arquivos fsdp.py e train.sh, e tenha o TransformerEngine 2.11 instalado. O DLC fornece uma imagem base validada com PyTorch e as bibliotecas CUDA necessárias para compatibilidade com o Blackwell. Abaixo está o Dockerfile:

FROM 763104351884.dkr.ecr.us-west-2.amazonaws.com/pytorch-training:2.9.0-gpu-py312-cu130-ubuntu22.04-sagemaker

# Install Transformer Engine
RUN pip install --upgrade --no-build-isolation transformer_engine[pytorch]==2.11.0

# Provide libcudart.so.12 for the pre-built flash-attn wheel
RUN pip install nvidia-cuda-runtime-cu12

# Make the linker able to find it
ENV LD_LIBRARY_PATH=/usr/local/lib/python3.12/site-packages/nvidia/cuda_runtime/lib:$LD_LIBRARY_PATH

COPY fsdp.py /opt/ml/code/fsdp.py
COPY train.sh /opt/ml/code/train.sh

ENV SAGEMAKER_SUBMIT_DIRECTORY /opt/ml/code
ENV SAGEMAKER_PROGRAM train.sh

Após a construção, crie um repositório privado no ECR (se ainda não tiver um) e envie a imagem para lá. Para instruções detalhadas de build, consulte a documentação sobre como adaptar seu próprio contêiner Docker para o Amazon SageMaker AI.

Passo 4: Reserve capacidade

Reserve capacidade via Flexible Training Plan para acesso previsível à taxa padrão, ou use Managed Spot Training para workloads com tolerância a interrupções e foco em redução de custos. Use Flexible Training Plans para execuções de produção que exigem disponibilidade contínua; use Spot para experimentação e workloads tolerantes a falhas onde a redução de custo supera o risco de interrupção.

Instâncias Spot estão sujeitas a interrupções — certifique-se de que seu script de treinamento salva checkpoints no Amazon S3 em intervalos regulares. O SageMaker AI retoma automaticamente um job Spot interrompido se você fornecer um checkpoint_s3_uri na configuração do estimador.

Atenção: Flexible Training Plans reservam capacidade e geram cobranças pela duração do plano, independentemente de jobs estarem em execução. Revise os detalhes de preços antes de criar um plano.

Passo 5: Submeta o job de treinamento

Substitua os valores de exemplo pelo ARN do seu training plan e pela URI da imagem ECR, e execute o código abaixo no seu ambiente de desenvolvimento local ou em uma instância de notebook do SageMaker AI:

from sagemaker.estimator import Estimator
from sagemaker import get_execution_role
from sagemaker.debugger import ProfilerConfig

training_plan_arn = ""  # Replace with your training plan ARN
ecr_image = ""  # Replace with your ECR image URI

# Adjust these values to match your workload
precision = "mxfp8"
num_layers = 10
batch_size = 8
seq_length = 2048

estimator = Estimator(
    image_uri=ecr_image,
    role=get_execution_role(),
    base_job_name='blackwell-training',
    instance_count=1,
    instance_type='ml.p6-b200.48xlarge',
    hyperparameters={
        "precision": precision,
        "num-layers": num_layers,
        "batch-size": batch_size,
        "seq-length": seq_length,
    },
    profiler_config=ProfilerConfig(disable_profiler=True),
    training_plan=training_plan_arn)

estimator.fit()

Para Managed Spot Training, substitua training_plan por use_spot_instances=True, defina max_run e max_wait, e adicione um checkpoint_s3_uri para retomada automática.

Passo 6: Monitore o job de treinamento

O SageMaker AI transmite logs para o Amazon CloudWatch automaticamente. No console do SageMaker AI, navegue até Training jobs e selecione seu job para encontrar o grupo de logs do CloudWatch. Abra /aws/sagemaker/TrainingJobs e procure por linhas [rank 0] para valores de perda e throughput. Para confirmar que o formato de precisão foi carregado, procure por mensagens como "Using FP8 recipe" ou "MXFP8 enabled".

Se o job parar com um erro de falta de memória CUDA (OOM), o log mostrará o tamanho da alocação. Reduza o batch size ou a sequence length, ou adicione activation checkpointing se ainda não tiver feito isso.

Limpeza de recursos

Para evitar cobranças contínuas após seus testes, encerre quaisquer jobs de treinamento em execução no console do SageMaker AI (note que isso não cancela um Flexible Training Plan).

Atenção: Os passos de limpeza abaixo excluem recursos permanentemente e não podem ser desfeitos. Verifique se você fez backup de todos os dados necessários antes de prosseguir.

• Exclua seu repositório Amazon ECR (isso remove permanentemente as imagens de contêiner).
• Exclua quaisquer artefatos de treinamento armazenados no Amazon S3 (isso remove permanentemente dados de treinamento e checkpoints).
• Remova os grupos de logs do CloudWatch (isso remove permanentemente os logs de treinamento).
• Exclua a role de execução do IAM criada para o SageMaker AI.

Conclusão

A combinação de memória expandida, interconexão de alta largura de banda e suporte a formatos de precisão reduzida no NVIDIA Blackwell muda o que é viável para treinamento de modelos grandes. Modelos transformer de 1B a 64B parâmetros apresentam ganhos consistentes quando essas otimizações são combinadas nas instâncias P6-B200 do SageMaker AI.

A chave está em entender se o workload é limitado por computação ou por memória, e então aplicar as mudanças de forma incremental para medir o impacto de cada uma. Para quem quiser explorar as opções de instância e detalhes de configuração, a documentação do Amazon SageMaker AI é o ponto de partida, ou é possível adquirir um Flexible Training Plan para reservar capacidade Blackwell. Dúvidas sobre workloads específicos podem ser direcionadas ao AWS Support ou ao time de conta AWS.

Fonte

Optimize model training on Amazon SageMaker AI with NVIDIA Blackwell (https://aws.amazon.com/blogs/machine-learning/optimize-model-training-on-amazon-sagemaker-ai-with-nvidia-blackwell/)