Améliorez les performances tarifaires de la formation de votre modèle à l'aide des clusters hétérogènes Amazon SageMaker

Ce billet est co-écrit avec Chaim Rand de Mobileye.

Certaines charges de travail d'apprentissage automatique (ML), telles que la formation de modèles de vision par ordinateur ou l'apprentissage par renforcement, impliquent souvent de combiner la tâche gourmande en GPU ou en accélérateur de la formation de modèles de réseau neuronal avec la tâche gourmande en processeur du prétraitement des données, comme l'augmentation d'image. Lorsque les deux types de tâches s'exécutent sur le même type d'instance, le prétraitement des données est bloqué sur le processeur, ce qui réduit l'utilisation du processeur graphique. Ce problème s'aggrave avec le temps, car le débit des nouvelles générations de GPU augmente à un rythme plus rapide que celui des CPU.

Pour résoudre ce problème, en juillet 2022, nous lancé grappes hétérogènes pour Amazon Sage Maker la formation de modèle, qui vous permet de lancer des tâches de formation qui utilisent différents types d'instances dans une seule tâche. Cela permet de décharger des parties du pipeline de prétraitement des données vers optimisé pour le calcul types d'instance, tandis que la tâche de réseau neuronal profond (DNN) continue de s'exécuter sur GPU ou calcul accéléré types d'instances. Nos benchmarks montrent jusqu'à 46 % d'avantages en termes de performances en termes de prix après l'activation de clusters hétérogènes dans une formation de modèle de vision par ordinateur TensorFlow liée au processeur.

Pour un cas d'utilisation similaire, Mobile, une société de développement de technologies de véhicules autonomes, avait ceci à partager :

"En déplaçant la formation du modèle de vision par ordinateur d'apprentissage en profondeur lié au processeur pour qu'elle s'exécute sur plusieurs types d'instances (accélérateurs CPU et GPU/ML), à l'aide d'un tf.data.service basée sur la solution que nous avons construite, nous avons réussi à réduire le temps de formation de 40 % tout en réduisant le coût de la formation de 30 %. Nous sommes ravis que les clusters hétérogènes nous permettent d'exécuter cette solution sur Amazon SageMaker.

— Ingénierie IA, Mobileye

Dans cet article, nous abordons les sujets suivants :

• Comment les clusters hétérogènes aident à éliminer les goulots d'étranglement du processeur
• Quand utiliser des clusters hétérogènes et d'autres alternatives
• Implémentations de référence dans PyTorch et TensorFlow
• Résultats des tests de performances
• Clusters hétérogènes à Mobileye

AWS instance de calcul accéléré famille comprend des accélérateurs de puces personnalisées AWS (Inférence AWS, Formation AWS), NVIDIA (GPU), Et Accélérateurs Gaudi de Habana Labs (une société Intel). Notez que dans cet article, nous utilisons indifféremment les termes GPU et accélérateur.

Comment les clusters hétérogènes éliminent les goulots d'étranglement du traitement des données

Les scientifiques des données qui forment des modèles d'apprentissage en profondeur visent à maximiser la rentabilité de la formation et à minimiser le temps de formation. Pour y parvenir, un objectif d'optimisation de base est d'avoir une utilisation élevée du GPU, la ressource la plus chère et la plus rare du marché. Cloud de calcul élastique Amazon (Amazon EC2). Cela peut être plus difficile avec les charges de travail ML qui combinent la propagation vers l'avant et vers l'arrière du modèle classique de réseau neuronal à forte intensité de GPU avec des tâches gourmandes en CPU, telles que le traitement des données et l'augmentation de la vision par ordinateur ou l'exécution d'une simulation d'environnement dans l'apprentissage par renforcement. Ces charges de travail peuvent finir par être liées au CPU, où avoir plus de CPU se traduirait par un débit plus élevé et une formation plus rapide et moins chère car les accélérateurs existants sont partiellement inactifs. Dans certains cas, les goulots d'étranglement du processeur peuvent être résolus en passant à un autre type d'instance avec un ratio CPU/GPU plus élevé. Cependant, il existe des situations où le passage à un autre type d'instance peut ne pas être possible en raison de l'architecture, du stockage ou des dépendances réseau de la famille d'instances.

