Listas de Preferência de Instâncias do Amazon SageMaker Substituem Novas Tentativas Manuais de GPU, mas Não o Planejamento de Capacidade

A Amazon apresentou as listas de preferência de instâncias do Amazon SageMaker, permitindo que uma solicitação de treinamento inclua até cinco opções de computação ordenadas, em vez de um único tipo de instância fixo. O SageMaker AI verifica essas opções por ordem de prioridade e inicia a primeira configuração com capacidade disponível.

A mudança ataca um problema operacional persistente. Jobs de treinamento do SageMaker com GPU podem permanecer pendentes quando o hardware solicitado não está disponível. As equipes têm respondido monitorando a capacidade, reenviando jobs ou mantendo scripts que tentam configurações alternativas.

Agora, a AWS transfere essa decisão de nova tentativa para o agendador gerenciado. No entanto, o recurso não cria capacidade de GPU nem comprova que aceleradores diferentes executarão corretamente uma carga de trabalho. Seu valor depende de as equipes conseguirem tornar seu código de treinamento, suas metas de desempenho e seus controles de custo realmente flexíveis em relação ao hardware.

Essa distinção pressiona uma prática conhecida de nuvem: tratar um tipo de instância como uma propriedade fixa de cada job. O Google Cloud já enfileira solicitações flexíveis de aceleradores por meio do Dynamic Workload Scheduler. Usuários do Azure Machine Learning também planejam em torno de cotas de computação regionais e específicas por família. Agora, a AWS torna a flexibilidade de hardware declarada uma parte essencial dos jobs individuais do SageMaker.

O Que a AWS Mudou com as Listas de Preferência de Instâncias do Amazon SageMaker

Uma solicitação do SageMaker agora pode expressar várias configurações de computação aceitáveis sem exigir um controlador externo de novas tentativas.

A AWS anunciou o recurso em 15 de setembro de 2026, tanto para jobs de treinamento quanto de processamento. Ele está disponível por meio das APIs, SDKs, ferramentas de linha de comando e console do SageMaker em todas as Regiões da AWS onde o SageMaker AI está disponível, segundo o aviso de disponibilidade regional da empresa.

Uma lista de preferência contém entre dois e cinco tipos de instância em ordem de prioridade. O SageMaker valida a lista, realiza uma varredura em memória e seleciona a primeira configuração com capacidade disponível. Apenas uma configuração listada executa o job.

Se nenhuma estiver imediatamente disponível, o job entra em uma fila orientada por eventos. O SageMaker tenta novamente à medida que a capacidade muda, em vez de exigir que um processo do cliente consulte o serviço e reenvie solicitações. O período total de espera pode ser limitado com MaxPendingTimeInSeconds.

Esse tempo limite se aplica à lista de preferência inteira, e não separadamente a cada opção. A AWS também afirma que ele só entra em vigor quando pelo menos uma configuração listada usa computação acelerada de famílias como ml.p, ml.g ou ml.trn.

Esse comportamento importa porque uma preferência é mais do que um nome alternativo de instância. As equipes podem atribuir uma contagem diferente de instâncias a cada opção. Um job pode preferir dois nós ml.g6.48xlarge, mas aceitar quatro nós ml.g5.48xlarge quando essa segunda configuração oferece throughput agregado adequado.

A AWS permite dois modelos de contagem. Um ResourceConfig.InstanceCount compartilhado pode se aplicar a todas as preferências, ou cada preferência pode definir sua própria contagem. Misturar essas abordagens é inválido, como explica a referência da API.

O recurso também se conecta aos SageMaker Flexible Training Plans, que reservam capacidade de GPU compatível por um período definido. Um job de treinamento pode colocar primeiro uma configuração correspondente respaldada por um plano e, em seguida, listar alternativas sob demanda. Se a opção reservada não puder ser provisionada, o SageMaker avança pelas preferências restantes.

Essa integração é limitada ao treinamento. Jobs de processamento recebem o mesmo mecanismo ordenado de contingência, mas não podem associar preferências aos Flexible Training Plans.

O caso de uso de processamento continua sendo significativo. O SageMaker Processing executa infraestrutura gerenciada para preparação de dados, engenharia de atributos, avaliação e trabalhos relacionados. Esses jobs frequentemente toleram uma gama mais ampla de hardware do que jobs de treinamento distribuído rigidamente otimizados.

A AWS apresenta a mudança como uma alternativa a loops manuais de novas tentativas e scripts de monitoramento de capacidade em seu post de lançamento. Esse é o benefício imediato mais claro. Um pipeline envia um único job, enquanto o SageMaker assume a busca por capacidade dentro dos limites declarados.

