Meilleures pratiques pour Amazon SageMaker Training Managed Warm Pools

Amazon SageMaker Training Managed Warm Pools vous offre la possibilité de choisir de réutiliser et de conserver l'infrastructure sous-jacente pendant une période définie par l'utilisateur. Ceci est fait tout en conservant l'avantage de transmettre le gros du travail indifférencié de la gestion des instances de calcul à Formation sur le modèle Amazon SageMaker. Dans cet article, nous décrivons les principaux avantages et les points faibles traités par SageMaker Training Managed Warm Pools, ainsi que les références et les meilleures pratiques.

Présentation des piscines chaudes gérées par la formation SageMaker

SageMaker Model Training est une fonctionnalité entièrement gérée qui lance des instances pour chaque travail, forme un modèle, exécute puis ralentit les instances après le travail. Vous n'êtes facturé que pour la durée du travail à la seconde près. Cette capacité entièrement gérée vous donne la liberté de vous concentrer sur votre algorithme d'apprentissage automatique (ML) et de ne pas vous soucier de charges lourdes indifférenciées comme la gestion de l'infrastructure lors de la formation de vos modèles.

Ce mécanisme nécessite un temps de démarrage fini pour une tâche d'apprentissage. Bien que ce temps de démarrage, également appelé temps de démarrage à froid, est assez faible, certains de nos cas d'utilisation client les plus exigeants nécessitent des temps de démarrage encore plus courts, comme moins de 20 secondes. Il existe deux cas d'utilisation importants qui ont ces exigences :

• Le premier est l'expérimentation active de ML par des data scientists utilisant le Amazon Sage Maker plate-forme de formation, en particulier lors de la formation de grands modèles, comme GPT3, qui nécessitent plusieurs itérations pour arriver à un état prêt pour la production.
• Le second est le lancement programmatique d'un grand nombre (de l'ordre de plusieurs centaines ou milliers) de jobs consécutifs sur le même type d'instances à une cadence planifiée. Par exemple, la recherche de paramètres ou la formation incrémentale.

Pour de tels cas d'utilisation, chaque seconde consacrée aux frais généraux, comme le temps de démarrage d'une tâche de formation, a un effet cumulatif sur toutes ces tâches.

Avec SageMaker Training Managed Warm Pools, les scientifiques des données et les ingénieurs ML ont la possibilité de choisir de maintenir les instances de formation SageMaker ou les clusters multi-instances au chaud pendant une durée prédéfinie et reconfigurable (keep_alive_period_in_seconds) après la fin de chaque tâche d'entraînement. Ainsi, même si vous encourez une pénalité de démarrage à froid pour la première tâche d'entraînement exécutée sur une instance ou un cluster, pour toutes les tâches d'entraînement suivantes, les instances sont déjà opérationnelles. Par conséquent, ces tâches d'entraînement ultérieures qui démarrent sur une instance avant la keep_alive_period_in_seconds expire n'entraîne pas la surcharge de temps de démarrage à froid. Cela peut réduire les temps de démarrage des tâches de formation à environ moins de 20 secondes (P90).

Les data scientists et les ingénieurs ML peuvent utiliser SageMaker Training Managed Warm Pools pour maintenir au chaud une ou plusieurs instances entre les exécutions de formation à des fins d'expérimentation ou exécuter plusieurs tâches consécutivement sur le même cluster à une ou plusieurs instances. Vous ne payez que la durée des emplois de formation et les reconfigurables keep_alive_period_in_seconds comme partout ailleurs, vous spécifiez pour chaque instance.

Essentiellement, avec SageMaker Training Managed Warm Pools, vous obtenez une combinaison de l'utilisation des instances gérées SageMaker avec la possibilité d'accepter et de provisionner la capacité et d'autogérer l'utilisation pendant de courts intervalles de temps. Ces intervalles sont configurables avant une tâche, mais si pendant la keep_alive_period_in_seconds intervalle, vous devez le réduire ou l'augmenter, vous pouvez le faire. Augmente à keep_alive_period_in_seconds peut être effectué à des intervalles allant jusqu'à 60 minutes, avec une période maximale pour une instance ou un cluster de 7 jours.

Pour commencer avec les piscines chaudes, commencez par demander une augmentation de la limite de quota du pool chaud, puis spécifiez le keep_alive_period_in_seconds paramètre lors du démarrage d'un travail de formation.

