Pour que Jarvis repère les zones de relief dangereuses partout en France, il faut simuler des dizaines de milliers de départs de feu, puis entraîner le modèle sur le résultat. Sur mon Mac, c'était des semaines de calcul. J'ai donc déplacé le travail sur MareNostrum 5, le supercalculateur de Barcelone. Voici comment je m'y suis pris, ce que j'y gagne, et les pièges dans lesquels je suis tombé.
Le problème de départ
Dans l'article précédent, j'expliquais comment j'apprends à un petit modèle à repérer, sur une carte, les configurations de relief qui piègent les équipages : talwegs, cols, pentes fortes face au vent. Pour qu'il apprenne, il lui faut des exemples. Beaucoup.
Ces exemples, je les fabrique avec le simulateur de KiloDelta, celui-là même que vous avez dans l'application. Je tire au sort un point de départ dans la végétation, une météo d'été, je laisse le feu courir six heures, et je regarde où il passe, à quelle vitesse, avec quelle hauteur de flammes. Chaque feu demande de lire le relief, les routes, les cours d'eau, la forêt, le bâti, parfois le vent recalculé sur le terrain. Puis on recommence, des milliers de fois par département.
Sur le Vaucluse, ça représente près de 250 000 points de départ possibles. Mon Mac le fait, mais à ce rythme-là, la France entière m'aurait occupé jusqu'à l'été prochain 😅😅😅.
MareNostrum 5, en deux mots
MareNostrum 5 est hébergé au Barcelona Supercomputing Center. Il fait partie du réseau européen EuroHPC, qui ouvre ces machines aux équipes de recherche et aux entreprises, y compris les petites, sur dossier.
La partie qui m'intéresse s'appelle la partition accélérée : un peu plus de 1100 serveurs, chacun avec 80 coeurs de calcul, 512 Go de mémoire et quatre cartes graphiques NVIDIA H100. Un feu simulé ne va pas plus vite là-bas que sur mon Mac. La différence, c'est le nombre : j'utilise quatre serveurs à la fois, avec huit départements en parallèle sur chacun, là où mon Mac en traite un seul à la fois.
On ne s'en sert pas comme d'un ordinateur. On écrit des « jobs », de petits scripts qui décrivent ce qu'on veut faire et avec quelles ressources, on les dépose dans une file d'attente, et la machine les lance quand elle a de la place. Parfois tout de suite, parfois plusieurs heures après (et je n'avais pas prévu cette contrainte).
La règle qui change tout : pas d'Internet
Les serveurs de calcul de MareNostrum n'ont aucun accès à Internet. C'est voulu, et c'est logique pour une machine de cette taille. Mais pour moi, c'est un vrai casse-tête : le simulateur de KiloDelta va chercher ses données en ligne, sur mes serveurs (altitudes, routes OpenStreetMap, BD TOPO et BD Forêt de l'IGN, vent recalculé par WindNinja).
J'ai donc dû emporter une copie de tout ça là-bas :
- les mêmes logiciels que sur mes serveurs, empaquetés dans des conteneurs ;
- les bases de données recopiées : 57 Go pour la BD TOPO, 66 Go pour la base OpenStreetMap, 2 Go pour la BD Forêt, plus le relief de toute la France ;
- un Python autonome et toutes ses bibliothèques, préparés sur mon Mac pour Linux : 3,6 Go à envoyer, puisque rien ne peut se télécharger sur place.
Au démarrage de chaque job, tout ce petit monde se lance sur le serveur de calcul, se vérifie, puis les simulations s'enchaînent comme si elles parlaient à la prod.
J'ai aussi posé une règle de mon côté : rien de secret ne part là-bas. Les clés qui servent à signer les modèles que l'application télécharge restent sur mon Mac. MareNostrum calcule, mon Mac vérifie et signe.
Le garde-fou : la parité
Recopier la prod, c'est bien. Être sûr que la copie donne exactement les mêmes résultats, c'est mieux. Sinon, j'entraînerais Jarvis sur des feux un peu faux, et je ne m'en rendrais jamais compte.
J'ai donc mis en place un contrôle à chaque installation : six feux du Vaucluse, toujours les mêmes, générés une fois en ligne sur la vraie prod, puis refaits sur MareNostrum. Il faut qu'au moins quatre sur six soient identiques, maille par maille, sinon rien n'est lancé. La prod elle-même varie un tout petit peu d'un tirage à l'autre, d'où la tolérance.
Ce contrôle m'a sauvé, je vais y revenir.
Ce qui a coincé
La mise en route a pris plus de temps que prévu. Pas à cause de la puissance de calcul, mais à cause de détails qu'on ne voit jamais quand tout tourne derrière un vrai serveur web.
La file d'attente. Mes jobs demandent des serveurs avec cartes graphiques, les plus demandés. Il m'est arrivé d'attendre plusieurs heures avant qu'un job démarre, pour le voir échouer en trois minutes sur une erreur bête.
Les services qui ne sont pas prêts. Au premier essai, mon contrôle interrogeait les services trois secondes après leur lancement. Deux d'entre eux n'avaient pas fini de démarrer. Le contrôle attend maintenant que chacun réponde vraiment, avec de vraies données.
Un générateur qui plante sans raison apparente. Le simulateur envoie ses requêtes d'une manière un peu particulière, que mes serveurs savent lire, mais pas la petite passerelle que j'avais écrite pour la base OpenStreetMap. Elle comprenait de travers et répondait à une question qu'on ne lui avait pas posée. Le simulateur, déboussolé, s'arrêtait net.
0 sur 6. Le plus instructif. Une fois tout réparé, le contrôle de parité est tombé : aucun des six feux n'était identique. Pire, les feux de MareNostrum étaient systématiquement 10 à 25 % plus petits que ceux de la prod. Pas un bug franc, une dérive.
J'ai fini par comparer, source par source, tout ce que le simulateur avait reçu des deux côtés. Les routes, la forêt, le bâti : quasiment pareil. Le relief : près de 40 % des altitudes manquaient côté MareNostrum. Sans altitude, pas de pente, et sans pente, le feu ne monte plus les versants aussi vite. D'où des feux plus petits.
La cause tenait en un mot dans une ligne de configuration. Le service d'altitude fermait sa connexion après chaque réponse, sans prévenir. Le simulateur, comme l'application, réutilise ses connexions pour aller plus vite. Près de quatre requêtes sur dix tombaient dans le vide, et le simulateur, prévu pour continuer sans réseau sur le terrain, mettait simplement « altitude inconnue » et poursuivait. Silencieusement. Une option corrigée, et le contrôle est passé à 6 sur 6.
C'est le genre d'erreur qui ne fait planter rien du tout et qui fausse tout. Sans le contrôle de parité, j'aurais entraîné Jarvis sur un relief à moitié plat.
Une bibliothèque oubliée. Premier vrai lancement sur les 96 départements : presque tous échouent, chacun après une dizaine de minutes de téléchargements. Il manquait une seule bibliothèque Python, celle qui transforme les polygones de forêt en grille. Sur mon Mac elle était là depuis des mois, je ne pensais plus à elle. Elle fait désormais partie de la liste, et l'installation vérifie sa présence avant de rendre la main.
Ce que j'y gagne
Une fois en route, la différence est énorme.
- Le temps. Ce qui m'aurait pris des semaines sur mon Mac devrait se compter en jours. Je prépare toute la France d'un coup, puis j'entraîne le modèle sur des cartes graphiques faites pour ça.
- La France entière, pas seulement le Sud. Jusqu'ici, je préparais en priorité les départements méditerranéens. Avec cette puissance, je peux traiter les 96 de la même façon, avec la même qualité.
- Plus d'essais. L'entraînement teste plusieurs réglages en parallèle et garde le meilleur. Sur un seul ordinateur, je devais choisir à l'instinct.
- Un résultat contrôlé. Avant d'arriver dans l'application, le modèle passe une porte de qualité : s'il ne fait pas mieux que celui en service, il n'est pas publié.
Ce que j'en retiens
La première : tester comme le vrai client. Mes contrôles utilisaient un outil qui réparait tout seul les connexions coupées. Ils ne voyaient donc pas le problème que le simulateur, lui, subissait. Un test qui ne se comporte pas comme l'utilisateur réel peut donner un feu vert trompeur.
La deuxième : échouer vite. Sur une machine où chaque essai coûte des heures d'attente, un contrôle qui casse au bout de trente secondes vaut de l'or.
La troisième : mesurer ce qui compte vraiment. Que les services répondent ne prouvait rien. Que les feux soient les mêmes, si.
La suite
À l'heure où j'écris, les 96 départements sont en cours de préparation sur MareNostrum. Viendront ensuite l'entraînement, la porte de qualité, puis la publication d'un nouveau pack Jarvis pour l'application, téléchargé une fois et utilisable sans réseau. Je vous raconterai la suite ici, chiffres à l'appui.