O agendador não escolhe uma máquina arbitrária que considere equivalente. Ele segue a ordem do cliente. Isso preserva uma divisão útil de responsabilidades: os operadores decidem quais configurações são válidas, e o SageMaker decide qual opção válida pode iniciar primeiro.

Esta é uma pequena mudança de API com uma implicação operacional maior. A flexibilidade de infraestrutura agora pode acompanhar a definição do job, em vez de ficar em código de orquestração ao redor dela.

Por Que a Capacidade de GPU do SageMaker se Tornou um Problema de Agendamento

O recurso escasso já não é apenas uma GPU; é a configuração de cluster certa, na Região certa e no momento certo.

Equipes de treinamento de IA frequentemente discutem aceleradores como unidades intercambiáveis, mas a capacidade de nuvem é dividida entre famílias de instâncias, tamanhos, Regiões, pools de disponibilidade, cotas e modelos de reserva. Um cliente pode ter permissão para solicitar uma máquina sem que ela esteja pronta para alocação imediata.

Essa fragmentação cria um tratamento de falhas incômodo. Um pipeline pode estar tecnicamente correto e ainda perder horas porque a configuração selecionada não consegue iniciar. Um engenheiro então precisa decidir se espera, muda o hardware, altera a contagem de nós ou move a carga de trabalho.

Antes das listas de preferência, os jobs de treinamento do SageMaker especificavam um único tipo de instância no envio. As equipes que aceitavam alternativas precisavam codificar essa flexibilidade em outro lugar. Algumas criavam funções de nova tentativa em torno de falhas de API. Outras enviavam várias variantes e cancelavam as perdedoras depois que uma iniciava.

Ambos os padrões introduzem trabalho de coordenação. Várias solicitações ativas podem complicar a observabilidade e o cancelamento. Scripts de novas tentativas sequenciais precisam de gerenciamento de estado, regras de backoff, tratamento de tempos limite, permissões e proteção contra execução duplicada.

O monitoramento de capacidade também se torna outro sistema de produção. A equipe precisa mantê-lo quando o comportamento do SDK muda, expor suas falhas e garantir que um controlador reiniciado não inicie duas vezes o mesmo job caro.

As listas de preferência de instâncias do Amazon SageMaker absorvem parte desse plano de controle. A solicitação de job carrega um conjunto limitado de resultados aceitáveis, e o serviço gerenciado faz a seleção assim que encontra capacidade.

Esse modelo reflete o comportamento de muitas cargas de trabalho reais. Ajuste fino, avaliação, pré-processamento e experimentação de modelos frequentemente têm uma configuração preferida, em vez de uma única configuração matematicamente obrigatória. Uma equipe pode preferir GPUs mais novas pela velocidade, mas aceitar GPUs mais antigas quando o tempo de início importa mais.

O mesmo princípio se aplica à contagem de nós. Dois nós mais rápidos e quatro nós mais lentos podem, às vezes, cumprir uma meta de conclusão semelhante. Eles não são inerentemente equivalentes, mas os desenvolvedores podem testá-los e declarar ambos aceitáveis.

A AWS não está sozinha ao transformar escassez em uma interface de agendamento. O modo Flex-start do Google Cloud enfileira solicitações de aceleradores até que todos os recursos necessários estejam disponíveis. O Google o posiciona para jobs de treinamento que podem tolerar um horário de início flexível.

Os mecanismos diferem. O modelo do Google enfatiza o atendimento de uma alocação e duração de aceleradores solicitadas. A AWS permite que um job do SageMaker percorra um conjunto ordenado de tipos e contagens. Ambas as abordagens pedem aos clientes que expressem flexibilidade, em vez de sondar repetidamente a capacidade.

O Azure Machine Learning expõe outra parte da restrição. Suas cotas de computação são gerenciadas por Região e família de VM, com limites separados para uso de workspace e assinatura. As famílias de GPU podem começar sem cota padrão de núcleos dedicados, dependendo da assinatura.

Esses sistemas mostram por que a disponibilidade de aceleradores não pode ser reduzida a uma página de catálogo. Uma instância listada pode ser compatível, mas ainda indisponível para uma conta, local, tamanho de job ou janela de tempo específicos.

Para clientes da AWS, a pressão imediata recai sobre equipes que mantêm lógica personalizada de provisionamento. Se um serviço de novas tentativas apenas alterna entre tipos de instância do SageMaker, sua função central agora se sobrepõe à plataforma.

