Amazon SageMaker AI ganha lista de preferência de instâncias

A Amazon adiciona ao SageMaker AI listas de preferência de instância para Training Jobs e Processing Jobs, com até cinco tipos ordenados por job. O serviço testa a lista em ordem e inicia o job automaticamente no primeiro tipo com capacidade livre, sem scripts manuais de retry (tentativas repetidas escritas à mão). Sem capacidade disponível, o job entra numa fila orientada a eventos (que reage a mudanças de capacidade em tempo real) e tenta de novo sozinho.

A Amazon integra o novo mecanismo aos Flexible Training Plans, recurso que reserva blocos de capacidade acelerada por um período fixo. Recorre à capacidade sob demanda só se a reserva não estiver disponível na hora da execução. O parâmetro MaxPendingTimeInSeconds define por quanto tempo o job espera na fila antes de desistir da tentativa, mas essa regra vale só para instâncias de computação acelerada — famílias ml.p, ml.g e ml.trn. Jobs que usam só CPU não passam por esse limite de espera. Processing Jobs ganham o mesmo fallback automático (troca de tipo quando a capacidade reservada falha), configurado pelo ClusterConfig.

Amazon SageMaker AI ganha lista de preferência de instâncias — Imagem: Divulgação/aws.amazon.com

Mas ficam de fora da integração com os Training Plans: o campo TrainingPlanArns funciona apenas para Training Jobs. Para ativar as listas de preferência, é preciso atualizar o SageMaker Python SDK com pip install --upgrade sagemaker e adicionar o campo instance_preferences na configuração de Compute do job. Um job de processamento leve, que roda em CPU, não ganha a tentativa automática entre tipos: continua preso ao tipo único que já pedia antes do anúncio. A integração chega também ao HyperPod, ambiente da Amazon para clusters de treinamento distribuído.

No HyperPod, que já usa esse mecanismo, a lista de preferências cobre cinco tipos: ml.p4d.24xlarge, ml.p5.48xlarge, ml.p5e.48xlarge, ml.p5en.48xlarge e ml.trn2.48xlarge — todos voltados a clusters com GPU ou com o chip Trainium, da própria Amazon. A customização serverless de fine-tuning (ajuste fino de modelos prontos), recurso separado para modelos como Nova, DeepSeek, Llama e Qwen, fica fora dessa fila e cobra por token processado em treinamento e em inferência.

Histórico de controle sobre hardware de treinamento

A Amazon já testava esse tipo de controle operacional com o SageMaker Profiler, lançado antes. A ferramenta rastreia uso de CPU e GPU, execução de kernels e operações de memória durante o treinamento, para tirar do time a tarefa de monitorar hardware manualmente. Equipes que rodam inferência de modelos customizados no SageMaker já pediam mais controle sobre tipo de instância, política de escalonamento automático, tamanho de contexto e nível de concorrência.

As listas de preferência levam essa mesma lógica de escolha manual para o treinamento, tirando dos scripts externos a decisão sobre qual GPU usar primeiro. A AWS também amplia o acesso a modelos de fundação de empresas como Anthropic, Meta e Mistral pelo Bedrock. Mas ter o modelo pronto não resolve sozinho o desafio de treinar ou ajustar esses modelos em escala, e é aí que entra a nova camada de resiliência do SageMaker AI.

Fim dos scripts caseiros de retry

Antes, os times escreviam scripts próprios para tentar de novo quando um tipo de instância não estava livre. Agora essa lógica vira parte do próprio SageMaker AI. Para adotar o recurso, o time só precisa declarar a lista de preferências e o campo instance_preferences na configuração de Compute do job, sem manter um loop de retry paralelo. Quem já usa Flexible Training Plans ganha um comportamento previsível: a reserva entra primeiro, e o job só sai dela se a capacidade reservada não aparecer. Essa diferença separa o alcance do recurso entre as duas cargas de trabalho suportadas hoje pelo SageMaker AI.