Blog

O que foi anunciado

A AWS anunciou que o Amazon SageMaker AI passou a oferecer suporte à personalização serverless do modelo NVIDIA Nemotron 3.5 Lightning. A novidade permite que equipes adaptem esse modelo de linguagem às suas necessidades específicas utilizando três abordagens de ajuste fino: Ajuste Fino Supervisionado (SFT), Otimização de Preferência Direta (DPO) e Ajuste Fino por Reforço (RFT).

Sobre o NVIDIA Nemotron 3.5 Lightning

O Nemotron 3.5 Lightning é um dos modelos de pesos abertos mais recentes da NVIDIA. Sua arquitetura é baseada em um modelo híbrido de Mistura de Especialistas (Mixture-of-Experts), contando com 3 bilhões de parâmetros ativos e 30 bilhões de parâmetros no total. Essa combinação permite alto desempenho com menor custo computacional em tarefas específicas.

Por que personalizar um modelo?

A personalização de modelos de fundação é uma estratégia poderosa para equipes que precisam de resultados de qualidade equivalente aos grandes modelos de fronteira, mas com menor custo e latência. A ideia central é simples: em vez de usar um modelo genérico e gigante, você treina um modelo menor com os seus próprios dados, fazendo com que ele se especialize exatamente no que a sua organização precisa.

No SageMaker AI, isso pode ser feito de três formas distintas:

• SFT (Ajuste Fino Supervisionado): utiliza dados rotulados para melhorar a precisão em tarefas específicas do seu domínio.
• DPO (Otimização de Preferência Direta): usa dados de preferência para alinhar as respostas do modelo ao tom e às diretrizes da sua organização.
• RFT (Ajuste Fino por Reforço): aplica sinais de recompensa para aprimorar o desempenho em tarefas novas.

A vantagem do serverless

O grande diferencial dessa novidade é a abordagem serverless: o SageMaker AI cuida de todo o provisionamento de infraestrutura e da orquestração do treinamento automaticamente. Isso significa que as equipes podem focar no que realmente importa — os dados e a avaliação dos resultados — sem precisar gerenciar clusters ou configurar ambientes de treinamento manualmente. O modelo de cobrança também segue a lógica serverless: você paga apenas pelo que utilizar.

Disponibilidade e como começar

A personalização serverless do NVIDIA Nemotron 3.5 Lightning no SageMaker AI está disponível nas seguintes regiões AWS:

• US East (Norte da Virgínia)
• US West (Oregon)
• Asia Pacific (Tóquio)
• Europe (Irlanda)

Para iniciar um job de personalização, basta acessar a página de Modelos no Amazon SageMaker Studio. Quem prefere acesso programático pode utilizar o SDK Python do SageMaker. Para aprofundar o conhecimento técnico, a AWS disponibiliza a documentação oficial de personalização de modelos com todos os detalhes necessários.

Fonte

Amazon SageMaker AI now supports serverless model customization for NVIDIA Nemotron 3.5 Lightning (https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-sagemaker-ft-nemotron-3-5-lightning/)

O problema clássico de melhorar um agente

Quem já trabalhou com agentes de IA sabe que melhorar a qualidade de um agente com desempenho abaixo do esperado costuma ser um processo manual e demorado. O fluxo típico envolve revisar traces longos para identificar onde o agente erra, ajustar componentes individuais como prompts, descrições de ferramentas e habilidades, e então rodar as avaliações novamente para verificar se houve melhora. É iterativo, custoso e difícil de escalar.

É justamente esse problema que a AWS busca resolver com o AgentCore optimization, uma funcionalidade do Amazon Bedrock AgentCore. Em um post de lançamento anterior, a AWS apresentou a capacidade de forma geral. Agora, o time técnico aprofunda como o mecanismo de recomendação funciona por dentro — e os números de desempenho são bastante expressivos.

Como o fluxo de otimização funciona

O AgentCore optimization parte dos traces de produção já registrados pelo AgentCore Observability. Esses traces são combinados com um sinal de recompensa (reward signal) para alimentar o otimizador, que propõe mudanças na configuração do agente. O ciclo completo envolve três etapas principais: gerar recomendações de configuração, validá-las por meio de avaliação em lote offline e testes A/B com tráfego real, e então promover as versões vencedoras para produção.

O componente central desse processo é o reflector — o módulo de raciocínio do otimizador. Ele analisa o comportamento avaliado do agente, identifica padrões que diferenciam execuções bem-sucedidas de falhas, e propõe alterações direcionadas na configuração. O output principal é um system prompt revisado, acompanhado de uma explicação sobre por que as mudanças propostas devem melhorar a qualidade do agente.

Um detalhe importante de design: traces de agentes costumam ser longos, e mesmo algumas dezenas deles podem facilmente ultrapassar a janela de contexto de um modelo. Em vez de truncar ou pré-resumir os traces para que caibam no prompt do reflector, a AWS optou por disponibilizar o corpus completo de traces via sistema de arquivos. O reflector recebe uma ferramenta de shell e é direcionado ao diretório com os traces, podendo inspecioná-los conforme necessário — listando arquivos, buscando com grep, lendo com cat, comparando saídas com diff. Não existe um pipeline fixo de extração de sinais; o próprio reflector determina quais evidências são relevantes e como traduzi-las em mudanças de configuração.

Dois modos de reflexão: Single Agent e Sub-Agent

Single Agent Reflector

O Single Agent Reflector é o modo que impulsiona as recomendações de system prompt no AgentCore optimization atualmente. Um único agente reflector percorre todo o conjunto de traces em uma única passagem. Ele analisa a distribuição de scores, examina os segmentos mais informativos de traces individuais, contrasta sucessos com falhas e retorna um conjunto coerente de edições para a configuração do agente.

Cada época de otimização repete esse ciclo: pontuar os traces, refletir e aceitar as edições que passam pelos guardrails. É possível executar épocas adicionais para trocar tempo de otimização por ganhos adicionais de qualidade.

Sub-Agent Reflector

O Sub-Agent Reflector estende o Single Agent Reflector, trocando um pouco de eficiência por um teto de qualidade mais alto. Em vez de um único agente percorrendo todos os traces, ele utiliza um swarm de agentes para explorar diferentes partes do conjunto de traces de forma dinâmica.

O problema que essa abordagem resolve é real: uma única passagem de reflexão pode se fixar nos padrões dos primeiros 5 a 10 traces analisados e deixar passar modos de falha que aparecem apenas em uma parcela menor do corpus. Com o Sub-Agent Reflector, cada sub-agente realiza uma análise em três níveis sobre um único trace:

• Superfície: extrai a recompensa, a dificuldade e o resultado da execução.
• Nível de turno: localiza o ponto de decisão onde a trajetória divergiu do caminho ótimo, usando comandos de shell como jq e grep para analisar o JSON do rollout.
• Cognitivo: diagnostica por que o agente falhou naquele ponto de decisão e fornece orientação reflexiva.

Cada sub-agente retorna uma descoberta concisa e uma regra corretiva. Como cada sub-agente opera em sua própria janela de contexto, ele consegue se concentrar em um único trace sem ser influenciado pelos demais. O orquestrador então agrega as descobertas, generaliza padrões recorrentes, remove duplicatas e condensa os insights em mudanças de configuração.

Essa funcionalidade experimental foi lançada como release preliminar no repositório open source do Strands no GitHub.

Guardrails: evitando que a otimização vá na direção errada

Um risco conhecido em otimização automática de configurações é o desvio em direções indesejadas: prompts que crescem indefinidamente após cada otimização, prompts que reproduzem literalmente frases dos traces de treinamento, ou restrições de segurança que são suavizadas na busca por um score melhor no avaliador.

Para evitar esses problemas, a AWS aplica guardrails baseados em rubrica a cada candidato de atualização antes que ele seja aceito:

• Teto de tamanho: candidatos que aumentam a configuração em mais de 20% em relação à versão anterior são rejeitados, e o otimizador é solicitado a compactar a proposta.
• Verificação de segurança: candidatos são avaliados contra padrões de segurança antes da promoção.
• Sem frases verbatim dos traces: candidatos não podem reutilizar frases exatas dos traces usados na otimização, o que ajuda a evitar overfitting em características superficiais dos traces de treinamento.

O post da AWS deixa claro que as recomendações devem ser revisadas e testadas antes do uso em produção — os guardrails são uma camada de proteção, não uma garantia absoluta de qualidade.

Resultados de avaliação nos benchmarks AppWorld e WebShop

A AWS avaliou o Single Agent Reflector e o Sub-Agent Reflector ao lado de duas linhas de base estabelecidas — GEPA e MIPROv2 — em dois benchmarks públicos: AppWorld e WebShop. Para cada método, o espaço de configuração foi varrido e o melhor resultado foi reportado junto com o número de turnos e o tempo de otimização em relógio de parede.

Dois padrões se destacam nos resultados:

Single Agent Reflector oferece a melhor relação qualidade-custo. No AppWorld, ele atinge 81,55% em 6 minutos e 20 turnos — 18 vezes mais rápido que o GEPA e 36 vezes mais rápido que o MIPROv2 para um score comparável ou superior. No WebShop, atinge 78,31% com apenas 5 turnos e 1 minuto de tempo de otimização. Esse modo é ideal quando ciclos de iteração rápidos são prioridade.

Sub-Agent Reflector alcança a maior qualidade nos dois benchmarks. No AppWorld, chega a 95,83% — um ganho de 23 pontos percentuais sobre a baseline e 16 pontos acima do segundo melhor método. No WebShop, atinge 79,15%, com ganho de 4 pontos sobre a baseline. A análise por sub-agente tem maior impacto no AppWorld, onde os modos de falha são mais diversos e uma única passagem de reflexão tende a perder padrões minoritários.

A tabela abaixo resume os melhores resultados por método em cada benchmark. As configurações são expressas como n_samples × épocas para os reflectors e n_samples × iterações para GEPA e MIPROv2. O modelo reflector utilizado foi o Opus 4.6 e o modelo de tarefa foi o Sonnet 4.5.

