> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

> Reprenez des runs W&B mis en pause, arrêtés ou plantés à l’aide des options du paramètre resume dans wandb.init().

# Reprendre un run

Indiquez comment W\&B doit réagir si un run s’arrête ou plante en définissant le paramètre `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.

| Argument | Description | L’ID du run existe | L’ID du run n’existe pas | Cas d’utilisation |
| - | - | - | - | - |
| `"must"` | W\&B doit reprendre le run spécifié par l’ID du run. | W\&B reprend le run avec le même ID. Reprise à partir de la dernière étape. | W\&B lève une erreur. | Reprendre un run qui doit utiliser le même ID. |
| `"allow"` | Autoriser W\&B à reprendre le run si l’ID du run existe. | W\&B reprend le run avec le même ID. Reprise à partir de la dernière étape. | W\&B initialise un nouveau run avec l’ID spécifié. | Reprendre un run sans écraser un run existant. |
| `"never"` | Ne jamais autoriser W\&B à reprendre un run spécifié par l’ID du run. | Lever une erreur si un run avec l’ID spécifié existe déjà. | W\&B initialise un nouveau run avec l’ID spécifié. | |
| `"auto"` | Autoriser W\&B à tenter automatiquement de reprendre le run si l’ID du run existe. Redémarrez le run depuis le même répertoire que le processus ayant échoué. | W\&B reprend le run avec le même ID. | W\&B initialise un nouveau run avec l’ID spécifié. | Permettre la reprise automatique des runs. |

<Note>
  **Quand utiliser `auto` ou `allow`**

  W\&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é.
</Note>

Pour tous les exemples ci-dessous, remplacez les valeurs entre `<>` par les vôtres.
<Tip>[Voir une démonstration en direct d’un run repris](https://forge.coreweave.com/wandb/wandb/resume-run/workspace?nw=nwuserjuliarose).</Tip>

<h2 id="resume-a-run-that-must-use-the-same-run-id">
  Reprendre un run qui doit utiliser le même ID de run
</h2>

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 `resume` sur `"must"` (`resume="must"`)
* Fournissez l’ID du run qui s’est arrêté ou a planté

L’extrait de code suivant montre comment procéder avec le SDK Python W\&B :

```python theme={"system"}
with wandb.init(entity="<entity>", project="<project>", id="<run ID>", resume="must") as run:
        # Placez votre code d'entraînement ici
```

<Warning>
  Vous obtiendrez des résultats inattendus si plusieurs processus utilisent le même `id` simultanément.

  Pour plus d’informations sur la gestion de plusieurs processus, consultez [Journaliser des expériences d’entraînement distribué](/fr/products/wandb/track/log/distributed-training).
</Warning>

<h2 id="resume-a-run-without-overriding-the-existing-run">
  Reprendre un run sans écraser le run existant
</h2>

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ètre `resume` 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 :

```python theme={"system"}
import wandb

with wandb.init(entity="<entity>", project="<project>", id="<run ID>", resume="allow") as run:
        # Placez votre code d’entraînement ici
```

<h2 id="enable-runs-to-automatically-resume">
  Activer la reprise automatique des runs
</h2>

L’extrait de code suivant montre comment activer la reprise automatique des runs avec le SDK Python ou avec des variables d’environnement.

<Tabs>
  <Tab title="SDK Python W&B">
    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 :

    ```python theme={"system"}
    with wandb.init(entity="<entity>", project="<project>", id="<run ID>", resume="auto") as run:
            # Your training code here
    ```
  </Tab>

  <Tab title="Script shell">
    L’exemple suivant montre comment spécifier la variable W\&B `WANDB_RUN_ID` dans un script bash :

    ```bash title="run_experiment.sh" theme={"system"}
    RUN_ID="$1"

    WANDB_RESUME=auto WANDB_RUN_ID="$RUN_ID" python eval.py
    ```

    Dans votre terminal, vous pouvez ensuite exécuter le script shell en lui passant l’ID du run W\&B. L’extrait de code suivant passe l’ID de run `akj172` :

    ```bash theme={"system"}
    sh run_experiment.sh akj172 
    ```
  </Tab>
</Tabs>

<Warning>
  La reprise automatique ne fonctionne que si le processus est redémarré sur le même système de fichiers que le processus ayant échoué.
</Warning>

Par exemple, supposons que vous exécutiez un script Python nommé `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/`.

<Note>
  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](/fr/products/wandb/runs#custom-run-ids) de la page « Qu’est-ce qu’un run ? ».
</Note>

<h2 id="resume-preemptible-sweeps-runs">
  Reprendre les runs de sweep préemptibles
</h2>

Gérez les signaux de préemption afin que W\&B puisse remettre automatiquement en file d’attente les runs de [sweep](/fr/products/wandb/sweeps) 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 CLI [`wandb agent`](/fr/products/wandb/ref/cli/wandb-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()`](/fr/products/wandb/ref/python/functions/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.

<h3 id="handle-a-preemption-signal">
  Gérer un signal de préemption
</h3>

Enregistrez un gestionnaire pour le signal que votre planificateur ou votre plateforme utilise pour indiquer une préemption, par exemple `SIGUSR1` ou `SIGTERM`. Dans ce gestionnaire :

1. Appelez [`mark_preempting()`](/fr/products/wandb/ref/python/experiments/run#mark_preempting) lorsqu’un run est actif.
2. Effectuez les opérations de nettoyage nécessaires, comme l’enregistrement d’un point de contrôle.
3. Quittez avec un code de statut non nul. Par convention, une terminaison par signal renvoie souvent `128 + signum`.

N’appelez pas `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](/fr/products/wandb/sweeps/signal-handling-sweep-runs).

Si vous suivez ce modèle, W\&B enregistre l’état du run à peu près comme suit :

| Scénario | État du run |
| - | - |
| Le run se termine normalement avec le code de sortie 0 | FINISHED |
| Le run échoue avec un code de sortie non nul | FAILED |
| Le run reçoit un signal non géré (par exemple `SIGKILL`) | CRASHED après environ cinq minutes |
| Le run reçoit un signal de préemption géré (par exemple `SIGTERM` ou `SIGUSR1`), le gestionnaire appelle `mark_preempting()` et le processus se termine avec un code non nul | PREEMPTED ; le run est placé en file d’attente pour la prochaine requête d’agent |

<Info>
  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.
</Info>

Les agents de sweep traitent les runs remis en file d’attente avant de demander de nouvelles combinaisons d’hyperparamètres à l’algorithme de recherche du sweep. Une fois la file d’attente vide, le sweep reprend sa planification normale.


## Related topics

- [Comment puis-je télécharger le fichier journal de la console d’un run ?](/fr/support/models/articles/how-do-i-download-the-console-log-file-from-a-run.md)