Système sur matériel vierge vs Kubernetes : Formation distribuée avec TensorFlow

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

Sommaire

1. Introduction
   1. Sur matériel vierge
   2. Kubernetes
2. Versions logicielles
3. Cas d’utilisation réel : CheXNet
4. Spécifications matérielles
5. Performances
6. Résumé
    

Introduction

Versions logicielles

Tableau 1
 

Cas d’utilisation réel : CheXNet

Comme présenté précédemment, 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. Plusieurs approches ont été explorées pour faire évoluer la formation d’un modèle capable d’atteindre des performances aussi bonnes ou meilleures que le modèle CheXNet-121 d’origine avec ResNet-50, ce qui est prometteur sur le plan de l’évolutivité et de l’amélioration de la précision de la formation (AUROC positif). Les auteurs ont fait preuve d’évolutivité sur les systèmes dotés de processeur, mais nous sommes intéressés par l’exploitation du parallélisme des processeurs graphiques pour accélérer le processus de formation. Le système Dell EMC PowerEdge C4140 offre à la fois densité et performances avec quatre processeurs graphiques Nvidia V100 dans une configuration SXM2.
 

Spécifications matérielles

Performances

Le débit d’image, mesuré en images par seconde, lors de la formation de CheXNet a été mesuré à l’aide de 1, 2, 3, 4 et 8 processeurs graphiques sur 2 nœuds C4140 sur les deux systèmes décrits dans le Tableau 2. Les caractéristiques techniques de l’exécution, notamment l’architecture du modèle et les données d’entrée, sont détaillées dans cet article. La Figure 1 compare les performances mesurées sur le système Kubernetes et le système sur matériel vierge.

 
Figure 1 : Comparaison de l’exécution d’une formation de CheXNet sur K8s et sur matériel vierge
 

Résumé

Le système sur matériel vierge présente une augmentation des performances de 8 % à mesure que nous évoluons jusqu’à 8 processeurs graphiques. Toutefois, les différences de conception de l’architecture du système peuvent entraîner ce léger écart dans les performances, au-delà de l’argument de comparaison conteneur/sur matériel vierge. Le système sur matériel vierge peut tirer parti de la bande passante et de la latence totales de la connexion InfiniBand brute et n’a pas à gérer la surcharge créée avec Software Defined Networks tels que Flannel. Il se peut également que le système K8s utilise IP sur InfiniBand, ce qui peut réduire la bande passante disponible. 
Ces chiffres peuvent varier en fonction de la charge applicative et des modèles de communication définis par le type d’applications exécutées. Dans le cas d’un problème de classification d’image, le taux de communication entre les processeurs graphiques est élevé, augmentant par conséquent le taux d’échange. Toutefois, l’utilisation d’une approche plutôt que d’une autre dépend des besoins de la charge applicative. Bien que notre système basé sur Kubernetes présente un léger impact sur les performances, environ 8 % dans ce cas, il relève les utilisateurs et les administrateurs des tâches de définition et de configuration des bibliothèques, des environnements et d’autres dépendances. Cette approche permet aux spécialistes des données d’être plus productifs et de se concentrer sur la résolution de problèmes métiers essentiels, tels que le data wrangling et la création de modèles.