🚀 Environnement virtuel Python : logs PyTorch (WSL 2)
Découvrez comment lancer votre expérience PyTorch sous WSL 2 : environnement virtuel Python, journal d’entraînement, checkpoint modèle IA et commandes utiles.
Expérience PyTorch : organiser les modèles, les logs et l'environnement Python
Un petit réseau de neurones peut s'entraîner en quelques secondes. Mais ça ne veut pas dire que l'expérience sera facile à reprendre, à comprendre ou à comparer plus tard. Si les paramètres du modèle restent planqués dans le dossier du projet, si les sorties d'entraînement disparaissent dès que vous fermez le terminal, et si vous ne savez plus quel interpréteur Python a été utilisé, le premier essai peut marcher... le deuxième, lui, devient vite une chasse au trésor.
Dans cet atelier, on reprend un projet PyTorch sous Ubuntu, tournant via WSL 2. Il contient déjà train.py, un environnement virtuel .venv et un fichier de paramètres xor_model.pth, issus d'un premier entraînement d'un réseau XOR. Le but est simple : séparer clairement ce qui concerne le modèle, garder trace des sorties du programme, et voir concrètement ce que l'activation d'un environnement virtuel change (ou ne change pas).
La méthode reste volontairement simple. Elle sert aussi à clarifier quelques confusions classiques : une copie n'est pas une sauvegarde "vivante" et synchronisée, un journal n'est pas un checkpoint, et un environnement virtuel ne remplace pas une "sandbox" système.
Revenir dans le projet et organiser les fichiers
Commencez côté Windows : ouvrez une invite de commandes, puis lancez Ubuntu dans WSL 2 :
wsl -d UbuntuWSL peut démarrer dans un répertoire Windows monté, par exemple /mnt/c/Users/.... Ce n'est pas grave : le plus important est d'aller dans le dossier Linux du projet, celui utilisé lors du premier atelier :
cd ~/research/first-neural-network
pwd
ls -la
cd change le répertoire courant, pwd affiche le chemin, et ls -la montre aussi les fichiers cachés comme .venv. Ce petit contrôle évite une erreur bête (mais fréquente) : lancer un script ou créer un dossier au mauvais endroit, parce que le terminal n'est pas dans le bon répertoire.
On va séparer trois choses : le code, les paramètres du modèle, et les journaux. Créez deux dossiers, puis copiez le fichier existant :
mkdir -p checkpoints logs
cp xor_model.pth checkpoints/
ls checkpoints
L'option -p empêche de planter si les dossiers existent déjà . Ici, checkpoints/ contiendra les paramètres sauvegardés, et logs/ servira à stocker les sorties texte du programme.
La commande cp laisse le fichier d'origine à la racine, et crée une copie dans checkpoints/. Les deux fichiers sont indépendants : si train.py écrase plus tard xor_model.pth à la racine, la copie dans checkpoints/ ne bougera pas. C'est bien un instantané, pas un "lien" vers le fichier courant.
VĂ©rifier la copie sans conclure trop vite
Pour comparer rapidement les tailles :
ls -lh xor_model.pth checkpoints/xor_model.pth-l affiche les détails (dont la taille et la date), et -h rend la taille plus lisible (kilo-octets, etc.). Des tailles identiques rassurent, mais ça ne prouve pas que le contenu est identique.
Si vous voulez aller plus loin, comparez l'empreinte :
sha256sum xor_model.pth checkpoints/xor_model.pthSi les empreintes sont les mêmes, les fichiers sont très probablement identiques (au sens exact de la somme SHA-256).
À noter : l'extension .pth ne suffit pas à savoir ce que contient le fichier. Dans ce projet, .pth correspond aux paramètres enregistrés par PyTorch. Mais selon le code, un .pth peut contenir autre chose aussi. Le nom ne remplace pas ce que fait vraiment train.py.
Activer l'environnement virtuel et vérifier Python
Avant de lancer l'entraînement, activez l'environnement du projet :
source .venv/bin/activatesource exécute le script d'activation dans le shell actuel. Ça compte : le script modifie PATH, pour que python et pip pointent en priorité vers ceux de .venv.
L'activation ne télécharge rien et ne "garantit" pas que tout fonctionnera. Elle choisit simplement un environnement où les dépendances doivent déjà être installées. Pour vérifier quel interpréteur vous utilisez :
which python
python --version
Après activation, le chemin indiqué par which python devrait tomber dans .../first-neural-network/.venv/bin/. Ça vaut mieux que de supposer que "python" désigne toujours le bon binaire.
Installer une dépendance dans le bon environnement
Si le projet a besoin de NumPy :
python -m pip install numpy
python -c "import numpy; print(numpy.__version__)"
Ici, python -m pip garantit que pip est lancé avec l'interpréteur que vous venez de sélectionner. Ensuite, la version s'affiche via __version__ (deux _ au début et à la fin).
Quand une dépendance manque, traitez ça comme un problème d'environnement : dans un projet suivi, notez aussi les dépendances pour que quelqu'un d'autre puisse reconstruire un environnement comparable. .venv est un répertoire local : ce n'est pas une recette complète à elle seule.
NumPy peut aussi éviter des avertissements lorsque PyTorch s'en sert, mais pour lire un fichier journal texte, vous n'avez pas besoin de NumPy : les outils de lecture sont côté Linux.
Pour creuser, voir la documentation officielle sur venv.
Enregistrer et suivre les journaux d'entraînement
Lancez le script en redirigeant ses sorties vers un fichier :
python train.py > logs/training.log 2>&1Un processus peut Ă©crire dans deux flux :
- stdout (descripteur 1) : les infos "normales", souvent via
print(Ă©poques, pertes, etc.) - stderr (descripteur 2) : les messages d'erreur, warnings et diagnostics
Dans la commande, > logs/training.log envoie stdout dans le fichier, puis 2>&1 envoie stderr vers la destination actuelle de stdout. L'ordre compte : on redirige d'abord la sortie standard, puis on rattrape l'erreur.
Pendant l'entraînement, le terminal peut sembler muet : c'est normal, puisque les sorties partent dans le fichier. Une fois terminé, l'invite revient. Pour vérifier :
cat logs/training.logcat affiche le fichier en entier. Si le journal est long, Ă©vitez de tout envoyer d'un coup :
head logs/training.log
tail -n 5 logs/training.log
less logs/training.log
head montre les premières lignes, tail -n 5 les cinq dernières, et less permet de naviguer (tapez q pour sortir). Si vous copiez ces commandes dans un script, pensez à supprimer l'espace éventuel avant tail pour éviter les surprises.
Remplacer le journal ou ajouter une nouvelle exécution
Avec >, vous écrasez le fichier existant. C'est pratique si vous ne voulez garder que "la dernière exécution". Si vous voulez conserver l'historique, utilisez plutôt >> :
python train.py >> logs/training.log 2>&1L'ajout conserve le contenu précédent, mais vous perdez une séparation claire entre deux runs. Pour comparer proprement des essais, donnez à chaque exécution un nom explicite comme training-2026-10-12.log (ou un identifiant d'expérience). Il n'y a pas une seule règle parfaite : choisissez selon la façon dont vous exploitez ensuite les résultats.
Un journal contient ce que le programme écrit. Ça ne sauvegarde pas le modèle et ça ne garantit pas que vous pourrez relancer l'entraînement ou retrouver exactement les paramètres. Les poids doivent être enregistrés dans train.py. Inversement, un checkpoint n'inclut pas forcément les pertes, avertissements, ou tout le contexte affiché pendant l'entraînement.
Suivre une expérience longue dans un second terminal
Pour suivre un entraînement plus long, lancez le script avec la sortie Python non tamponnée :
cd ~/research/first-neural-network
source .venv/bin/activate
python -u train.py > logs/training.log 2>&1
L'option -u force Python Ă remonter ses sorties sans les garder en tampon, ce qui rend les nouvelles lignes visibles plus vite dans le fichier.
Dans un second terminal, allez dans le projet et observez le fichier :
wsl -d Ubuntu
cd ~/research/first-neural-network
tail -f logs/training.log
tail -f affiche les dernières lignes puis continue de suivre les ajouts. Arrêtez avec Ctrl+C dans ce second terminal : ça stoppe le "suivi", pas l'entraînement du premier terminal.
Comprendre ce que l'environnement virtuel isole
Un environnement virtuel Python fournit des exécutables dédiés et un emplacement pour les paquets. Dans notre exemple, .venv est un dossier à l'intérieur de first-neural-network. Voici les éléments utiles à repérer :
| Chemin | RĂ´le |
|---|---|
.venv/bin/python |
Interpréteur Python de l'environnement ; copie ou lien symbolique |
.venv/bin/pip |
Point d'entrée pour installer des paquets |
.venv/bin/activate |
Script qui active l'environnement dans le shell |
.venv/lib/pythonX.Y/site-packages/ |
Paquets installés ; X.Y dépend de la version Python |
train.py |
Script d'entraînement |
xor_model.pth |
Fichier de paramètres à la racine du projet |
checkpoints/xor_model.pth |
Copie distincte des paramètres |
logs/training.log |
Journal des sorties redirigées |
L'activation change la résolution de commandes comme python et pip. Elle ne change pas le répertoire courant. Et surtout : elle ne transforme pas .venv en "système" à part ni en sécurité magique. Le shell et Python peuvent toujours accéder aux fichiers du projet, et selon les permissions, à d'autres fichiers du système.
VĂ©rifier le changement par soi-mĂŞme
Pour voir la différence, partez d'un nouveau shell Ubuntu (ou faites deactivate si vous étiez déjà dedans), puis exécutez :
cd ~/research/first-neural-network
pwd
which python3
source .venv/bin/activate
pwd
which python
ls xor_model.pth
Vous devriez observer :
pwdreste identique avant et après activation.- Après activation,
which pythonpointe vers un binaire dans.venv/bin/. ls xor_model.pthtrouve toujours le fichier Ă la racine du projet.
C'est une vérification simple, mais elle évite une confusion fréquente : environnement Python versus répertoire de travail. Si votre script ne trouve pas un fichier relatif, le problème vient souvent du répertoire courant, pas de l'environnement virtuel.
Pour quitter l'environnement :
deactivateLes fichiers restent lĂ : checkpoints, logs et code ne bougent pas. Seul le contexte du shell change.
Un minimum de discipline pour rendre l'essai reprenable
Pour cet exemple XOR, séparer checkpoints/ et logs/ suffit à rendre le dossier plus clair. Ensuite, gardez une règle simple : chaque artefact doit répondre à une question.
- Quel code a produit le modèle ? Gardez le script et les paramètres de l'expérience.
- Quel modèle a été obtenu ? Enregistrez un checkpoint, avec un nom lisible.
- Que s'est-il passé pendant l'exécution ? Gardez les sorties utiles dans un journal.
- Quel environnement a été utilisé ? Notez la version de Python et les dépendances.
Pas besoin d'une plateforme entière pour un réseau XOR. Mais si plusieurs personnes comparent des essais, ou si un résultat doit être défendu/justifié, il faut au minimum : le code, les paramètres, les dépendances et les sorties pertinentes. Le "bon" niveau d'outillage, c'est celui qui enlève les ambiguïtés sans rendre l'expérience plus lourde que nécessaire.
Pour la suite, la documentation PyTorch sur l'enregistrement et le chargement des modèles aide à distinguer les paramètres sauvegardés du reste du processus d'entraînement.
Conclusion : une expérience doit pouvoir être reprise
Pour rendre ce premier entraînement plus simple à reprendre, on a organisé les paramètres dans checkpoints/, les sorties dans logs/, activé .venv, et vérifié ce que cette activation change vraiment. La différence clé est simple : le journal raconte l'exécution, le checkpoint contient des données du modèle, et l'environnement virtuel choisit le Python et les dépendances.
Commencez par appliquer cette structure à votre projet, puis vérifiez que train.py enregistre bien le modèle au bon endroit. Si vous continuez, regardez le guide de sauvegarde et de chargement des modèles PyTorch et adaptez le nommage des logs au nombre d'expériences que vous comparez vraiment. L'organisation la plus efficace n'est pas forcément la plus compliquée : c'est celle qui vous permet de retrouver, sans deviner, ce qui a été exécuté et ce qui a été sauvegardé.