O recurso também pressiona padrões internos rígidos que aprovam exatamente um tipo de instância por modelo. Esses padrões simplificaram benchmarking e governança, mas transformam toda escassez de capacidade em um bloqueio. Agora, as equipes têm um motivo para certificar várias configurações para cada carga de trabalho.

Isso não elimina a orquestração. Pipelines ainda precisam de dependências, rastreamento de artefatos, políticas de falha e validação pós-execução. A mudança reduz o trabalho da orquestração ao mover uma decisão recorrente — qual configuração aceitável pode iniciar — para o próprio SageMaker.

Flexibilidade Substitui a Lógica de Novas Tentativas, Não as Restrições de Capacidade

O mecanismo melhora a busca por infraestrutura disponível, mas não pode fornecer infraestrutura que não existe.

Quando um job chega, o SageMaker valida sua configuração e lista de preferência em relação aos recursos e limites compatíveis. Em seguida, o agendador verifica as opções uma vez, na ordem declarada. A primeira opção disponível vence e começa o provisionamento.

Se todas as opções estiverem indisponíveis, a fila orientada por eventos aguarda uma mudança relevante de capacidade. Isso é mais eficiente do que a consulta contínua do cliente, mas ainda é uma fila. Um job pode permanecer pendente até que seu tempo limite expire.

Esse limite importa ao avaliar a alegação da AWS de que o recurso ajuda jobs a iniciar mais cedo. A comparação é com um job fixado em uma única configuração indisponível ou com um sistema de novas tentativas gerenciado pelo cliente e mais lento. A AWS não publicou benchmarks independentes que mostrem melhorias medianas no tempo de início entre Regiões, famílias de instâncias ou tamanhos de cluster.

Uma lista também não combina capacidade parcial de várias entradas. Se uma preferência solicita oito nós, o SageMaker precisa conseguir provisionar essa configuração selecionada. O sistema escolhe uma preferência completa, em vez de montar um cluster heterogêneo a partir de fragmentos disponíveis.

Isso separa as preferências de instância dos clusters heterogêneos do SageMaker. Um cluster heterogêneo executa deliberadamente vários grupos de instâncias em um único job de treinamento. Uma lista de preferência representa alternativas mutuamente exclusivas, das quais apenas uma se torna o ambiente de computação do job.

A distinção protege a consistência da execução. Frameworks de treinamento distribuído geralmente esperam uma topologia conhecida assim que o job começa. Selecionar uma configuração predefinida é mais simples do que misturar dinamicamente arquiteturas de hardware, características de rede e perfis de memória.

A integração com Training Plans acrescenta outra camada de decisão. Uma preferência pode apontar para um plano reservado correspondente, enquanto entradas posteriores usam capacidade sob demanda. A AWS avalia primeiro a opção reservada quando os operadores a colocam em primeiro lugar.

Essa sequência dá às organizações uma forma direta de priorizar capacidade pré-paga sem torná-la a única alternativa do trabalho. Ainda assim, a alternativa de contingência pode mudar o resultado econômico. Uma opção sob demanda pode ter um custo efetivo diferente, e um número maior de nós pode ampliar essa diferença.

O recurso tampouco parece substituir o Managed Spot Training. O Managed Spot Training trata de uma troca diferente ao usar capacidade EC2 Spot interrompível. A AWS afirma que essa abordagem pode reduzir o custo de computação, enquanto interrupções podem prolongar o tempo de conclusão e exigir checkpointing.

As preferências de instância tratam principalmente da seleção inicial de capacidade entre configurações aceitáveis. O treinamento Spot trata do modelo de compra e do risco de interrupção depois que uma carga de trabalho obtém computação. As equipes precisam avaliar essas dimensões separadamente.

O melhor caso de uso é, portanto, um trabalho sensível a reinicializações, mas flexível em hardware. Considere um pipeline noturno de avaliação que pode executar em várias gerações de GPU. Perder sua janela de relatórios pela manhã importa, mas usar o acelerador absolutamente mais rápido não.

A equipe pode certificar várias configurações, ordená-las conforme seu equilíbrio preferido entre tempo de conclusão e despesa esperada, e então definir um período máximo de espera. O SageMaker seleciona dentro desse conjunto testado.

Grandes execuções de pré-treinamento apresentam um caso mais difícil. Seus padrões de comunicação, demandas de memória, comportamento de checkpoint e topologia podem ser ajustados em torno de um único acelerador e interconexão. Uma alternativa nominalmente compatível pode tornar o trabalho mais lento, mais caro ou instável.