Boas práticas para usar o otimizador

Com base na experiência acumulada, a AWS compartilha algumas orientações práticas para quem for usar o AgentCore optimization:

• Comece com um conjunto pequeno de traces. Entre 10 e 50 traces diversos já oferecem um ponto de partida útil para a otimização. Expanda o conjunto apenas se as recomendações estiverem muito restritas.
• Use mais do que um scalar reward quando for apropriado. O reflector lê os traces como arquivos, então qualquer sinal escrito no trace fica disponível para ele. Além do score numérico, feedback em texto livre — como a justificativa de um avaliador, uma anotação humana ou uma reclamação de usuário — pode ser incluído no mesmo arquivo de trace.
• Revise e valide as recomendações. Use a explicação da recomendação, avaliações offline e testes A/B controlados para avaliar uma configuração proposta antes de promovê-la para produção.
• Use análise independente de traces para modos de falha diversos. O Sub-Agent Reflector experimental analisa traces de forma independente antes de agregar os resultados. Considere essa abordagem quando diferentes subconjuntos de traces revelam padrões de falha distintos.
• Estenda a análise além dos system prompts. Evidências dos traces também podem identificar oportunidades de melhoria em descrições de ferramentas e habilidades reutilizáveis. Aplique os mesmos guardrails e o mesmo fluxo de validação ao avaliar esses tipos de mudanças de configuração.
• Comece pelo fluxo de otimização gerenciado. Para a maioria dos casos de uso em produção, o AgentCore optimization oferece o caminho recomendado de traces até recomendações e validação. Times com restrições especializadas de pesquisa ou integração podem aplicar o mesmo padrão de trace, avaliação e validação em um fluxo de reflexão customizado.

Por onde começar

Para quem quiser explorar o AgentCore optimization na prática, a AWS disponibiliza vários pontos de entrada: a página de detalhes do Amazon Bedrock AgentCore, a documentação de otimização, o console do Amazon Bedrock AgentCore e o repositório de exemplos do AgentCore. O Sub-Agent Reflector experimental também está disponível no repositório open source do Strands no GitHub para quem quiser explorar a abordagem multi-agente de forma mais aprofundada.

Fonte

Optimizing agent system prompts with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/optimizing-agent-system-prompts-with-amazon-bedrock-agentcore/)

O problema: agentes de IA que conhecem os fatos, mas erram o método

Agentes de IA construídos sobre modelos de fundação (FM — Foundation Models) frequentemente aplicam de forma equivocada os frameworks de decisão clínica, mesmo quando foram treinados com as diretrizes corretas. Peça a um agente que classifique uma variante missense do TP53 usando os critérios ACMG/AMP — ele vai citar o framework certo, mas vai errar nas categorias de evidência, ignorar limiares de frequência populacional ou inventar pontuações de preditores computacionais.

O modelo conhece os fatos, mas não domina os procedimentos de raciocínio que profissionais da área internalizam ao longo de anos de formação. Essa lacuna gera falhas silenciosas em interpretação de variantes genéticas, adjudicação de sinistros, desenho de ensaios clínicos e análise de imagens. As respostas parecem corretas, mas aplicam critérios errados — com consequências regulatórias e de segurança para o paciente.

A solução: HCLS Agent Skills, uma coleção open source de habilidades para agentes

Para endereçar esse problema, a AWS publicou uma coleção de 38 habilidades de agente open source abrangendo 11 domínios de saúde e ciências da vida (HCLS — Healthcare and Life Sciences), que inclui genômica, descoberta de fármacos, operações de saúde e imagens médicas. O catálogo completo de habilidades está organizado por domínio e tudo está liberado sob licença MIT-0.

As habilidades seguem o padrão aberto Agent Skills e são documentos markdown estruturados (SKILL.md) que codificam procedimentos de decisão de domínio em um formato que agentes de IA conseguem consumir em tempo de inferência por meio de divulgação progressiva. Cada habilidade declara gatilhos, dependências e metadados em frontmatter YAML, seguidos de frameworks de decisão, tabelas de parâmetros, padrões de código e critérios de validação.

Dois tipos de habilidades

As habilidades do repositório se dividem em dois tipos:

• Habilidades de raciocínio: codificam metodologia e frameworks de decisão que orientam como o agente pensa. Por exemplo, a habilidade genomic-variant-interpretation codifica o framework completo de classificação ACMG/AMP, incluindo categorias de evidência, limiares de frequência populacional e pontos de corte de preditores computacionais.
• Habilidades de pipeline: codificam comandos específicos de ferramentas, parâmetros validados e templates de código que produzem artefatos executáveis. A habilidade variant-calling, por exemplo, fornece comandos GATK4 HaplotypeCaller com grupos de anotação corretos, alvos de sensibilidade VQSR e configurações Mutect2 para tumor-normal.

Essa taxonomia dupla dá ao agente tanto o julgamento para tomar decisões corretas quanto a precisão técnica para executá-las.

O que diferencia habilidades de outras abordagens

Diferente da Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation), que recupera trechos limitados de documentos indexados, as habilidades codificam o próprio procedimento de decisão e as condições de erro. Também não são fine-tuning: são prompts estruturados que se ativam contextualmente com base em padrões de gatilho na consulta do usuário.

Três propriedades tornam as habilidades distintas: são auditáveis (cada critério de decisão é legível por humanos em markdown, não escondido em pesos do modelo), portáteis (funcionam em mais de 20 serviços como Amazon Bedrock AgentCore, AWS Strands Agents SDK, Kiro, Amazon Quick Desktop, Claude Code, OpenAI Codex e outros) e fáceis de manter (mudanças anuais em políticas médicas ou novos critérios experimentais podem ser refletidos editando um arquivo de texto, sem retreinar o modelo).

Instalação e configuração

Para acompanhar os exemplos, é necessário um dos serviços suportados pela AWS: Kiro ou Kiro CLI para uso interativo e orquestração multi-agente; o AWS Strands Agents SDK com acesso a modelos de fundação do Amazon Bedrock; o AgentCore harness do Amazon Bedrock AgentCore com uma implementação de agente existente; ou o Quick Desktop para gerenciamento de habilidades via interface gráfica. Também é possível usar qualquer harness de agente de código como Claude Code ou OpenAI Codex. Além disso, são necessários Python 3.10+ com uv e Git.

O primeiro passo é clonar o repositório:

git clone https://github.com/awslabs/hcls-agent-skills.git
cd hcls-agent-skills

Para instalar apenas as habilidades sem a configuração do agente, use a skills CLI universal:

npx skills add awslabs/hcls-agent-skills

Para o Kiro, o script install.sh instala tanto as habilidades quanto um agente pré-configurado. Execute ./install.sh --target kiro e troque para o agente com /agent hcls. Para modo multi-agente, execute ./install.sh --target kiro --mode multiagent e use /agent hcls-multiagent.

Para o AWS Strands Agents SDK, carregue as habilidades diretamente no código Python:

from strands import Agent
from strands.skills import AgentSkills

agent = Agent(
    model=model_id,
    skills=AgentSkills(skills="./skills/"),
)

Para o AgentCore, siga a documentação de Skills para adicionar habilidades a um agente hospedado no AgentCore. Para o Amazon Quick Desktop, execute ./install.sh --target quick-desktop ou siga as instruções de Skills na documentação do Amazon Quick.

Padrões de implantação

Agente único com Quick Desktop

Com as habilidades instaladas, o agente do Quick Desktop ganha raciocínio estruturado de domínio HCLS sem configuração adicional. Quando uma pergunta de domínio é feita, o agente ativa automaticamente as habilidades relevantes com base nos padrões de gatilho da consulta. Por exemplo, perguntar “Qual é o impacto no RAF de codificar E11.9 em vez de E11.42?” aciona a habilidade de ajuste de risco e o agente responde com mapeamentos HCC específicos, resolução de hierarquia e deltas RAF quantificados — em vez de uma sugestão genérica para “revisar a documentação”.

Arquitetura multi-agente com Kiro CLI

Carregar todas as 38 habilidades em um único contexto de agente consome cerca de 80 mil tokens. Isso é viável com modelos de contexto grande, mas cria um desafio de engenharia de contexto. Uma alternativa é a invocação explícita de habilidades, mas isso exige que o usuário saiba qual habilidade invocar antes de fazer a pergunta — exatamente a lacuna de expertise que as habilidades pretendem preencher.

A arquitetura multi-agente do Kiro CLI resolve os dois problemas. Um agente coordenador leve (sem habilidades carregadas) roteia consultas para oito especialistas de domínio, cada um carregando apenas suas habilidades relevantes (aproximadamente 15 mil tokens por especialista). O coordenador cuida da classificação de intenção enquanto os especialistas lidam com o raciocínio de domínio. A configuração multi-agente é definida em arquivos JSON de agentes — consulte o config do agente coordenador para a lógica de roteamento e um config de agente especialista como exemplo de como as habilidades de domínio são atribuídas a um especialista.

Integração com Strands SDK e deploy no AgentCore

O AWS Strands Agents SDK oferece carregamento nativo de habilidades para construir agentes HCLS personalizados:

from strands import Agent
from strands.skills import AgentSkills
from strands.multiagent import MultiAgentOrchestrator

# Define domain specialists with their skill sets
genomics_agent = Agent(
    name="hcls-genomics",
    model=model_id,
    skills=AgentSkills(skills="./skills/genomics/"),
)
imaging_agent = Agent(
    name="hcls-imaging",
    model=model_id,
    skills=AgentSkills(skills="./skills/imaging/"),
)

# Coordinator routes to specialists
coordinator = MultiAgentOrchestrator(
    agents=[genomics_agent, imaging_agent, ...],
    model=model_id,
)

response = coordinator("Classify NM_000546.6:c.743G>A in TP53 using ACMG criteria")

