Les listes de préférences d’instances Amazon SageMaker remplacent les nouvelles tentatives manuelles pour les GPU, mais pas la planification des capacités

Amazon a introduit les listes de préférences d’instances Amazon SageMaker, qui permettent à une même demande d’entraînement d’inclure jusqu’à cinq options de calcul ordonnées au lieu d’un unique type d’instance fixe. SageMaker AI examine ces options par ordre de priorité et lance la première configuration disposant de capacités disponibles.

Ce changement s’attaque à un problème opérationnel persistant. Les tâches d’entraînement SageMaker reposant sur des GPU peuvent rester en attente lorsque le matériel demandé n’est pas disponible. Les équipes y ont répondu en surveillant les capacités, en soumettant à nouveau les tâches ou en maintenant des scripts essayant des configurations alternatives.

AWS intègre désormais cette décision de nouvelle tentative dans son ordonnanceur managé. Toutefois, cette fonctionnalité ne crée pas de capacités GPU et ne garantit pas que différents accélérateurs exécuteront correctement une charge de travail. Son intérêt dépend de la capacité des équipes à rendre leur code d’entraînement, leurs objectifs de performance et leurs contrôles de coûts réellement flexibles vis-à-vis du matériel.

Cette distinction met sous pression une pratique cloud bien connue : considérer un type d’instance comme une propriété fixe de chaque tâche. Google Cloud met déjà en file d’attente les demandes d’accélérateurs flexibles via son Dynamic Workload Scheduler. Les utilisateurs d’Azure Machine Learning doivent également planifier autour de quotas de calcul régionaux et propres à chaque famille. AWS fait désormais de la flexibilité matérielle déclarée un élément de premier plan des tâches SageMaker individuelles.

Ce qu’AWS a changé avec les listes de préférences d’instances Amazon SageMaker

Une seule demande SageMaker peut désormais exprimer plusieurs configurations de calcul acceptables sans nécessiter de contrôleur externe de nouvelles tentatives.

AWS a annoncé cette fonctionnalité le 15 septembre 2026 pour les tâches d’entraînement comme de traitement. Elle est disponible via les API SageMaker, les SDK, les outils en ligne de commande et la console dans toutes les régions AWS où SageMaker AI est disponible, selon l’avis de disponibilité régionale de l’entreprise.

Une liste de préférences contient entre deux et cinq types d’instances classés par ordre de priorité. SageMaker valide la liste, effectue un balayage en mémoire et sélectionne la première configuration disposant de capacités disponibles. Une seule des configurations répertoriées exécute la tâche.

Si aucune n’est immédiatement disponible, la tâche entre dans une file d’attente pilotée par les événements. SageMaker réessaie à mesure que les capacités évoluent, sans obliger un processus client à interroger le service et à soumettre de nouveau les demandes. La durée totale d’attente peut être limitée avec MaxPendingTimeInSeconds.

Ce délai s’applique à l’ensemble de la liste de préférences, et non séparément à chaque option. AWS précise également qu’il ne prend effet que lorsqu’au moins une configuration répertoriée utilise du calcul accéléré issu de familles telles que ml.p, ml.g ou ml.trn.

Ce comportement importe, car une préférence représente plus qu’un nom d’instance alternatif. Les équipes peuvent attribuer un nombre d’instances différent à chaque option. Une tâche peut préférer deux nœuds ml.g6.48xlarge, mais accepter quatre nœuds ml.g5.48xlarge lorsque cette seconde configuration fournit un débit global suffisant.

AWS autorise deux modèles de comptage. Un ResourceConfig.InstanceCount partagé peut s’appliquer à toutes les préférences, ou chaque préférence peut définir son propre nombre. Mélanger ces approches n’est pas valide, comme l’explique la référence d’API.

La fonctionnalité se connecte également aux SageMaker Flexible Training Plans, qui réservent des capacités GPU prises en charge pour une période définie. Une tâche d’entraînement peut placer en premier une configuration correspondante reposant sur un plan, puis répertorier des alternatives à la demande. Si l’option réservée ne peut pas être provisionnée, SageMaker passe aux préférences restantes.