O novo agendador não pode decidir se essa alternativa continua sendo cientificamente ou economicamente válida. Esse julgamento permanece com o responsável pela carga de trabalho.

As listas de preferência de instâncias do Amazon SageMaker são, portanto, declarativas, e não adaptativas em sentido amplo. O SageMaker responde a sinais de capacidade, mas não faz benchmark do modelo, reescreve configurações distribuídas nem otimiza a lista em relação a um prazo.

Isso ainda é significativo. Serviços gerenciados criam valor quando retiram de cada cliente uma responsabilidade repetitiva e bem delimitada e a implementam uma vez. A alternativa de capacidade se encaixa nesse padrão, desde que o cliente forneça limites de compatibilidade honestos.

Compatibilidade e Custo Continuam Sendo Responsabilidade do Operador

O risco mais importante não é que o SageMaker escolha a preferência errada; é que uma equipe declare uma preferência insegura como aceitável.

A AWS alerta explicitamente que o SageMaker não valida a compatibilidade entre tipos distintos. O serviço não determina se um contêiner oferece suporte a todas as arquiteturas de GPU, se seus drivers são compatíveis ou se sua configuração distribuída exige rede Elastic Fabric Adapter.

Assim, um trabalho pode passar na validação da solicitação e ainda falhar após o provisionamento. Esse resultado consome tempo de inicialização e pode reduzir o benefício esperado da alternativa automática.

O comportamento dos frameworks merece atenção especial. Recursos de CUDA, bibliotecas de comunicação coletiva, formatos de precisão mista, saídas de compiladores e kernels específicos de dispositivo podem variar entre gerações de aceleradores. Não se deve presumir que um contêiner testado em hardware H100 se comportará de forma idêntica em hardware A100 ou L40S.

A memória é outro limite. Uma carga de trabalho que cabe em um acelerador pode exceder a memória do dispositivo em outro, mesmo quando o throughput teórico agregado parece semelhante. Aumentar o número de nós não resolve automaticamente restrições de memória por dispositivo.

A topologia distribuída também afeta o desempenho. Substituir dois nós de alta largura de banda por quatro nós mais lentos altera o volume de comunicação, a sobrecarga de sincronização e a exposição a falhas. Uma contagem igual de GPUs ou uma estimativa aproximada de computação não garante o mesmo tempo de conclusão.

Os exemplos da AWS ilustram a intenção, e não uma fórmula universal de equivalência. Um exemplo lista duas instâncias ml.g6.48xlarge antes de quatro instâncias ml.g5.48xlarge. O cliente deve decidir se essa relação se mantém para seu modelo, tamanho de lote, padrão de rede e pilha de software.

As equipes devem fazer benchmark de cada configuração listada usando a mesma imagem de contêiner, caminho de dados e launcher distribuído usados em produção. O registro de aprovação resultante deve incluir tempo de execução, verificações de convergência, utilização, taxa de falhas e validação da saída.

A política de custos exige a mesma disciplina. A ordem de preferência expressa prioridade, não um teto de orçamento. Uma alternativa com mais instâncias pode iniciar antes, mas gerar uma fatura total maior do que a opção preferida.

Por outro lado, hardware mais antigo pode executar por mais tempo e eliminar uma aparente economia por instância. A medida relevante é o resultado completo do trabalho, incluindo atraso de inicialização, tempo de execução, novas tentativas, armazenamento e qualquer impacto posterior sobre prazos.

O lançamento também cria uma exigência de observabilidade. As equipes precisam registrar qual preferência venceu, por quanto tempo o trabalho esperou, por que as alternativas foram ordenadas e se o desempenho real correspondeu ao benchmark.

Sem esses registros, a seleção automática se torna opaca. Os engenheiros podem observar maior variação no tempo de execução ou no custo sem saber que a família de instâncias subjacente mudou entre execuções.

As regras de governança talvez também precisem de atualização. A AWS oferece suporte a políticas de identidade que restringem tipos de instância do SageMaker. A lista de preferências aprovada por uma organização precisa permanecer dentro desses controles, das cotas da conta e da disponibilidade regional.

A capacidade reservada introduz outro possível equívoco. Uma preferência do Flexible Training Plan pode oferecer um compromisso de capacidade mais forte, mas uma alternativa não transforma uma reserva indisponível em mais oferta reservada. Ela move o trabalho para um caminho sob demanda separadamente aceitável.

Os trabalhos de processamento precisam de sua própria revisão. Uma alternativa de CPU pode fazer sentido para algumas transformações, mas também pode alterar drasticamente o tempo de conclusão. As equipes devem evitar listar uma opção de CPU apenas porque a API permite.

