Ces dernières années ont montré une croissance étonnante des réseaux de neurones d'apprentissage en profondeur (DNN). Cette croissance se voit dans des modèles plus précis et ouvre même de nouvelles possibilités avec l'IA générative : grands modèles de langage (LLM) qui synthétisent le langage naturel, générateurs de texte en image, etc. Ces capacités accrues des DNN s'accompagnent du coût d'avoir des modèles massifs qui nécessitent des ressources de calcul importantes pour être formés. La formation distribuée résout ce problème avec deux techniques : le parallélisme des données et le parallélisme des modèles. Le parallélisme des données est utilisé pour mettre à l'échelle le processus de formation sur plusieurs nœuds et travailleurs, et le parallélisme des modèles divise un modèle et l'adapte à l'infrastructure désignée. Amazon Sage Maker formation distribuée les tâches vous permettent en un clic (ou un appel d'API) de configurer un cluster de calcul distribué, de former un modèle, d'enregistrer le résultat dans Service de stockage simple Amazon (Amazon S3) et arrêtez le cluster lorsque vous avez terminé. De plus, SageMaker a continuellement innové dans l'espace de formation distribué en lançant des fonctionnalités telles que grappes hétérogènes et des bibliothèques de formation distribuées pour parallélisme des données ainsi que parallélisme de modèle.

Une formation efficace sur un environnement distribué nécessite l'ajustement d'hyperparamètres. Un exemple courant de bonne pratique lors de la formation sur plusieurs GPU consiste à multiplier la taille du lot (ou du mini-lot) par le numéro de GPU afin de conserver la même taille de lot par GPU. Cependant, l'ajustement des hyperparamètres a souvent un impact sur la convergence du modèle. Par conséquent, la formation distribuée doit équilibrer trois facteurs : la distribution, les hyperparamètres et la précision du modèle.

Dans cet article, nous explorons l'effet de la formation distribuée sur la convergence et comment utiliser Réglage automatique du modèle Amazon SageMaker pour affiner les hyperparamètres du modèle pour la formation distribuée en utilisant le parallélisme des données.

Le code source mentionné dans cet article se trouve sur le GitHub référentiel (une instance m5.xlarge est recommandée).

Évoluez la formation d'un environnement unique à un environnement distribué

Le parallélisme des données est un moyen d'adapter le processus de formation à plusieurs ressources de calcul et d'obtenir un temps de formation plus rapide. Avec le parallélisme des données, les données sont partitionnées entre les nœuds de calcul, et chaque nœud calcule les gradients en fonction de leur partition et met à jour le modèle. Ces mises à jour peuvent être effectuées à l'aide d'un ou de plusieurs serveurs de paramètres de manière asynchrone, un-à-plusieurs ou tout-à-tout. Une autre façon peut être d'utiliser un algorithme AllReduce. Par exemple, dans l'algorithme ring-allreduce, chaque nœud ne communique qu'avec deux de ses nœuds voisins, réduisant ainsi les transferts de données globaux. Pour en savoir plus sur les serveurs de paramètres et ring-allreduce, voir Lancer facilement la formation distribuée TensorFlow avec Horovod ou les serveurs de paramètres dans Amazon SageMaker. En ce qui concerne le partitionnement des données, s'il existe n nœuds de calcul, alors chaque nœud devrait obtenir un sous-ensemble des données, environ 1/n en taille.

Pour démontrer l'effet de la formation à l'échelle sur la convergence du modèle, nous exécutons deux expériences simples :

Chaque formation de modèle a été exécutée deux fois : sur une seule instance et répartie sur plusieurs instances. Pour la formation distribuée DNN, afin d'utiliser pleinement les processeurs distribués, nous avons multiplié la taille du mini-lot par le nombre d'instances (quatre). Le tableau suivant résume la configuration et les résultats.

Pour les deux modèles, le temps de formation a été réduit presque linéairement par le facteur de distribution. Cependant, la convergence des modèles a subi une baisse significative. Ce comportement est cohérent pour les deux modèles différents, les différentes instances de calcul, les différentes méthodes de distribution et les différents types de données. Alors, pourquoi la distribution du processus de formation a-t-elle affecté la précision du modèle ?

Plusieurs théories tentent d'expliquer cet effet :