Cette intégration est limitée à l’entraînement. Les tâches de traitement bénéficient du même mécanisme de repli ordonné, mais elles ne peuvent pas associer leurs préférences à des Flexible Training Plans.

Le cas d’usage du traitement reste significatif. SageMaker Processing exécute une infrastructure managée pour la préparation des données, l’ingénierie des variables, l’évaluation et les travaux connexes. Ces tâches tolèrent souvent une gamme matérielle plus large que les tâches d’entraînement distribué étroitement optimisées.

AWS présente ce changement comme une alternative aux boucles de nouvelles tentatives manuelles et aux scripts de surveillance des capacités dans son article de lancement. C’est l’avantage immédiat le plus clair. Un pipeline soumet une seule tâche, tandis que SageMaker prend en charge la recherche de capacité dans les limites déclarées.

L’ordonnanceur ne choisit pas une machine arbitraire qu’il considère comme équivalente. Il suit l’ordre défini par le client. Cela préserve une répartition utile des responsabilités : les opérateurs décident quelles configurations sont valides, et SageMaker détermine quelle option valide peut démarrer en premier.

Il s’agit d’une petite évolution de l’API aux conséquences opérationnelles plus larges. La flexibilité de l’infrastructure peut désormais accompagner la définition de la tâche au lieu de résider dans le code d’orchestration environnant.

Pourquoi la capacité GPU de SageMaker est devenue un problème d’ordonnancement

La ressource rare n’est plus seulement un GPU ; c’est la bonne configuration de cluster dans la bonne région, au bon moment.

Les équipes d’entraînement IA parlent souvent des accélérateurs comme d’unités interchangeables, mais les capacités cloud sont réparties entre familles d’instances, tailles, régions, pools de disponibilité, quotas et modèles de réservation. Un client peut être autorisé à demander une machine sans que celle-ci soit prête à être allouée immédiatement.

Cette fragmentation crée une gestion des échecs inconfortable. Un pipeline peut être techniquement correct tout en perdant des heures parce que sa configuration sélectionnée ne peut pas démarrer. Un ingénieur doit alors décider s’il faut attendre, changer de matériel, modifier le nombre de nœuds ou déplacer la charge de travail.

Avant les listes de préférences, les tâches d’entraînement SageMaker indiquaient un seul type d’instance lors de leur soumission. Les équipes qui acceptaient des alternatives devaient encoder cette flexibilité ailleurs. Certaines ont construit des fonctions de nouvelle tentative autour des échecs d’API. D’autres soumettaient plusieurs variantes et annulaient les perdantes après le démarrage de l’une d’entre elles.

Ces deux modèles introduisent du travail de coordination. Plusieurs demandes actives peuvent compliquer l’observabilité et les annulations. Les scripts de nouvelles tentatives séquentielles nécessitent une gestion d’état, des règles de temporisation progressive, la gestion des délais d’expiration, des autorisations et une protection contre les exécutions en double.

La surveillance des capacités devient elle aussi un système de production supplémentaire. L’équipe doit le maintenir lorsque le comportement des SDK évolue, exposer ses défaillances et s’assurer qu’un contrôleur redémarré ne lance pas deux fois la même tâche coûteuse.

Les listes de préférences d’instances Amazon SageMaker absorbent une partie de ce plan de contrôle. La demande de tâche transporte un ensemble limité de résultats acceptables, et le service managé effectue la sélection une fois que de la capacité est trouvée.

Ce modèle reflète le comportement de nombreuses charges de travail réelles. L’ajustement fin, l’évaluation, le prétraitement et l’expérimentation de modèles disposent souvent d’une configuration préférée plutôt que d’une seule configuration mathématiquement obligatoire. Une équipe peut privilégier des GPU récents pour leur vitesse, mais accepter des GPU plus anciens lorsque le délai de démarrage compte davantage.

Le même principe s’applique au nombre de nœuds. Deux nœuds plus rapides et quatre nœuds plus lents peuvent parfois atteindre un objectif de fin d’exécution similaire. Ils ne sont pas intrinsèquement équivalents, mais les développeurs peuvent les tester et déclarer les deux acceptables.

