Prédire pour dimensionner : apprendre aux supercalculateurs leur propre empreinte d’exécution

Un modèle prédictif à apprentissage continu qui estime le temps d’exécution, la mémoire et l’énergie des applications scientifiques sur supercalculateur — pour que les chercheurs dimensionnent leurs allocations au lieu de deviner.

Une illustration conceptuelle qui oppose la phase initiale, où l’on devine, à la clarté offerte par un modèle à apprentissage continu.

Note de recherche · 23 septembre 2026 · 5 min de lecture

Le problème du dimensionnement

Toute campagne scientifique sur un supercalculateur commence par un pari. Combien de nœuds ? Combien de mémoire ? Combien de temps l’exécution va-t-elle durer ? Pour le DDF Pipeline — le logiciel d’auto-calibration et d’imagerie du radiotélescope LOFAR — l’enjeu est considérable : la dernière publication de données LoTSS (LOFAR Two-metre Sky Survey) a consommé à elle seule 16 millions d’heures de calcul. Et derrière chacune de ces heures se cache une décision de dimensionnement prise, le plus souvent, à l’aveugle.

Les astronomes qui utilisent le DDF Pipeline sont des scientifiques, pas des spécialistes du calcul intensif. Ils allouent les précieuses heures de calcul de leur projet par l’intermédiaire de SLURM, un ordonnanceur qui leur demande de déclarer leurs besoins à l’avance (--time, --cpus-per-task, --mem) puis applique une politique d’équité qui récompense les projets consommant moins que ce qui leur a été accordé. Surdimensionnez, et vous gaspillez des ressources, perdez de la priorité et attendez plus longtemps dans les files ; sous-dimensionnez, et votre tâche échoue. Traduire des paramètres scientifiques en dimensionnement correct relève du jeu de devinettes, avec un coût réel des deux côtés.

Le workflow du DDF Pipeline — trois étapes pour lesquelles nous aimerions connaître le site le plus adapté à leur exécution.

Pourquoi deviner coûte si cher

La difficulté ne vient pas d’un manque d’expérience, mais d’un manque de prévisibilité. Les exécutions du DDF Pipeline varient selon plusieurs dimensions à la fois, et un seul changement peut déplacer l’empreinte de ressources d’un ordre de grandeur :

Paramètres de l’application. La résolution de l’image de sortie va de 5 000×5 000 à 20 000×20 000 pixels, ce qui fait passer la mémoire au pic de ~10 Go à ~400 Go.
Volume des données d’entrée. De quelques centaines de mégaoctets à plusieurs gigaoctets, ce qui étire le temps d’exécution de quelques minutes à plusieurs jours sur un seul nœud.
Structure des données. Entre 1 et 24 sous-bandes de fréquence, chacune modifiant la façon dont la charge se répartit — et son efficacité énergétique — sur les nœuds alloués.

Ajoutez une dimension multi-sites et le problème se complexifie. Dans les workflows répartis entre plusieurs centres, le dimensionnement conditionne le placement des tâches : espace disque, attente en file et site d’exécution dépendent tous de l’empreinte que vous avez prédite. Les contraintes matérielles diffèrent d’un site à l’autre — 768 Go par nœud sur Adastra, 192 Go de mémoire par nœud sur Jean Zay, 228 Go par nœud sur Joliot-Curie — et une configuration qui tient sur une machine peut être impossible sur une autre.

L’espace des configurations est tout simplement trop vaste pour être testé exhaustivement. Ce n’est pas un problème que l’on résout une fois pour toutes : il appelle un modèle qui continue d’apprendre à mesure que les exécutions s’accumulent.

Ce qu’il faut pour y parvenir

Construire un modèle prédictif à apprentissage continu est un travail d’équipe en cinq pièces, chacune portée par un spécialiste différent et conçue pour s’emboîter avec les autres :

Carte de connaissances structurée — une description de l’environnement d’exécution propre au supercalculateur, mise en correspondance avec les métriques SLURM.
Jeu d’indicateurs de performance des tâches, JoPInS — la structure qui contient les mesures des indicateurs de performance des tâches des applications descripteurs formelles, relativement à leurs exécutions.
Greffon de supervision — le collecteur qui capture les preuves des tâches réelles.
Base de données — le magasin central où toutes les exécutions s’accumulent au format JoPInS.
Apprentissage automatique exposé en tant que HAPS — un modèle entraîné par version d’application et par environnement d’exécution, avec accès aux ressources et aux applications de calcul intensif pour son apprentissage continu.