• Lorsque les mises à jour de tenseurs sont volumineuses, le trafic entre les nœuds de calcul et le serveur de paramètres peut être encombré. Par conséquent, les serveurs de paramètres asynchrones subiront une convergence bien pire en raison des retards dans les mises à jour des poids [1].
• L'augmentation de la taille des lots peut entraîner un sur-ajustement et une mauvaise généralisation, réduisant ainsi la précision de la validation [2].
• Lors de la mise à jour asynchrone des paramètres de modèle, certains DNN peuvent ne pas utiliser les pondérations de modèle mises à jour les plus récentes ; par conséquent, ils calculeront des gradients basés sur des poids qui ont quelques itérations de retard. Cela conduit à un poids périmé [3] et peut être causé par un certain nombre de raisons.
• Certains hyperparamètres sont spécifiques au modèle ou à l'optimiseur. Par exemple, la documentation officielle de XGBoost indique que le exact valeur pour le tree_mode l'hyperparamètre ne prend pas en charge la formation distribuée car XGBoost utilise la distribution de données de fractionnement de ligne alors que le exact La méthode tree fonctionne sur un format de colonne triée.
• Certains chercheurs ont proposé que la configuration d'un mini-lot plus grand puisse conduire à des gradients avec moins de stochasticité. Cela peut se produire lorsque la fonction de perte contient des minima locaux et des points de selle et qu'aucun changement n'est apporté à la taille du pas, l'optimisation restant bloquée dans ces minima locaux ou point de selle [4].

Optimiser pour la formation distribuée

L'optimisation des hyperparamètres (HPO) est le processus de recherche et de sélection d'un ensemble d'hyperparamètres optimaux pour un algorithme d'apprentissage. SageMaker Automatic Model Tuning (AMT) fournit HPO en tant que service géré en exécutant plusieurs tâches de formation sur l'ensemble de données fourni. SageMaker AMT recherche les plages d'hyperparamètres que vous spécifiez et renvoie les meilleures valeurs, telles que mesurées par une métrique que vous choisissez. Vous pouvez utiliser SageMaker AMT avec les algorithmes intégrés ou utiliser vos algorithmes et conteneurs personnalisés.

Cependant, l'optimisation pour la formation distribuée diffère du HPO commun car au lieu de lancer une seule instance par tâche de formation, chaque tâche lance en fait un cluster d'instances. Cela signifie un impact plus important sur les coûts (surtout si vous considérez les instances coûteuses accélérées par GPU, qui sont typiques pour DNN). En plus de Limites AMT, vous pourriez éventuellement frapper Limites du compte SageMaker pour le nombre simultané d'instances de formation. Enfin, le lancement de clusters peut introduire des frais généraux opérationnels en raison d'un temps de démarrage plus long. SageMaker AMT dispose de fonctionnalités spécifiques pour résoudre ces problèmes. Hyperbande avec arrêt anticipé garantit que les configurations d'hyperparamètres performantes sont affinées et que celles qui sont sous-performantes sont automatiquement arrêtées. Cela permet une utilisation efficace du temps de formation et réduit les coûts inutiles. De plus, SageMaker AMT prend entièrement en charge l'utilisation des instances ponctuelles Amazon EC2, qui peuvent optimiser la coût de la formation jusqu'à 90% sur les instances à la demande. En ce qui concerne les temps de démarrage longs, SageMaker AMT réutilise automatiquement les instances de formation dans chaque tâche de réglage, réduisant ainsi le temps de démarrage moyen de chaque travail de formation par 20 fois. De plus, vous devez suivre Bonnes pratiques AMT, telles que le choix des hyperparamètres pertinents, leurs plages et échelles appropriées et le meilleur nombre de tâches de formation simultanées, et la définition d'une graine aléatoire pour reproduire les résultats.

Dans la section suivante, nous voyons ces fonctionnalités en action lorsque nous configurons, exécutons et analysons une tâche AMT à l'aide de l'exemple XGBoost dont nous avons parlé précédemment.

Configurer, exécuter et analyser une tâche de réglage

