AIMaster améliore la stabilité et la continuité des tâches d'apprentissage profond distribué à grande échelle. Il résout les problèmes tels que les anomalies logicielles et matérielles, les blocages de tâches et les défaillances d'instances en fournissant une surveillance des tâches, des décisions de tolérance aux pannes et un contrôle des ressources.
Contexte
L'apprentissage profond est largement utilisé. À mesure que les modèles et les données prennent de l'ampleur, l'entraînement distribué devient une pratique courante. Avec l'augmentation du nombre d'instances de tâches, les anomalies logicielles et matérielles peuvent entraîner des échecs de tâches.
Pour garantir le fonctionnement stable des tâches d'apprentissage profond distribué à grande échelle, DLC propose une fonctionnalité de surveillance de tolérance aux pannes basée sur AIMaster. AIMaster est un composant au niveau de la tâche. Lorsque vous activez cette fonctionnalité, une instance AIMaster s'exécute parallèlement aux autres instances de votre tâche pour fournir une surveillance des tâches, des décisions de tolérance aux pannes et un contrôle des ressources.
Limites
AIMaster prend actuellement en charge les frameworks suivants : PyTorch, MPI, TensorFlow et ElasticBatch.
Étape 1 : Activer la surveillance de tolérance aux pannes
Vous pouvez activer la fonctionnalité de surveillance de tolérance aux pannes dans la console ou via un SDK lors de la soumission d'une tâche d'entraînement DLC.
Dans la console
Lorsque vous soumettez une tâche d'entraînement DLC dans la console, accédez à la section Fault Tolerance and Diagnosis, activez l'option Automatic Fault Tolerance et configurez les paramètres supplémentaires. Pour plus d'informations, consultez la rubrique Créer une tâche d'entraînement. DLC démarre alors un rôle AIMaster supplémentaire pour surveiller la tâche tout au long de son cycle de vie et effectuer une tolérance aux pannes en cas d'erreurs.
Détails :
Vous pouvez configurer des paramètres supplémentaires dans la zone de texte Other Cofiguration. Pour le détail des paramètres, consultez la rubrique Annexe : Paramètres de tolérance aux pannes.
-
Après avoir activé Hanging Detection, vous pouvez activer la fonctionnalité C4D Detection. C4D (Calibrating Collective Communication over Converged ethernet - Diagnosis) est un outil de diagnostic développé par Alibaba Cloud pour diagnostiquer les tâches lentes ou bloquées lors de l'entraînement de grands modèles. Pour plus d'informations, consultez la rubrique Utiliser C4D.
RemarqueC4D dépend de ACCL (bibliothèque de communication collective haute performance d'Alibaba Cloud). Assurez-vous que ACCL est installé. Pour plus d'informations, consultez la rubrique ACCL : bibliothèque de communication collective haute performance d'Alibaba Cloud.
Actuellement, la détection C4D est disponible pour les tâches DLC qui utilisent Lingjun AI Computing Service.
Après avoir activé Hanging Detection, vous pouvez utiliser l'outil d'analyse des instantanés de la pile d'appels de fonctions pour localiser la ligne de code exacte où se produit un blocage de tâche. Vous devez configurer le seuil de détection de blocage pour que cet outil fonctionne correctement. Pour plus d'informations, consultez la rubrique « Utiliser l'outil d'analyse des instantanés de la pile d'appels de fonctions ».
Via le SDK DLC
Étape 2 : Configurer les fonctionnalités avancées
Sélectionnez parmi les fonctionnalités avancées suivantes en fonction de vos besoins de surveillance.
Configurer les notifications de tolérance aux pannes
Après avoir activé la surveillance de tolérance aux pannes pour une tâche, vous pouvez configurer des notifications pour les événements de tolérance aux pannes. Dans la page Workspace Details, choisissez Configure Workspace > Configure Event Notification. Ensuite, cliquez sur Create Event Rule et définissez le type d'événement sur DLC task > Automatic Fault Tolerance. Pour plus d'informations, consultez la rubrique Centre d'événements de l'espace de travail.
Lorsqu'une tâche d'entraînement rencontre une exception, telle qu'une perte NaN, vous pouvez utiliser le SDK AIMaster dans votre code pour envoyer un message de notification personnalisé :
Pour utiliser cette fonctionnalité, vous devez installer le package wheel AIMaster. Pour plus d'informations, consultez la rubrique FAQ.
from aimaster import job_monitor as jm
job_monitor_client = jm.Monitor(config=jm.PyTorchConfig())
...
if loss == Nan and rank == 0:
st = job_monitor_client.send_custom_message(content="The training loss of the job is NaN.")
if not st.ok():
print('failed to send message, error %s' % st.to_string())Configurer des mots-clés d'erreur personnalisés pouvant être réessayés
La surveillance de tolérance aux pannes inclut une détection intégrée des erreurs courantes pouvant être réessayées. Si vous souhaitez qu'AIMaster effectue une tolérance aux pannes lorsque des mots-clés spécifiques apparaissent dans les journaux d'une instance ayant échoué, vous pouvez les configurer dans votre code. Après configuration, le module de surveillance analyse la fin du journal de l'instance ayant échoué pour rechercher ces mots-clés.
La politique de tolérance aux pannes doit être définie sur ExitCodeAndErrorMsg.
-
Exemple de configuration de mots-clés d'erreur personnalisés pouvant être réessayés pour une tâche PyTorch
from aimaster import job_monitor as jm jm_config_params = {} jm_config = jm.PyTorchConfig(**jm_config_params) monitor = jm.Monitor(config=jm_config) monitor.set_retryable_errors(["connect timeout", "error_yyy", "error_zzz"])Les paramètres configurés dans monitor.set_retryable_errors sont les mots-clés d'erreur personnalisés pouvant être réessayés.
-
Exemple de configuration de mots-clés d'erreur personnalisés pouvant être réessayés pour une tâche TensorFlow
from aimaster import job_monitor as jm jm_config_params = {} jm_config = jm.TFConfig(**jm_config_params) monitor = jm.Monitor(config=jm_config) monitor.set_retryable_errors(["connect timeout", "error_yyy", "error_zzz"])
Configurer la détection de blocage de tâche par étapes
Par défaut, la configuration de détection de blocage s'applique à l'ensemble de la tâche. Cependant, les tâches s'exécutent souvent en plusieurs étapes distinctes. Par exemple, la communication entre nœuds lors de l'initialisation peut prendre plus de temps que pendant l'étape d'entraînement, où les journaux sont mis à jour plus fréquemment. Pour détecter rapidement un blocage de tâche pendant le processus d'entraînement, DLC propose une fonctionnalité de détection de blocage par étapes. Cela vous permet de configurer différents intervalles de détection de blocage pour différentes étapes de la tâche. Configurez-la comme suit :
monitor.reset_config(jm_config_params)
# Example:
# monitor.reset_config(job_hang_interval=10)
# or
# config_params = {"job_hang_interval": 10, }
# monitor.reset_config(**config_params)Voici un exemple de détection de blocage par étapes pour une tâche PyTorch.
import torch
import torch.distributed as dist
from aimaster import job_monitor as jm
jm_config_params = {
"job_hang_interval": 1800 # Global 30-minute detection.
}
jm_config = jm.PyTorchConfig(**jm_config_params)
monitor = jm.Monitor(config=jm_config)
dist.init_process_group('nccl')
...
# impl these two funcs in aimaster sdk
# user just need to add annotations to their func
def reset_hang_detect(hang_seconds):
jm_config_params = {
"job_hang_interval": hang_seconds
}
monitor.reset_config(**jm_config_params)
def hang_detect(interval):
reset_hang_detect(interval)
...
@hang_detect(180) # Reset hang detection to 3 minutes, for this function's scope only.
def train():
...
@hang_detect(-1) # Disable hang detection temporarily, for this function's scope only.
def test():
...
for epoch in range(0, 100):
train(epoch)
test(epoch)
self.scheduler.step()
Utiliser C4D
C4D (Calibrating Collective Communication over Converged ethernet - Diagnosis) est un outil développé par Alibaba Cloud pour diagnostiquer les tâches lentes ou bloquées lors de l'entraînement de grands modèles. C4D dépend de la bibliothèque de communication collective haute performance d'Alibaba Cloud (ACCL). Assurez-vous que ACCL est installé et que les variables d'environnement sont correctement configurées. Pour plus d'informations, consultez la rubrique ACCL : bibliothèque de communication collective haute performance d'Alibaba Cloud. Actuellement, vous pouvez utiliser la fonctionnalité de détection C4D lorsque vous sélectionnez Lingjun AI Computing Service pour une tâche DLC.
Présentation de la fonctionnalité
C4D agrège les informations d'état de tous les nœuds d'une tâche pour déterminer si un nœud présente des problèmes au niveau de la couche de communication ou ailleurs.
Tous les paramètres
Après avoir activé la fonctionnalité de détection C4D, vous pouvez configurer les paramètres suivants dans la zone de texte Other Configurations :
Paramètre | Description | Valeur d'exemple |
--c4d-log-level | Définit le niveau de journal de sortie C4D. Valeurs valides :
La valeur par défaut est Warning, qui génère des journaux aux niveaux Warning et Error. Nous recommandons d'utiliser la valeur par défaut pour un fonctionnement normal. Pour résoudre les problèmes de performances, vous pouvez définir le niveau sur Info. |
|
--c4d-common-envs | Définissez les variables d'environnement pour l'exécution de C4D. Le format est
|
|
Pour les journaux de niveau erreur, AIMaster isole automatiquement le nœud correspondant et redémarre la tâche. La logique de traitement pour chaque niveau de journal est la suivante :
Niveau d'erreur | Description | Actions |
Error | Par défaut, un blocage de tâche au niveau de la couche de communication qui dépasse trois minutes entraîne l'échec de la tâche. Vous pouvez modifier ce paramètre par défaut en configurant les paramètres C4D_HANG_TIMEOUT et C4D_HANG_TIMES. | AIMaster isole automatiquement le nœud signalé dans le journal. |
Warning | Par défaut, un blocage de tâche au niveau de la couche de communication qui dépasse 10 secondes affecte les performances mais n'entraîne pas l'échec de la tâche. Vous pouvez modifier ce paramètre par défaut en configurant le paramètre C4D_HANG_TIMEOUT. | Aucune isolation automatique des nœuds. Une confirmation manuelle est requise. |
Un blocage de tâche hors couche de communication qui dépasse 10 secondes peut entraîner l'échec de la tâche. | Aucune isolation automatique des nœuds. Une confirmation manuelle est requise. | |
Info | Lenteur au niveau de la couche de communication et hors couche de communication. | Ces journaux de diagnostic concernent principalement les problèmes de performances et nécessitent une confirmation manuelle. |
Si vous constatez qu'une tâche DLC s'exécute lentement ou est bloquée, accédez à la liste des tâches DLC et cliquez sur le nom de la tâche pour ouvrir la page de présentation de la tâche. Dans la section Instances, consultez le journal du nœud AIMaster pour voir les résultats de diagnostic C4D. Pour plus d'informations sur les résultats du diagnostic, consultez la rubrique Exemples de résultats de diagnostic.
Exemples de résultats de diagnostic
RankCommHang : indique qu'un nœud présente un blocage au niveau de la couche de communication.
RankNonCommHang : indique qu'un nœud présente un blocage en dehors de la couche de communication, tel qu'un blocage dans le processus de calcul.
RankCommSlow : indique qu'un nœud est lent au niveau de la couche de communication.
RankNonCommSlow : indique qu'un nœud est lent en dehors de la couche de communication.
Analyser les instantanés de la pile d'appels
Un problème fréquent lors de l'entraînement de grands modèles est le blocage d'une tâche (job hang). L'un des types les plus courants est un blocage NCCL, qui génère généralement une entrée de journal telle que « Watchdog caught collective operation timeout ». Pour vous aider à identifier rapidement la cause racine des blocages de tâches, nous avons développé l'outil d'analyse des instantanés de la pile d'appels de fonctions. Suivez ces étapes pour l'utiliser :
Étape 1 : Installer pystack ou py-spy
Commencez par vérifier si pystack ou py-spy est installé dans l'image de votre conteneur. Si ce n'est pas le cas, vous devez en installer un. Par exemple, utilisez la commande suivante pour installer pystack :
pip install pystack -i https://mirrors.cloud.aliyuncs.com/pypi/simple/ --trusted-host mirrors.cloud.aliyuncs.comÉtape 2 : Activer la détection des blocages
Pour savoir comment activer la détection des blocages, reportez-vous à la section Dans la console. Pour que l'outil d'analyse des instantanés de la pile d'appels de fonctions fonctionne correctement, vous devez également définir une valeur appropriée pour le seuil de détection des blocages. Déterminez d'abord la valeur du délai d'expiration (timeout) de votre tâche de modèle. Vous pouvez généralement trouver cette information dans le journal d'erreurs après qu'une tâche s'est bloquée. Par exemple :
Watchdog caught collective operation timeout: WorkNCCL(SeqNum=2143, OpType=ALLREDUCE, NumelIn=659, NumelOut=659, Timeout(ms)=600000) ran for 600535 milliseconds before timing outÀ partir du champ Timeout de ce journal d'erreurs, vous pouvez voir que le délai d'expiration de la tâche est de 600 000 millisecondes (600 secondes ou 10 minutes). Dans ce cas, nous vous recommandons de définir le seuil de détection des blocages à 450 secondes. Si la valeur Timeout de votre journal est de 1 800 secondes, nous vous recommandons de définir le seuil à 1 500 secondes. En règle générale, le seuil de détection des blocages doit être inférieur d'environ 150 à 200 secondes à la valeur du délai d'expiration de la tâche.
Une fois la détection des blocages correctement configurée, AIMaster collecte et analyse automatiquement la pile d'appels de fonctions du processus de la tâche lorsqu'un blocage se produit. Vous pouvez consulter le résultat de l'analyse dans le journal du nœud AIMaster. Voici un exemple de résultat d'analyse fourni par l'outil après un blocage de tâche :
Dans le résultat de l'analyse, le champ stack affiche la pile d'appels de fonctions, le champ threads répertorie les threads où cette pile est apparue, et le champ count indique le nombre de threads présentant cette pile. Les piles avec un count de 1 sont très probablement la cause du blocage de la tâche et doivent être examinées en priorité.
Étape 3 : Consulter les raisons du redémarrage
-
Consultez les cycles de redémarrage : Les informations de redémarrage de la tâche sont organisées par cycle. Sur la page des détails de la tâche, vous pouvez développer les détails d'un cycle pour afficher des informations telles que le temps passé à chaque étape. Cela vous aide à comprendre plus précisément l'état d'exécution de la tâche.
-
Consultez l'historique des redémarrages : Vous pouvez cliquer sur le nombre de redémarrages ou sur l'onglet Restart records pour afficher les informations de redémarrage pertinentes, y compris la raison du redémarrage, le résultat et la durée.
Procédure :
Dans la liste Restart records, cliquez sur Description pour afficher les informations détaillées d'un redémarrage spécifique, y compris les champs Restarts, Restart Time, Node Name, Instance Name, Error Code, Error Message et Error Source.
-
Cliquez sur View Aggregation Fault Details pour développer la liste complète des détails de tous les enregistrements de redémarrage.
Annexe : Paramètres de tolérance aux pannes
Cette section décrit tous les paramètres de la fonctionnalité de surveillance de la tolérance aux pannes. Vous pouvez vous référer aux exemples de configuration de paramètres courants pour planifier vos réglages. Lorsque vous activez la surveillance de la tolérance aux pannes, vous pouvez configurer ces paramètres dans la section Other Cofiguration selon vos besoins.
Tous les paramètres
Configuration générale
Fonctionnalité | Paramètre | Description | Valeur par défaut |
Mode d'exécution de la tâche | --job-execution-mode | Le mode d'exécution de la tâche. Valeurs valides :
Le comportement de tolérance aux pannes diffère selon le type de tâche pour les erreurs pouvant faire l'objet d'une nouvelle tentative :
| Sync |
Paramètres de redémarrage de la tâche | --enable-job-restart | Indique s'il faut autoriser la tâche à redémarrer lorsque les conditions de tolérance aux pannes sont remplies ou qu'une exception d'exécution est détectée. Valeurs valides :
| False |
--max-num-of-job-restart | Le nombre maximal de fois où la tâche peut redémarrer. Si ce nombre est dépassé, la tâche échoue. | 3 |
Configuration d'exécution
S'applique aux scénarios où aucune instance n'a échoué.
Fonctionnalité | Paramètre | Description | Valeur par défaut |
Détection des blocages de tâche | --enable-job-hang-detection | Indique s'il faut activer la détection des blocages d'exécution pour la tâche. Cette fonctionnalité prend uniquement en charge les tâches synchrones. Valeurs valides :
| False |
--job-hang-interval | La durée en secondes pendant laquelle une tâche peut être suspendue. Il doit s'agir d'un entier positif. Si la durée de suspension dépasse cette valeur, la tâche est considérée comme anormale et redémarre. | 1800 | |
--enable-c4d-hang-detection | Indique s'il faut activer la détection C4D pour diagnostiquer et localiser rapidement les nœuds lents et les nœuds défaillants qui provoquent un blocage de la tâche pendant l'exécution. Remarque Ce paramètre prend effet uniquement lorsque le paramètre --enable-job-hang-detection est également activé. | False | |
Détection des blocages à la sortie de la tâche | --enable-job-exit-hang-detection | Indique s'il faut activer la détection des blocages lors de la sortie de la tâche. Cette fonctionnalité prend uniquement en charge les tâches synchrones. Valeurs valides :
| False |
--job-exit-hang-interval | La durée en secondes pendant laquelle une tâche peut être suspendue lors de la sortie. Il doit s'agir d'un entier positif. Si la durée de sortie dépasse cette valeur, la tâche est considérée comme anormale et redémarre. | 600 |
Configuration de la tolérance aux pannes
S'applique aux scénarios où au moins une instance a échoué.
Fonctionnalité | Paramètre | Description | Valeur par défaut |
Politique de tolérance aux pannes | --fault-tolerant-policy | La politique de tolérance aux pannes. Valeurs valides :
| ExitCodeAndErrorMsg |
Nombre maximal d'occurrences de la même erreur | --max-num-of-same-error | Le nombre maximal de fois où la même erreur peut se produire sur une seule instance. Si le nombre d'erreurs dépasse cette valeur, la tâche échoue. | 10 |
Taux d'échec maximal toléré | --max-tolerated-failure-rate | Le taux d'échec maximal toléré. Si la proportion d'instances ayant échoué dépasse cette valeur, la tâche échoue. La valeur par défaut de -1 désactive cette fonctionnalité. Par exemple, une valeur de 0,3 signifie que la tâche échoue si plus de 30 % des workers rencontrent une erreur. | -1 |
Exemples de configuration des paramètres
Les exemples suivants montrent des configurations de paramètres courantes pour différents types de tâches d'entraînement.
-
Tâche d'entraînement synchrone (courante pour les tâches PyTorch)
Lorsqu'une instance échoue et répond aux conditions de tolérance aux pannes, la tâche redémarre.
--job-execution-mode=Sync --enable-job-restart=True --max-num-of-job-restart=3 --fault-tolerant-policy=ExitCodeAndErrorMsg -
Tâche d'entraînement asynchrone (courante pour les tâches TensorFlow)
Pour les erreurs pouvant faire l'objet d'une nouvelle tentative, les instances Worker ayant échoué sont redémarrées. Si une instance PS ou Chief échoue, la tâche n'est pas redémarrée par défaut. Pour activer les redémarrages de tâche, définissez --enable-job-restart=True.
--job-execution-mode=Async --fault-tolerant-policy=OnFailure -
Tâche d'inférence hors ligne (courante pour les tâches ElasticBatch)
Les instances sont indépendantes, semblables à une tâche asynchrone. Lorsqu'une instance échoue, seule cette instance redémarre.
--job-execution-mode=Async --fault-tolerant-policy=OnFailure
FAQ
Q : Comment installer le SDK AIMaster ?
Utilisez la commande correspondant à votre version de Python pour installer le package wheel.
# Python 3.6
pip install -U http://odps-release.cn-hangzhou.oss.aliyun-inc.com/aimaster/pai_aimaster-1.2.1-cp36-cp36m-linux_x86_64.whl
# Python 3.8
pip install -U http://odps-release.cn-hangzhou.oss.aliyun-inc.com/aimaster/pai_aimaster-1.2.1-cp38-cp38-linux_x86_64.whl
# Python 3.10
pip install -U http://odps-release.cn-hangzhou.oss.aliyun-inc.com/aimaster/pai_aimaster-1.2.1-cp310-cp310-linux_x86_64.whl