Repères

Nous avons effectué des tests d'analyse comparative pour mesurer la latence de démarrage des tâches à l'aide d'une image TensorFlow de 1.34 Go, de 2 Go de données et de différents modes d'entrée de données de formation (Amazon FSx, Fast File Mode, File Mode). Les tests ont été exécutés sur divers types d'instances des familles m4, c4, m5 et c5 dans la région us-east-2. La latence de démarrage a été mesurée comme le temps entre la création de la tâche et le début de la tâche de formation réelle sur les instances. Les premières tâches qui ont démarré le cluster et créé le pool tiède avaient une latence de démarrage de 2 à 3 minutes. Cette latence plus élevée est due au temps nécessaire pour provisionner l'infrastructure, télécharger l'image et télécharger les données. Les tâches consécutives qui utilisaient le cluster de pool tiède avaient une latence de démarrage d'environ 20 secondes pour le mode de fichier rapide (FFM) ou Amazon FSx, et de 70 secondes pour le mode de fichier (FM). Ce delta résulte du fait que FM exige que l'intégralité de l'ensemble de données soit téléchargé depuis Amazon S3 avant le début de la tâche.

Votre choix de mode de saisie des données d'entraînement affecte le temps de démarrage, même avec Warm Pools. Des conseils sur le mode de saisie à sélectionner se trouvent dans la section des meilleures pratiques plus loin dans cet article.

Le tableau suivant résume la latence de démarrage du travail P90 pour différents modes d'entrée de données d'apprentissage.

Mode d'entrée de données	Latence de démarrage P90 (secondes)
	Premier travail	Emplois Warm Pool (deuxième emploi et suivants)
FSx	136	19
Mode fichier rapide	143	21
Mode fichier	176	70

Meilleures pratiques pour l'utilisation des piscines chaudes

Dans la section suivante, nous partageons quelques bonnes pratiques lors de l'utilisation des piscines chaudes.

Quand utiliser les piscines chaudes ?

Les piscines chaudes sont recommandées dans les scénarios suivants :

