resume dans wandb.init(). Lorsque vous initialisez un run, W&B vérifie si l’ID du run existe déjà et applique le comportement défini par la valeur de resume.
Le tableau suivant décrit le comportement de W&B en fonction de l’argument passé au paramètre resume et selon que l’ID du run existe ou non.
Quand utiliser
auto ou allowW&B recommande d’utiliser resume="allow" et d’indiquer l’ID du run que vous souhaitez reprendre.L’option resume="auto" ne nécessite pas d’indiquer d’ID de run, mais elle peut entraîner un comportement inattendu si plusieurs runs échouent dans le même répertoire ou si l’arborescence des fichiers change. Lorsque vous utilisez resume="auto", vous devez également veiller à redémarrer le run depuis le même répertoire que le processus ayant échoué.<> par les vôtres.
Reprendre un run qui doit utiliser le même ID de run
Si un run est arrêté, plante ou échoue, vous pouvez le reprendre avec le même ID de run. Pour ce faire, initialisez un run en spécifiant les éléments suivants :- Définissez le paramètre
resumesur"must"(resume="must") - Fournissez l’ID du run qui s’est arrêté ou a planté
Reprendre un run sans écraser le run existant
Reprenez un run arrêté ou planté sans écraser le run existant. C’est particulièrement utile si votre processus ne se termine pas correctement. Au prochain démarrage de W&B, la journalisation reprendra à partir de la dernière étape. Définissez le paramètreresume sur "allow" (resume="allow") lors de l’initialisation d’un run avec W&B. Fournissez l’ID du run arrêté ou planté. L’extrait de code suivant montre comment procéder avec le SDK Python W&B :
Activer la reprise automatique des runs
L’extrait de code suivant montre comment activer la reprise automatique des runs avec le SDK Python ou avec des variables d’environnement.- SDK Python W&B
- Script shell
Passez
auto comme argument au paramètre resume lorsque vous initialisez un run. Veillez à redémarrer le run depuis le même répertoire que le processus ayant échoué.Copiez-collez l’extrait de code suivant. Remplacez les valeurs entre <> par les vôtres :train.py dans le répertoire Users/AwesomeEmployee/Desktop/ImageClassify/training/. Ce script train.py crée un run pour lequel la reprise automatique est activée. Supposons ensuite que le script d’entraînement s’arrête. Pour reprendre ce run, vous devez relancer votre script train.py depuis Users/AwesomeEmployee/Desktop/ImageClassify/training/.
Si vous ne pouvez pas partager de système de fichiers, spécifiez la variable d’environnement
WANDB_RUN_ID ou passez l’ID du run avec le SDK Python W&B. Pour plus d’informations sur les ID de run, consultez la section ID de run personnalisés de la page « Qu’est-ce qu’un run ? ».Reprendre les runs de sweep préemptibles
Gérez les signaux de préemption afin que W&B puisse remettre automatiquement en file d’attente les runs de sweep interrompus pour qu’un autre agent les prenne en charge. Cette approche est utile lorsque l’agent de sweep s’exécute sur des ressources de calcul préemptibles, comme une file d’attente préemptible SLURM, une instance Spot Amazon EC2 ou une VM préemptible Google Cloud. Les instructions ci-dessous s’appliquent lorsque vous démarrez des agents de sweep avec la CLIwandb agent. La CLI lance votre programme d’entraînement en tant que sous-processus. Elles ne s’appliquent pas entièrement si vous utilisez uniquement l’API Python wandb.agent(). En effet, l’API Python exécute la fonction d’entraînement dans un thread : la transmission et le relais des signaux du système d’exploitation ne se comportent donc pas comme avec l’agent CLI.
Gérer un signal de préemption
Enregistrez un gestionnaire pour le signal que votre planificateur ou votre plateforme utilise pour indiquer une préemption, par exempleSIGUSR1 ou SIGTERM. Dans ce gestionnaire :
- Appelez
mark_preempting()lorsqu’un run est actif. - Effectuez les opérations de nettoyage nécessaires, comme l’enregistrement d’un point de contrôle.
- Quittez avec un code de statut non nul. Par convention, une terminaison par signal renvoie souvent
128 + signum.
mark_preempting() de manière inconditionnelle juste après wandb.init(). Chaque échec, y compris ceux dus à des bugs dans le code, risquerait alors d’être signalé comme une préemption, et le run serait remis en file d’attente à répétition.
Pour des exemples exécutables, l’option --forward-signals de l’agent CLI et un tableau de référence complet des différentes utilisations de mark_preempting(), consultez Gestion des signaux et runs de sweep.
Si vous suivez ce modèle, W&B enregistre l’état du run à peu près comme suit :
Lorsqu’un agent de sweep récupère un run préempté, le processus d’entraînement doit appeler
wandb.init() dans un délai de 60 minutes. Si l’initialisation n’a pas lieu, par exemple si le processus échoue après avoir récupéré le run mais avant d’appeler wandb.init(), W&B ne rend le run disponible pour un autre agent qu’à l’expiration du bail de 60 minutes.