AWS n’est pas la seule entreprise à transformer la rareté en interface d’ordonnancement. Le mode Flex-start de Google Cloud met les demandes d’accélérateurs en file d’attente jusqu’à ce que toutes les ressources requises deviennent disponibles. Google le positionne pour les tâches d’entraînement pouvant tolérer une heure de démarrage flexible.

Les mécanismes diffèrent. Le modèle de Google met l’accent sur la fourniture d’une allocation d’accélérateurs et d’une durée demandées. AWS permet à une tâche SageMaker de parcourir un ensemble ordonné de types et de nombres d’instances. Les deux approches demandent aux clients d’exprimer leur flexibilité au lieu de sonder à répétition les capacités.

Azure Machine Learning expose une autre partie de la contrainte. Ses quotas de calcul sont gérés par région et par famille de VM, avec des limites distinctes pour l’utilisation de l’espace de travail et de l’abonnement. Les familles GPU peuvent démarrer sans quota par défaut de cœurs dédiés, selon l’abonnement.

Ces systèmes montrent pourquoi la disponibilité des accélérateurs ne peut pas être réduite à une page de catalogue. Une instance répertoriée peut être prise en charge, tout en restant indisponible pour un compte, un emplacement, une taille de tâche ou une fenêtre temporelle donnés.

Pour les clients AWS, la pression immédiate s’exerce sur les équipes qui maintiennent une logique de provisionnement personnalisée. Si un service de nouvelles tentatives ne fait que parcourir les types d’instances SageMaker, sa fonction centrale recoupe désormais celle de la plateforme.

La fonctionnalité met également sous pression les normes internes rigides qui n’approuvent qu’un seul type d’instance par modèle. Ces normes simplifiaient les analyses comparatives et la gouvernance, mais elles transforment chaque pénurie de capacité en blocage. Les équipes ont désormais une raison de certifier plusieurs configurations pour chaque charge de travail.

Cela n’élimine pas l’orchestration. Les pipelines ont toujours besoin de dépendances, de suivi des artefacts, de politiques d’échec et de validation après exécution. Le changement réduit le rôle de l’orchestration en déplaçant une décision récurrente — quelle configuration acceptable peut démarrer — dans SageMaker lui-même.

La flexibilité remplace la logique de nouvelles tentatives, pas les contraintes de capacité

Le mécanisme améliore la recherche d’infrastructure disponible, mais il ne peut pas fournir une infrastructure qui n’existe pas.

Lorsqu’une tâche arrive, SageMaker valide sa configuration et sa liste de préférences par rapport aux ressources et limites prises en charge. L’ordonnanceur vérifie ensuite les options une fois, dans l’ordre déclaré. La première option disponible l’emporte et commence à être provisionnée.

Si toutes les options sont indisponibles, la file d’attente pilotée par les événements attend un changement de capacité pertinent. Cette approche est plus efficace qu’une interrogation continue par le client, mais il s’agit toujours d’une file d’attente. Une tâche peut rester en attente jusqu’à l’expiration de son délai.

Cette limite importe pour évaluer l’affirmation d’AWS selon laquelle la fonctionnalité aide les tâches à démarrer plus rapidement. La comparaison porte sur une tâche verrouillée sur une configuration indisponible ou sur un système de nouvelles tentatives géré par le client, plus lent. AWS n’a pas publié de benchmarks indépendants montrant des améliorations médianes du temps de démarrage selon les régions, les familles d’instances ou les tailles de cluster.

Une liste ne combine pas non plus des capacités partielles issues de plusieurs entrées. Si une préférence demande huit nœuds, SageMaker doit pouvoir provisionner cette configuration sélectionnée. Le système choisit une préférence complète plutôt que d’assembler un cluster hétérogène à partir de fragments disponibles.

Cela distingue les préférences d’instances des clusters hétérogènes SageMaker. Un cluster hétérogène exécute délibérément plusieurs groupes d’instances au sein d’une même tâche d’entraînement. Une liste de préférences représente des alternatives mutuellement exclusives, dont une seule devient l’environnement de calcul de la tâche.