Dans de telles situations, vous devez augmenter la quantité de puissance CPU en mélangeant les types d'instances : instances avec GPU et CPU. En résumé, cela se traduit par un rapport CPU:GPU globalement plus élevé. Jusqu'à récemment, les tâches de formation SageMaker étaient limitées à des instances d'un seul type d'instance choisi. Avec les clusters hétérogènes SageMaker, les scientifiques des données peuvent facilement exécuter une tâche de formation avec plusieurs types d'instances, ce qui permet de décharger certaines des tâches CPU existantes des instances GPU vers des instances CPU dédiées optimisées pour le calcul, ce qui se traduit par une utilisation GPU plus élevée et plus rapide et plus coûteuse. formation efficace. De plus, grâce à la puissance supplémentaire du processeur, vous pouvez faire en sorte que les tâches de prétraitement qui étaient traditionnellement effectuées hors ligne en tant qu'étape préliminaire à la formation fassent partie de votre travail de formation. Cela accélère l'itération et l'expérimentation sur les hypothèses de prétraitement des données et de formation DNN et les hyperparamètres.

Par exemple, considérez un type d'instance GPU puissant, ml.p4d.24xlarge (96 vCPU, 8 x NVIDIA A100 GPU), avec un ratio CPU:GPU de 12:1. Supposons que votre travail de formation nécessite 20 vCPU pour prétraiter suffisamment de données pour qu'un GPU soit utilisé à 100 %. Par conséquent, pour que les 8 GPU soient utilisés à 100 %, vous avez besoin d'un type d'instance de 160 vCPU. Cependant, ml.p4d.24xlarge manque de 64 vCPU, soit 40 %, ce qui limite l'utilisation du GPU à 60 %, comme illustré à gauche du diagramme suivant. Est-ce que l'ajout d'une autre instance ml.p4d.24xlarge aiderait ? Non, car le ratio CPU:GPU de la tâche resterait le même.

Avec des clusters hétérogènes, nous pouvons ajouter deux ml.c5.18xlarge (72 vCPU), comme indiqué à droite du diagramme. Le vCPU total net dans ce cluster est de 210 (96+2*72), ce qui conduit à un ratio CPU:GPU de 30:1. Chacune de ces instances optimisées pour le calcul sera déchargée avec une tâche de prétraitement des données gourmande en CPU et permettra une utilisation efficace du GPU. Malgré le coût supplémentaire du ml.c5.18xlarge, l'utilisation plus élevée du GPU permet un traitement plus rapide, et donc des avantages de performances de prix plus élevés.

Quand utiliser des clusters hétérogènes et d'autres alternatives

Dans cette section, nous expliquons comment identifier un goulot d'étranglement de processeur et discutons de sa résolution en utilisant le type d'instance à la hausse par rapport aux clusters hétérogènes.

Le moyen rapide d'identifier un goulot d'étranglement CPU est de surveiller le CPU et le GPU métriques d'utilisation pour les emplois de formation SageMaker dans Amazon Cloud Watch. Vous pouvez accéder à ces vues à partir du Console de gestion AWS dans le lien hypertexte des métriques d'instance de la page de la tâche d'entraînement. Choisissez les métriques pertinentes et passez d'une résolution de 5 minutes à 1 minute. Notez que l'échelle est de 100 % par vCPU ou GPU, de sorte que le taux d'utilisation d'une instance avec 4 vCPU/GPU peut atteindre 400 %. La figure suivante est un exemple de ces métriques CloudWatch, où le CPU est utilisé à environ 100 %, indiquant un goulot d'étranglement du CPU, tandis que le GPU est sous-utilisé.