Première étape — une carte de connaissances structurée de l’environnement d’exécution

Avant de pouvoir prédire, il faut pouvoir décrire. La carte de connaissances structurée (ou ontologie) formalise l’environnement d’exécution propre au supercalculateur dans lequel les tâches s’exécutent. Sa valeur tient à la mise en correspondance : aligner la carte de connaissances structurée des tâches sur les métriques SLURM brutes, pour qu’une description conceptuelle — « cette tâche avait besoin d’un nœud à grande mémoire » — devienne une grandeur mesurable et comparable.

La carte de connaissances structurée des tâches — le pont entre la façon dont les chercheurs pensent leurs exécutions et la façon dont SLURM les mesure. Crédit : Gaëlle Richet.

Deuxième étape — décrire chaque exécution avec JoPInS

Chaque exécution est capturée par un jeu d’indicateurs de performance des tâches, JoPInS. Le descripteur définit les paramètres d’entrée — réglages de l’application et choix système — et les métriques de sortie — temps, mémoire, énergie — pour chaque tâche. Chaque indicateur est représenté par un triplet : JoPInS = (valeur, type de valeur, description), une structure assez simple pour être collectée à grande échelle et assez riche pour servir à l’apprentissage.

Troisième étape — recueillir les preuves du terrain

Une paire de greffons transforme les tâches réelles en données d’apprentissage. Le client en ligne de commande, cli-monitoring-haps, collecte les informations sur les tâches d’une application donnée, exposée en tant que HAPS, dans le contexte d’une campagne de publication de données. Le collecteur côté serveur, server-monitoring-haps, lit les métriques système de SLURM (sacct -j <JOB_ID>) et récupère les métriques propres à l’application dans la base HAPS. Chaque exécution est ensuite formalisée en JoPInS et envoyée à la base de données.

Quatrième étape — centraliser dans la base de données

Tous ces enregistrements JoPInS atterrissent dans la base de données — la source unique de vérité sur le comportement réel des applications sur de vraies machines. C’est la mémoire du système, et le carburant du modèle.

Cinquième étape — relier l’apprentissage automatique au système

La boucle se referme autour de HAPS (services applicatifs de calcul intensif), dans un dispositif qui reste conforme aux exigences de sécurité des ZRR imposées aux supercalculateurs français, considérés comme des actifs stratégiques nationaux. Étape 1 : exécution de campagnes d’applications scientifiques sur les supercalculateurs. Étape 2 : collecte des données par le greffon de supervision. Étape 3 : entraînement et évaluation du modèle — un modèle d’apprentissage automatique est entraîné sur le jeu de données d’une campagne, testé, sa précision mesurée, et seulement alors exposé lui-même en tant que HAPS.

De l’exécution à la prédiction

Une fois la boucle en marche, les pièces produisent quelque chose de nouveau : un modèle d’apprentissage automatique exposé comme un service. Entraînez un modèle expert sur les données d’une campagne, mesurez sa précision, et le modèle devient un oracle qui prédit, pour toute nouvelle configuration, le temps d’exécution, la mémoire utilisée et la consommation d’énergie de l’application. L’objectif est pratique : compte tenu de la variabilité des paramètres et des données d’entrée, identifier les configurations d’allocation qui offrent le meilleur compromis entre temps d’exécution et consommation d’énergie — avant qu’une seule heure de calcul ne soit dépensée.

De la devinette à la connaissance

Un ordonnanceur vous demande de prédire votre propre avenir — et traditionnellement, cette prédiction relevait du jugement personnel. Avec un modèle qui apprend en continu, nourri par les exécutions réelles, la conversation change. Le supercalculateur cesse de demander à ses utilisateurs de deviner et se met à leur dire ce dont ils ont besoin. Le dimensionnement cesse d’être un pari — et les scientifiques peuvent consacrer leurs heures de calcul à la science, pas aux intuitions.