Conseils et astuces pour optimiser le flux de travail avec TF et Horovod sur les GPU

L’article a été écrit par Rakshith Vasudev et John Lockman, HPC AI Innovation Lab, en octobre 2019


Introduction

Horovod est un cadre de Deep Learning distribué permettant d’accélérer la formation sur différents cadres de Deep Learning tels que Tensorflow, Keras, Pytorch et MXNet. Il a été conçu pour faciliter la mise en place de projets de Deep Learning distribués et pour accélérer leur création grâce à TensorFlow. Horovod prend en charge la parallélisation du processus d’apprentissage. Il prend en charge à la fois le parallélisme des données et le parallélisme des modèles. Lorsqu’une tâche d’apprentissage de réseau neuronal utilisant Horovod est en cours d’exécution, ces conseils généraux peuvent être utilisés pour le débogage et l’amélioration des performances.

Description

Cet article utilise CheXNet comme exemple de référence. CheXNet est un modèle d’assistant radiologiste basé sur l’IA qui utilise DenseNet pour identifier jusqu’à 14 pathologies à partir d’une image de rayons X donnée.

1. La configuration correcte de l’environnement peut faire économiser beaucoup de temps lors de tentatives de débogage des problèmes de performances. Assurez-vous que la version GPU du framework d’apprentissage profond est bien utilisée. Dans cet exemple, tensorflow-gpu packagé par anaconda est utilisé.
   
    

2. L’utilisation de horovodrun ou mpirun avec des paramètres de liaison peut offrir des gains de performance. Idéalement, le processus contrôlant un GPU doit être lié au socket du CPU le plus proche. Sur le serveur Dell EMC PowerEdge C4140, l’option optimale serait --map-by socket. Il n’est pas nécessaire de spécifier une option de liaison.

   Cela doit ressembler à ce qui suit : 

   mpirun --map-by socket -np x python pyfile.py - -pyoptions
   
    

3. La tâche doit être configurée de sorte qu’un processus MPI travaille sur un processeur graphique. S’il y a plus de processus que le nombre de GPU, les processus entrent en concurrence pour les ressources de calcul et ne sont pas en mesure d’exécuter la tâche avec de bonnes performances. Dans l’exemple ci-dessus, x doit être égal au nombre de GPU à utiliser.
   
    

4. Pour définir un processus par processeur graphique, utilisez la ConfigProto() de tensorflow comme suit :

   config.gpu_options.visible_device_list=str(hvd.local_size())
   
    

5. Pour vérifier le nombre de processus utilisant le processeur graphique, l’option pour la consommation de mémoire du processeur graphique ‘watch nvidia-smi’ peut être utilisée. Cela permet également d’afficher la consommation énergétique.

   
   Figure 1 : Capture d’écran de la sortie de la commande nvidia-smi indiquant l’utilisation de la mémoire, de l’alimentation et du processeur graphique.
   
   
    
6. Si le pipeline de données est correctement configuré et que les paramètres de mpirun sont corrects, l’utilisation du processeur graphique doit se situer au-delà de 90 % une fois que l’apprentissage du modèle commence. Des baisses occasionnelles à un taux d’utilisation de 10 à 25 % sont acceptables, mais elles doivent être peu fréquentes.
   
   
    
