> ## Documentation Index
> Fetch the complete documentation index at: https://wb-21fd5541-dbrian-docs-serverless-training-quickstart.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

# Reprendre un run

Définissez le paramètre `resume` dans `wandb.init()` pour indiquer à W\&B comment réagir si un run s’arrête ou plante. 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 présente le comportement de W\&B selon l’argument transmis au paramètre `resume` et selon que l’ID du run existe ou non.

| Argument  | Description                                                                                                                                                | Run ID exists                                                                      | Run ID does not exist                                     | Use case                                              |
| --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------- |
| `"must"`  | W\&B doit reprendre le run spécifié par l’ID du run.                                                                                                       | W\&B reprend le run avec le même ID de run. Reprise à partir de la dernière étape. | W\&B lève une erreur.                                     | Reprendre un run qui doit utiliser le même ID de run. |
| `"allow"` | Autoriser W\&B à reprendre le run si l’ID du run existe.                                                                                                   | W\&B reprend le run avec le même ID de run. Reprise à partir de la dernière étape. | W\&B initialise un nouveau run avec l’ID de run spécifié. | Reprendre un run sans remplacer 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 de run spécifié. |                                                       |
| `"auto"`  | Autoriser W\&B à essayer automatiquement de reprendre le run si l’ID du run existe. Redémarrez le run depuis le même répertoire que le processus en échec. | W\&B reprend le run avec le même ID de run.                                        | W\&B initialise un nouveau run avec l’ID de run spécifié. | Permettre la reprise automatique des runs.            |

<Note>
  **Quand utiliser `auto` plutôt que `allow`**

  W\&B recommande d’utiliser `resume="allow"` et de spécifier l’ID exact du run que vous souhaitez reprendre.

  L’option `resume="auto"` ne vous oblige pas à spécifier un ID de run, mais elle peut entraîner un comportement inattendu si plusieurs runs échouent dans le même répertoire ou si la structure des répertoires change. Vous devez également veiller à redémarrer le run depuis le même répertoire que le processus en échec lorsque vous utilisez `resume="auto"`.
</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://wandb.ai/wandb/resume-run/workspace?nw=nwuserjuliarose).</Tip>

<div id="resume-a-run-that-must-use-the-same-run-id">
  ## Reprendre un run avec le même ID de run
</div>

Si un run est arrêté, plante ou échoue, vous pouvez le reprendre en utilisant le même ID de run. Pour ce faire, initialisez un run et indiquez les éléments suivants :

* Définissez le paramètre `resume` sur `"must"` (`resume="must"`)
* 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={null}
with wandb.init(entity="<entity>", project="<project>", resume="must") as run:
        # Votre code d'entraînement ici
```

<Warning>
  Des résultats inattendus peuvent survenir si plusieurs processus utilisent simultanément le même `id`.

  Pour plus d’informations sur la manière de gérer plusieurs processus, voir [Consigner des expériences d’entraînement distribué](/fr/models/track/log/distributed-training/)
</Warning>

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

Reprenez un run arrêté ou planté sans écraser le run existant. Cela est particulièrement utile si votre processus ne se termine pas correctement. La prochaine fois que vous démarrerez W\&B, W\&B reprendra la journalisation à partir de la dernière étape.

Définissez le paramètre `resume` sur `"allow"` (`resume="allow"`) lorsque vous initialisez 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={null}
import wandb

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

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

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

<Tabs>
  <Tab title="SDK Python W&B">
    Passez `auto` comme valeur du paramètre `resume` lorsque vous initialisez un run. Veillez à redémarrer le run depuis le même répertoire que le processus défaillant.

    Copiez-collez l’extrait de code suivant. Remplacez les valeurs entre `<>` par les vôtres :

    ```python theme={null}
    with wandb.init(entity="<entity>", project="<project>", id="<run ID>", resume="auto") as run:
            # Votre code d’entraînement ici
    ```
  </Tab>

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

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

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

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

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

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

Par exemple, supposons que vous exécutiez un script Python appelé `train.py` dans un répertoire nommé `Users/AwesomeEmployee/Desktop/ImageClassify/training/`. Dans `train.py`, le script crée un run avec reprise automatique activée. Supposons ensuite que le script d’entraînement s’arrête. Pour reprendre ce run, vous devrez redémarrer votre script `train.py` dans `Users/AwesomeEmployee/Desktop/ImageClassify/training/` .

<Note>
  Si vous ne pouvez pas utiliser le même 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. Voir la section [ID de run personnalisés](./#custom-run-ids) de la page « Que sont les runs ? » pour plus d’informations sur les ID de run.
</Note>

<div id="resume-preemptible-sweeps-runs">
  ## Reprendre des runs Sweeps préemptibles
</div>

Lorsque vous gérez correctement la préemption, les runs de [sweep](/fr/models/sweeps/) interrompus peuvent être automatiquement remis en file d’attente afin qu’un autre agent puisse les récupérer. Ce schéma est particulièrement utile lorsque l’agent de sweep s’exécute dans un environnement préemptible, comme un job SLURM dans une file d’attente préemptible, une instance EC2 Spot ou une VM préemptible sur Google Cloud.

Le comportement ci-dessous s’applique lorsque vous exécutez des agents de sweep avec l’interface en ligne de commande [`wandb agent`](/fr/models/ref/cli/wandb-agent), qui lance votre programme d’entraînement en tant que **sous-processus**. Il ne s’applique pas entièrement lorsque vous utilisez uniquement l’API Python [`wandb.agent()`](/fr/models/ref/python/functions/agent), car dans ce cas, votre fonction d’entraînement s’exécute dans un thread plutôt que dans un processus distinct. La réception et la transmission des signaux du système d’exploitation ne correspondent donc pas au modèle de l’agent CLI.

**Schéma recommandé :** enregistrez un gestionnaire de signal pour le signal de préemption utilisé par votre planificateur ou votre plateforme (par exemple `SIGUSR1` ou `SIGTERM`). Dans le gestionnaire, appelez [`mark_preempting()`](/fr/models/ref/python/experiments/run#mark_preempting) lorsqu’un run est actif, effectuez tout nettoyage nécessaire (par exemple l’enregistrement d’un point de contrôle), puis quittez avec un code non nul (une convention courante est `128 + signum` pour une terminaison par signal). N’appelez **pas** `mark_preempting()` de manière inconditionnelle juste après `wandb.init()`. Sinon, chaque échec, y compris les bugs dans le code, risque d’être marqué comme une préemption et le run sera remis en file d’attente de manière répétée.

Pour obtenir des exemples exécutables, des informations sur `--forward-signals` dans l’agent CLI, ainsi qu’un tableau de référence complet des différents usages de `mark_preempting()`, voir [Signal handling and sweep runs](/fr/models/sweeps/signal-handling-sweep-runs).

Lorsque vous suivez ce schéma, 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 |

Les agents de sweep vident la file d’attente des runs avant que le sweep ne génère de nouvelles combinaisons d’hyperparamètres à partir de l’algorithme de recherche. Une fois la file d’attente vide, le sweep reprend sa planification normale.