Recetter un cluster sur preuves.

Rapprochez chaque système du matériel accepté : châssis, édition et nombre de GPU, CPU, DIMM, disques, NIC et micrologiciels. Joignez les numéros de série et résolvez les substitutions avant les essais.

Pour le calcul loué, documentez ressources attribuées, isolation et périmètre d’accès. Cet inventaire est la référence de tous les résultats suivants.

Consignez image système, pilote, CUDA, framework, empreinte du conteneur et configuration applicative. Ajoutez politique de puissance GPU, paramètres réseau et éventuels travaux partageant le système.

Conservez commandes de test et fichiers d’entrée. Un résultat n’est reproductible que si l’environnement et les entrées peuvent être reconstitués.

Un test de communications collectives consigne nombre de nœuds, rangs GPU, tailles de messages, correspondance NIC et version exacte du test. Séparez mesures internes et entre nœuds. Exécutez ensuite l’application avec modèle, entrées et concurrence convenus.

Conservez les journaux bruts des deux essais. Débit de port, bande passante collective et débit applicatif décrivent des parties distinctes du système.

Fixez la durée d’essai et consignez températures, limitations thermiques, erreurs matérielles et échecs de tâches. Sauvegardez un point de contrôle sur le stockage prévu, arrêtez la charge de test et restaurez-la. Vérifiez état applicatif récupéré et intégrité des données.

Tout test perturbateur exige périmètre, retour arrière et fenêtre de maintenance approuvée.

Pour chaque essai, conservez critère, résultat observé, emplacement des preuves, exception et responsable. Clôturez les échecs par un nouvel essai ou une exception explicitement acceptée.

La remise nomme configuration acceptée, responsable d’exploitation et circuit d’escalade. Objectifs de disponibilité et délais de réponse figurent dans l’accord de service.