Conseils et pièges de configuration pour la bibliothèque de données parallèles distribuées SageMaker - Amazon SageMaker

Conseils et pièges de configuration pour la bibliothèque de données parallèles distribuées SageMaker

Consultez les conseils et les pièges suivants avant d'utiliser la bibliothèque de données parallèles distribuées de SageMaker. Cette liste contient des conseils qui s'appliquent à tous les cadres.

Traitement des données

Si, pendant l'entraînement, vous prétraitez des données à l'aide d'une bibliothèque externe qui utilise le CPU, vous risquez d'être limité en termes de CPU car la bibliothèque de données parallèles distribuées de SageMaker l'utilise pour les opérations AllReduce. Pour réduire la durée d'entraînement, vous pouvez déplacer les étapes de pré-traitement vers une bibliothèque qui utilise des GPU ou en effectuant tous les pré-traitements avant l'entraînement.

Nœud simple ou nœuds multiples

Nous vous recommandons d'utiliser cette bibliothèque avec des nœuds multiples. Vous pouvez utiliser la bibliothèque avec une configuration multi-périphériques à hôte unique (par exemple, une instance de calcul ML unique avec plusieurs GPU), mais en utilisant deux nœuds ou plus, vous pouvez améliorer significativement les performances avec l'opération AllReduce de la bibliothèque. De plus, sur un hôte unique, NVLink contribue déjà à l'efficacité de l'opération AllReduce dans le nœud.

Déboguer l'efficacité de mise à l'échelle avec le débogueur

Vous pouvez utiliser Amazon SageMaker Debugger pour contrôler et visualiser l'utilisation du CPU et du GPU, ainsi que d'autres métriques d'intérêt, pendant l'entraînement. Vous pouvez utiliser les règles intégrées de Debugger pour contrôler les problèmes liés à la performance de calcul, tels que CPUBottleneck, LoadBalancing et LowGPUUtilization. Vous pouvez spécifier ces règles avec les configurations Debugger lorsque vous définissez un estimateur de kit SDK Python Amazon SageMaker. Si vous utilisez l'AWS CLI et AWS Boto3 pour l'entraînement sur SageMaker, vous pouvez activer Debugger comme indiqué dans Configure Debugger Using Amazon SageMaker API (Configurer Debugger à l'aide de l'API Amazon SageMaker).

Pour voir un exemple d'utilisation de Debugger dans une tâche d'entraînement SageMaker, vous pouvez référencer l'un des exemples de bloc-notes dans le référentiel GitHub d'exemples de bloc-notes SageMaker. Pour en savoir plus sur Debugger, consultez Amazon SageMaker Debugger.

Taille de lot

Dans l'entraînement distribué, la taille de lot augmente proportionnellement à l'ajout de nœuds. Pour améliorer la vitesse de convergence à mesure que vous ajoutez des nœuds à votre tâche d'entraînement et que vous augmentez la taille de lot globale, augmentez le taux d'apprentissage.

Pour cela, vous pouvez procéder à un échauffement progressif du taux d'apprentissage, le taux d'apprentissage passant d'une valeur faible à une valeur élevée à mesure que la tâche d'entraînement progresse. Cette élévation progressive évite une brusque augmentation du taux d'apprentissage et permet une convergence saine dès le début de l'entraînement. Par exemple, vous pouvez utiliser une règle de mise à l'échelle linéaire selon laquelle le taux d'apprentissage est également multiplié par k chaque fois que la taille du mini-lot est multipliée par k. Pour en savoir plus sur cette technique, consultez le document de recherche Accurate, Large Minibatch SGD: Training ImageNet in 1 Hour, sections 2 et 3.

Options MPI personnalisées

La bibliothèque de données parallèles distribuées SageMaker utilise l'interface MPI (Message Passing Interface), une norme bien connue de gestion de la communication entre les nœuds d'un cluster haute performance, et utilise la bibliothèque NCCL de NVIDIA pour la communication au niveau du GPU. Lorsque vous utilisez la bibliothèque de données parallèles avec un Estimator TensorFlow ou Pytorch, le conteneur respectif configure l'environnement MPI et exécute la commande mpirun pour démarrer des tâches sur les nœuds du cluster.

