Ce qu’il faut vraiment pour exécuter du code sur un superordinateur à 200 millions d’euros

• MareNostrum V de l’Université polytechnique de Catalogne à Barcelone est l’un des 15 plus grands superordinateurs au monde, une infrastructure publique de recherche de 200 millions d’euros qui exécute du calcul distribué sur 8 000 nœuds
• Il ne s’agit pas d’un unique ordinateur haute performance, mais d’un système distribué où des milliers d’ordinateurs indépendants sont reliés par une topologie fat-tree InfiniBand NDR200, permettant à n’importe quel nœud de communiquer avec la même latence minimale
• La soumission des tâches se fait via le gestionnaire de charge de travail SLURM, en mettant en file des jobs auprès de l’ordonnanceur à l’aide de scripts batch précisant les ressources demandées, la limite de temps et le budget du projet
• Le système fonctionne dans un environnement air gap sans accès à l’Internet externe : il faut donc préparer à l’avance les bibliothèques et jeux de données nécessaires, et l’extraction des résultats devient parfois le vrai goulet d’étranglement plutôt que le calcul lui-même
• C’est une ressource publique gratuite pour les chercheurs : l’accès est possible via la RES pour les institutions espagnoles, et via les appels réguliers de l’entreprise commune EuroHPC pour le reste de l’Europe

---

Architecture : le réseau est l’ordinateur

• Le plus grand malentendu autour du HPC est l’idée qu’on loue un unique ordinateur ultra-puissant ; en réalité, on soumet des tâches distribuées à des milliers d’ordinateurs indépendants
• Pour éviter que les GPU restent inactifs en attendant les transferts de données dans un contexte de calcul distribué, MareNostrum V s’appuie sur une fabric InfiniBand NDR200 organisée en topologie fat-tree
  • Dans un réseau classique, plusieurs ordinateurs partageant le même switch créent des goulets d’étranglement en bande passante
  • La topologie fat-tree augmente la bande passante des liens à mesure qu’on monte dans la hiérarchie réseau, garantissant une bande passante non bloquante (non-blocking)
  • N’importe lequel des 8 000 nœuds peut communiquer avec n’importe quel autre avec la même latence minimale

Composition des partitions de calcul

• Partition à usage général (GPP) : conçue pour les charges CPU fortement parallèles, avec 6 408 nœuds embarquant chacun 112 cœurs Intel Sapphire Rapids, pour une performance de crête cumulée de 45,9 PFlops
• Partition accélérée (ACC) : conçue pour des usages spécialisés comme l’entraînement IA ou la dynamique moléculaire, avec 1 120 nœuds équipés chacun de 4 GPU NVIDIA H100 SXM, pour une performance de crête de 260 PFlops
  • En prenant un prix public unitaire d’environ 25 000 dollars pour un H100, le coût des seuls GPU dépasse 110 millions de dollars
• Nœuds de connexion (Login Nodes) : point d’entrée initial en SSH, réservés aux tâches légères comme le transfert de fichiers, la compilation du code ou la soumission de scripts de job, et non au calcul

Infrastructure quantique

• MareNostrum 5 intègre physiquement et logiquement le premier ordinateur quantique d’Espagne
  • Il comprend un système quantique à portes logiques et un quantum annealer à qubits supraconducteurs, MareNostrum-Ona
• Les unités de traitement quantique (QPU) ne remplacent pas le superordinateur classique : elles jouent le rôle d’accélérateurs spécialisés
• Les problèmes d’optimisation ou les simulations de chimie quantique difficiles même pour des GPU H100 peuvent être déportés vers le matériel quantique, faisant du système une plateforme majeure de calcul hybride classique-quantique à grande échelle

Air gap, quotas et réalité opérationnelle du HPC

• Air gap : l’accès SSH depuis l’extérieur est possible, mais les nœuds de calcul n’ont pas accès à l’Internet externe
  • pip install, wget ou l’accès à des dépôts HuggingFace externes sont impossibles
  • Il faut télécharger et compiler à l’avance tout ce qui est nécessaire aux scripts, puis le préparer dans les répertoires de stockage
  • Les administrateurs fournissent la plupart des bibliothèques et logiciels via le système module
• Transfert de données : les entrées et sorties passent par les nœuds de connexion via scp ou rsync
  • Le calcul réel étant très rapide, l’extraction des résultats terminés vers la machine locale devient parfois le goulet d’étranglement
• Limites et quotas : chaque projet reçoit un budget de temps CPU défini, avec des limites strictes sur le nombre de jobs simultanés ou en attente pour un même utilisateur
  • Une limite de wall-time stricte doit être indiquée pour chaque tâche
  • Si le temps demandé est dépassé, ne serait-ce que d’une seconde, l’ordonnanceur arrête immédiatement le processus