Após o agente funcionar localmente, é possível movê-lo para produção com o Amazon Bedrock AgentCore, que oferece hospedagem gerenciada, auto scaling, limites de segurança e capacidades de observabilidade sem necessidade de gerenciar infraestrutura. Siga a documentação de Skills no AgentCore para configurar as habilidades no nível do ambiente.

Casos de uso em prática

Caso 1: Avaliação de candidatos a reposicionamento de fármacos em descoberta de medicamentos

Uma equipe de biotecnologia investigando reposicionamento de fármacos para fibrose pulmonar idiopática (FPI) quer avaliar medicamentos aprovados que modulam a sinalização TGF-β1 pelo receptor TGFBR1 (ALK5). Sem habilidades, o agente produz uma revisão de literatura genérica listando inibidores conhecidos do TGFBR1, sem critérios de classificação estruturados, hierarquia de evidências ou framework de avaliação de traduzibilidade.

Com as habilidades drug-repurposing e translational-research ativadas, o agente aplica o framework de consulta DGIdb priorizando tipos de interação e bancos de dados-fonte; classifica candidatos usando uma hierarquia de evidências estruturada; avalia a sobreposição de mecanismo de ação mapeando a inibição do TGFBR1 para os processos patológicos chave da FPI; e avalia a traduzibilidade clínica usando critérios T0→T1, examinando dados de segurança existentes da indicação original e compatibilidade de janela terapêutica.

Caso 2: Pipeline de ajuste de risco CMS-HCC em operações de saúde

Um plano Medicare Advantage com 12.000 membros precisa calcular pontuações de Fator de Ajuste de Risco (RAF — Risk Adjustment Factor) a partir de dados de sinistros com diagnósticos ICD-10, usando coeficientes do Modelo CMS-HCC V28. Sem habilidades, o agente produz um pipeline plausível mas incompleto — frequentemente omitindo a resolução de hierarquia, usando coeficientes desatualizados V24 ou aplicando hierarquias após a soma (o que infla as pontuações).

Com as habilidades risk-adjustment e claims-billing-rules ativadas, o agente gera SQL correto que une códigos de diagnóstico ao crosswalk ICD-10-para-HCC com deduplicação dentro do ano de medição; implementa corretamente a resolução de hierarquia V28; aplica a segmentação demográfica correta; e explica proativamente que pular a resolução de hierarquia conta condições em dobro em múltiplos níveis de especificidade, inflando sistematicamente as pontuações RAF e criando responsabilidade de auditoria sob revisão CMS RADV.

Caso 3: Pré-processamento de RM ponderada em T1 para morfometria baseada em voxel

Um estudo de neuroimagem com 45 adultos saudáveis precisa de um pipeline padrão de pré-processamento T1w para análise de morfometria baseada em voxel (VBM — Voxel-Based Morphometry) em um ambiente híbrido FSL/ANTs. Sem habilidades, o agente pode sugerir um pipeline razoável, mas com a ordem errada — por exemplo, correção de campo de viés após a remoção de crânio (o que vicia as máscaras cerebrais) — ou usar limiares inadequados e omitir estratégias de detecção de falhas.

Com as habilidades radiology-preprocessing e imaging-study-design ativadas, o agente especifica a ordem correta de processamento com justificativa: reorientar para espaço padrão, depois correção de campo de viés antes da remoção do crânio, depois extração cerebral com parâmetros ajustados para adultos saudáveis e, finalmente, registro no template MNI152. Também documenta os modos de falha em cada etapa e fornece um script bash completo com verificação de erros.

Resultados da avaliação

Foi realizada uma avaliação pareada para medir o impacto das habilidades em 410 prompts de domínio (380 de habilidade única e 30 de habilidades cruzadas), usando dois harnesses de agente: Kiro CLI com modelo automático e um agente construído com o AWS Strands Agents SDK com o modelo explicitamente fixado no Claude Sonnet 4.6. A configuração completa está disponível em eval/execute.py.

Cinco dimensões de pontuação foram empregadas para o juiz de LLM (Modelo de Linguagem de Grande Escala): precisão científica, coerência, relevância, pensamento crítico e acionabilidade. O Claude Opus 4.7 do Amazon Bedrock foi usado como juiz, com o prompt de pontuação completo disponível em eval/judge.py.

Os resultados gerais são expressivos. As habilidades venceram 69,5 a 85,9% das comparações diretas nas duas configurações de harness. O sinal mais forte foi em pensamento crítico, confirmando que a contribuição primária das habilidades é metodológica: ensinar ao agente quais frameworks aplicar, quais suposições questionar e quais limitações sinalizar. A tabela abaixo resume os resultados de alto nível:

• Taxa de vitória geral (d de Cohen): 69,5% (0,39) no Kiro CLI e 85,9% (0,97) no Strands Agent
• Pensamento crítico: 78,0% (0,65) no Kiro CLI e 85,1% (1,03) no Strands Agent
• Precisão científica: 69,3% (0,34) no Kiro CLI e 86,2% (0,85) no Strands Agent
• Acionabilidade: 68,0% (0,37) no Kiro CLI e 77,3% (0,56) no Strands Agent

Há forte evidência de que as habilidades ajudam mais quando o agente base tem mais dificuldade. A correlação de Pearson entre a qualidade da resposta de base e o benefício das habilidades é de −0,59 no Kiro CLI e −0,61 no Strands Agent. As habilidades também reduzem o desvio padrão das pontuações de resposta — por exemplo, o desvio padrão das pontuações em respostas de dados clínicos caiu de 6,8 para 3,3 com as habilidades carregadas no Kiro CLI, uma redução de 51%. Em fluxos de trabalho HCLS regulados, onde a consistência importa tanto quanto a qualidade média, essa redução de variância é um benefício significativo. A metodologia de avaliação completa está disponível no relatório técnico de avaliação.

Estendendo e criando novas habilidades

Os fluxos de trabalho da sua equipe podem precisar de limiares diferentes, protocolos adicionais ou cobertura de domínios inteiramente novos. O repositório inclui três guias para personalização:

• CUSTOMIZING.md: cobre fluxos de trabalho práticos para modificar, estender e criar habilidades do zero, incluindo a adição de regras específicas da organização a habilidades existentes.
• SKILL_DESIGN_GUIDE.md: documenta padrões baseados em evidências para escrever habilidades eficazes — árvores de decisão, tabelas de limiares, listas de erros comuns e seções de formato de resposta.
• QUALITY_CHECKLIST.md: fornece um checklist de qualidade pré-merge cobrindo frontmatter, estrutura, qualidade do conteúdo e requisitos de teste.

Para testar suas mudanças, gere prompts de avaliação que reflitam os fluxos de trabalho reais da equipe e execute o framework de avaliação:

uv venv --python 3.12 && source .venv/bin/activate
uv pip install -e ".[dev]"

# Generate 30 evaluation prompts for each of the skills
python eval/generate_prompts.py --count 30

# Run pairwise evaluation against your modified skills
python -m eval.run --skills ./my-custom-skills/ --parallel 2
python eval/build_review.py
open eval/results/review.html

A avaliação produz uma comparação pareada mostrando se a habilidade modificada melhora as respostas em relação à base, com detalhamentos por dimensão idênticos aos resultados reportados. Contribuições de novas habilidades de domínio para a coleção open source são bem-vindas, seguindo o guia de contribuição.

Como começar

As habilidades são arquivos locais e não criam recursos AWS — nenhuma limpeza é necessária para os exemplos básicos. Se você implantou um agente Strands no harness do Amazon Bedrock AgentCore, siga o passo de limpeza para excluir os recursos do agente implantado.

Para começar a usar a coleção HCLS Agent Skills:

• Clone o repositório
• Use as habilidades interativamente com Kiro ou Amazon Quick Desktop
• Construa agentes personalizados com o AWS Strands Agents SDK
• Implante agentes em produção com o Amazon Bedrock AgentCore
• Explore modelos de fundação no Amazon Bedrock

Fonte