Comme mentionné précédemment, le code source peut être trouvé sur le GitHub repo. Aux étapes 1 à 5, nous téléchargeons et préparons les données, créons le xgb3 (l'estimateur XGBoost distribué est configuré pour utiliser trois instances), exécutez les tâches d'entraînement et observez les résultats. Dans cette section, nous décrivons comment configurer la tâche de réglage pour cet estimateur, en supposant que vous avez déjà suivi les étapes 1 à 5.

Une tâche de réglage calcule les hyperparamètres optimaux pour les tâches de formation qu'elle lance en utilisant une métrique pour évaluer les performances. Tu peux configurez votre propre métrique, que SageMaker analysera en fonction de l'expression régulière que vous configurez et émettez à stdout, ou utilisez les métriques de Algorithmes intégrés SageMaker. Dans cet exemple, nous utilisons le métrique d'objectif XGBoost intégrée, nous n'avons donc pas besoin de configurer une regex. Pour optimiser la convergence du modèle, nous optimisons en fonction de la métrique AUC de validation :

objective_metric_name="validation:auc"

Nous accordons sept hyperparamètres :

• num_round – Nombre de tours pour booster pendant l'entraînement.
• eta - Réduction de la taille des pas utilisée dans les mises à jour pour éviter le surajustement.
• Alpha – Terme de régularisation L1 sur les poids.
• min_child_weight – Somme minimale de poids d'instance (hesse) nécessaire chez un enfant. Si l'étape de partition de l'arborescence aboutit à un nœud feuille avec la somme du poids de l'instance inférieure à min_child_weight, le processus de construction renonce à un partitionnement supplémentaire.
• profondeur max – Profondeur maximale d'un arbre.
• colsample_bylevel – Rapport de sous-échantillonnage des colonnes pour chaque fractionnement, à chaque niveau. Ce sous-échantillonnage a lieu une fois pour chaque nouveau niveau de profondeur atteint dans un arbre.
• colsample_bytree – Rapport de sous-échantillonnage des colonnes lors de la construction de chaque arbre. Pour chaque arbre construit, le sous-échantillonnage a lieu une fois.

Pour en savoir plus sur les hyperparamètres XGBoost, consultez Hyperparamètres XGBoost. Le code suivant montre les sept hyperparamètres et leurs plages :

hyperparameter_ranges = { "num_round": IntegerParameter(100, 200), "eta": ContinuousParameter(0, 1), "min_child_weight": ContinuousParameter(1, 10), "alpha": ContinuousParameter(0, 2), "max_depth": IntegerParameter(1, 10), "colsample_bylevel": ContinuousParameter(0, 1), "colsample_bytree": ContinuousParameter(0, 1),
}

Ensuite, nous fournissons le configuration pour la stratégie Hyperband et la configuration de l'objet tuner à l'aide du SDK SageMaker. HyperbandStrategyConfig peut utiliser deux paramètres : max_resource (facultatif) pour le nombre maximal d'itérations à utiliser pour une tâche d'entraînement pour atteindre l'objectif, et min_resource – le nombre minimal d'itérations à utiliser par une tâche d'apprentissage avant d'arrêter l'apprentissage. Nous utilisons HyperbandStrategyConfig configurer StrategyConfig, qui est ensuite utilisé par la définition de la tâche de réglage. Voir le code suivant :

hsc = HyperbandStrategyConfig(max_resource=30, min_resource=1)
sc = StrategyConfig(hyperband_strategy_config=hsc)

Maintenant, nous créons un HyperparameterTuner objet, auquel nous transmettons les informations suivantes :

• L'estimateur XGBoost, configuré pour s'exécuter avec trois instances
• Le nom et la définition de la métrique objective
• Nos gammes d'hyperparamètres
• Réglage des configurations de ressources telles que le nombre de tâches de formation à exécuter au total et le nombre de tâches de formation pouvant être exécutées en parallèle
• Paramètres Hyperband (la stratégie et la configuration que nous avons configurées à la dernière étape)
• Arrêt précoce (early_stopping_type) mis à Off

Pourquoi définissons-nous l'arrêt anticipé sur Désactivé ? Les tâches de formation peuvent être arrêtées prématurément lorsqu'elles ne sont pas susceptibles d'améliorer la métrique objective de la tâche de réglage des hyperparamètres. Cela peut aider à réduire le temps de calcul et à éviter de sur-ajuster votre modèle. Cependant, Hyperband utilise un mécanisme intégré avancé pour appliquer un arrêt anticipé. Par conséquent, le paramètre early_stopping_type doit être réglé sur Off lors de l'utilisation de la fonction d'arrêt anticipé interne Hyperband. Voir le code suivant :

tuner = HyperparameterTuner( xgb3, objective_metric_name, hyperparameter_ranges, max_jobs=30, max_parallel_jobs=4, strategy="Hyperband", early_stopping_type="Off", strategy_config=sc
)

Enfin, nous commençons le travail de réglage automatique du modèle en appelant le s'adapter méthode. Si vous souhaitez lancer la tâche de manière asynchrone, définissez wait à False. Voir le code suivant:

tuner.fit(
{"train": s3_input_train, "validation": s3_input_validation},
include_cls_metadata=False,
wait=True,
)

Vous pouvez suivre la progression et le résumé de la tâche sur la console SageMaker. Dans le volet de navigation, sous Formation, choisissez Tâches de réglage d'hyperparamètres, puis choisissez la tâche de réglage appropriée. La capture d'écran suivante montre la tâche de réglage avec des détails sur l'état et les performances des tâches de formation.

Lorsque le travail de réglage est terminé, nous pouvons examiner les résultats. Dans l'exemple de bloc-notes, nous montrons comment extraire les résultats à l'aide du SDK SageMaker. Tout d'abord, nous examinons comment le travail de réglage a augmenté la convergence du modèle. Vous pouvez joindre le HyperparameterTuner objet en utilisant le nom du travail et appelez le décrire méthode. La méthode renvoie un dictionnaire contenant les métadonnées et les résultats de la tâche de réglage.

Dans le code suivant, nous récupérons la valeur de la tâche de formation la plus performante, telle que mesurée par notre métrique objective (validation AUC) :

tuner = HyperparameterTuner.attach(tuning_job_name=tuning_job_name)
tuner.describe()["BestTrainingJob"]["FinalHyperParameterTuningJobObjectiveMetric"]["Value"]

Le résultat est de 0.78 en AUC sur l'ensemble de validation. C'est une amélioration significative par rapport au 0.63 initial !

Voyons ensuite à quelle vitesse notre tâche d'entraînement s'est déroulée. Pour cela, nous utilisons le HyperparameterTuningJobAnalytics dans le SDK pour récupérer les résultats de la tâche de réglage et les lire dans une trame de données Pandas à des fins d'analyse et de visualisation :

tuner_analytics = sagemaker.HyperparameterTuningJobAnalytics(tuning_job_name)
full_df = tuner_analytics.dataframe()
full_df.sort_values(by=["FinalObjectiveValue"], ascending=False).head()

Voyons le temps moyen d'une tâche d'entraînement avec la stratégie Hyperband :

full_df["TrainingElapsedTimeSeconds"].mean()

Le temps moyen était d'environ 1 minute. Ceci est cohérent avec le mécanisme de stratégie Hyperband qui arrête tôt les tâches de formation sous-performantes. En termes de coût, le travail de réglage nous a facturé un total de 30 minutes de temps de formation. Sans l'arrêt anticipé d'Hyperband, la durée totale de formation facturable devait être de 90 minutes (30 tâches * 1 minute par tâche * 3 instances par tâche). C'est trois fois mieux en termes d'économies ! Enfin, nous voyons que la tâche de réglage a exécuté 30 tâches de formation et a pris un total de 12 minutes. C'est presque 50 % de moins que le temps prévu (30 tâches/4 tâches en parallèle * 3 minutes par tâche).

Conclusion

Dans cet article, nous avons décrit certains problèmes de convergence observés lors de la formation de modèles avec des environnements distribués. Nous avons vu que SageMaker AMT utilisant Hyperband répondait aux principales préoccupations que l'optimisation de la formation distribuée parallèle aux données introduisait : la convergence (qui s'améliorait de plus de 10 %), l'efficacité opérationnelle (la tâche de réglage prenait 50 % moins de temps qu'une tâche séquentielle non optimisée). ont pris) et la rentabilité (30 contre les 90 minutes facturables de temps de travail de formation). Le tableau suivant résume nos résultats :

