1. Définir la référence et le résultat attendu
Commencez par ce que vous voulez refaire : produire les mêmes catégories, obtenir des valeurs proches ou reprendre une trajectoire d’entraînement. Gardez un petit jeu d’entrées qui traverse les étapes importantes et un exemple de sortie valide. Une installation qui termine sans erreur ne répond pas encore à cette question.
Prenons un cas pédagogique : votre application produit des embeddings pour un échantillon identifié. Sur l’environnement de référence, vous devez relever la forme des sorties, leur type, l’absence de valeurs non finies et le critère métier utile. Si vous comparez des valeurs, choisissez une tolérance justifiée par votre usage. Aucun seuil numérique universel n’est fourni ici.
Attribuez une révision au code, aux données et aux poids. Un nom comme « dernier-modele » peut changer sans que le programme le montre. Associez aussi les paramètres et le prétraitement à la référence. Ce dossier permet de savoir si une différence vient du logiciel, des entrées ou des conditions d’exécution.
Faites défiler le tableau pour lire toutes les colonnes.| Élément | À conserver | Contrôle après reconstruction |
|---|---|---|
| Code et paramètres | Révision, éventuelles modifications, configuration | Même point d’entrée et mêmes options. |
| Données et poids | Version ou empreinte, provenance et droits d’accès | Même échantillon et même contenu attendu. |
| Python et paquets | Versions, procédure et sources d’installation | Interpréteur correct et dépendances cohérentes. |
| Système et backend | OS, architecture, pilote, CUDA ou ROCm | Périphérique visible et calcul minimal réussi. |
| Résultat | Format et critères d’acceptation | Structure puis qualité ou tolérance prévue. |
2. Séparer la chaîne système des paquets Python
Vérifiez ensemble la carte, le système, le pilote, Python et les bibliothèques. Un environnement virtuel organise les paquets Python ; il ne remplace pas le pilote du système. De même, la référence d’une image ne suffit pas à décrire l’accès réel au GPU depuis son hôte. Pour une extension compilée, consignez les outils et bibliothèques de compilation nécessaires.
Choisissez la distribution PyTorch à partir de la plateforme de calcul de votre projet. Sur ROCm, PyTorch réutilise les appels torch.cuda et les périphériques nommés cuda : le nom de l’interface ne permet pas d’identifier NVIDIA. Relevez séparément torch.version.cuda et torch.version.hip. Une extension écrite pour une chaîne donnée mérite son propre contrôle.
Conservez la procédure qui a effectivement permis l’installation, avec l’origine des paquets. Évitez de mélanger une commande récente trouvée en ligne avec un fichier de dépendances ancien sans en examiner la compatibilité. La documentation consultée peut évoluer ; inscrivez les versions utilisées dans votre propre dossier.
3. Écrire une reconstruction plutôt que copier le dossier installé
Créez un nouvel environnement avec le Python retenu. Utilisez ensuite explicitement son interpréteur pour installer et lancer le projet. Sous Linux, ce sera par exemple .venv-rebuild/bin/python ; sous Windows, .venv-rebuild\Scripts\python.exe. Vous n’avez pas besoin de dépendre d’une activation antérieure. La documentation Python précise qu’un environnement virtuel doit être recréé lorsqu’il change d’emplacement.
pip freeze fournit un inventaire des paquets installés, pas un fichier de verrouillage calculé. Conservez-le comme observation. Le fichier de reconstruction doit aussi expliciter les index ou fichiers nécessaires à votre variante de PyTorch et les versions compatibles. Relisez les chemins ou URL qu’un inventaire pourrait contenir avant de le partager.
Les commandes ci-dessous illustrent une reconstruction Linux à adapter ; elles ne constituent pas un essai exécuté de votre projet. Le fichier requirements-rebuild.txt doit déjà décrire votre environnement, y compris le choix correct de PyTorch. Ne le remplacez pas par une liste de versions supposées universelles.
python -m venv .venv-rebuild
.venv-rebuild/bin/python -m pip --version
.venv-rebuild/bin/python -m pip install -r requirements-rebuild.txt
.venv-rebuild/bin/python -m pip check
.venv-rebuild/bin/python -m pip freeze --all > installed-after.txt4. Vérifier le contrat des dépendances avant le calcul
python -m pip check, lancé avec le bon interpréteur, recherche des dépendances installées manquantes ou incompatibles selon leurs métadonnées. Un résultat sans conflit n’est pas une validation du pilote, des extensions natives ou de la qualité de l’application. Gardez donc cette étape courte et poursuivez vers un contrôle de calcul.
Pour rendre la reconstruction plus stricte, vous pouvez fixer les versions et conserver les empreintes des distributions autorisées. Cette décision demande de maintenir la liste complète qui correspond à votre plateforme. Une archive de roues compilées peut dépendre de l’OS et de l’architecture ; elle n’est pas une garantie de portabilité entre deux machines différentes.
Dans notre exemple d’embeddings, comparez l’inventaire reconstruit à la référence avant de modifier le modèle ou ses paramètres. Si une différence est volontaire, notez-la et traitez la nouvelle exécution comme une variante. Sinon, corrigez la reconstruction ; changer plusieurs couches à la fois rendra le diagnostic moins précis.
5. Passer du contrôle minimal à l’application
Dans l’interpréteur du projet, relevez Python, PyTorch et le backend, puis vérifiez le périphérique et un petit calcul. Arrêtez cette étape si le GPU attendu n’est pas accessible ; une exécution CPU de secours brouillerait la comparaison. Le diagnostic Kernodeck fournit un rapport interprétable et distingue les étapes réellement franchies.
Une fois ce contrôle réussi, utilisez votre petit échantillon applicatif. Pour les embeddings, vérifiez le nombre de sorties, leurs dimensions, leur correspondance avec les identifiants et le critère choisi. Rechargez les fichiers depuis le dossier de sortie. Un calcul matriciel réussi ne démontre pas que le prétraitement ou une extension du projet fonctionne.
Si l’essai plante à la lecture des données, au transfert ou pendant une opération spécifique, gardez l’étape et la première erreur. La reconstruction générale est peut-être correcte ; le blocage peut appartenir au chargeur de données ou à un opérateur particulier. Orientez alors le diagnostic vers cette couche.
6. Distinguer reconstruction et identité numérique
Retrouver les mêmes dépendances ne garantit pas des résultats identiques entre matériels, plateformes ou versions de PyTorch. Fixer une graine ne couvre pas toutes les sources de variation. Documentez les générateurs utilisés, les transformations des données et les réglages de précision ou de déterminisme pertinents.
Définissez le critère de comparaison avant de regarder la différence : structure exacte, tolérance numérique ou stabilité d’une métrique. Certains réglages déterministes peuvent refuser des opérations ou modifier le coût de calcul. Le résultat recherché est une conclusion compréhensible dans les conditions annoncées, pas une promesse d’identité sur toute machine.
Pour une reprise d’entraînement, les versions ne suffisent pas : il faut aussi restaurer l’état de calcul et la progression. Le dossier de reprise vérifie cette question séparément. Son exercice CPU et sa tolérance ne deviennent pas automatiquement les conditions de votre modèle.
7. Terminer avec un dossier qu’un autre lancement peut utiliser
Le dossier final réunit la procédure, l’inventaire observé, la configuration, les références des données et les résultats du contrôle. Ajoutez la séquence exacte : reconstruire, diagnostiquer, exécuter l’échantillon, relire la sortie. Conservez les accès à part et précisez seulement comment les fournir.
Reprenez cette séquence dans un dossier propre avant de considérer l’environnement comme transmissible. Le contrôle doit réussir sans récupérer une variable d’un notebook ancien ni chercher un fichier oublié. Si un changement est nécessaire, corrigez la procédure et donnez une nouvelle identité à la référence. Vous obtenez une base utilisable pour votre prochaine période de calcul.