Réceptionner une configuration GPU en équipe

Préparer la décision avant la mise à disposition

Commencez par une unité de travail terminée : un dossier enrichi et exporté, un lot de rendus ouvert par son destinataire ou une évaluation accompagnée de ses sorties. Écrivez le critère métier à côté du critère technique. Un programme peut se terminer sans erreur et produire des résultats inutilisables. À l’inverse, un résultat correct obtenu une seule fois ne démontre pas encore que l’équipe sait relancer le travail et récupérer ses fichiers.

Conservez les paramètres qui influencent la charge : volume des entrées, précision, taille des lots, concurrence et dépendances. Distinguez une file de travaux indépendants, une tâche qui répartit son calcul sur plusieurs cartes et un service recevant des requêtes en continu. Ces trois organisations n’ont pas les mêmes critères de réception. Une ligne « GPU puissant » ne donne à personne un moyen de trancher.

Le responsable du projet fixe les critères avant les essais. L’exploitant prépare les accès, le responsable applicatif fournit le lancement connu et le destinataire valide les sorties. Une même personne peut porter plusieurs rôles ; chaque rôle doit néanmoins avoir un titulaire et un remplaçant. Réservez dans la période choisie l’installation, les essais, une correction possible et l’export final, en plus du calcul utile.

Séparer fabricant, allocation et tâche réelle

La fiche d’un GPU décrit un matériel de référence. La machine allouée apporte d’autres propriétés : nombre de périphériques visibles, accès accordés, versions logicielles, volumes et chemins utilisables. La tâche étalon apporte un troisième niveau : le résultat obtenu avec vos données et vos réglages. Dans la grille, affectez chaque ligne à un seul niveau pour éviter qu’une caractéristique du fabricant soit traitée comme une mesure de votre service.

Ne déduisez ni NVLink, ni une topologie particulière, ni un débit disque du seul modèle de carte. Si votre application dépend de ces propriétés, transformez-les en exigences explicites, faites préciser le périmètre puis contrôlez-le sur la cible. Si elles ne sont pas nécessaires à votre charge, ne les ajoutez pas comme conditions artificielles de réception.

La mémoire par GPU et le nombre de cartes restent deux colonnes différentes. Un lot B200 chez Capordia comprend deux GPU ; cela ne suffit pas à donner une mémoire unique à un programme prévu pour une seule carte. Documentez le mécanisme de répartition du logiciel avant d’en attendre un bénéfice.

Établir l’inventaire sans modifier les réglages

Sur NVIDIA, les commandes ci-dessous relèvent la version de l’outil, la liste des GPU et quelques attributs au format CSV. Consultez d’abord l’aide installée : les champs et fonctions disponibles dépendent de la version. La documentation NVIDIA recommande des identifiants comme l’UUID pour suivre un périphérique, l’ordre des indices pouvant changer. Gardez les unités écrites par l’outil. Ces relevés ne lancent pas une tâche GPU et ne qualifient pas sa performance.

Pour AMD, relevez la version avec « amd-smi version », puis l’inventaire et les propriétés statiques avec « amd-smi list --json » et « amd-smi static --json ». Vérifiez les options via l’aide de votre installation. AMD SMI suppose un GPU AMD et son pilote ; la documentation consultée est celle d’AMD SMI 27.0.0. Un champ indisponible doit rester « non établi », avec son motif, plutôt que recevoir une valeur devinée.

Archivez ensuite les versions de l’application et de ses bibliothèques. Le bandeau CUDA de NVIDIA SMI ne prouve pas à lui seul la version du toolkit installé. Pour ROCm, confrontez la combinaison GPU, système et version à la matrice correspondante. Dans les deux cas, le test décisif reste le lancement de votre application dans l’environnement réellement prévu.

Le fichier fournit les commandes NVIDIA et AMD à exécuter sur votre machine, puis à joindre au procès-verbal. Elles s’appuient sur les documentations officielles ; aucun résultat CUDA ou ROCm n’a été mesuré dans cet exemple. Le fichier de commandes téléchargeable reprend les deux branches et les champs à joindre au procès-verbal.

nvidia-smi --version
nvidia-smi --help-query-gpu
nvidia-smi -L
nvidia-smi --query-gpu=index,name,uuid,memory.total --format=csv

Transformer chaque exigence en contrôle observable

Une bonne ligne de réception relie un critère, une méthode et une pièce justificative. « Assez de stockage » devient par exemple : emplacement de travail identifié, espace disponible relevé avant le lancement et export ouvert depuis sa destination. La quantité nécessaire est celle de votre travail, y compris les fichiers intermédiaires ; ce guide ne présume pas une capacité de disque attachée à chaque GPU.

Fixez les unités avant de comparer deux relevés. Un Go décimal vaut un milliard d’octets ; un Gio vaut 2 puissance 30 octets. Les outils peuvent afficher les notations anglaises GB et GiB, ou MiB pour une unité plus petite. Conservez la valeur brute et son unité, puis indiquez la conversion éventuelle. N’écartez pas une configuration sur la seule différence de notation entre une fiche et un relevé.

Pour le réseau, testez le flux du projet : même destination, mêmes permissions et type de fichiers représentatif. Un téléchargement isolé ne qualifie pas l’export de milliers de petits résultats. Mesurez et documentez le transfert dans les deux sens si le projet l’utilise, puis inscrivez le seuil que votre calendrier exige. Sans seuil décidé avant l’essai, une durée observée reste une observation.