A ausência de dados de campo publicados é a maior incerteza atual. A AWS descreveu o fluxo de agendamento e as regras de configuração, mas os clientes ainda não dispõem de evidências amplas sobre ganhos no tempo de início sob diferentes condições de escassez.

Medições úteis devem comparar o recurso com a linha de base existente de cada equipe. Isso inclui o tempo entre o envio e a execução, a porcentagem de trabalhos que usam uma alternativa, taxas de timeout, consumo total de computação e incidentes operacionais causados por mudanças de configuração.

Essas medições revelarão se a flexibilidade de capacidade de GPU do SageMaker elimina trabalho operacional real ou apenas desloca a variabilidade para uma camada menos visível.

Três Sinais Mostrarão se o Recurso Funciona na Prática

A adoção deve ser avaliada pelos resultados dos trabalhos, não pela quantidade de equipes que adicionam um segundo tipo de instância à sua configuração.

O primeiro sinal é a frequência de alternativas combinada ao tempo de início. As equipes devem medir com que frequência o SageMaker seleciona qualquer opção abaixo da primeira preferência e como isso altera a latência entre o envio e o início.

Uma alta taxa de alternativas com esperas mais curtas sustentaria a principal alegação da AWS. Isso mostraria que há capacidade disponível no conjunto mais amplo mesmo quando o tipo preferido está limitado.

Uma alta taxa de alternativas sem esperas mais curtas enfraqueceria esse argumento. Isso poderia significar que as alternativas listadas compartilham o mesmo gargalo regional, que os clusters solicitados são grandes demais ou que a fila orientada por eventos não melhora materialmente o atendimento dessa carga de trabalho.

O segundo sinal é a variação de desempenho e custo entre as configurações selecionadas. Cada alternativa deve ser associada ao tempo de execução, utilização, status de conclusão e consumo total de recursos.

Resultados estáveis fortaleceriam o argumento de tratar a infraestrutura como um conjunto de preferências. Grandes desvios mostrariam que as alternativas não eram realmente equivalentes, mesmo que cada configuração pudesse tecnicamente executar o contêiner.

Isso é especialmente importante para pipelines recorrentes. Uma equipe pode aceitar uma execução mais lenta durante um experimento urgente, mas rejeitar imprevisibilidade persistente em uma programação diária de produção.

O terceiro sinal é como a AWS amplia o recurso e sua telemetria associada. Os clientes devem acompanhar eventos de seleção mais detalhados, explicações mais claras sobre o estado de espera, ferramentas de ordenação sensíveis a custo e integração mais ampla com controles de pipeline.

O suporte a políticas mais sofisticadas também seria relevante. Operadores podem eventualmente querer restrições como um prazo, um limite de gastos ou a exigência de que o throughput da alternativa permaneça dentro de uma faixa testada. A lista ordenada atual codifica esses julgamentos manualmente.

As respostas dos concorrentes fornecem contexto de apoio, mas a evidência decisiva virá das operações dos clientes. O Google já trata a escassez de aceleradores como um problema de agendamento por meio do Dynamic Workload Scheduler. O Azure expõe os limites de cota que determinam se trabalhos gerenciados podem executar.

O movimento distintivo da AWS é inserir várias configurações aceitáveis diretamente em uma solicitação de treinamento ou processamento do SageMaker. Se os clientes conseguirem inícios mais rápidos sem variação inaceitável, esse modelo se tornará difícil de ignorar para plataformas gerenciadas de ML.

O teste de curto prazo é simples. Selecione uma carga de trabalho flexível em hardware, faça benchmark de cada configuração candidata e defina um tempo máximo de espera antes de ativar a alternativa automática. Em seguida, compare pelo menos várias execuções com o antigo processo de novas tentativas.

Registre o tipo de instância escolhido, a duração na fila, o tempo de execução, o status de conclusão e o uso total de recursos. Não trate um lançamento bem-sucedido como o resultado completo.

As listas de preferência de instâncias do Amazon SageMaker tornam o tratamento de capacidade menos manual, mas recompensam a preparação. Equipes que validam suas alternativas podem remover código de infraestrutura frágil. Equipes que inserem alternativas especulativas podem apenas automatizar a descoberta de incompatibilidades.

A pergunta útil não é se cinco opções são melhores do que uma. É se sua organização consegue definir cinco resultados genuinamente aceitáveis, classificá-los deliberadamente e medir o que acontece quando o SageMaker escolhe entre eles.