Vous pouvez configurer des opérations MPI personnalisées à l'aide du paramètre custom_mpi_options dans l'Estimator. Tous les indicateurs mpirun passés dans ce champ sont ajoutés à la commande mpirun et exécutés par SageMaker pour l'entraînement. Par exemple, pour définir le paramètre distribution d'un Estimator, vous pouvez exploiter la ressource suivante afin d'utiliser la variable NCCL_DEBUG pour imprimer la version NCCL au début du programme :

distribution = {'smdistributed':{'dataparallel':{'enabled': True, "custom_mpi_options": "-verbose -x NCCL_DEBUG=VERSION"}}}

Utiliser Amazon FSx et configurer une capacité de stockage et de débit optimale

Lors de l'entraînement d'un modèle sur plusieurs nœuds avec un parallélisme de données distribué, il est fortement recommandé d'utiliser FSx for Lustre. Amazon FSx est un service de stockage évolutif et hautes performances qui prend en charge le stockage de fichiers partagés avec un débit plus rapide. En utilisant le stockage Amazon FSx à grande échelle, vous pouvez obtenir une vitesse de chargement de données plus rapide sur les nœuds de calcul.

En règle générale, avec le parallélisme de données distribué, vous vous attendez à ce que le débit total d'entraînement évolue de manière quasi linéaire avec le nombre de GPU. Cependant, si vous utilisez un stockage Amazon FSx sous-optimal, les performances d'entraînement peuvent ralentir en raison d'un faible débit Amazon FSx.

Par exemple, si vous utilisez le type de déploiement SCRATCH_2 du système de fichiers Amazon FSx avec une capacité de stockage minimale de 1,2 Tio, la capacité de débit d'I/O est de 240 Mo/s. Le stockage Amazon FSx fonctionne de manière à vous permettre d'attribuer des périphériques de stockage physiques, et plus il y a de périphériques attribués, plus le débit que vous obtenez est élevé. Le plus petit incrément de stockage pour le type SRATCH_2 est de 1,2 Tio et le gain de débit correspondant est de 240 Mo/s.

Supposons que vous ayez un modèle à entraîner sur un cluster à 4 nœuds sur un jeu de données de 100 Go. Avec une taille de lot donnée optimisée pour le cluster, supposons que le modèle peut terminer une époque en 30 secondes environ. Dans ce cas, la vitesse d'I/O minimale requise est d'environ 3 Go/s (100 Go/30 s). Il s'agit manifestement d'une exigence de débit beaucoup plus élevée que 240 Mo/s. Avec une capacité Amazon FSx aussi limitée, la mise à l'échelle de votre tâche d'entraînement distribuée vers des clusters plus importants peut aggraver les problèmes de goulet d'étranglement d'I/O. Le débit d'entraînement du modèle peut s'améliorer dans les époques ultérieures à mesure que le cache s'accumule, mais le débit d'Amazon FSx peut toujours être un goulet d'étranglement.

Pour atténuer ces problèmes de goulet d'étranglement d'I/O, vous devez augmenter la taille de stockage Amazon FSx afin d'obtenir une capacité de débit plus élevée. En règle générale, pour trouver un débit d'I/O optimal, vous pouvez expérimenter différentes capacités de débit d'Amazon FSx, en attribuant un débit égal ou légèrement inférieur à votre estimation, jusqu'à ce que vous trouviez qu'il est suffisant pour résoudre les problèmes de goulet d'étranglement d'I/O. Dans le cas de l'exemple susmentionné, le stockage Amazon FSx avec un débit de 2,4 Go/s et un cache RAM de 67 Go serait suffisant. Si le système de fichiers a un débit optimal, le débit d'entraînement du modèle doit atteindre son maximum immédiatement ou après la première époque de création du cache.

Pour en savoir plus sur l'augmentation des types de stockage et de déploiement Amazon FSx, veuillez consulter les sections suivantes dans la documentation Amazon FSx for Lustre :