Pourquoi la sortie console de mon run n’est-elle pas capturée ?

W&B capture les flux stdout et stderr de votre script et les enregistre dans le fichier output.log, accessible dans l’onglet Files du run. Par défaut, ce fichier est téléversé à la fin du run : un journal vide ou manquant s’explique donc souvent par une question de délai, et non par un échec de la capture. Pour en savoir plus sur les téléversements en plusieurs parties (console_multipart), la rotation des fragments et les cas où il convient de les activer, consultez journaux de la console et wandb.Settings. Pour télécharger les journaux, consultez Comment puis-je télécharger le fichier journal de la console d’un run ?.

La capture de la console est désactivée

Vous pouvez désactiver la capture de la console dans les paramètres ou à l’aide d’une variable d’environnement :

wandb.init(settings=wandb.Settings(console="off"))

WANDB_CONSOLE=off python my_script.py

Vérifiez si l’un de ces paramètres est défini dans votre environnement ou dans votre configuration de lancement. Pour réactiver la capture, supprimez ce paramètre ou définissez WANDB_CONSOLE=wrap.

Entraînement distribué (DDP / multiprocessing)

L’onglet Logs n’enregistre que la sortie du processus auquel appartient le run W&B actif. Avec Lightning/DDP, les appels à print() ou wandb.termlog() effectués depuis des processus workers qui ne possèdent pas le run s’affichent uniquement dans le terminal local. Initialisez le run sur le rank 0 et utilisez console="wrap".

import wandb
from lightning.pytorch import Trainer
from lightning.pytorch.loggers import WandbLogger

wandb_logger = WandbLogger(
    project="my_project",
    settings=wandb.Settings(console="wrap"),  # ou WANDB_CONSOLE=wrap
)
trainer = Trainer(logger=wandb_logger, strategy="ddp", devices=2, accelerator="gpu")

Si l’onglet Logs reste vide, essayez console="redirect". La sortie peut apparaître dans output.log, sous l’onglet Files, même si elle n’est pas diffusée en direct. Consultez Journaliser des expériences distribuées pour découvrir des modèles de journalisation depuis le rank 0.

Run toujours actif, mais aucun fichier dans l’onglet Files

Tant qu’un run est actif, l’onglet Logs diffuse la sortie en continu, mais output.log n’apparaît généralement dans l’onglet Files qu’une fois le run terminé, sauf si vous avez activé la journalisation multipart de la console lors de l’appel à wandb.init(). Il est impossible de modifier la fréquence de téléversement une fois le run démarré.

Run planté avant le vidage

Sans la journalisation multipart, un run interrompu de force (OOM, SIGKILL, etc.) peut ne téléverser aucun fichier output.log et n’afficher aucun bouton de téléchargement. Activez console_multipart avant le démarrage du run afin que les fragments téléversés avant le plantage soient conservés sur le serveur. Une copie locale est toujours écrite dans wandb/run-[TIMESTAMP]-[ID]/logs/output.log.

Les runs repris perdent la sortie console précédente

Avec les anciennes versions du SDK, wandb.init(resume="allow", id=...) peut écraser un fichier output.log unique. Avec console_multipart=True, chaque session génère ses propres fragments dans logs/. Pour la configuration, voir Journaux de la console.

L’onglet Logs affiche moins de lignes que prévu

Pour préserver les performances, l’onglet Logs limite l’affichage : un run stocke jusqu’à 100 000 lignes au total, et l’App affiche jusqu’à 10 000 lignes à la fois. Faites défiler les journaux pour consulter les lignes plus anciennes. Le journal complet se trouve dans output.log ou dans des fragments multipart. Vous pouvez le télécharger depuis l’onglet Files des détails du run, ou via l’API.

Journaux Runs

​La capture de la console est désactivée

​Entraînement distribué (DDP / multiprocessing)

​Run toujours actif, mais aucun fichier dans l’onglet Files

​Run planté avant le vidage

​Les runs repris perdent la sortie console précédente

​L’onglet Logs affiche moins de lignes que prévu