Pour un diagnostic détaillé, exécutez les tâches d'entraînement avec Débogueur Amazon SageMaker pour profiler l'état d'utilisation des ressources, les statistiques et les opérations de structure, en ajoutant une configuration de profileur lorsque vous construisez un estimateur SageMaker à l'aide du SDK SageMaker Python. Après avoir soumis la tâche d'entraînement, passez en revue le rapport du profileur pour les goulots d'étranglement du processeur.

Si vous concluez que votre tâche pourrait bénéficier d'un rapport de calcul CPU/GPU plus élevé, envisagez d'abord de passer à un autre type d'instance dans la même famille d'instances, s'il en existe un. Par exemple, si vous entraînez votre modèle sur ml.g5.8xlarge (32 vCPU, 1 GPU), envisagez de passer à ml.g5.16xlarge (64 vCPU, 1 GPU). Ou, si vous entraînez votre modèle à l'aide de l'instance multi-GPU ml.g5.12xlarge (48 vCPU, 4 GPU), envisagez de passer à ml.g5.24xlarge (96 vCPU, 4 GPU). Se référer au G5 spécification de famille d'instances pour plus de détails.

Parfois, la mise à l'échelle n'est pas une option, car il n'y a pas de type d'instance avec un ratio vCPU:GPU plus élevé dans la même famille d'instances. Par exemple, si vous entraînez le modèle sur ml.trn1.32xlarge, ml.p4d.24xlarge ou ml.g5.48xlarge, vous devez envisager des clusters hétérogènes pour la formation du modèle SageMaker.

Outre la mise à l'échelle, nous aimerions noter qu'il existe d'autres alternatives à un cluster hétérogène, comme NVIDIA DALI, qui décharge le prétraitement des images sur le GPU. Pour plus d'informations, reportez-vous à Surmonter les goulots d'étranglement du prétraitement des données avec le service de données TensorFlow, NVIDIA DALI et d'autres méthodes.

Pour simplifier la prise de décision, reportez-vous à l'organigramme suivant.

Comment utiliser les clusters hétérogènes SageMaker

Pour démarrer rapidement, vous pouvez accéder directement aux exemples TensorFlow ou PyTorch fournis dans le cadre de cet article.

Dans cette section, nous vous expliquons comment utiliser un cluster hétérogène SageMaker avec un exemple simple. Nous supposons que vous savez déjà comment former un modèle avec le SDK SageMaker Python et la classe Estimator. Si ce n'est pas le cas, reportez-vous à Utilisation du SDK SageMaker Python avant de continuer.

Avant cette fonctionnalité, vous initialisiez la classe Estimator de la tâche d'entraînement avec la InstanceCount et les paramètres InstanceType, qui supposent implicitement que vous n'avez qu'un seul type d'instance (un cluster homogène). Avec la sortie des clusters hétérogènes, nous avons introduit le nouveau sagemaker.instance_group.InstanceGroup classer. Cela représente un groupe d'une ou plusieurs instances d'un type d'instance spécifique, conçu pour jouer un rôle logique (comme le traitement des données ou l'optimisation du réseau neuronal. Vous pouvez avoir deux groupes ou plus et spécifier un nom personnalisé pour chaque groupe d'instances, l'instance type et le nombre d'instances pour chaque groupe d'instances. Pour plus d'informations, reportez-vous à Utilisation du SDK SageMaker Python ainsi que Utilisation des API SageMaker de bas niveau.

Après avoir défini les groupes d'instances, vous devez modifier votre script de formation pour lire le SageMaker informations sur l'environnement de formation qui inclut une configuration de cluster hétérogène. La configuration contient des informations telles que les groupes d'instances actuels, les hôtes actuels de chaque groupe et le groupe dans lequel l'hôte actuel réside avec leur classement. Vous pouvez créer une logique dans votre script d'entraînement pour affecter les groupes d'instances à certaines tâches d'entraînement et de traitement des données. De plus, votre script de formation doit prendre en charge la communication de groupe inter-instance ou les mécanismes de chargement de données distribuées (par exemple, tf.data.service dans TensorFlow ou générique client-serveur gRPC) ou tout autre framework (par exemple, Apache Spark).