• Vous expérimentez et ajustez votre script de manière interactive sur une série de tâches courtes.
• Vous exécutez votre propre optimisation d'hyperparamètres à grande échelle sur mesure (par exemple, Synchronisation).
• Vous avez un traitement par lots qui exécute un grand nombre (de l'ordre de plusieurs centaines ou milliers) de tâches consécutives sur le même type d'instances à une cadence quotidienne ou hebdomadaire. Par exemple, former un modèle ML par ville.

Les pools chauds ne sont pas recommandés lorsqu'il est peu probable que quelqu'un réutilise le pool chaud avant son expiration. Par exemple, un seul travail long qui s'exécute via un pipeline ML automatisé.

Minimiser la latence de démarrage des tâches de formation en pool chaud

Les tâches de formation qui réutilisent un pool tiède démarrent plus rapidement que la première tâche qui a créé le pool tiède. Cela est dû au fait que les instances ML continuent de s'exécuter entre les tâches avec une image Docker de conteneur de formation en cache pour éviter d'extraire le conteneur de Registre des conteneurs élastiques Amazon (Amazon ECR). Cependant, même lors de la réutilisation d'un pool tiède, certaines étapes d'initialisation se produisent pour tous les travaux. L'optimisation de ces étapes peut réduire le temps de démarrage de votre travail (à la fois le premier travail et les travaux suivants). Considérer ce qui suit:

• Le mode de saisie des données d'entraînement peut affecter le temps de démarrage – Les canaux d'entrée des données de formation gérées sont recréés pour chaque tâche de formation, ce qui contribue à la latence de démarrage de la tâche. Ainsi, faire des expériences initiales sur un ensemble de données plus petit permettra un temps de démarrage plus rapide (et un temps de formation plus rapide). Pour les étapes ultérieures de l'expérimentation, lorsqu'un ensemble de données volumineux est nécessaire, envisagez d'utiliser un type de mode d'entrée qui a un temps d'initialisation minimal ou fixe. Par exemple, le mode d'entrée FILE copie l'intégralité de l'ensemble de données à partir de Service de stockage simple Amazon (Amazon S3) à l'instance de formation, ce qui prend du temps pour les grands ensembles de données (même avec des pools tièdes). Le mode de fichier rapide est mieux adapté pour une latence de démarrage plus faible, car seules les métadonnées d'objet S3 doivent être lues à partir d'Amazon S3 avant que la charge de travail puisse démarrer. Le Amazon FSx pour Lustreou Système de fichiers Amazon Elastic (Amazon EFS) mode d'entrée du système de fichiers, a un temps d'initialisation fixe quel que soit le nombre de fichiers dans le système de fichiers, ce qui est avantageux lorsque vous travaillez avec un grand ensemble de données.
  Pour plus d'informations sur le choix d'un canal d'entrée, voir Choisissez la meilleure source de données pour votre tâche de formation Amazon SageMaker.
• Réduire l'installation des packages pendant l'exécution – Toute installation de logiciel qui a lieu pendant le démarrage du conteneur, par exemple, le pip de Python ou le système d'exploitation apt-get, augmentera la latence des tâches de formation. Minimiser cette latence de démarrage nécessite de faire un compromis entre la flexibilité et la simplicité des installations d'exécution par rapport à l'installation au moment de la construction du conteneur. Si vous utilisez votre propre conteneur Docker avec SageMaker, reportez-vous à Adaptation de votre propre conteneur Docker pour fonctionner avec SageMaker. Si vous comptez sur images de conteneur SageMaker prédéfinies, vous aurez besoin de étendre un conteneur prédéfini et gérer explicitement ces conteneurs. Considérez ceci si vos installations d'exécution augmentent considérablement la latence de démarrage.
• Évitez de mettre à jour fréquemment votre image Docker – Si vous utilisez votre propre conteneur Docker avec SageMaker, essayez d'éviter de le mettre à jour à chaque exécution de tâche. Si l'image Docker change entre les soumissions de tâches, le pool tiède sera réutilisé, mais le processus de démarrage devra extraire à nouveau l'image de conteneur d'Amazon ECR au lieu de réutiliser une image de conteneur mise en cache. Si l'image Docker doit être mise à jour, limitez les mises à jour à la dernière couche Docker pour tirer parti de la mise en cache de la couche Docker. Idéalement, vous devriez supprimer le contenu Dockerfile qui est susceptible de changer au fil des itérations, comme l'hyperparamètre, les définitions d'ensembles de données et le code ML lui-même. Pour itérer sur le code ML sans avoir à reconstruire les images Docker à chaque modification, vous pouvez adopter le paradigme de conteneur de framework préconisé dans la boîte à outils de formation SageMaker. Si vous souhaitez développer un conteneur de framework avec votre propre code, reportez-vous à ceci Tutoriel Amazon SageMaker.

Partager des piscines chaudes entre plusieurs utilisateurs

Lorsque vous travaillez avec une grande équipe de scientifiques des données, vous pouvez partager des pools chauds qui ont correspondant aux critères de l'emploi, comme le même Gestion des identités et des accès AWS (IAM) rôle ou image de conteneur.

Regardons un exemple de chronologie. L'utilisateur 1 démarre une tâche d'entraînement qui se termine et entraîne la création d'un nouveau pool chaud. Lorsque l'utilisateur 2 démarre une tâche d'entraînement, la tâche réutilise le pool chaud existant, ce qui entraîne un démarrage rapide de la tâche. Pendant que la tâche de l'utilisateur 2 est en cours d'exécution avec le pool tiède utilisé, si un autre utilisateur démarre une tâche d'entraînement, un deuxième pool tiède sera créé.

Ce comportement de réutilisation permet de réduire les coûts en partageant des pools chauds entre les utilisateurs qui démarrent des tâches similaires. Si vous souhaitez éviter de partager des pools chauds entre les utilisateurs, les travaux des utilisateurs ne doivent pas avoir correspondant aux critères de l'emploi (par exemple, ils doivent utiliser un rôle IAM différent).

Avertir les utilisateurs à la fin du travail

Lorsque vous utilisez des pools chauds à des fins d'expérimentation, nous vous recommandons d'avertir les utilisateurs lorsque leur tâche est terminée. Cela permet aux utilisateurs de reprendre l'expérimentation avant l'expiration du pool chaud ou Arrêtez la piscine chaude si elle n'est plus nécessaire. Vous pouvez également déclencher automatiquement des notifications à travers Amazon Event Bridge.

Autres outils pour des travaux de formation rapides d'expérimentation et de dépannage

Avec les piscines chaudes, vous pouvez démarrer une tâche en moins de 20 secondes. Certains scénarios nécessitent une expérimentation et un dépannage interactifs et pratiques en temps réel. L'open-source Bibliothèque SageMaker SSH Helper vous permet d'intégrer un conteneur de formation SageMaker et d'effectuer un développement et un débogage à distance.

Conclusion

Avec SageMaker Training Managed Warm Pools, vous pouvez garder vos instances de matériel de formation de modèle au chaud après chaque tâche pendant une période spécifiée. Cela peut réduire jusqu'à 8 fois la latence de démarrage d'une tâche d'entraînement de modèle. Les pools tièdes gérés SageMaker Training sont disponibles dans toutes les régions AWS publiques où SageMaker Model Training est disponible.

Pour commencer, consultez Entraînement à l'aide des pools chauds gérés par SageMaker.

---

À propos des auteurs

Dr Romi Datta  est un responsable principal de la gestion des produits au sein de l'équipe Amazon SageMaker responsable de la formation, du traitement et du magasin de fonctionnalités. Il travaille chez AWS depuis plus de 4 ans, occupant plusieurs postes de direction dans la gestion des produits dans SageMaker, S3 et IoT. Avant AWS, il a occupé divers postes de gestion de produits, d'ingénierie et de leadership opérationnel chez IBM, Texas Instruments et Nvidia. Il a une maîtrise et un doctorat. en génie électrique et informatique de l'Université du Texas à Austin et un MBA de la Booth School of Business de l'Université de Chicago.

Arun Nagarajan est ingénieur principal au sein de l'équipe Amazon SageMaker et se concentre sur les domaines de la formation et des MLOps. Il fait partie de l'équipe SageMaker depuis l'année de lancement et a aimé contribuer à différents domaines de SageMaker, notamment l'inférence en temps réel et les produits Model Monitor. Il aime explorer le plein air dans la région du nord-ouest du Pacifique et escalader des montagnes.

Amy vous est responsable du développement logiciel chez AWS SageMaker. Elle se concentre sur la réunion d'une équipe d'ingénieurs logiciels pour créer, maintenir et développer de nouvelles fonctionnalités de la plate-forme de formation SageMaker qui aide les clients à former leurs modèles ML plus efficacement et plus facilement. Elle a une passion pour la technologie ML et AI, en particulier liée à l'image et à la vision de ses études supérieures. Dans ses temps libres, elle aime travailler sur la musique et l'art avec sa famille.

Sifei Li est ingénieur logiciel chez Amazon AI où elle travaille à la création de plates-formes Amazon Machine Learning et faisait partie de l'équipe de lancement d'Amazon SageMaker. Dans ses temps libres, elle aime jouer de la musique et lire.

Jenna Zhao est ingénieur en développement logiciel chez AWS SageMaker. Elle est passionnée par la technologie ML/AI et s'est concentrée sur la création de la plate-forme de formation SageMaker qui permet aux clients de former rapidement et facilement des modèles d'apprentissage automatique. En dehors du travail, elle aime voyager et passer du temps avec sa famille.

Paras Mehra est chef de produit senior chez AWS. Il se concentre sur l'aide à la création de la formation et du traitement Amazon SageMaker. Dans ses temps libres, Paras aime passer du temps avec sa famille et faire du vélo de route dans la Bay Area. Vous pouvez le retrouver sur LinkedIn.

Gili Nachoum est un architecte de solutions spécialisé AI/ML senior qui travaille au sein de l'équipe EMEA Amazon Machine Learning. Gili est passionnée par les défis de la formation de modèles d'apprentissage en profondeur et par la façon dont l'apprentissage automatique change le monde tel que nous le connaissons. Dans ses temps libres, Gili aime jouer au tennis de table.

Olivier Cruchant est un architecte de solutions spécialiste de l'apprentissage automatique chez AWS, basé en France. Olivier aide les clients d'AWS, des petites startups aux grandes entreprises, à développer et déployer des applications d'apprentissage automatique de niveau production. Dans ses temps libres, il aime lire des articles de recherche et explorer la nature sauvage avec ses amis et sa famille.

Emilie Webber a rejoint AWS juste après le lancement de SageMaker et essaie d'en parler au monde depuis ! En dehors de la création de nouvelles expériences ML pour les clients, Emily aime méditer et étudier le bouddhisme tibétain.