Section 1 : Ouverture
Récemment, l'article "GoldMiner : Elastic Scaling of Training Data Pre-Processing Pipelines for Deep Learning" co-écrit par la plateforme d'apprentissage automatique d'Alibaba Cloud PAI et l'équipe du professeur Yang Zhi de l'Université de Pékin a été accepté par SIGMOD 2023, la plus grande conférence de le champ de la base de données.
GoldMiner a observé que le pipeline de prétraitement des données dans les tâches d'apprentissage en profondeur est sans état et possède une élasticité inhérente aux ressources. Sur cette base, GoldMiner sépare l'exécution du pipeline de prétraitement des données et de la formation du modèle, identifie les calculs de prétraitement des données sans état grâce à une analyse automatique des graphiques de calcul, et réalise une accélération parallèle efficace et une mise à l'échelle élastique pour eux, atténuant ainsi les goulots d'étranglement du prétraitement des données. Grâce à la conception collaborative avec le planificateur de cluster, GoldMiner exploite davantage l'élasticité des ressources des calculs de prétraitement des données et améliore considérablement l'efficacité de la planification des clusters. Les expériences montrent que GoldMiner peut améliorer les performances d'entraînement de 12,1 fois et améliorer l'utilisation du cluster GPU de 2,5 fois.
Section 2 : Contexte
Ces dernières années, avec l'évolution continue des accélérateurs GPU et l'émergence de diverses technologies d'optimisation logicielle, l'efficacité informatique de la formation en apprentissage profond est constamment portée à un nouveau niveau. Mais dans le même temps, l'apprentissage en profondeur reste essentiellement un type de tâche multi-étapes et multi-ressources : il nécessite non seulement une grande quantité de calculs d'entraînement sur le GPU, mais nécessite également souvent un pipeline de prétraitement des données côté CPU (comme comme l'amélioration des données, la conversion des caractéristiques, etc.), etc.), ce type de calcul de prétraitement est une étape nécessaire pour former un modèle de haute qualité. Par conséquent, l'amélioration des performances d'entraînement côté GPU entraîne également une plus grande pression de prétraitement des données, faisant de ce dernier un nouveau goulot d'étranglement des performances.
Nous observons que les goulots d'étranglement du prétraitement des données ont un impact profond à la fois sur les performances de formation des tâches et sur l'efficacité de l'utilisation des ressources du cluster. D'une part, pour une seule tâche d'entraînement, le goulot d'étranglement du prétraitement des données signifie la perte de performances d'entraînement. Nous avons effectué un test de performances en utilisant un GPU et différents nombres de vCPU sur une machine virtuelle équipée de 8 GPU V100 et de 64 cœurs vCPU pour observer combien de vCPU sont nécessaires pour différents modèles afin d'obtenir des performances optimales. Les résultats montrent (ci-dessous) que la plupart des modèles ont besoin de plus de 8 vCPU (c'est-à-dire le nombre moyen de vCPU qu'un GPU peut obtenir) pour atteindre des performances optimales, et certains modèles ont même besoin de consommer 64 vCPU sur les huit cartes de l'ensemble. machine. Cela signifie que ce type de modèle peut ne pas être en mesure d'obtenir suffisamment de ressources CPU dans le cluster partagé, ce qui entraîne une baisse des performances de la partie de prétraitement des données, ce qui affecte finalement l'efficacité de la formation (l'axe vertical sur le côté droit du la figure ci-dessous indique les performances relatives).
D'autre part, les problèmes mentionnés ci-dessus seront plus graves dans les scénarios cloud, affectant l'efficacité de l'allocation des ressources dans les clusters partagés. À l'heure actuelle, les entreprises construisent ou achètent généralement des clusters GPU partagés pour exécuter des tâches de formation, et l'utilisation du GPU est très importante dans ces clusters GPU. Afin d'éviter un processeur insuffisant pour leurs tâches, les utilisateurs peuvent augmenter activement le ratio CPU-GPU des tâches.Cependant, ces ratios CPU-GPU définis par l'utilisateur peuvent facilement conduire à la fragmentation des ressources du cluster. Par exemple, parce que certaines tâches avec un ratio CPU-GPU élevé s'exécutent sur une certaine machine, le CPU est finalement alloué avant le GPU, de sorte que le GPU inactif sur la machine ne sera pas alloué, ce qui entraînera non seulement des ressources GPU coûteuses à perdre, mais aussi Augmenter le temps d'attente des tâches. Nos observations dans le cluster GPU interne d'Alibaba ont révélé que près de 40 % du temps d'attente des tâches était perdu dans cette situation « assez de GPU mais pas assez de CPU ».
Une façon de résoudre les deux problèmes ci-dessus consiste à séparer la formation côté GPU du prétraitement des données côté CPU, de sorte que l'allocation des ressources de ces deux parties du calcul n'ait pas à être liée à la même machine. De cette façon, lorsque les ressources CPU de la machine sont insuffisantes, les ressources d'autres machines peuvent être utilisées.D'une part, plus de ressources CPU peuvent être allouées à une seule tâche pour obtenir l'effet d'accélération, et en même temps, le problème que le GPU fragmenté ne peut pas être alloué peut être atténué. En fait, cette idée n'est pas proposée pour la première fois, mais il existe encore une série de défis techniques pour améliorer l'efficacité des tâches et des clusters de cette manière.
Section Trois : Défis
Bien que certaines solutions (telles que le service tf.data, PyTorch DPP) prennent en charge l'exécution séparée des calculs de prétraitement des données, les défis suivants restent à résoudre dans les technologies existantes :
- Efficacité de la segmentation des calculs : la technologie existante utilise simplement l'API Dataset/DataLoader fournie par le cadre d'apprentissage en profondeur pour séparer les calculs encapsulés dans ces API en tant que calculs de prétraitement des données. Cependant, nous avons constaté que même en dehors de ce type d'API, certains calculs peuvent encore être effectués séparément, et la méthode de segmentation simple manque l'opportunité pour cette partie de l'accélération parallèle.
- Intrusivité du code utilisateur : le service tf.data [1], PyTorch DPP [2] et d'autres technologies permettant d'obtenir une exécution séparée du prétraitement des données nécessitent que l'utilisateur reconstruise cette partie de la logique du code, ce qui est relativement intrusif. Nous espérons obtenir l'effet de réaliser cette séparation d'une manière transparente pour l'utilisateur.
- Combinaison avec l'ordonnancement du cluster : après avoir été séparé de la formation, le calcul du prétraitement des données contient en fait une élasticité inhérente aux ressources, mais aucune des technologies existantes n'exploite cette partie de l'élasticité au niveau de l'ordonnancement du cluster pour améliorer l'efficacité globale d'utilisation des ressources du cluster.
La quatrième plaque : briser le jeu
GoldMiner est un service de prétraitement automatique et élastique des données. Comme le montre la figure, GoldMiner utilise les rôles de travailleur de données (DW) et de travailleur de formation (TW) pour effectuer respectivement le prétraitement des données et la formation. GoldMiner peut automatiquement identifier le calcul de la partie du travailleur de données à partir du code utilisateur d'origine (y compris les calculs qui ne sont pas encapsulés dans l'API Dataset/DataLoader). Dans le même temps, GoldMiner a réalisé la mise à l'échelle élastique des calculs de prétraitement des données, et grâce à la conception collaborative avec le planificateur de cluster, l'efficacité du cluster a encore été améliorée.
La clé pour GoldMiner pour obtenir cet effet est d'utiliser la nature sans état des calculs de prétraitement des données . Sans état signifie ici que le prétraitement des données ne dépend pas des paramètres du modèle, et que les paramètres du modèle doivent être mis à jour à plusieurs reprises à chaque itération de la formation, de sorte que les calculs qui ne dépendent pas des paramètres du modèle peuvent être effectués de manière asynchrone avec la partie formation. Nous savons que les calculs d'apprentissage en profondeur peuvent être exprimés sous la forme d'un graphe de flux de données (DFG). GoldMiner y trouve automatiquement les sous-graphes sans état grâce à l'analyse du DFG de l'utilisateur. La figure ci-dessous est le DFG d'un modèle de recommandation typique. Différent de la méthode de division directe du jeu de données (partition simple dans la figure), GoldMiner étend automatiquement la portée de la segmentation à certaines opérations de conversion de caractéristiques ultérieures en identifiant la relation de dépendance avec le modèle. paramètres (partition attendue). Les expériences montrent que grâce à cette expansion, nous pouvons encore augmenter l'effet de l'accélération parallèle des travailleurs de données de 1,6 fois.
Sur la base de la segmentation automatique des graphiques, GoldMiner réalise en outre l'accélération parallèle de certains sous-graphes de travailleurs de données parmi plusieurs travailleurs de données et le transfert de données entre les travailleurs de données et les travailleurs de formation. Tirant parti de la nature sans état des travailleurs de données, cette exécution distribuée permet une mise à l'échelle dynamique du nombre de travailleurs de données, permettant une utilisation plus efficace des ressources lors du processus de modification des ressources inactives du cluster.
Afin de tirer pleinement parti de l'élasticité des ressources des travailleurs de données, GoldMiner fournit un planificateur de travailleurs de données, qui effectuera des ajustements dynamiques des ressources au niveau des tâches et des clusters. Pour chaque tâche, GoldMiner ajuste la taille de ses DW et TW pour rechercher une configuration avec l'efficacité d'expansion la plus élevée ; dans la dimension de cluster, GoldMiner ajuste dynamiquement la répartition des travailleurs de données entre différentes tâches pour optimiser certains objectifs de planification globaux (tels que Minimize temps de réalisation de la tâche). Ces deux couches d'ajustement utilisent un indice de performance unifié, c'est-à-dire la file d'attente qui transfère les données entre DW et TW. L'état de cette file d'attente reflète la vitesse relative de DW et TW, ainsi que les avantages potentiels de l'augmentation de DW. Des expériences dans un cluster de 64 GPU montrent que le planificateur GoldMiner peut raccourcir le temps moyen d'exécution des tâches de 2,5 fois et augmenter le taux d'allocation du GPU de 2,1 fois.
Le cinquième bloc : application
Nous avons précédemment évalué l'effet de GoldMiner sur le modèle de recommandation réel du client, et les résultats montrent que GoldMiner peut accélérer le modèle utilisateur de 1,43 fois et réduire le coût de formation de 13 %. Actuellement en déploiement.
Dans le même temps, nous avons également développé une implémentation de la version PyTorch, et nous intégrerons bientôt PAI-DLC pour offrir aux utilisateurs la possibilité d'accélérer le prétraitement des données.
Sixième plat :
- 论文名字：GoldMiner : mise à l'échelle élastique des pipelines de prétraitement des données de formation pour l'apprentissage en profondeur
- Auteurs de l'article : Zhao Hanyu, Yang Zhi, Cheng Yu, Tian Chao, Ren Shiru, Xiao Wencong, Yuan Man, Chen Langshi, Liu Kaibo, Zhang Yang, Li Yong, Lin Wei
- Lien pdf papier : https://dl.acm.org/doi/pdf/10.1145/3589773
- les références:
[1] Andrew Audibert, Yang Chen, Dan Graur, Ana Klimovic, Jiri Simsa, Chandramohan A. Thekkath. Un cas pour la désagrégation du traitement des données ML. https://arxiv.org/abs/2210.14826
[2] Mark Zhao, Niket Agarwal, Aarti Basant, Bugra Gedik, Satadru Pan, Mustafa Ozdal, Rakesh Komuravelli, Jerry Pan, Tianshu Bao, Haowei Lu, Sundaram Narayanan, Jack Langman, Kevin Wilfong, Harsha Rastogi, Carole-Jean Wu, Christos Kozyrakis, Parik Pol. Comprendre le stockage et l'ingestion de données pour la formation de modèles de recommandation approfondie à grande échelle. ISCA'22