Le statut « non exécuté » vaut mieux qu’un succès sans pièce. La grille CSV laisse vides les colonnes d’observation, de date et de preuve. Vous pouvez supprimer un contrôle hors périmètre uniquement en expliquant pourquoi et en conservant l’accord du décideur.

Faire de la tâche étalon un passage de relais

Choisissez un échantillon autorisé qui fait apparaître les contraintes du travail réel. Une démonstration minuscule est utile pour vérifier le lancement ; elle ne remplace pas un cas révélant le pic mémoire, les fichiers intermédiaires ou l’export final. Consignez l’identifiant du jeu d’essai, les versions et le paramétrage. Le dossier collectif référence la méthode de fourniture des secrets sans enregistrer leur valeur.

Le responsable applicatif réalise un cycle complet depuis un démarrage connu jusqu’à l’ouverture des sorties. L’exploitant refait ensuite le parcours à partir de la procédure, sans dépendre d’un état caché dans le terminal du premier opérateur. L’objectif est de vérifier une passation utilisable : chemins, droits, lancement, emplacement des journaux et récupération.

Définissez aussi ce qui se passe après un échec maîtrisé. Une sortie temporaire doit pouvoir être distinguée d’un résultat accepté. Le dossier de réception ne doit pas inventer un mécanisme de reprise que l’application ne possède pas : il constate celui qui existe et renvoie vers la procédure de migration pour organiser les lots interrompus. Si le calcul est numérique, la tolérance appartient au protocole métier ; l’identité bit à bit n’est pas une exigence universelle.

Quand vous comparez plusieurs configurations, gardez ce protocole constant. Notez aussi les erreurs et les essais à reprendre. La décision finale peut préférer une option parce qu’elle simplifie la file de travail, la réception ou le calendrier ; elle n’a pas besoin de transformer un seul relevé en classement général de GPU.

Lire un exemple rempli sans le prendre pour une mesure

L’exemple téléchargeable « Atelier des plans » est entièrement fictif. Une équipe veut traiter un corpus d’essai de douze documents techniques puis récupérer un index consultable par les relecteurs. Les douze documents sont une hypothèse d’organisation ; aucune vitesse, consommation mémoire ou mesure GPU n’est donnée. La cible H100 est une candidate de cadrage, à confirmer après examen du logiciel et de la charge.

Le responsable applicatif prépare le lancement et les identifiants attendus. L’exploitation contrôle les accès et le retour des fichiers. La personne chargée des résultats doit confirmer que chaque document possède une sortie lisible et une référence dans l’index. Dans ce scénario, elle n’a pas encore pu ouvrir l’export depuis sa destination. Les lignes matérielles et applicatives restent non exécutées ; la décision fictive est donc « mise en service bloquée ».

Cet exemple montre comment remplir les responsabilités et rendre une décision explicable sans fabriquer un succès. L’absence d’une preuve d’export n’est pas une simple note en marge : elle bloque précisément l’usage qui exige des résultats récupérables. La nouvelle tentative devra reprendre ce contrôle, joindre sa pièce et faire dater la décision. Il ne suffit pas d’effacer le commentaire dans la grille.

Refuser, accepter une réserve ou remettre la décision

Un critère bloquant non satisfait arrête la réception du périmètre concerné. Un contrôle impossible ne devient pas réussi par défaut : il produit un statut « bloqué » ou « non exécuté », une action et un propriétaire. Évitez d’utiliser « réserve » pour masquer un prérequis du travail. Si une sortie ne peut pas être récupérée, accepter le calcul seul n’autorise pas la chaîne complète.

Une réserve peut convenir à un point secondaire si l’usage autorisé est clairement limité, si une solution temporaire est vérifiée et si quelqu’un accepte ce périmètre. Inscrivez une échéance de recontrôle et ce qui se passera si elle n’est pas tenue. Une réception limitée à un essai ne vaut pas réception de la production.

Le procès-verbal conserve la décision, les contrôles qui la justifient et ceux qui restent ouverts. L’acceptation technique ne confirme ni un paiement ni une date contractuelle : ces suivis gardent leurs propres références. Une fois les critères atteints, l’équipe remet à l’exploitation le lancement, les versions, les emplacements des données et la procédure de sortie.

Télécharger et utiliser le dossier de réception version 1

Le modèle Markdown sert de page de garde et de procès-verbal. La grille CSV fournit les contrôles à personnaliser, avec des colonnes pour le niveau de preuve, le responsable, le critère décidé avant le test, la méthode, l’observation, la pièce et le statut. Ouvrez le CSV en UTF-8 avec une virgule comme séparateur ; les champs de résultat sont volontairement vides. Conservez une copie vierge avant de travailler.

Ouvrez le modèle avec un éditeur de texte et la grille avec un tableur. Adaptez l’exemple fictif à vos exigences, puis relevez les observations sur votre propre machine. La licence fournie autorise l’usage et l’adaptation en conservant la notice ; les noms de produits et documentations externes gardent leurs droits respectifs.

Utilisez cette réception pour autoriser un périmètre précis, puis complétez-la lors d’un changement de versions, de données ou de mode d’exploitation. Elle ne constitue ni un benchmark universel ni une garantie d’absence d’interruption. Le guide de migration prend le relais lorsqu’il faut déplacer un état de travail et expliquer le devenir de chaque lot.