Passons en revue un exemple simple de lancement d'une tâche d'entraînement hétérogène et de lecture de la configuration de l'environnement au moment de l'exécution.

1. Lors de la définition et du lancement de la tâche d'entraînement, nous configurons deux groupes d'instances utilisés comme arguments de l'estimateur SageMaker :

   from sagemaker.instance_group import InstanceGroup
   data_group = InstanceGroup("data_group", "ml.c5.18xlarge", 2)
   dnn_group = InstanceGroup("dnn_group", "ml.p4d.24xlarge", 1)
   
   from sagemaker.pytorch import PyTorch
   estimator = PyTorch(...,
       entry_point='launcher.py',
       instance_groups=[data_group, dnn_group]
   )

2. Sur le script de formation du point d'entrée (nommé launcher.py), nous lisons la configuration du cluster hétérogène pour déterminer si l'instance exécutera le prétraitement ou le code DNN :

   from sagemaker_training import environment
   env = environment.Environment()
   if env.current_instance_group == 'data_group': ...;

Sur ce, résumons les tâches que SageMaker effectue en votre nom et les tâches dont vous êtes responsable.

SageMaker effectue les tâches suivantes :

1. Provisionnez différents types d'instances en fonction de la définition du groupe d'instances.
2. Provisionnez les canaux d'entrée sur tous les groupes d'instances ou sur des groupes d'instances spécifiques.
3. Distribuez les scripts de formation et les dépendances aux instances.
4. Configurez un cluster MPI sur un groupe d'instances spécifique, s'il est défini.

Vous êtes responsable des tâches suivantes :

1. Modifiez votre script de tâche de démarrage de formation pour spécifier des groupes d'instances.
2. Mettre en œuvre un pipeline de données distribué (par exemple, tf.data.service).
3. Modifiez votre script de point d'entrée (voir launcher.py dans l'exemple de bloc-notes) pour être un point d'entrée unique qui s'exécutera sur toutes les instances, détectera dans quel groupe d'instances il s'exécute et déclenchera le comportement approprié (tel que le traitement des données ou l'optimisation DNN).
4. Lorsque la boucle de formation est terminée, vous devez vous assurer que votre processus de point d'entrée se termine sur toutes les instances de tous les groupes d'instances. Ceci est important car SageMaker attend que toutes les instances aient terminé le traitement avant de marquer la tâche comme terminée et d'arrêter la facturation. La launcher.py Le script dans les blocs-notes d'exemple TensorFlow et PyTorch fournit une implémentation de référence des instances de groupe de données de signalisation pour se fermer lorsque les instances de groupe DNN terminent leur travail.

Exemples de notebooks pour les clusters hétérogènes SageMaker

Dans cette section, nous proposons un résumé des exemples de cahiers pour les frameworks TensorFlow et PyTorch ML. Dans les blocs-notes, vous pouvez trouver les détails de mise en œuvre, des procédures pas à pas sur le fonctionnement du code, des extraits de code que vous pouvez réutiliser dans vos scripts de formation, des organigrammes et une analyse de comparaison des coûts.

Notez que dans les deux exemples, vous ne devez pas vous attendre à ce que le modèle converge de manière significative. Notre intention est uniquement de mesurer le pipeline de données et le débit d'optimisation du réseau neuronal exprimé en époque/étape. Vous devez comparer avec votre propre modèle et ensemble de données pour produire des avantages de performance des prix qui correspondent à votre charge de travail.

Cluster hétérogène utilisant un chargeur de données distribué basé sur tf.data.service (TensorFlow)

Ce cahier montre comment mettre en œuvre un cluster hétérogène pour la formation SageMaker à l'aide de TensorFlow tf.data.service pipeline de données distribué basé. Nous formons un modèle de vision par ordinateur d'apprentissage en profondeur Resnet50 qui nécessite une augmentation des données gourmande en CPU. Il utilise Horvode pour le parallélisme des données distribuées multi-GPU.

Nous exécutons la charge de travail dans deux configurations : d'abord en tant que cluster homogène, une seule instance ml.p4d.24xlarge, à l'aide d'un standard tf.data pipeline qui présente les goulots d'étranglement du processeur conduisant à une utilisation réduite du processeur graphique. Dans la deuxième exécution, nous passons d'un type d'instance unique à deux groupes d'instances à l'aide d'un cluster hétérogène SageMaker. Cette exécution décharge une partie du traitement des données sur des instances de CPU supplémentaires (à l'aide tf.data.service).