Improving HCLS AI reasoning with open-source agent skills (https://aws.amazon.com/blogs/machine-learning/improving-hcls-ai-reasoning-with-open-source-agent-skills/)

O problema da redação de IPI em escala

Organizações que processam milhares de documentos digitalizados por dia — formulários médicos, solicitações de seguros, registros financeiros — enfrentam um desafio recorrente de conformidade: a necessidade de redigir Informações de Identificação Pessoal (IPI) antes de compartilhar esses documentos com terceiros ou encaminhá-los para processamento interno.

A redação manual simplesmente não escala. Ela consome horas de trabalho, introduz erros humanos e cria exposição regulatória. Além disso, redação é tanto um problema de detecção quanto de precisão: uma única página pode conter múltiplos nomes, datas e endereços, onde apenas alguns são sensíveis para aquele caso de uso específico.

As abordagens tradicionais combinam Reconhecimento Óptico de Caracteres (OCR) com correspondência de padrões ou modelos de Aprendizado de Máquina (ML) customizados. Essas soluções têm limitações claras quando o texto está degradado, quando há lógica de negócio no nível de campo, ou quando os formatos de documento mudam e exigem retreinamento de modelos.

A AWS publicou um guia técnico detalhado mostrando como automatizar de ponta a ponta a detecção e redação de IPI em documentos e imagens usando o Amazon Bedrock Data Automation (BDA), o AWS Step Functions e o AWS Lambda.

Como a IA generativa resolve as limitações tradicionais

Modelos de fundação conseguem interpretar uma página de documento de forma holística — incluindo layout, rótulos de campos e contexto — e distinguir a quem pertence cada informação usando instruções em linguagem natural, sem precisar de modelos de entidades treinados.

O Amazon Bedrock Data Automation é um serviço do Amazon Bedrock que extrai informações estruturadas de documentos não estruturados, imagens, áudio e vídeo. Por meio do recurso de blueprints personalizados, é possível declarar campos nomeados para extração precisa usando instruções em linguagem natural. Para cada campo, o BDA retorna o conteúdo detectado, uma pontuação de confiança e as coordenadas da caixa delimitadora (bounding box) para pós-processamento.

Para saber mais sobre blueprints e esquemas de saída personalizados, a AWS disponibiliza a documentação oficial do Amazon Bedrock Data Automation. Para orientações mais amplas sobre gestão de IPI em aplicações de IA generativa, a AWS também publicou a Generative AI Security Scoping Matrix.

Desenhando um blueprint de redação de IPI

A solução proposta tem duas partes: um blueprint BDA personalizado que define o que deve ser redigido, e um pipeline serverless que aplica esse blueprint em escala.

Para criar um blueprint adequado, o artigo recomenda responder a quatro perguntas de escopo:

• O que é informação sensível? — Nome do paciente, data de nascimento, endereço residencial, informações de contato
• O que não é informação sensível? — Nome do médico, datas de exame, endereço do consultório, notas clínicas
• Onde essa informação aparece na página? — Em campos estruturados, texto manuscrito, múltiplas instâncias ao longo do documento
• Como removê-la? — Identificar as coordenadas da bounding box, converter PDF para PNG e aplicar blocos pretos nas regiões correspondentes

O caso de uso demonstrado no artigo é a redação de IPI em Attending Physician Statements (declarações de médicos assistentes) antes do processamento de sinistros. O blueprint final define 37 campos distribuídos em 9 grupos de campos (field groups), cobrindo identidade do paciente, contatos de emergência, familiares, documentos de governo e identificadores de seguro.

Abaixo está um trecho representativo do esquema de blueprint, mostrando o grupo PatientIdentity:

{
  "PatientIdentity": {
    "type": "object",
    "properties": {
      "patient_first_name": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's given or first name."
      },
      "patient_last_name": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's surname or family name. Look carefully in all sections including signature areas."
      },
      "patient_date_of_birth": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's date of birth in any format (dd-mm-yyyy, mm/dd/yyyy, etc.)."
      },
      "patient_mrn": {
        "type": "string",
        "inferenceType": "explicit",
        "instruction": "The patient's Medical Record Number (MRN)."
      }
    }
  }
}

Cada campo usa inferenceType: "explicit" para extração sem transformação e uma instrução em linguagem natural para delimitar o escopo da detecção. Isso permite, por exemplo, que o BDA distinga a data de nascimento do paciente das datas de consulta ou assinatura — mesmo quando diferentes formatos aparecem na mesma página.

Avaliando o blueprint: precisão e recall

Após projetar o blueprint, o artigo recomenda avaliá-lo calculando precisão e recall contra documentos redigidos manualmente como referência (ground truth). Os testes cobriram seis níveis de qualidade de documento:

• Formulários digitados limpos
• Documentos impressos e enviados por fax
• Fax com baixa qualidade de impressão
• Formulários manuscritos
• Documentos manuscritos, impressos e reescaneados
• Digitalizações de baixa resolução (100 DPI)

Os testes iniciais em 12 documentos (47 páginas) mostraram que o blueprint identificava cada instância de IPI ao menos uma vez, mas ocasionalmente perdia instâncias repetidas em blocos de texto narrativo e anotações manuscritas de médicos.

Para aumentar o recall com impacto mínimo na precisão, a solução introduz uma segunda passagem de detecção usando a saída padrão do BDA, combinando os resultados por meio de uma etapa de correspondência de tokens. Uma única chamada à API do BDA retorna dois tipos de saída:

• Saída personalizada (custom output): campos de IPI com bounding boxes detectados pelo blueprint
• Saída padrão (standard output): extração completa com bounding box para cada palavra da página

O trecho de código abaixo mostra como a chamada assíncrona é feita:

response = self._runtime.invoke_data_automation_async(
    inputConfiguration={"s3Uri": input_s3_uri},
    outputConfiguration={"s3Uri": output_s3_uri},
    dataAutomationProfileArn=profile_arn,
    dataAutomationConfiguration={
        "dataAutomationProjectArn": project_arn,
        "stage": stage,
    },
)

A lógica de correspondência de tokens normaliza cada valor de IPI detectado em tokens no nível de palavra e varre a saída padrão da página buscando palavras cuja forma normalizada corresponda a algum token de IPI. Novos matches não sobrepostos são adicionados ao conjunto final de coordenadas a redigir. Com isso, instâncias repetidas de IPI são capturadas onde quer que reapareçam na página — inclusive em parágrafos de texto livre e manuscritos.

Como ambas as passagens usam uma única chamada à API, a verificação de qualidade adiciona cobertura sem latência extra de uma segunda invocação. Os resultados da avaliação mostram:

• Blueprint apenas: precisão de 97,0% e recall de 89,3%
• Blueprint + saída padrão + lógica de correspondência: precisão de 96,5% e recall de 95,2%

A pontuação de confiança retornada pelo BDA também pode ser usada para encaminhar casos-limite para revisão humana, conforme necessário para cada caso de uso.

Arquitetura do pipeline serverless

O pipeline é estruturado como um fluxo de trabalho serverless com cinco funções AWS Lambda orquestradas por uma máquina de estados do AWS Step Functions. Dois níveis aninhados de distributed maps do Step Functions paralelizam as chamadas à API do BDA no nível de página. Os documentos PDF de entrada são fornecidos por um prefixo do Amazon S3.

O pipeline recebe três entradas na Step Function:

• Um prefixo S3 de entrada com os PDFs não redigidos
• Um prefixo S3 de saída para os resultados
• O ARN (Amazon Resource Name) do blueprint BDA validado para o caso de uso

As cinco etapas do fluxo são:

• Initialize (Inicialização): valida a entrada, resolve o blueprint, lista os documentos no S3 e gera um manifesto para o mapa distribuído no nível de documento
• Preprocess (Pré-processamento): converte cada PDF em imagens PNG por página
• Detect and Redact (Detecção e Redação): envia cada imagem de página ao BDA para detecção de IPI e aplica blocos pretos sobre as coordenadas detectadas
• Reassemble (Remontagem): combina as páginas redigidas em um único PDF redigido por documento e gera metadados
• Report (Relatório): agrega os resumos dos documentos em um relatório de job e executa uma verificação de reconciliação

A função de Redação realiza quatro operações por página: invoca o BDA, analisa o resultado, redige a imagem e faz upload para o S3. O BDA retorna coordenadas normalizadas (esquerda, topo, largura e altura como frações entre 0 e 1), que são convertidas para coordenadas de pixel. A função expande levemente cada caixa para compensar variações e desenha um retângulo preto preenchido sobre a região. Diferente de abordagens baseadas em anotação, essa técnica sobrescreve os dados de pixel da própria imagem — o conteúdo coberto não está presente no arquivo de saída e não pode ser recuperado.

Recuperação de falhas e relatório final

O pipeline usa uma abordagem em camadas para recuperação de falhas. A primeira camada lida com picos de throttling usando o mecanismo nativo de retry com backoff exponencial e jitter do Step Functions. A segunda camada isola erros de documentos corrompidos sem interromper o processamento dos demais.

Dois tipos de isolamento se aplicam:

• Falhas no nível de documento (PDF corrompido, erro de remontagem): o pipeline registra a falha no relatório enquanto os outros documentos continuam sendo processados
• Falhas no nível de página (throttling persistente que esgota as tentativas): a recuperação usa o recurso de redrive nativo do Step Functions, sem reprocessar o trabalho já concluído

O relatório final agrega estatísticas por documento, dados de tempo e um resumo de reconciliação. Um exemplo de saída:

{
  "documents_submitted": 12,
  "documents_output": 12,
  "documents_failed": 0,
  "fully_reconciled": true,
  "total_pages": 47,
  "total_pii_fields": 331,
  "total_pii_blueprint_count": 294,
  "total_pii_match_count": 37,
  "average_confidence": 0.8079,
  "pipeline_duration_seconds": 290.7
}

Segurança do pipeline

A solução é construída sobre os controles de segurança dos serviços AWS utilizados:

• Acesso com escopo mínimo via IAM: cada função Lambda tem uma função de Gerenciamento de Identidade e Acesso (IAM) dedicada com privilégios mínimos, restrita ao bucket do pipeline e apenas às ações necessárias
• Criptografia em repouso e em trânsito: a criptografia padrão do S3 protege todos os documentos com AES-256; a comunicação com os serviços usa Segurança da Camada de Transporte (TLS)
• Rede privada: as funções Lambda suportam implantação em Nuvem Privada Virtual (VPC) via variáveis de infraestrutura como código; quando habilitado, o tráfego permanece fora da internet pública por meio de VPC endpoints
• Auditabilidade: o AWS CloudTrail registra toda a atividade de API no pipeline, suportando revisões de conformidade

Quando usar essa abordagem

O artigo destaca que a abordagem com blueprints BDA é especialmente adequada para casos onde os documentos estão degradados ou em formatos mistos, onde há lógica de negócio no nível de campo (como redigir o nome do paciente mas não o do médico), ou onde coordenadas de bounding box no nível de pixel são necessárias para a redação em imagens.

O mesmo pipeline de produção pode ser reutilizado para diferentes tipos de documento simplesmente alterando o schema do blueprint e o prefixo S3 de entrada — tornando a solução um padrão reutilizável para redação de IPI em prontuários médicos, formulários de onboarding financeiro, requerimentos governamentais e qualquer workload intensivo em documentos com dados sensíveis.

Para começar, a AWS disponibiliza documentação sobre criação de blueprints no Amazon Bedrock Data Automation e um artigo complementar sobre como o BDA interage com o Bedrock Guardrails.

Fonte

