5 conseils pour une formation multi-GPU avec Keras

• 21 janvier 2018
• Vassilis Vryniotis
• . 1 commentaire

Le Deep Learning (le mot à la mode préféré de la fin des années 2010 avec blockchain / bitcoin et Data Science / Machine Learning) nous a permis de faire des choses vraiment cool ces dernières années. Outre les progrès des algorithmes (qui reposent certes sur des idées déjà connues depuis les années 1990, aussi appelées «l'ère du Data Mining»), les principales raisons de son succès peuvent être attribuées à la disponibilité de grands ensembles de données gratuits, à l'introduction de bibliothèques open-source et l'utilisation de GPU. Dans cet article de blog, je me concentrerai sur les deux derniers et je partagerai avec vous quelques conseils que j'ai appris à la dure.

Pourquoi TensorFlow & Keras?

TensorFlow est une bibliothèque Deep Learning très populaire développée par Google qui vous permet de prototyper rapidement des réseaux complexes. Il est livré avec de nombreuses fonctionnalités intéressantes telles que l'auto-différenciation (qui vous évite d'estimer / coder les gradients des fonctions de coût) et la prise en charge du GPU (qui vous permet d'obtenir facilement une amélioration de la vitesse 200x en utilisant un matériel décent). De plus, il offre une interface Python, ce qui signifie que vous pouvez rapidement créer un prototype sans avoir besoin d'écrire du code C ou CUDA. Certes, il existe de nombreux autres frameworks que l'on peut utiliser à la place de TensorFlow, tels que Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK, etc. mais tout se résume à votre cas d'utilisation et à vos préférences personnelles.

Mais pourquoi Keras? Pour moi, utiliser directement TF, c'est comme faire du Machine Learning avec Numpy. Oui c'est faisable et de temps en temps, vous devez le faire (surtout si vous écrivez des couches / fonctions de perte personnalisées) mais voulez-vous vraiment écrire du code qui décrit les réseaux complexes comme une série d'opérations vectorielles (oui, je sais il existe des méthodes de niveau supérieur dans TF mais elles ne sont pas aussi cool que Keras)? Et si vous souhaitez déménager dans une autre bibliothèque? Eh bien, vous auriez probablement besoin de réécrire le code, ce qui est nul. Ta ta taaa, Keras à la rescousse! Keras vous permet de décrire vos réseaux à l'aide de concepts de haut niveau et d'écrire du code indépendant du backend, ce qui signifie que vous pouvez exécuter les réseaux sur différentes bibliothèques d'apprentissage en profondeur. Peu de choses que j'aime chez Keras, c'est qu'il est bien écrit, qu'il a une architecture orientée objet, qu'il est facile de contribuer et qu'il a une communauté amicale. Si vous l'aimez, dites merci à François Cholet pour le développer et le open-sourcing.

Conseils et astuces pour la formation multi-GPU

Sans plus tarder, passons à quelques conseils pour tirer le meilleur parti de la formation GPU sur Keras et à quelques pièges à garder à l'esprit:

1. La formation multi-GPU n'est pas automatique

La formation des modèles sur GPU à l'aide de Keras et Tensorflow est transparente. Si vous disposez d'une carte NVIDIA et que vous avez installé CUDA, les bibliothèques la détecteront automatiquement et l'utiliseront pour la formation. Trop cool! Mais que faire si vous êtes un gamin gâté et que vous avez plusieurs GPU? Eh bien, malheureusement, vous devrez travailler un peu pour réaliser une formation multi-GPU.

Il existe plusieurs façons de paralléliser un réseau en fonction de ce que vous souhaitez réaliser, mais les deux principales approches sont la parallélisation du modèle et des données. Le premier peut vous aider si votre modèle est trop complexe pour tenir dans un seul GPU tandis que le second vous aide lorsque vous souhaitez accélérer l'exécution. En règle générale, lorsque les gens parlent de formation multi-GPU, ils parlent de cette dernière. Auparavant, c'était plus difficile à réaliser, mais heureusement, Keras a récemment inclus une méthode utilitaire appelée multi_gpu_model ce qui facilite la formation / les prédictions parallèles (actuellement uniquement disponible avec le backend TF). L'idée principale est que vous transmettez votre modèle à travers la méthode et qu'il est copié sur différents GPU. L'entrée d'origine est divisée en morceaux qui sont transmis aux différents GPU, puis ils sont agrégés en une seule sortie. Cette méthode peut être utilisée pour réaliser un entraînement et des prédictions parallèles, mais gardez à l'esprit que pour l'entraînement, elle ne s'adapte pas linéairement à la quantité de GPU en raison de la synchronisation requise.

2. Faites attention à la taille du lot

Lorsque vous effectuez un entraînement multi-GPU, faites attention à la taille du lot car elle a plusieurs effets sur la vitesse / la mémoire, la convergence de votre modèle et si vous ne faites pas attention, vous risquez de corrompre les poids de votre modèle!

Vitesse / mémoire: Évidemment, plus le lot est grand, plus l'apprentissage / la prédiction est rapide. En effet, il y a une surcharge lors de l'introduction et de la suppression des données des GPU, de sorte que les petits lots ont plus de surcharge. D'un autre côté, plus le lot est volumineux, plus vous avez besoin de mémoire dans le GPU. Surtout pendant la formation, les entrées de chaque couche sont conservées en mémoire car elles sont nécessaires à l'étape de rétro-propagation, donc augmenter trop la taille de votre lot peut entraîner des erreurs de mémoire insuffisante.

Convergence: Si vous utilisez Stochastic Gradient Decent (SGD) ou certaines de ses variantes pour entraîner votre modèle, vous devez garder à l'esprit que la taille du lot peut affecter la capacité de votre réseau à converger et à se généraliser. Les tailles de lot typiques dans de nombreux problèmes de vision par ordinateur se situent entre 32 et 512 exemples. Comme Keskar et coll. le dire: «Il a été observé dans la pratique que lors de l'utilisation d'un lot plus grand (que 512), il y a une dégradation de la qualité du modèle, telle que mesurée par sa capacité à généraliser.». Notez que d'autres optimiseurs différents ont des propriétés différentes et que des techniques d'optimisation distribuées spécialisées peuvent aider à résoudre le problème. Si vous êtes intéressé par les détails mathématiques, je vous recommande de lire la thèse de Joeri Hermans "Sur l'apprentissage en profondeur évolutif et la descente de dégradé en parallèle ».

Corrompre les poids: C'est un détail technique désagréable qui peut avoir des résultats dévastateurs. Lorsque vous effectuez un entraînement multi-GPU, il est important d'alimenter tous les GPU avec des données. Il peut arriver que le tout dernier lot de votre époque contienne moins de données que défini (car la taille de votre jeu de données ne peut pas être divisée exactement par la taille de votre lot). Cela peut empêcher certains GPU de recevoir des données lors de la dernière étape. Malheureusement, certaines couches Keras, notamment la couche de normalisation par lots, ne peuvent pas faire face à ce qui conduit à l'apparition de valeurs nan dans les poids (la moyenne courante et la variance dans la couche BN). Pour rendre les choses encore plus méchantes, on n'observera pas le problème pendant la formation (alors que la phase d'apprentissage est 1) car la couche spécifique utilise la moyenne / variance du lot dans les estimations. Néanmoins lors des prédictions (phase d'apprentissage mise à 0), on utilise la moyenne / variance courante qui dans notre cas peut devenir nan conduisant à de mauvais résultats. Alors rendez-vous service et assurez-vous toujours que la taille de votre lot est fixe lorsque vous effectuez un entraînement multi-GPU. Deux méthodes simples pour y parvenir sont soit de rejeter les lots qui ne correspondent pas à la taille prédéfinie, soit de répéter les enregistrements dans le lot jusqu'à ce que vous atteigniez la taille prédéfinie. Enfin, gardez à l'esprit que dans une configuration multi-GPU, la taille du lot doit être un multiple du nombre de GPU disponibles sur votre système.

3. La famine des données GPU, c'est-à-dire que les processeurs ne peuvent pas suivre le rythme des GPU

Généralement, la partie la plus coûteuse lors de la formation / prévision des réseaux profonds est l'estimation qui se produit sur les GPU. Les données sont prétraitées dans les processeurs en arrière-plan et sont transmises périodiquement aux GPU. Néanmoins, il ne faut pas sous-estimer la vitesse des GPU; il peut arriver que si votre réseau est trop peu profond ou que l'étape de prétraitement est trop complexe, vos processeurs ne puissent pas suivre vos GPU ou en d'autres termes, ils ne les alimentent pas en données assez rapidement. Cela peut conduire à une faible utilisation du GPU qui se traduit par un gaspillage d'argent / de ressources.

Keras effectue généralement les estimations des lots en parallèle, mais en raison du GIL (Global Interpreter Lock) de Python, vous ne pouvez pas vraiment réaliser un véritable multi-threading en Python. Il existe deux solutions pour cela: soit utiliser plusieurs processus (notez qu'il y a beaucoup de pièges dans celui-ci que je ne vais pas aborder ici) ou garder votre étape de prétraitement simple. Dans le passé, j'ai envoyé une Pull-Request sur Keras pour alléger une partie de la pression inutile que nous imposions aux processeurs pendant le prétraitement de l'image, de sorte que la plupart des utilisateurs ne devraient pas être affectés s'ils utilisent les générateurs standard. Si vous avez des générateurs personnalisés, essayez de pousser autant de logique que possible vers les bibliothèques C telles que Numpy car certaines de ces méthodes libérer le GIL ce qui signifie que vous pouvez augmenter le degré de parallélisation. Un bon moyen de détecter si vous êtes confronté à une pénurie de données GPU est de surveiller l'utilisation du GPU, mais soyez néanmoins averti que ce n'est pas la seule raison de l'observer (la synchronisation qui se produit pendant l'entraînement sur plusieurs GPU est également à blâmer pour une faible utilisation. ). En règle générale, la privation de données GPU peut être détectée en observant les rafales GPU suivies de longues pauses sans utilisation. Dans le passé, j'ai ouvert une extension pour Dstat qui peut vous aider à mesurer l'utilisation de votre GPU, alors jetez un œil sur le article de blog original.

4. Sauvegarde de vos modèles parallèles

Supposons que vous ayez utilisé la méthode mutli_gpu_model pour paralléliser votre modèle, que la formation soit terminée et que vous souhaitiez maintenant conserver ses poids. La mauvaise nouvelle est que vous ne pouvez pas simplement appeler save () dessus. Actuellement, Keras a une limitation qui ne vous permet pas de enregistrer un modèle parallèle. Il y a 2 façons de contourner cela: soit appelez save () sur la référence du modèle d'origine (les poids seront mis à jour automatiquement) soit vous devez sérialiser le modèle en découpant la version parallélisée et en nettoyant toutes les connexions inutiles. La première option est bien plus simple, mais à l'avenir, je prévois d'ouvrir une méthode serialize () qui exécute cette dernière.

5. Le comptage des GPU disponibles a un effet secondaire désagréable

Malheureusement, pour le moment, il y a un effet secondaire désagréable sur la méthode tensorflow.python.client.device_lib.list_local_devices () qui provoque la création d'une nouvelle session TensorFlow et l'initialisation de tous les GPU disponibles sur le système. Cela peut entraîner des résultats inattendus tels que l'affichage de plus de GPU que spécifié ou l'initialisation prématurée de nouvelles sessions (vous pouvez lire tous les détails à ce sujet demande d'extraction). Pour éviter des surprises similaires, il est conseillé d'utiliser la méthode K.get_session (). List_devices () de Keras à la place, qui vous renverra tous les GPU actuellement enregistrés sur la session. Enfin, gardez à l'esprit que l'appel de la méthode list_devices () est en quelque sorte coûteux, donc si vous êtes simplement intéressé par le nombre de GPU disponibles, appelez la méthode une fois et stockez leur numéro sur une variable locale.

C'est tout! J'espère que vous avez trouvé cette liste utile. Si vous avez trouvé d'autres pièges / astuces pour la formation GPU sur Keras, partagez-les ci-dessous dans les commentaires. 🙂