Nous comparons ensuite les configurations homogènes et hétérogènes et trouvons les principaux avantages en termes de performances en termes de prix. Comme le montre le tableau suivant, la tâche hétérogène (86 ms/étape) est 2.2 fois plus rapide à entraîner que la tâche homogène (192 ms/étape), ce qui rend l'entraînement d'un modèle 46 % moins cher.

Exemple 1 (TF)	ml.p4d.24xl	ml.c5.18xl	Prix ​​par heure*	Temps de pas moyen	Coût par étape	Amélioration de la performance des prix
homogène	1	0	$37.688	192 ms	$0.201	.
Hétérogène	1	2	$45.032	86 ms	$0.108	46%

* Le prix par heure est basé sur us-east-1 Tarification à la demande de SageMaker

Cette accélération est rendue possible en utilisant le vCPU supplémentaire, fourni par le groupe de données, et un prétraitement plus rapide. Voir le cahier pour plus de détails et de graphiques.

Cluster hétérogène utilisant un chargeur de données distribué basé sur client-serveur gRPC (PyTorch)

Ce cahier illustre un exemple de charge de travail utilisant un cluster hétérogène pour la formation SageMaker à l'aide d'un chargeur de données distribué basé sur un client-serveur gRPC. Cet exemple utilise un seul GPU. Nous utilisons le modèle PyTorch basé sur les éléments suivants exemple officiel du MNIST. Le code de formation a été modifié pour être lourd sur le prétraitement des données. Nous entraînons ce modèle dans les modes de cluster homogène et hétérogène, et comparons les performances de prix.

Dans cet exemple, nous avons supposé que la charge de travail ne pouvait pas bénéficier de plusieurs GPU et dépendait d'une architecture GPU spécifique (NVIDIA V100). Nous avons exécuté des tâches de formation homogènes et hétérogènes et avons trouvé des avantages clés en termes de performances de prix, comme indiqué dans le tableau suivant. La tâche hétérogène (1.19 s/étape) est 6.5 fois plus rapide à entraîner que la tâche homogène (0.18 s/étape), ce qui rend l'entraînement d'un modèle 77 % moins cher.

Exemple 2 (PT)	ml.p3.2xl	ml.c5.9xl	Prix ​​par heure*	Temps de pas moyen	Coût par étape	Amélioration de la performance des prix
homogène	1	0	$3.825	1193 ms	$0.127	.
Hétérogène	1	1	$5.661	184 ms	$0.029	77%

* Le prix par heure est basé sur us-east-1 Tarification à la demande de SageMaker

Cela est possible car avec un nombre de processeurs plus élevé, nous pourrions utiliser 32 travailleurs du chargeur de données (contre 8 avec ml.p3.2xlarge) pour prétraiter les données et maintenir le GPU à près de 100 % utilisé à intervalles fréquents. Voir le cahier pour plus de détails et de graphiques.

Clusters hétérogènes à Mobileye

Mobileye, une société d'Intel, développe des systèmes avancés d'aide à la conduite (ADAS) et des technologies de véhicules autonomes dans le but de révolutionner l'industrie du transport, de rendre les routes plus sûres et de sauver des vies. Ces technologies sont activées à l'aide de modèles sophistiqués de vision par ordinateur (CV) formés à l'aide de SageMaker sur de grandes quantités de données stockées dans Service de stockage simple Amazon (Amazon S3). Ces modèles utilisent des techniques de réseau neuronal d'apprentissage en profondeur de pointe.