7. Définissez la taille du lot de façon à ce que la mémoire GPU soit presque pleine, mais limitez-la afin que les besoins en mémoire ne soient pas dépassés. Il est important de prendre en compte le mode de fonctionnement de la mise à l’échelle du taux d’apprentissage. La mise à l’échelle du taux d’apprentissage est le concept selon lequel, à mesure que le nombre de GPU augmente, le taux d’apprentissage doit également être multiplié par un facteur proportionnel au nombre de GPU. Cela permet au modèle de converger efficacement. Cela réduit le nombre d’opérations d’e/s en ajustant le nombre maximal d’images possibles sur un GPU sans compromettre la convergence des modèles. Il convient de noter que la mise à l’échelle du taux d’apprentissage n’est pas toujours la meilleure solution pour améliorer la convergence des modèles dans un environnement de charge applicative distribuée.
   Pour vérifier si la mise à l’échelle du taux d’apprentissage est nécessaire :
   
   
   a) Entraîner le modèle avec et sans mise à l’échelle du taux d’apprentissage en mode distribué.
   b) Si le modèle sans mise à l’échelle du taux d’apprentissage est plus performant que le modèle avec mise à l’échelle du taux d’apprentissage, la mise à l’échelle du taux d’apprentissage n’est pas nécessaire. 
   
   
   Lors de l’entraînement à la convergence en particulier, la règle d’ajuster le nombre maximal possible d’images par lot n’est pas toujours obligatoire. En général, il existe un compromis entre la taille du lot et la convergence (indépendamment de l’utilisation de la mise à l’échelle du taux d’apprentissage) que le chercheur de données doit être en mesure de choisir en fonction de son cas d’utilisation.
   Encore une fois, vous pouvez examiner la consommation de mémoire du processeur graphique à l’aide de ‘watch nvidia-smi’.  Dans cette étude de cas, la mise à l’échelle du taux d’apprentissage n’a pas été utilisée, car les valeurs AUC donnaient un meilleur modèle et la taille du minibatch local était de 64. Lorsqu’une mise à l’échelle du taux d’apprentissage est utilisée, il est courant d’avoir des itérations de préchauffage, comme le décrit ce document.
   
    

8. Profilez vos tâches à l’aide de horovod timeline et nvprof pour afficher tous les goulets d’étranglement susceptibles de se produire.  Le goulet d’étranglement est vraisemblablement dû à l’une des raisons suivantes :

   a) Le pipeline de données tf n’est pas correctement configuré, et ainsi beaucoup de temps est consacré à préparer les données alors que l’accélérateur est inactif. Pour y remédier, tf pipeline doit être corrigé. 
   Veuillez lire cet article pour plus d’informations sur la configuration d’un pipeline de données tf. 
   
   b) La communication n’utilise peut-être pas la structure correcte : assurez-vous d’utiliser InfiniBand, pour voir l’utilisation de la structure, ajoutez –x NCCL_DEBUG=INFO à l’exécution de mpirun comme suit :
           mpirun -np 8 --map-by socket -x NCCL_DEBUG=INFO python $HOME/models/chexnet/chexnet.py --batch_size=128 --epochs=15
           ou utilisez horrundrun qui inclut la liaison –x.
   
   
    
9. Pour une mise en œuvre correcte de la distribution, les GPU doivent communiquer efficacement entre eux. S’ils ne communiquent pas efficacement, cela provoque un goulot d’étranglement de la communication. Pour vérifier s’ils communiquent de manière optimale, suivez les étapes ci-dessous :
   
   Analysez d’abord la façon dont les processeurs graphiques communiquent en utilisant le -x binding comme indiqué ci-dessus dans au point 8b
   
   Si les processeurs graphiques communiquent :
   1) dans le nœud, dans le cas optimal, vous obtiendrez un résultat du type :  
   gpu002:1299562:1299573 [0] NCCL INFO Ring 00: 0[0] -> 1[1] via P2P/IPC
    
   2) en dehors du nœud, dans le cas optimal, vous obtiendrez un résultat du type :
   gpu028:149460:149495 [0] NCCL INFO Ring 01: 16 -> 0 [send] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01: 12 -> 8 [receive] via NET/IB/0
   gpu009:164181:164216 [0] NCCL INFO Ring 01: 4 -> 8 [receive] via NET/IB/0

• les options de liaison appropriées sont en place,
• tester plusieurs processus qui ne gaspillent pas de mémoire GPU,
• utiliser une approche de pipeline moderne,
• recourir au profilage pour vérifier que les GPU sont utilisés au moins 80 % du temps durant l’exécution de la tâche,
• utiliser les dernières bibliothèques liées à CUDA