Afin d'affiner la mise à l'échelle (taille du cluster), vous pouvez répéter le travail de réglage avec plusieurs configurations de cluster et comparer les résultats pour trouver les hyperparamètres optimaux qui satisfont la vitesse et la précision du modèle.

Nous avons inclus les étapes pour y parvenir dans la dernière section du cahier.

Bibliographie

[1] Lian, Xiangru, et al. "Descente de gradient stochastique parallèle décentralisée asynchrone." Conférence internationale sur l'apprentissage automatique. PMLR, 2018.

[2] Keskar, Nitish Shirish, et al. "Sur la formation en gros lots pour l'apprentissage en profondeur: écart de généralisation et minima pointus." arXiv preprint arXiv: 1609.04836 (2016).

[3] Dai, Wei et al. "Pour comprendre l'impact de l'obsolescence dans l'apprentissage automatique distribué." arXiv preprint arXiv: 1810.03264 (2018).

[4] Dauphin, Yann N., et al. "Identifier et attaquer le problème du point de selle dans l'optimisation non convexe de grande dimension." Progrès des systèmes de traitement de l'information neuronale 27 (2014).

À propos de l’auteur

Uri Rosenberg est le responsable technique spécialisé en IA et ML pour l'Europe, le Moyen-Orient et l'Afrique. Basé en Israël, Uri s'efforce de permettre aux entreprises clientes de concevoir, créer et exploiter des charges de travail ML à grande échelle. Dans ses temps libres, il aime faire du vélo, de la randonnée et se plaindre de la préparation des données.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Automobile / VE, Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• Décalages de bloc. Modernisation de la propriété des compensations environnementales. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/effectively-solve-distributed-training-convergence-issues-with-amazon-sagemaker-hyperband-automatic-model-tuning/