Nous avons remarqué que pour l'un de nos modèles CV, le goulot d'étranglement du processeur était principalement causé par un prétraitement de données lourd conduisant à des GPU sous-utilisés. Pour cette charge de travail spécifique, nous avons commencé à rechercher des solutions alternatives, évalué les technologies de pipeline de données distribuées avec des clusters hétérogènes basés sur des instances EC2 et proposé des implémentations de référence pour les deux. TensorFlow ainsi que PyTorch. La sortie du cluster hétérogène SageMaker nous permet d'exécuter cette charge de travail et des charges de travail similaires sur SageMaker pour obtenir de meilleurs avantages en termes de prix et de performances.

Considérations

Avec le lancement de la fonctionnalité de cluster hétérogène, SageMaker offre beaucoup plus de flexibilité dans le mélange et l'appariement des types d'instances au sein de votre travail de formation. Cependant, tenez compte des éléments suivants lorsque vous utilisez cette fonctionnalité :

• La fonctionnalité de cluster hétérogène est disponible via SageMaker PyTorch ainsi que TensorFlow classes d'estimateur de cadre. Les frameworks pris en charge sont PyTorch v1.10 ou version ultérieure et TensorFlow v2.6 ou version ultérieure.
• Tous les groupes d'instances partagent la même image Docker.
• Tous les groupes d'instances partagent le même script d'entraînement. Par conséquent, votre script d'entraînement doit être modifié pour détecter à quel groupe d'instances il appartient et le fork s'exécute en conséquence.
• Les noms d'hôte des instances d'entraînement (par exemple, alog-1, algo-2, etc.) sont attribués de manière aléatoire et n'indiquent pas à quel groupe d'instances ils appartiennent. Pour obtenir le rôle de l'instance, nous vous recommandons d'obtenir son appartenance au groupe d'instances lors de l'exécution. Ceci est également pertinent lors de l'examen des journaux de connexion CloudWatch, car le nom du flux de journal [training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp] a le nom d'hôte.
• Une stratégie de formation distribuée (généralement un cluster MPI) ne peut être appliquée qu'à un seul groupe d'instances.
• SageMaker Piscines chaudes gérées et Sage Maker Mode local ne peut actuellement pas être utilisé avec la formation de cluster hétérogène.

Conclusion

Dans cet article, nous avons expliqué quand et comment utiliser la fonctionnalité de cluster hétérogène de la formation SageMaker. Nous avons démontré une amélioration des performances de prix de 46 % sur un cas d'utilisation réel et vous avons aidé à démarrer rapidement avec le chargeur de données distribué (tf.data.service et gRPC client-serveur). Vous pouvez utiliser ces implémentations avec des modifications de code minimales dans vos scripts de formation existants.

Pour commencer, essayez notre exemples de cahiers. Pour en savoir plus sur cette fonction, consultez Entraînement à l'aide d'un cluster hétérogène.

---

À propos des auteurs

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.

Hrushikesh Gangur est un architecte de solutions principal pour les startups AI/ML avec une expertise à la fois dans la formation ML et la mise en réseau AWS. Il aide les startups des technologies Autonomous Vehicle, Robotics, CV, NLP, MLOps, ML Platform et Robotics Process Automation à gérer leur entreprise de manière efficace et efficiente sur AWS. Avant de rejoindre AWS, Hrushikesh a acquis plus de 20 ans d'expérience dans l'industrie, principalement autour des plates-formes cloud et de données.

Gal Ochri est chef de produit senior au sein de l'équipe Amazon SageMaker. Il a 7 ans d'expérience dans les outils, les frameworks et les services d'apprentissage automatique.

Chaïm Rand est un développeur d'algorithmes d'apprentissage automatique travaillant sur les technologies d'apprentissage en profondeur et de vision par ordinateur pour les solutions de véhicules autonomes chez Mobileye, une société Intel. Découvrez son blogue.