• Journalisation : après soumission d’un job, il n’y a pas de sortie terminal en direct ; tout stdout et stderr est automatiquement redirigé vers des fichiers de log, par exemple sim_12345.out et sim_12345.err
  • On vérifie ensuite les résultats et on débogue en relisant ces fichiers texte après la fin du job ou après un crash
  • Il est possible de suivre l’état d’un job soumis avec squeue ou tail -f

Gestionnaire de charge de travail SLURM

• Une fois l’allocation de recherche approuvée, la connexion en SSH affiche une invite de terminal Linux tout à fait ordinaire
• Comme des milliers de chercheurs utilisent la machine simultanément, exécuter directement un script lourd depuis le terminal peut faire tomber un nœud de connexion et valoir un courriel d’avertissement de la part des administrateurs système
• SLURM (Simple Linux Utility for Resource Management) est un logiciel open source d’ordonnancement de jobs : on décrit dans un script Bash le matériel nécessaire, l’environnement logiciel et le code à exécuter, puis le système met la tâche en file, la lance quand le matériel est disponible et libère les nœuds à la fin
• Principales directives #SBATCH :
  • --nodes : nombre de machines physiques nécessaires
  • --ntasks : nombre total de processus MPI (tasks) à créer, que SLURM répartit entre les nœuds
  • --time : limite stricte de wall-clock time, au-delà de laquelle le job est immédiatement interrompu
  • --account : identifiant du projet sur lequel le temps CPU sera imputé
  • --qos : Quality of Service ou file d’attente spécifique à utiliser, par exemple une file debug offrant un accès rapide mais avec une durée d’exécution courte

Exemple concret : orchestration d’un sweep OpenFOAM

• Pour prédire l’appui aérodynamique à l’aide d’un modèle surrogate de ML, il faut exécuter 50 simulations CFD (mécanique des fluides numérique) haute fidélité sur 50 maillages 3D différents
• Exemple de script de job SLURM pour un cas CFD OpenFOAM unique sur la partition à usage général :
  • Ressources définies avec --nodes=1, --ntasks=6, --time=00:30:00, etc.
  • Chargement de l’environnement avec module load OpenFOAM/11-foss-2023a
  • Exécution séquentielle via srun --mpi=pmix de surfaceFeatureExtract, blockMesh, decomposePar, snappyHexMesh, potentialFoam, simpleFoam, puis reconstructPar
• Plutôt que de soumettre les 50 jobs manuellement, on peut utiliser les dépendances SLURM pour chaîner chaque tâche à la précédente
  • sbatch --dependency=afterany:$PREV_JOB_ID permet d’enregistrer 50 jobs en file en quelques secondes
  • Le lendemain matin, les 50 évaluations aérodynamiques sont traitées et journalisées, prêtes à être converties en tenseurs pour l’entraînement ML

Limites de la parallélisation : la loi d’Amdahl

• S’il y a 112 cœurs par nœud mais seulement 6 tasks demandées pour la simulation CFD, c’est à cause de la loi d’Amdahl
• Tout programme contient une partie sérielle (serial fraction) impossible à paralléliser, et le gain théorique de vitesse est strictement limité par cette proportion
  • Formule : S = 1 / ((1−p) + p/N), où S est l’accélération globale, p la part parallélisable et N le nombre de cœurs processeur
  • Si seulement 5 % du code est sériel, même en utilisant tous les cœurs de MareNostrum V, l’accélération théorique maximale n’est que de 20×
• Répartir les tasks sur trop de cœurs augmente le surcoût de communication via le réseau InfiniBand
  • Si la transmission des conditions aux limites entre cœurs prend plus de temps que le calcul lui-même, ajouter du matériel peut en fait ralentir l’exécution
• Sur une petite simulation (N=100), le temps d’exécution augmente après 16 threads ; le matériel n’est pleinement productif que sur de grands systèmes (N=10k+)
• Écrire du code pour un superordinateur revient en grande partie à maîtriser le ratio calcul/communication

Comment y accéder

• Malgré le coût du matériel, l’accès à MareNostrum V est gratuit pour les chercheurs, le temps de calcul étant traité comme une ressource scientifique financée sur fonds publics
• Les chercheurs rattachés à des institutions espagnoles peuvent candidater via le Réseau espagnol de supercalcul (RES)
• Les chercheurs de toute l’Europe peuvent candidater via les appels d’accès réguliers de l’entreprise commune EuroHPC
  • La voie Development Access est conçue pour les projets de portage de code ou de benchmark de modèles ML, ce qui la rend particulièrement accessible aux data scientists