Cette distinction protège la cohérence de l’exécution. Les frameworks d’entraînement distribué attendent généralement une topologie connue une fois la tâche démarrée. Sélectionner une configuration prédéfinie est plus simple que de mélanger dynamiquement des architectures matérielles, des caractéristiques réseau et des profils de mémoire.

L’intégration aux Training Plans ajoute une couche de décision supplémentaire. Une préférence peut pointer vers un plan réservé correspondant, tandis que les entrées suivantes utilisent une capacité à la demande. AWS évalue d’abord l’option réservée lorsque les opérateurs la placent en première position.

Cette séquence donne aux organisations un moyen direct de privilégier la capacité prépayée sans en faire la seule voie d’exécution du job. Toutefois, le repli peut modifier le résultat économique. Une solution à la demande peut présenter un coût effectif différent, et un plus grand nombre de nœuds peut amplifier cet écart.

La fonctionnalité ne semble pas non plus remplacer Managed Spot Training. Managed Spot Training répond à un autre compromis en utilisant de la capacité EC2 Spot interruptible. AWS indique que cette approche peut réduire le coût de calcul, mais que les interruptions peuvent allonger le délai d’achèvement et nécessiter la mise en place de points de contrôle.

Les préférences d’instances traitent avant tout de la sélection initiale de capacité parmi des configurations acceptables. L’entraînement Spot concerne le modèle d’achat et le risque d’interruption une fois qu’une charge de travail a obtenu des ressources de calcul. Les équipes doivent évaluer ces dimensions séparément.

Le meilleur cas d’usage est donc un job sensible aux redémarrages, mais flexible sur le plan matériel. Prenons un pipeline d’évaluation nocturne pouvant s’exécuter sur plusieurs générations de GPU. Manquer la fenêtre de reporting matinale est problématique, mais utiliser l’accélérateur absolument le plus rapide ne l’est pas.

L’équipe peut certifier plusieurs configurations, les classer selon l’équilibre qu’elle privilégie entre délai d’achèvement et dépense attendue, puis définir une durée maximale d’attente. SageMaker sélectionne alors au sein de ce périmètre testé.

Les grands entraînements de préapprentissage présentent un cas plus difficile. Leurs schémas de communication, exigences mémoire, comportements de checkpointing et topologies peuvent être optimisés autour d’un accélérateur et d’une interconnexion spécifiques. Un repli nominalement pris en charge pourrait rendre le job plus lent, plus coûteux ou instable.

Le nouveau planificateur ne peut pas déterminer si ce repli demeure scientifiquement ou économiquement valable. Ce jugement reste du ressort du propriétaire de la charge de travail.

Les listes de préférences d’instances Amazon SageMaker sont donc déclaratives, et non adaptatives au sens large. SageMaker réagit aux signaux de capacité, mais ne benchmarke pas le modèle, ne réécrit pas les paramètres distribués et n’optimise pas la liste en fonction d’une échéance.

Cela reste important. Les services managés créent de la valeur lorsqu’ils retirent à chaque client une responsabilité répétitive et clairement circonscrite pour l’implémenter une seule fois. Le repli de capacité correspond à ce modèle, à condition que le client fournisse des limites de compatibilité réalistes.

La compatibilité et le coût restent la responsabilité de l’opérateur

Le risque principal n’est pas que SageMaker choisisse la mauvaise préférence ; c’est qu’une équipe déclare acceptable une préférence qui ne l’est pas.

AWS avertit explicitement que SageMaker ne valide pas la compatibilité entre types d’instances. Le service ne détermine pas si un conteneur prend en charge chaque architecture GPU, si ses pilotes sont compatibles ou si sa configuration distribuée exige le réseau Elastic Fabric Adapter.

Un job peut donc passer la validation de la requête tout en échouant après le provisionnement. Ce résultat consomme du temps de démarrage et peut réduire le bénéfice attendu du repli automatique.