Build a serverless PII redaction pipeline with Amazon Bedrock Data Automation (https://aws.amazon.com/blogs/machine-learning/build-a-serverless-pii-redaction-pipeline-with-amazon-bedrock-data-automation/)

O problema real de treinar modelos em escala

Treinar modelos de linguagem de grande porte é um processo que dura horas ou dias, distribuído por dezenas de nós. Nessa escala, interrupções não são exceção — são estatisticamente inevitáveis. Partições de rede, erros de memória, exceções de software ou eventos de infraestrutura vão, em algum momento, derrubar ao menos um worker.

O problema é que uma única falha de GPU desencadeia uma cascata: timeouts da Biblioteca de Comunicação Coletiva da NVIDIA (NCCL — NVIDIA Collective Communication Library) se propagam para os workers saudáveis, pods reiniciam fora de sincronia, e o cluster queima horas caras de GPU sem fazer progresso real de treinamento.

Existe ainda um segundo gargalo: o checkpointing síncrono. A cada salvamento, todos os ranks ficam bloqueados aguardando a conclusão da escrita em disco — um overhead que, nos experimentos documentados pela AWS, consumiu até 40% do tempo total de execução.

Para endereçar ambos os problemas, a AWS publicou um guia técnico detalhando como integrar o NVIDIA Resiliency Extension (NVRx) ao treinamento com PyTorch Paralelismo de Dados Totalmente Fragmentado (FSDP — Fully Sharded Data Parallel) no Serviço Gerenciado de Kubernetes da Amazon (Amazon EKS — Amazon Elastic Kubernetes Service). O código completo para reprodução está disponível no repositório.

Visão geral da solução

A arquitetura combina os primitivos de tolerância a falhas do NVRx com um ambiente de treinamento baseado em EKS, projetado para cargas de trabalho de GPU multi-nó de alto desempenho. O NVRx cuida da resiliência na camada de aplicação — checkpointing assíncrono, reinicialização in-process e reinicialização in-job — enquanto o cluster EKS fornece a fundação de infraestrutura: agendamento de GPU, rede de alta largura de banda e armazenamento compartilhado para persistência de checkpoints.

O que é o NVRx

O NVIDIA Resiliency Extension (NVRx) é uma camada Python instalável via pip (pip install nvidia-resiliency-ext) que adiciona primitivos de tolerância a falhas ao PyTorch — sem kernels customizados, sem fork do PyTorch, sem recompilação. Os primitivos se encaixam em um script FSDP existente como importações comuns, sem alterar o modelo ou o código de treinamento. Cada capacidade pode ser adotada de forma independente.

O guia da AWS exercita três funcionalidades principais: checkpointing assíncrono, reinicialização in-process e ft_launcher (reinicialização in-job).

Infraestrutura no Amazon EKS

O Amazon EKS é um serviço gerenciado de Kubernetes que cuida do plano de controle, atualizações e disponibilidade do servidor de API. A configuração utiliza grupos de nós autogerenciados de instâncias p5.48xlarge, cada uma com 8 GPUs NVIDIA H100 de 80 GB e 32 interfaces de Rede de Fabric Elástico (EFA — Elastic Fabric Adapter). Os pods de treinamento rodam como Kubernetes Jobs com Services headless para descoberta de peers via DNS, permitindo que substituições de pods se reconectem sem reconfigurar o job.

Para armazenamento de checkpoints, a solução utiliza o Amazon FSx para Lustre (SCRATCH_2, 1,2 TB) montado em todos os pods de treinamento via driver FSx CSI. Posicionar o FSx na mesma Zona de Disponibilidade dos nós GPU minimiza a latência de leitura durante a recuperação — ponto crítico, pois o carregamento do checkpoint (não o mecanismo de reinicialização em si) domina o tempo de recuperação em escala.

Os principais serviços AWS envolvidos são: Amazon EKS para gerenciamento do ciclo de vida dos pods e Jobs; instâncias EC2 p5.48xlarge com 8x H100 80 GB e 32x adaptadores EFA; EFA fornecendo 3.200 Gbps de largura de banda de rede para operações all-reduce do NCCL; Amazon FSx para Lustre como sistema de arquivos compartilhado POSIX para I/O distribuído de checkpoints; e Amazon Registro de Contêineres Elástico (Amazon ECR — Amazon Elastic Container Registry) para a imagem de treinamento.

As três capacidades do NVRx em detalhe

Checkpointing assíncrono: desacoplando I/O do treinamento

O ponto de partida é um loop FSDP padrão lançado pelo torchrun com salvamento síncrono de checkpoints. Nesse modelo, o salvamento bloqueia todos os ranks até que os shards de cada rank sejam gravados no armazenamento compartilhado — e uma falha de worker derruba o job inteiro, exigindo reinício completo a partir do último checkpoint.

A substituição é direta: troca-se o torch.save pelo TorchAsyncCheckpoint do NVRx. Instancia-se uma vez com persistent_queue=True, chama-se async_save(state_dict, path) no lugar do torch.save, e chama-se finalize_async_save(blocking=True) uma vez ao encerrar o job. Um processo em background assume a escrita real; a thread principal segue imediatamente para o próximo passo de forward/backward. Com FSDP LOCAL_STATE_DICT, cada rank escreve seu próprio shard diretamente, sem all-gather e sem gargalo no rank 0.

import torch
import torch.distributed as dist
from nvidia_resiliency_ext.checkpointing.async_ckpt.torch_ckpt import TorchAsyncCheckpoint

# Initialize the async checkpoint manager once after model/optimizer setup.
async_ckpt = TorchAsyncCheckpoint(persistent_queue=True)

# Training loop
for step, batch in enumerate(dataloader):
    loss = model(batch)
    loss.backward()
    optimizer.step()

    # Checkpoint every N steps
    if step % checkpoint_interval == 0:
        state_dict = build_state_dict(model, optimizer, step)  # FSDP LOCAL_STATE_DICT, CPU-staged
        # torch.save(state_dict, path)  # was blocking
        async_ckpt.async_save(state_dict, path)  # returns immediately

# Drain any in-flight save at job exit.
async_ckpt.finalize_async_save(blocking=True)

Reinicialização in-process: recuperação sem tocar no ciclo de vida do contêiner

A função de treinamento é envolvida com inprocess.Wrapper. O wrapper assume o loop de reinicialização: uma exceção na função envolvida (ou um travamento detectado pelo watchdog) dispara uma re-entrada em vez de encerrar o processo. O construtor configura quatro aspectos: timeouts (soft_timeout, hard_timeout, barrier_timeout, completion_timeout), verificações de saúde (CudaHealthCheck + FaultCounter), um RetryController que limita o total de reinicializações e define um tamanho mínimo de world size sobrevivente, e atribuição de ranks (ActivateAllRanks + ShiftRanks) que compacta os sobreviventes para manter o world contíguo.

import nvidia_resiliency_ext.inprocess as inprocess
from nvidia_resiliency_ext.inprocess import CallWrapper

def train_with_inprocess_restart(args, restart_metrics, base_store=None, call_wrapper: CallWrapper = None):
    # Re-init dist, rebuild FSDP, load latest checkpoint, train.
    # call_wrapper.ping() each step;
    # call_wrapper.iteration tells you which restart you're on.
    ...

wrapped_train = inprocess.Wrapper(
    store_kwargs = {"host_name": master_addr, "port": master_port + 1},
    soft_timeout = datetime.timedelta(seconds=args.soft_timeout_seconds),
    hard_timeout = datetime.timedelta(seconds=args.hard_timeout_seconds),
    barrier_timeout = datetime.timedelta(seconds=args.barrier_timeout_seconds),
    completion_timeout = datetime.timedelta(seconds=args.barrier_timeout_seconds),
    health_check = inprocess.Compose(
        inprocess.health_check.CudaHealthCheck(),
        inprocess.health_check.FaultCounter(max_rank_faults=20)),
    initialize = inprocess.initialize.RetryController(
        max_iterations=args.max_restarts,
        min_active_world_size=1),
    rank_assignment = inprocess.Compose(
        inprocess.rank_assignment.ActivateAllRanks(),
        inprocess.rank_assignment.ShiftRanks()),
)(train_with_inprocess_restart)

wrapped_train(args, restart_metrics, base_store)

Por baixo dos panos, um ProgressWatchdog usa Py_AddPendingCall para registrar timestamps entre instruções de bytecode, tornando travamentos dentro do NCCL (uma extensão C) detectáveis. Uma MonitorThread monitora o TCPStore do inprocess em busca de uma flag de interrupção e injeta RankShouldRestart na thread principal ao detectá-la. O AbortTorchDistributed então coleta rastreamentos do Flight Recorder, aborta os backends NCCL e destrói o grupo de processos. O processo Python permanece vivo — apenas o grupo de processos distribuídos é reconstruído.

Reinicialização in-job com ft_launcher: cobrindo falhas mais graves

Para falhas que o in-process não consegue capturar — SIGKILL, término por falta de memória (OOM — Out of Memory) e travamentos em nível de sistema operacional — o NVRx oferece o ft_launcher. A mudança é trocar o torchrun pelo ft_launcher na invocação do job, adicionando alguns parâmetros específicos de controle de reinicialização:

# --- before ---
torchrun --nnodes=$NNODES --nproc_per_node=$GPU_PER_NODE \
  --rdzv-backend=c10d --rdzv-endpoint=$MASTER_ADDR:29500 \
  train.py [args]

# --- after ---
ft_launcher --nnodes=$NNODES --nproc_per_node=$GPU_PER_NODE \
  --rdzv_backend=c10d --rdzv_endpoint=$MASTER_ADDR:29500 \
  --max-restarts=20 --ft-restart-policy=any-failed \
  --ft-rank-heartbeat-timeout=900 \
  --ft-initial-rank-heartbeat-timeout=1200 \
  --monitor-interval=5 \
  train_ft_launcher.py [args]

No script de treinamento, instancia-se um RankMonitorClient uma vez após a inicialização distribuída e envia-se um heartbeat a cada step:

import nvidia_resiliency_ext.fault_tolerance as fault_tolerance

ft_client = fault_tolerance.RankMonitorClient()
ft_client.init_workload_monitoring()  # once, after dist init

for step in range(1, args.max_steps + 1):
    loss = train_step(model, next(data_iter), optimizer)
    ft_client.send_heartbeat()  # liveness signal to RankMonitorServer

Um RankMonitorServer por rank rastreia os intervalos de heartbeat contra os timeouts configurados. Ao detectar timeout, o launcher envia SIGTERM para os sobreviventes (SIGKILL para os que não respondem), libera a memória GPU, faz o re-rendezvous e spawna workers frescos. Os workers recarregam do último checkpoint na inicialização.

Como as camadas se complementam

As duas camadas de recuperação cobrem classes de falha distintas: o in-process captura o que cabe dentro de um processo Python (exceções transientes, travamentos NCCL detectáveis pelo watchdog); o ft_launcher captura o que mata o processo ou trava em nível de SO (SIGKILL, OOM, deadlocks abaixo do Python); e o orquestrador de cluster cuida da perda de nó. O checkpointing assíncrono é ortogonal a ambos: pode ser pareado com qualquer camada de recuperação (ou nenhuma) e limita a quantidade de trabalho perdido em caso de falha.

Resultados dos benchmarks

Checkpointing assíncrono vs síncrono

A AWS realizou benchmarks comparando checkpointing assíncrono (NVRx) versus síncrono (torch.save) no treinamento FSDP do LLaMA-3.1-8B, variando de 2 a 8 nós (16 a 64 GPUs H100) com intervalo de checkpoint a cada 1.000 steps.

O checkpointing assíncrono manteve eficiência de treinamento acima de 99% em todas as escalas (99,2% com 2 nós, 99,8% com 8 nós), enquanto o síncrono ficou estagnado entre 57% e 61%, perdendo ~40% do tempo de execução em I/O bloqueante — independentemente do número de nós. A lacuna persiste porque o overhead de checkpoint é limitado pelo armazenamento: o tempo de escrita no FSx Lustre (~275s) é constante, seja com 16 ou 64 GPUs. O modo assíncrono esconde essa latência completamente ao sobrepor o I/O com o próximo segmento de treinamento.

Ao variar a frequência de checkpoint em escala de 8 nós, a vantagem assíncrona fica ainda mais evidente. A cada 1.000 steps, o assíncrono atinge 99,8% de eficiência contra 60,3% do síncrono. A cada 100 steps, o síncrono despenca para 14,7% enquanto o assíncrono degrada graciosamente para 29,6% — ainda 2x mais eficiente. O ponto de cruzamento ocorre quando o intervalo de treinamento entre checkpoints (~280s a 100 steps) se aproxima do tempo de I/O do FSx (~275s).

A implicação prática é direta: equipes que treinam em escala frequentemente checkpointam com pouca frequência para evitar a penalidade de bloqueio, aceitando horas de progresso perdido em caso de falha. O checkpointing assíncrono elimina esse tradeoff — é possível checkpointar agressivamente (a cada poucos minutos) com overhead próximo de zero.

Recuperação de falhas

Os experimentos de recuperação de falhas foram conduzidos em 2 nós p5.48xlarge (16 GPUs H100 no total) treinando LLaMA-3.1-8B com FSDP, checkpointando a cada 500 steps em uma execução de 2.000 steps. Cinco falhas determinísticas foram injetadas em cada execução (mesma semente, mesmo cronograma de falhas) e três mecanismos de recuperação foram comparados.

O NVRx in-process restart alcançou 31% de goodput de treinamento com 87% de goodput de infraestrutura, recuperando em ~10 segundos com zero reinicializações de contêiner. O ft_launcher alcançou 25,5% de goodput de treinamento (85,9% de infra goodput) com 17s de recuperação por falha. A reinicialização padrão do Kubernetes foi catastrófica: 11,5% de goodput de treinamento, 35,8% de infra goodput e 270s de recuperação por falha.

O modo de falha da baseline é uma cascata: um rank cai, o rank sobrevivente atinge timeout do NCCL (60s), ambos os pods reiniciam fora de sincronia, disparando CrashLoopBackOff e ciclos adicionais de timeout antes que o treinamento possa ser retomado. Em clusters com centenas a milhares de GPUs, onde falhas de hardware ocorrem a cada poucas horas, esse padrão significa que o cluster pode gastar mais tempo se recuperando do que treinando.

Pré-requisitos e como começar

Para reproduzir a solução, são necessários: conta AWS com cota de serviço para instâncias p5.48xlarge (ou p4de.24xlarge); cluster Amazon EKS (v1.28+) com grupos de nós GPU autogerenciados habilitados para EFA e o plugin de dispositivo NVIDIA instalado; sistema de arquivos Amazon FSx para Lustre (SCRATCH_2) na mesma Zona de Disponibilidade dos nós GPU; imagem de contêiner com PyTorch 2.9+ e NVRx 0.4.1 para reproduzir os benchmarks (ou v0.6.0 para implantação atual); kubectl configurado para o cluster; conta HuggingFace com acesso ao meta-llama/Llama-3.1-8B; e dataset de treinamento pré-baixado no armazenamento compartilhado.

Para criação do cluster EKS com nós GPU e rede EFA, os guias de infraestrutura estão disponíveis em awsome-distributed-ai/1.architectures. Para a configuração específica do NVRx incluindo módulos Terraform, build do contêiner e preparação do dataset, consulte o README do caso de teste NVRx.

Limpeza de recursos

Para evitar cobranças contínuas, a AWS orienta remover os recursos na seguinte ordem — objetos Kubernetes que montam FSx devem ser removidos antes do próprio sistema de arquivos, ou a exclusão ficará presa em finalizadores de volume:

1. Deletar os jobs de treinamento com ./deploy.sh --delete training-job-inprocess.yaml e kubectl get jobs -n nvrx-training
2. Liberar o volume claim com kubectl delete -f fsx-storage.yaml (o PersistentVolume usa persistentVolumeReclaimPolicy: Retain, então isso desanexa o sistema de arquivos sem deletá-lo — o FSx continua sendo cobrado até ser removido na etapa 4)
3. Escalar os grupos de nós GPU para zero via AWS CLI
4. Deletar o sistema de arquivos, repositório de imagens e cluster usando as ferramentas de provisionamento originais (terraform destroy, eksctl delete cluster ou CloudFormation)

Conclusão

A combinação do NVRx com o Amazon EKS resolve dois gargalos clássicos do treinamento distribuído em escala: o bloqueio por checkpoints síncronos e o tempo excessivo de recuperação após falhas. Com checkpointing assíncrono, a eficiência de treinamento se mantém acima de 99% de 16 a 64 GPUs H100. Com reinicialização in-process, a recuperação ocorre em ~10 segundos sem reinicializações de contêiner; com ft_launcher, falhas graves (SIGKILL, OOM) são tratadas sem interromper o job. Ambas representam uma mudança de patamar frente à recuperação padrão do Kubernetes, onde cascatas de timeout NCCL e tempestades de CrashLoopBackOff consomem mais de 4 minutos por falha.

O exemplo completo reproduzível está disponível no repositório awsome-distributed-ai. Para mais contexto sobre o NVRx, consulte a extensão de resiliência da NVIDIA e a palestra da GTC: Build Fault-Tolerant Distributed AI Training at Scale.

Referências

• Amazon Elastic Kubernetes Service (Amazon EKS)
• Amazon FSx para Lustre
• Amazon Elastic Container Registry (Amazon ECR)
• Elastic Fabric Adapter (EFA)
• Treinamento distribuído com Amazon EKS e Torch Distributed Elastic

Fonte

Fault tolerant distributed training on Amazon EKS using NVRx (https://aws.amazon.com/blogs/machine-learning/fault-tolerant-distributed-training-on-amazon-eks-using-nvrx/)

O problema que o prompt caching resolve

Imagine uma aplicação que envia um contrato de 10.000 tokens para um modelo de linguagem junto com 50 perguntas diferentes de usuários. Sem nenhum mecanismo de cache, isso representa 500.000 tokens de entrada cobrados pelo preço cheio — mesmo que o modelo já tenha processado aquele conteúdo dezenas de vezes antes.

As alternativas tradicionais para contornar esse problema têm custos embutidos: reduzir o tamanho dos prompts pode comprometer a qualidade do contexto; diminuir a janela de contexto limita a capacidade de raciocínio do modelo; e o cache de respostas idênticas só ajuda quando a pergunta é exatamente a mesma, o que raramente acontece em produção.

O prompt caching no Amazon Bedrock atua diretamente na infraestrutura para resolver esse problema. Ao armazenar um snapshot do processamento parcial da entrada, requisições subsequentes com o mesmo prefixo ignoram o reprocessamento daquele trecho. O resultado prático: redução de até 90% no custo dos tokens de entrada em cache e melhora no tempo até o primeiro token (TTFT — Time to First Token), sem alterar o modelo ou a qualidade dos prompts.

Como o mecanismo funciona

O funcionamento é direto: ao incluir um marcador cachePoint na requisição, o Amazon Bedrock verifica se o conteúdo anterior a esse marcador corresponde a uma entrada já existente no cache. Se houver correspondência (cache hit), o modelo pula o reprocessamento daqueles tokens e parte do estado já armazenado. Se não houver (cache miss), o conteúdo é processado normalmente e gravado em cache para uso futuro.

Quatro conceitos definem o comportamento do cache na prática:

• Escopo do cache: as entradas são isoladas por conta AWS e por Região.
• Limite mínimo de tokens: cada checkpoint precisa atingir um mínimo para ser ativado. O Claude Sonnet 4.5 e 4.6, por exemplo, exigem ao menos 1.024 tokens por checkpoint; modelos Opus exigem 4.096.
• TTL (Time-to-Live): entradas expiram conforme o TTL definido na requisição. O padrão é 5 minutos, com alguns modelos suportando até 1 hora.
• Sintaxe agnóstica de modelo: a sintaxe cachePoint da Converse API funciona igualmente para Claude (Anthropic) e Amazon Nova.

Estrutura de preços

O prompt caching introduz duas categorias adicionais de tokens, além dos tokens de entrada e saída padrão:

• cacheWriteInputTokens: tokens gravados no cache na primeira requisição — custo 25% maior que o input padrão.
• cacheReadInputTokens: tokens lidos do cache nas requisições seguintes — custo 90% menor que o input padrão.
• cacheWriteInputTokens com TTL de 1 hora: custo 100% maior (2x) que o input padrão.

Para cargas de trabalho com contexto repetido, a economia líquida fica em torno de 75% nos custos de tokens de entrada. Por exemplo: ao enviar um documento de 10.000 tokens com 10 perguntas diferentes, a primeira requisição gera um cache write. As nove seguintes leem do cache com 90% de desconto, resultando em economia líquida de aproximadamente 75% — desde que todas ocorram dentro da janela de TTL. Consulte a página de preços do Amazon Bedrock para os valores detalhados.

Seis cenários práticos com a Converse API

A documentação da AWS apresenta seis padrões progressivos de implementação, do básico ao avançado. Todos os exemplos utilizam o modelo Anthropic Claude Sonnet 4.5 (global.anthropic.claude-sonnet-4-5-20250929-v1:0) e requerem Python 3.10 ou superior com as dependências boto3>=1.43.0 e langchain-aws>=0.2.12. Para habilitar o acesso ao modelo, consulte a documentação de gerenciamento de acesso a modelos.

Cenário 1: Cache de conteúdo de mensagem

O caso de uso mais comum: cachear documentos longos consultados repetidamente, como em aplicações de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) ou assistentes de código que referenciam bases de código extensas.

O marcador cachePoint é inserido entre o documento estático e a pergunta dinâmica:

content = [
    {"text": "<conteúdo do documento estático>"},
    {"cachePoint": {"type": "default"}},  # cacheia tudo acima
    {"text": "<pergunta do usuário>"}     # dinâmico, muda por requisição
]

A resposta da API inclui os campos cacheWriteInputTokens (na primeira chamada) e cacheReadInputTokens (nas chamadas seguintes). Em testes com o Claude Sonnet 4.5 e um documento acima de 1.024 tokens, a primeira resposta mostra:

{
  "inputTokens": 28,
  "outputTokens": 253,
  "cacheWriteInputTokens": 1898,
  "cacheReadInputTokens": 0
}

E a requisição seguinte com o mesmo documento, mas pergunta diferente:

{
  "inputTokens": 28,
  "outputTokens": 294,
  "cacheWriteInputTokens": 0,
  "cacheReadInputTokens": 1898
}

Os modelos Claude no Amazon Bedrock suportam gerenciamento simplificado de cache: um único cachePoint já verifica automaticamente hits nos prefixos de até aproximadamente 20 blocos de conteúdo anteriores ao marcador. Para controle mais granular, é possível inserir múltiplos cachePoint após cada seção, habilitando hits parciais de cache.

Cenário 2: Cache de system prompt

Aplicações baseadas em personas detalhadas — assistentes de domínio, bots de atendimento com políticas complexas, agentes com instruções extensas — pagam o custo de reprocessar o system prompt em cada interação. Com o cache de system prompt, esse custo é pago uma única vez.

O cachePoint é inserido dentro do parâmetro system, separado das mensagens do usuário:

system = [
    {"text": "<system prompt detalhado>"},
    {"cachePoint": {"type": "default"}}
]

Independente do que o usuário perguntar, o prefixo do system prompt é reutilizado do cache enquanto o TTL estiver ativo.

Cenário 3: Cache de definições de ferramentas

Aplicações agênticas frequentemente definem dezenas de ferramentas com schemas JSON detalhados. Esses schemas raramente mudam entre requisições, mas são reprocessados a cada chamada. O cache de tool definitions evita esse reprocessamento repetido.

O cachePoint é adicionado como último elemento do array tools dentro de toolConfig:

toolConfig = {
    "tools": [
        {"toolSpec": {"name": "tool_1", ...}},
        {"toolSpec": {"name": "tool_2", ...}},
        {"cachePoint": {"type": "default"}}  # após as definições de ferramentas
    ]
}

Cenário 4: Cache com TTL misto

Nem todo conteúdo tem o mesmo ciclo de vida. Conhecimento de domínio e catálogos de produtos mudam raramente e se beneficiam de TTLs longos. Contexto de sessão e preferências do usuário mudam com frequência e exigem TTLs curtos.

Com o TTL misto, diferentes seções do conteúdo recebem tempos de expiração distintos dentro de uma única requisição:

content = [
    {"text": "<material de referência central>"},
    {"cachePoint": {"type": "default", "ttl": "1h"}},  # TTL longo primeiro
    {"text": "<contexto de sessão>"},
    {"cachePoint": {"type": "default", "ttl": "5m"}},  # TTL curto depois
    {"text": "<pergunta do usuário>"}
]

Regra importante: checkpoints com TTL mais longo devem aparecer antes dos checkpoints com TTL mais curto. A API retorna erro caso a ordem seja invertida. A resposta inclui um campo cacheDetails com o detalhamento de tokens por TTL, permitindo verificar se ambas as camadas estão funcionando corretamente.

Uma referência prática para escolha de TTL por tipo de conteúdo:

• Conhecimento de domínio, catálogos, documentação de referência: 1 hora
• Contexto de sessão, preferências do usuário: 5 minutos
• Definições de ferramentas e schemas de API: 1 hora
• Dados em tempo real e queries específicas do usuário: sem cache

Cenário 5: Isolamento por tenant

Em aplicações multi-tenant, entradas de cache dentro da mesma conta e Região AWS podem ser compartilhadas entre requisições. Para evitar que o cache de um tenant seja lido por outro, a solução recomendada é o padrão de prefixo SHA-256.

O hash do tenant_id é adicionado como prefixo ao conteúdo cacheado. Como o hash muda o prefixo do conteúdo, o Amazon Bedrock cria entradas de cache separadas para cada tenant:

import hashlib

sha256_hash = hashlib.sha256(tenant_id.encode()).hexdigest()
instructions = f"{sha256_hash}:{instructions}"

O overhead é mínimo: o hash SHA-256 adiciona apenas 64 caracteres (aproximadamente 16 tokens) ao prompt. Não há configuração server-side necessária — o isolamento é obtido puramente via prefixo de conteúdo, com entradas de cache independentes por tenant.

Cenário 6: Integração com LangChain

Para equipes que utilizam o framework LangChain, o prompt caching se integra diretamente à classe ChatBedrockConverse através do método create_cache_point(), que gera o bloco cachePoint correto sem necessidade de manipular o formato bruto da API:

from langchain_aws import ChatBedrockConverse
from langchain_core.messages import HumanMessage, SystemMessage

HumanMessage(content=[
    {"type": "text", "text": "<conteúdo do documento>"},
    ChatBedrockConverse.create_cache_point()
])

O mesmo padrão funciona em chains LCEL (LangChain Expression Language) com ChatPromptTemplate, permitindo reutilização em pipelines completos. As métricas de cache ficam disponíveis em usage_metadata da resposta, nos campos cache_creation e cache_read.

Converse API vs. InvokeModel API

Os cenários acima utilizam a Converse API, que oferece sintaxe de cachePoint agnóstica de modelo. Para quem usa a InvokeModel API com modelos Anthropic, a sintaxe é diferente: o controle de cache é feito via "cache_control": {"type": "ephemeral"} dentro do próprio bloco de conteúdo, e o campo cacheDetails não está disponível na resposta.

A recomendação da AWS para novas aplicações é usar a Converse API, pois o mesmo código de caching funciona tanto para Claude quanto para Amazon Nova sem modificações.

Boas práticas para produção

• Mapeie o que é estático vs. dinâmico: system prompts, schemas de ferramentas e documentos de referência são candidatos naturais ao cache. Perguntas do usuário e dados em tempo real, não.
• Respeite o limite mínimo de tokens: conteúdo abaixo do threshold é processado normalmente sem cache. Verifique os requisitos do modelo que está usando.
• Monitore as métricas de cache: acompanhe cacheWriteInputTokens e cacheReadInputTokens nos logs. Uma taxa de hit baixa pode indicar que o conteúdo muda com frequência demais ou que o TTL está muito curto.
• Aplique controles de IA responsável: para deploys em produção, o Amazon Bedrock Guardrails pode ser combinado com os padrões de cache para adicionar filtragem de conteúdo e validação de grounding.
• Combine locais de cache: é possível cachear system prompt, conteúdo de mensagem e definições de ferramentas simultaneamente em uma única requisição, acumulando as economias.

Próximos passos

O conjunto completo de notebooks e scripts referenciados está disponível no repositório amazon-bedrock-samples no GitHub. Para detalhes sobre configuração e modelos suportados, consulte a documentação do Amazon Bedrock Prompt Caching. Para começar, acesse o Amazon Bedrock ou abra o console do Amazon Bedrock para habilitar o acesso ao modelo.

Fonte

Optimizing cost and latency with Amazon Bedrock prompt caching (https://aws.amazon.com/blogs/machine-learning/optimizing-cost-and-latency-with-amazon-bedrock-prompt-caching/)

O problema clássico: esperar por GPU disponível

Quem trabalha com treinamento de modelos de IA em escala conhece bem a frustração: você submete um job, e a instância GPU que precisa simplesmente não está disponível naquele momento. Com o job preso a um único tipo de instância, a única saída é esperar — ou montar gambiarras manuais para tentar alternativas.

Esse cenário é especialmente crítico em pipelines de re-treinamento noturno, execuções de fine-tuning em produção e jobs de processamento agendados. Um simples InsufficientCapacityError às 2h da manhã pode comprometer a atualização do modelo e atrasar ciclos inteiros de experimentação.

Para contornar o problema, muitas equipes desenvolveram scripts customizados que monitoram o status do job, cancelam requisições travadas e resubmetem com tipos alternativos. Além de frágeis, essas soluções não se integram com opções de capacidade reservada — e adicionam sobrecarga operacional que se acumula a cada nova execução de treinamento.

A solução: listas de preferência de instâncias

A AWS anunciou as listas de preferência de instâncias para Jobs de Treinamento do Amazon SageMaker AI e Jobs de Processamento do Amazon SageMaker AI. Com essa funcionalidade, em vez de fixar o job a um único tipo de instância, é possível fornecer uma lista ordenada de até cinco tipos aceitáveis em uma única chamada de API.

O Amazon SageMaker AI avalia a lista em ordem de prioridade e inicia o job no primeiro tipo com capacidade disponível — sem intervenção manual, sem scripts de polling e sem loops de retry.

Como o fluxo de provisionamento funciona

O processo segue quatro etapas principais:

• Etapa 1: Você submete o job com uma lista ordenada de até cinco tipos de instância.
• Etapa 2: O SageMaker AI valida a configuração do job e a lista de preferências em relação aos tipos suportados e aos limites de recursos.
• Etapa 3: O scheduler realiza uma varredura em memória pela lista ordenada e identifica o primeiro tipo com capacidade disponível.
• Etapa 4: O tipo vencedor é provisionado imediatamente e o job começa a execução.

Se nenhum tipo da lista tiver capacidade disponível no momento da avaliação, o job entra em uma fila orientada a eventos e realiza retries automáticos quando a capacidade for liberada. Esse tempo de espera é controlado pelo parâmetro MaxPendingTimeInSeconds, que define o tempo máximo que o SageMaker AI pode aguardar percorrendo a lista.

Vale destacar: o MaxPendingTimeInSeconds só tem efeito para jobs que solicitam instâncias de computação acelerada — como as famílias ml.p, ml.g e ml.trn. Para instâncias CPU, esse parâmetro não tem efeito. Além disso, o timeout se aplica à lista inteira, não a cada tipo individualmente.

Integração com Planos de Treinamento Flexíveis (FTP)

Equipes que investiram em Planos de Treinamento Flexíveis (FTP) — que reservam capacidade GPU por um período definido a taxas com desconto — ganham uma extensão natural com as listas de preferência. É possível associar um Training Plan a preferências específicas da lista e deixar as demais usando capacidade sob demanda.

O sweep avalia a reserva primeiro. Se aquela preferência não puder ser provisionada, o sistema avança para o próximo tipo na lista, que pode usar capacidade on-demand. Não é necessária nenhuma troca manual — o que tiver capacidade primeiro vence.

Exemplos de código: jobs de treinamento

Os exemplos abaixo utilizam o SDK Python do Amazon SageMaker v3 com a classe ModelTrainer.

Exemplo 1: Três tipos de GPU com contagem uniforme (P5, P4d e P4de)

Neste exemplo, são especificados três tipos de instância GPU com a mesma contagem. O SageMaker AI tenta provisionar a primeira preferência (P5) e recorre ao P4d ou P4de se não houver capacidade disponível.

from sagemaker.core.shapes.shapes import InstancePreference
from sagemaker.train.model_trainer import ModelTrainer
from sagemaker.train.configs import Compute, OutputDataConfig

trainer = ModelTrainer(
    training_image="763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.3.0-gpu-py311-cu121-ubuntu22.04-sagemaker",
    source_code="train.py",
    role="arn:aws:iam:: 111122223333:role/SageMakerExecutionRole",
    base_job_name="large-model-training-70b",
    output_data_config=OutputDataConfig(
        s3_output_path="s3:// amzn-s3-demo-bucket /training-output/"
    ),
    compute=Compute(
        instance_count=8,  # Same count regardless of which type wins
        volume_size_in_gb=500,
        keep_alive_period_in_seconds=3600,
        instance_preferences=[
            InstancePreference(instance_type="ml.p5.48xlarge"),   # Priority 1: H100
            InstancePreference(instance_type="ml.p4d.24xlarge"),  # Priority 2: A100
            InstancePreference(instance_type="ml.p4de.24xlarge"), # Priority 3: A100 (80GB)
        ],
    ),
)

trainer.train(wait=False)
print(f"Job submitted: {trainer._latest_training_job.training_job_name}")

Exemplo 2: Contagens por preferência para equivalência de computação

Nem todos os tipos de instância entregam o mesmo throughput por nó. Quando a lista inclui tipos com arquiteturas de GPU diferentes, é possível especificar uma contagem de instâncias diferente para cada entrada, alcançando throughput total equivalente. No exemplo abaixo, duas instâncias ml.g6.48xlarge (16 GPUs L40S no total) são a primeira preferência, com quatro ml.g5.48xlarge (32 GPUs A10G no total) como fallback para compensar a menor performance por GPU.

compute = Compute(
    volume_size_in_gb=500,
    instance_preferences=[
        # 2× g6.48xlarge (8× L40S GPUs each = 16 GPUs total)
        InstancePreference(instance_type="ml.g6.48xlarge", instance_count=2),
        # 4× g5.48xlarge (8× A10G GPUs each = 32 GPUs, but lower per-GPU perf)
        InstancePreference(instance_type="ml.g5.48xlarge", instance_count=4),
    ],
)

Dica: Use contagens por preferência quando seu script de treinamento consegue se adaptar a diferentes quantidades de GPU — por exemplo, via torchrun com --nproc_per_node=auto. Cada configuração deve entregar throughput total equivalente para sua carga de trabalho.

Exemplo 3: Integração com Training Plan (híbrido reservado e on-demand)

Este exemplo combina capacidade reservada de um Training Plan com fallback on-demand, garantindo que os jobs possam iniciar mesmo quando a capacidade reservada está totalmente utilizada.

compute = Compute(
    instance_count=4,
    volume_size_in_gb=500,
    instance_preferences=[
        # Priority 1: Use my reserved P5 capacity (guaranteed, no wait)
        InstancePreference(
            instance_type="ml.p5.48xlarge",
            training_plan_arns=[
                "arn:aws:sagemaker:us-west-2:111122223333:training-plan/my-p5-reservation"
            ],
        ),
        # Priority 2: On-demand P4d (if reservation is fully consumed)
        InstancePreference(instance_type="ml.p4d.24xlarge"),
        # Priority 3: On-demand P4de (last resort)
        InstancePreference(instance_type="ml.p4de.24xlarge"),
    ],
)

Jobs de processamento também são suportados

O mesmo mecanismo de fallback se aplica a jobs de processamento. Em vez de configurar as preferências de instância no recurso de treinamento, você as especifica no ClusterConfig do job de processamento. O SageMaker AI avalia a lista em ordem de prioridade no momento do lançamento e provisiona automaticamente o cluster com o primeiro tipo disponível.

from sagemaker.processing import Processor

processor = Processor(
    role="arn:aws:iam::123456789012:role/SageMakerExecutionRole",
    image_uri="763104351884.dkr.ecr.us-east-1.amazonaws.com/pytorch-training:2.3.0-gpu-py311-cu121-ubuntu22.04-sagemaker",
    instance_count=2,
    volume_size_in_gb=100,
    entrypoint=["python3", "process.py"],
    instance_preferences=[
        {"InstanceType": "ml.g5.12xlarge"},  # Priority 1
        {"InstanceType": "ml.g5.4xlarge"},   # Priority 2
        {"InstanceType": "ml.m5.12xlarge"},  # Priority 3 (CPU fallback)
    ],
)

processor.run(
    inputs=[...],
    outputs=[...],
)

Atenção: Jobs de processamento não suportam integração com Training Plans. O campo TrainingPlanArns é exclusivo para jobs de treinamento.

Boas práticas ao configurar listas de preferência

1. Liste apenas tipos de instância compatíveis

O SageMaker AI não valida compatibilidade entre tipos — arquitetura de GPU, suporte a Elastic Fabric Adapter (EFA) e versões de driver. Certifique-se de que seu container de treinamento funciona em todos os tipos listados.

2. Use contagens por preferência para equivalência de throughput

Se a lista inclui tipos com diferentes capacidades de computação por nó, ajuste as contagens para equiparar o throughput total:

{ "InstanceType": "ml.p5.48xlarge", "InstanceCount": 2 },  // 2× H100 nodes
{ "InstanceType": "ml.p4d.24xlarge", "InstanceCount": 4 }  // 4× A100 nodes ≈ same total FLOPS

3. Combine com Training Plans para capacidade garantida e flexível

Coloque a capacidade reservada primeiro na lista de preferências, para que o SageMaker AI tente iniciar com recursos pré-pagos antes de recorrer a alternativas on-demand:

• Prioridade 1: P5 reservado (via Training Plan) → instantâneo se a reserva estiver disponível
• Prioridade 2: P4d on-demand → bom fallback a taxas padrão
• Prioridade 3: P4de on-demand → último recurso

4. Controle o tempo de fila com MaxPendingTimeInSeconds

Defina por quanto tempo o job pode continuar tentando a lista antes de ser encerrado (aplica-se apenas a instâncias de computação acelerada):

StoppingCondition={
    "MaxRuntimeInSeconds": 86400,
    "MaxPendingTimeInSeconds": 1800  # Fail after 30 minutes if no capacity
}

Como começar

Para usar as listas de preferência de instâncias, basta seguir estes passos:

• Atualize o SDK Python do Amazon SageMaker: pip install --upgrade sagemaker
• Adicione instance_preferences à sua configuração de Compute seguindo o Guia do Desenvolvedor do Amazon SageMaker AI
• Liste de 2 a 5 tipos de instância compatíveis em ordem de prioridade
• Submeta o job pelo console do Amazon SageMaker AI e deixe o serviço encontrar capacidade automaticamente

Para saber mais sobre tipos de instância, preços e Training Plans, consulte a página de detalhes do Amazon SageMaker AI.

Fonte

Announcing instance preference lists for Amazon SageMaker AI training jobs (https://aws.amazon.com/blogs/machine-learning/announcing-instance-preference-lists-for-amazon-sagemaker-ai-training-jobs/)