1. Choisir le point de départ qui correspond au projet
Une base Ubuntu convient lorsque vous savez organiser votre pile logicielle et décrire ses dépendances système. Une préparation PyTorch permet de signaler le framework central du projet. Blender indique un besoin de création ou de rendu. La préparation personnalisée sert lorsque votre application possède déjà des conditions spécifiques que ces libellés résument mal.
Ces choix n’emportent pas automatiquement votre code, vos poids, vos données ni vos licences. Écrivez ce qui doit être disponible, ce que vous apportez et ce que vous vérifierez au démarrage. Le nom d’une préparation ne doit pas vous dispenser de contrôler la version réellement exécutée.
Une bonne demande ne consiste pas à lister tous les outils connus. Décrivez le chemin utile : lire une entrée, charger une ressource, calculer puis écrire un résultat. Cela aide à distinguer une dépendance obligatoire d’un outil de confort et à diagnostiquer l’étape qui manque.
Faites défiler le tableau pour lire toutes les colonnes.| Préparation | Besoin à décrire | Contrôle propre au projet |
|---|---|---|
| Ubuntu | Version attendue et dépendances système indispensables | Votre programme démarre avec les bibliothèques nécessaires. |
| PyTorch | Python, variante du framework et extensions | Import, calcul sur le backend puis tâche représentative. |
| Blender | Version, extensions, ressources liées et format d’export | Projet ouvert et étape de traitement vérifiée. |
| Personnalisée | Procédure, versions et fichiers de référence | Chaque critère du cahier de préparation est contrôlé. |
2. Écrire un cahier de préparation compact
Pour un projet Python, distinguez le système, l’interpréteur, les paquets et les ressources de l’application. Gardez les versions exactes lorsqu’une dépendance les exige. Lorsque vous acceptez une plage, expliquez le contrôle qui permettra de la valider. « Installer les dernières versions » est difficile à rapprocher d’un environnement de référence.
Exemple pédagogique : votre projet classe des images avec une extension native. Votre demande indique la version de Python, la variante de PyTorch choisie, la référence du projet et les prérequis de l’extension. Elle fournit trois images de contrôle autorisées et décrit la forme de sortie attendue. Elle n’annonce pas de débit ni de mémoire suffisante sans essai.
Le dossier de préparation peut rester court : un README, un fichier de dépendances et une référence de code suffisent si les étapes et les accès sont clairs. Conservez les paramètres modifiables dans un fichier séparé afin qu’une nouvelle taille de batch ne transforme pas la demande en une autre installation.
Objectif : classer un petit échantillon d’images
Code : dépôt et révision du projet
Python : version requise par l’application
PyTorch : version et variante CUDA ou ROCm retenues
Extensions : versions, provenance et prérequis de compilation
Entrées : échantillon autorisé et identifiants attendus
Contrôle : sortie par identifiant, format valide, résultat relisible
Fourniture des accès : procédure séparée, sans secret dans cette fiche3. Examiner les dépendances propres à PyTorch
Vérifiez la chaîne de calcul avant de multiplier les paquets. Le sélecteur officiel PyTorch permet de choisir une installation selon la plateforme. CUDA et ROCm ne sont pas deux noms interchangeables d’un même binaire. Le framework principal peut fonctionner tandis qu’un opérateur spécialisé ou une extension du projet reste incompatible.
Si une extension doit être compilée, sa construction peut nécessiter des outils et bibliothèques supplémentaires. La documentation PyTorch précise que l’installation du paquet torch ne fournit pas automatiquement les chaînes de compilation nécessaires à toutes les extensions. Indiquez ces prérequis dans la procédure ; une commande d’installation qui tente de compiler n’est pas une anomalie à masquer.
Planifiez trois contrôles séparés : import du framework, petit calcul sur le périphérique et opération utilisant l’extension. Si les deux premiers passent et le troisième échoue, vous disposez d’un diagnostic plus précis qu’un simple « PyTorch ne marche pas ». Notez la première erreur complète et les versions en cause.
4. Choisir comment décrire l’environnement
Pour les paquets Python, une procédure de reconstruction avec un environnement virtuel est souvent une base simple. Elle cible un interpréteur et sépare les dépendances du projet. Elle ne décrit pas toute la machine : gardez les besoins système dans le README et ne présentez pas la copie d’un répertoire installé comme une procédure portable.
Si votre projet utilise déjà un conteneur, fournissez sa recette, sa référence et les paramètres indispensables au lancement. Un tag peut évoluer ; une référence par empreinte identifie plus précisément une image donnée. Il faut néanmoins organiser les mises à jour et revalider le projet. Le conteneur ne prouve pas, à lui seul, l’accès au GPU ou la présence de vos données.
Choisissez le mécanisme que vous savez maintenir. Une image très complète peut cacher des dépendances inutiles ; une recette trop minimale peut laisser des installations manuelles hors du dossier. Dans les deux cas, le contrôle applicatif reste le point de comparaison. Ces indications décrivent votre préparation, sans présumer les modalités de fourniture d’une image par le service.
5. Préparer les notebooks et les projets graphiques
Un notebook aide à explorer les données et à visualiser une sortie. Son fichier et le processus qui exécute ses cellules sont toutefois distincts : les variables d’une ancienne session ne constituent pas une dépendance documentée. Avant transfert, redémarrez le noyau et exécutez les cellules dans l’ordre ; relevez le Python utilisé.
Lorsque l’essai devient un traitement régulier, préparez un point d’entrée qui ne demande pas de manipuler les cellules une par une. Le guide consacré au passage du notebook au script détaille cette transformation. Votre demande de préparation doit identifier le besoin de notebook, sans confondre l’interface de travail avec un contrôle réussi du programme.
Pour Blender ou un autre logiciel graphique, ajoutez les ressources liées, les extensions et la procédure d’export. Un projet qui s’ouvre sur votre poste peut dépendre de fichiers placés ailleurs. Demandez-vous comment une autre machine retrouvera chacun d’eux et quel petit résultat permettra de vérifier la chaîne avant le travail complet.
6. Réceptionner avec des critères et un résultat relu
Lors de la mise à disposition, comparez les versions observées à votre fiche. Lancez le diagnostic, puis le cas applicatif prévu. Pour les trois images de l’exemple, contrôlez que chaque identifiant a une sortie, que les catégories sont valides et que les fichiers produits peuvent être relus. Un écran sans erreur ne remplace pas ce bilan.
Gardez les écarts utiles : version différente, extension absente, entrée inaccessible, sortie écrite ailleurs. Distinguez ce qui empêche de commencer de ce qui appelle simplement une mise à jour de documentation. Pour demander de l’aide, joignez la référence de commande et un extrait minimal ; il n’est pas nécessaire de transmettre tout votre corpus.
Une préparation validée pour l’échantillon ne garantit ni la capacité mémoire ni le comportement de toutes les charges futures. Augmentez ensuite le volume avec un objectif défini et examinez la première limite rencontrée. Conservez enfin la procédure corrigée : elle devient votre référence pour la prochaine location.