Le comportement des frameworks mérite une attention particulière. Les capacités CUDA, les bibliothèques de communication collective, les formats de précision mixte, les sorties de compilateurs et les kernels spécifiques aux appareils peuvent varier d’une génération d’accélérateurs à l’autre. Il ne faut pas supposer qu’un conteneur testé sur du matériel H100 se comportera de manière identique sur du matériel A100 ou L40S.

La mémoire constitue une autre limite. Une charge de travail qui tient sur un accélérateur peut dépasser la mémoire de l’appareil sur un autre, même lorsque le débit théorique global semble similaire. Augmenter le nombre de nœuds ne résout pas automatiquement les contraintes de mémoire par appareil.

La topologie distribuée affecte aussi les performances. Remplacer deux nœuds à large bande passante par quatre nœuds plus lents modifie le volume de communication, la surcharge de synchronisation et l’exposition aux défaillances. Un nombre équivalent de GPU ou une estimation approximative de calcul ne garantissent pas un délai d’achèvement équivalent.

Les exemples d’AWS illustrent une intention plutôt qu’une formule d’équivalence universelle. Un exemple répertorie deux instances ml.g6.48xlarge avant quatre instances ml.g5.48xlarge. Le client doit déterminer si cette relation reste valable pour son modèle, sa taille de lot, son schéma réseau et sa pile logicielle.

Les équipes devraient benchmarker chaque configuration répertoriée avec la même image de conteneur, le même chemin de données et le même lanceur distribué que ceux utilisés en production. Le dossier d’approbation qui en résulte devrait inclure le temps d’exécution, les contrôles de convergence, l’utilisation, le taux d’échec et la validation des sorties.

La politique de coût exige la même rigueur. L’ordre de préférence exprime une priorité, pas un plafond budgétaire. Un repli utilisant davantage d’instances peut démarrer plus tôt tout en générant une facture totale plus élevée que l’option privilégiée.

À l’inverse, un matériel plus ancien peut fonctionner plus longtemps et annuler une économie apparente par instance. La mesure pertinente est le résultat complet du job, y compris le délai de démarrage, le temps d’exécution, les nouvelles tentatives, le stockage et tout impact en aval sur les échéances.

Ce lancement crée également une exigence en matière d’observabilité. Les équipes doivent enregistrer quelle préférence a été retenue, combien de temps le job a attendu, pourquoi les alternatives ont été ordonnées ainsi, et si les performances réelles correspondaient au benchmark.

Sans ces données, la sélection automatique devient opaque. Les ingénieurs peuvent constater une plus grande variabilité du temps d’exécution ou du coût sans savoir que la famille d’instances sous-jacente a changé entre deux exécutions.

Les règles de gouvernance devront peut-être également être mises à jour. AWS prend en charge des politiques d’identité qui limitent les types d’instances SageMaker. La liste de préférences approuvée d’une organisation doit rester conforme à ces contrôles, aux quotas de compte et à la disponibilité régionale.

La capacité réservée introduit une autre confusion potentielle. Une préférence Flexible Training Plan peut offrir un engagement de capacité plus fort, mais un repli ne transforme pas une réservation indisponible en davantage d’approvisionnement réservé. Il déplace le job vers une voie à la demande distincte mais acceptable.

Les jobs de traitement nécessitent leur propre examen. Un repli vers le CPU peut avoir du sens pour certaines transformations, mais il peut aussi modifier radicalement le délai d’achèvement. Les équipes devraient éviter de répertorier une option CPU simplement parce que l’API l’autorise.

L’absence de données de terrain publiées constitue aujourd’hui la plus grande incertitude. AWS a décrit le flux de planification et les règles de configuration, mais les clients ne disposent pas encore de preuves étendues concernant les gains de temps de démarrage dans diverses conditions de pénurie.

Les mesures utiles devraient comparer cette fonctionnalité à la référence existante de chaque équipe. Elles incluent le délai entre la soumission et l’exécution, le pourcentage de jobs utilisant un repli, les taux de timeout, la consommation totale de calcul et les incidents opérationnels causés par les changements de configuration.

Ces mesures révéleront si la flexibilité de capacité GPU de SageMaker élimine une véritable charge opérationnelle ou si elle déplace simplement la variabilité vers une couche moins visible.

Trois signaux montreront si la fonctionnalité fonctionne en pratique

L’adoption devrait être évaluée selon les résultats des jobs, et non selon le nombre d’équipes ajoutant un second type d’instance à leur configuration.

Le premier signal est la fréquence des replis associée au temps de démarrage. Les équipes devraient mesurer à quelle fréquence SageMaker sélectionne une option autre que la première préférence et comment cela modifie la latence entre soumission et démarrage.

Un taux élevé de replis associé à des attentes plus courtes étayerait l’affirmation centrale d’AWS. Cela montrerait que la capacité existe dans un pool plus large, même lorsque le type privilégié est contraint.

Un taux élevé de replis sans réduction des délais d’attente affaiblirait cet argument. Cela pourrait signifier que les alternatives répertoriées partagent le même goulot d’étranglement régional, que les clusters demandés sont trop grands, ou que la file pilotée par événements n’améliore pas matériellement le provisionnement pour cette charge de travail.

Le deuxième signal est la variabilité des performances et des coûts entre les configurations sélectionnées. Chaque repli devrait être associé au temps d’exécution, à l’utilisation, au statut d’achèvement et à la consommation totale de ressources.

Des résultats stables renforceraient l’argument en faveur du traitement de l’infrastructure comme un ensemble de préférences. De grands écarts montreraient que les alternatives n’étaient pas réellement équivalentes, même si chaque configuration pouvait techniquement exécuter le conteneur.

C’est particulièrement important pour les pipelines récurrents. Une équipe peut accepter une exécution plus lente lors d’une expérience urgente, mais refuser une imprévisibilité persistante dans un calendrier de production quotidien.

Le troisième signal est la manière dont AWS élargit la fonctionnalité et sa télémétrie associée. Les clients devraient surveiller l’apparition d’événements de sélection plus riches, d’explications plus claires des états en attente, d’outils d’ordonnancement tenant compte des coûts et d’une intégration plus large aux contrôles de pipelines.

La prise en charge de politiques plus nuancées serait également importante. Les opérateurs pourraient à terme souhaiter des contraintes telles qu’une échéance, une limite de dépense ou l’exigence que le débit du repli reste dans une plage testée. La liste ordonnée actuelle encode ces jugements manuellement.

Les réactions des concurrents apportent un contexte utile, mais les preuves décisives viendront des opérations clients. Google traite déjà la rareté des accélérateurs comme un problème de planification grâce à Dynamic Workload Scheduler. Azure expose les limites de quota qui déterminent si les jobs managés peuvent s’exécuter.

La démarche distinctive d’AWS consiste à placer plusieurs configurations acceptables directement dans une requête d’entraînement ou de traitement SageMaker. Si les clients obtiennent des démarrages plus rapides sans variabilité inacceptable, ce modèle deviendra difficile à ignorer pour les plateformes ML managées.

Le test à court terme est simple. Sélectionnez une charge de travail flexible sur le plan matériel, benchmarkez chaque configuration candidate et définissez une durée maximale d’attente avant d’activer le repli automatique. Comparez ensuite au moins plusieurs exécutions avec l’ancien processus de nouvelle tentative.

Enregistrez le type d’instance choisi, la durée dans la file d’attente, le temps d’exécution, le statut d’achèvement et l’utilisation totale des ressources. Ne considérez pas qu’un lancement réussi constitue le résultat complet.

Les listes de préférences d’instances Amazon SageMaker rendent la gestion de capacité moins manuelle, mais elles récompensent la préparation. Les équipes qui valident leurs alternatives peuvent éliminer du code d’infrastructure fragile. Celles qui saisissent des replis spéculatifs risquent seulement d’automatiser la découverte d’incompatibilités.

La question utile n’est pas de savoir si cinq options sont meilleures qu’une. Elle est de savoir si votre organisation peut définir cinq résultats véritablement acceptables, les classer délibérément et mesurer ce qui se produit lorsque SageMaker choisit parmi eux.