À quatre voix : porter un modèle atmosphérique sur GPU avec l’IA

Comment accélérer sur carte graphique un modèle de chimie-transport atmosphérique mature, sans réécrire son cœur scientifique ? La question semble technique, presque banale : exploiter des cœurs CUDA, viser un gain massif. Sauf que derrière le « portage », il y a autre chose : des équations, des approximations numériques, des choix physiques enchevêtrés dans des milliers de lignes héritées d'années de recherche. Comprendre l'existant. Proposer une stratégie de migration cohérente, techniquement et scientifiquement. Et ne surtout pas casser la physique en route. Le gain réellement validé sur une journée simulée, une fois la précision contrôlée, est de l'ordre de ×2,7, pas d'un facteur dix annoncé d'emblée.

C'est dans ce contexte que nous avons mené, récemment, un chantier de ~7 semaines (310 commits, 50+ lots de diagnostic, ~16 audits formalisés) qui devait nous apprendre bien plus que du GPU. Il devait nous apprendre à travailler avec l'IA, et à réinventer le mode projet. Deux faces, un même chantier : accélérer sans trahir la physique, et inventer une façon de décider à quatre.

Première surprise : l'IA sait lire la science

On partait avec des modèles « frontier » (GPT 5.5, Claude Opus 4.7, entre autres), en espérant surtout de l'aide sur le code. La surprise : ils tiennent la route en science.

Ils comprennent les équations. Ils lisent les papiers. Ils relient un schéma numérique à sa justification physique. Pas à la perfection, pas sans vérification, mais assez pour accélérer une phase d'archéologie scientifique qui, autrement, aurait pris des semaines de lectures croisées entre spécialistes.

L'IA ne remplace pas le modélisateur. Elle ouvre des pistes à toute vitesse ; lui court derrière pour les éprouver.

Concrètement, cela nous a permis d'explorer des stratégies de portage GPU argumentées : quelles parties du modèle se prêtent au parallélisme massif, lesquelles exigent une réécriture algorithmique, lesquelles doivent rester sur CPU pour préserver la stabilité numérique. Une subtilité décisive : le modèle alterne transport et chimie à chaque sous-pas, et non « tout le transport puis toute la chimie ». Cette alternance a été redécouverte en lisant le code ; une première implémentation qui séparait les blocs provoquait des dérives locales sur le monoxyde d'azote atteignant −99 %.

Rust, Cargo, et une base de tests qui tient debout

Le choix de Rust n'était pas anodin. Au-delà de la performance et de la sûreté mémoire (précieuses quand on manipule des grilles de calcul massives), c'est l'écosystème de tests intégré qui a fait la différence.

Le modèle de référence reste en Fortran, inchangé (deux lignes ajoutées pour brancher le module d'accélération). L'orchestration GPU est en Rust : mémoire carte, lancements CUDA, échanges CPU↔GPU. Avec Cargo, les tests ne sont pas un add-on : cargo test exécute les tests unitaires (modules #[cfg(test)]) et les tests d'intégration (dossier tests/). Pas de framework à brancher, pas de runner externe à maintenir. Chaque itération de portage pouvait s'accompagner de garde-fous reproductibles.

Cette base de tests, co-construite avec l'IA mais validée par nous, est devenue le fil rouge du projet : la garantie que l'accélération GPU ne dégradait pas la validité scientifique.

Une démarche scientifique, pas une démarche « vibe coding »

Le piège, avec l'IA, c'est de produire du code qui a l'air correct. En calcul scientifique, « ça compile » ne suffit pas. Il faut que ça corresponde aux mesures, aux références analytiques, aux simulations de référence.

Notre protocole, en boucle : hypothèse falsifiable → test ne changeant qu'une variable → verdict chiffré consigné → garde-fou de non-régression. Exemple concret, sur la voie full-GPU : un biais d'azote de +11 % après 2 h. Première piste (émissions/dépôts sur GPU) : faux coupable. Forcer la chimie sur CPU : biais disparaît. Cause finale : le rythme d'alternance transport↔chimie. Une fois corrigé, sur un cas court en voie fidèle : 13 espèces sur 13 au vert, matière conservée à < 0,15 %.

Les résultats négatifs comptent autant. Augmenter les fils OpenMP pour gagner ~10 min/24 h ? annulé (−7 % d'azote). Réécrire le transport autrement ? instable sur 24 h, documenté et désactivé. L'IA accélère l'implémentation ; l'humain tranche sur ce qui ferme une porte définitivement.

Trois modes, un compromis fidélité / débit

Concrètement, nous avons livré trois façons de lancer le même modèle : tout sur processeur (référence), transport accéléré sur carte graphique (fidèle), ou transport et chimie accélérés (plus rapide, critères de validation plus souples). Pas un seul interrupteur « GPU », mais trois modes complémentaires :

• cpu : le modèle de référence, inchangé ; baseline de tous les écarts.
• hybrid : transport sur GPU, chimie et aérosols sur CPU ; la voie « fidèle », qui vise la parité stricte.
• gpu : transport et chimie sur GPU (méthode Rosenbrock ROS2), aérosols sur CPU ; la voie « exploratoire », débit maximal.

Sur une journée simulée (cas Île-de-France), mesurée sur une RTX 4070 face à un CPU déjà parallélisé sur 8 fils OpenMP :

En voie fidèle (hybrid), le gain mesuré est plus modeste (×1,2 sur la même journée simulée), mais la parité stricte avec le CPU reste l'objectif. La chimie représente ~89 % du temps de calcul en mode hybride : c'est la bonne cible. Le frein actuel du full-GPU, c'est le cycle aérosol resté sur CPU : d'où un gain « seulement » ×2,7 sur le pipeline complet, alors qu'une borne haute de ×9 a été mesurée quand ce bloc ne limite plus. Un chiffre de vitesse ne vaut que si la précision est démontrée en parallèle.

Face aux mesures : l'accélération est neutre

Deux questions distinctes : (1) le GPU reproduit-il le modèle CPU de référence ? (2) change-t-il l'accord avec la réalité ?

Sur une journée simulée à l'échelle de la France, comparée à des stations de mesure publiques : l'écart moyen modèle↔mesures sur l'ozone reste ~22 μg/m³ ; passer du CPU au GPU ne déplace le résultat que de ~0,5 μg/m³, un effet ≈ 40 fois plus petit que l'écart « normal » entre modèle et réalité. Trois configurations (CPU, hybride, full GPU) se tiennent dans un mouchoir ; le full GPU est même légèrement le plus proche des observations.

Deux personnalités IA, et le fil qui se perd

Revenons à l'organisation. À un moment, nous avons poussé l'expérience plus loin : donner à l'IA des « personnalités » distinctes, une orientée ingénierie logicielle, l'autre orientée science. L'idée : simuler une revue croisée, comme entre un dev et un chercheur.

Résultat : nous avons failli perdre le fil. Les échanges devenaient denses, redondants, parfois contradictoires. Difficile de savoir qui avait dit quoi, quelle proposition venait de quel modèle, et surtout quelle décision avait été prise.

C'est là que nous nous sommes remis dessus, à deux humains. Un spécialiste mathématiques / modélisation. Un spécialiste informatique / systèmes. Chacun avec sa propre IA. Quatre interlocuteurs au total. Et aucun mode projet existant pour gérer ça.

Inventer la communication à quatre

Quelques règles se sont imposées, non pas théoriques, mais nées de l'urgence :

• Entre humains, toujours écrire. Même court. Même sur Slack. Un message écrit force à formuler une décision, pas seulement à réagir au flux IA.
• Ne jamais copier-coller l'output de l'IA dans la conversation principale. Le texte généré n'est pas une prise de position humaine ; c'est un brouillon, une piste, un document de travail.
• Quand on partage du contenu IA, le traiter comme une pièce jointe. Sur Slack : un fichier, un snippet, un message séparé clairement identifié, pas mélangé au fil de décision.

Ces règles nous ont débloqués. Mais il restait un problème : la synchronisation. Qui avait validé quoi ? Quelle version du plan de portage faisait foi ?

Versionner le travail en Markdown

La solution pragmatique : des fichiers Markdown versionnés (Git), où nous consignions le plan, les décisions, les résultats de tests, les questions ouvertes. Un journal de bord partagé, relu par les deux humains, indépendant du bruit des conversations IA, dans le même esprit que les audits formalisés et les lots de diagnostic du chantier.

À deux humains et deux IA, ça marche. L'accélération GPU ne dégrade pas l'accord avec les mesures : l'effet matériel reste marginal face à l'écart habituel entre modèle et observations. Le portage avance plus vite qu'anticipé. Et le spécialiste mathématiques a déjà une liste de pistes scientifiques pour améliorer encore le modèle : optimisations algorithmiques, reformulations numériques, axes de recherche que le GPU rend enfin explorables.

Ce que le portage a révélé (utile même sans GPU)

Porter fidèlement un modèle oblige à comprendre son code dans le détail. Nous avons dû saisir des mécanismes peu documentés hors du Fortran d'origine ; à chaque étape, des erreurs de notre propre implémentation ont produit des dérives spectaculaires, corrigées une par une :

• Mauvaise lecture d'un commentaire trompeur sur les espèces « inertes » : vitesses de réaction sous-estimées jusqu'à un facteur 10¹⁹, radical OH à +4400 % avant correction.
• Cycle aérosol incomplet dans une version intermédiaire (pas seulement l'équilibre thermodynamique) : ammoniac libre à +125 000 %.
• Profilage du temps de calcul : toute optimisation future doit cibler la chimie en priorité ; le transport n'est pas le bon levier.

Ce qui ne scale pas (encore)

Soyons honnêtes : si nous avions été plus d'humains et plus d'IA, ce mode de fonctionnement n'aurait probablement pas tenu. Quatre voix, c'est gérable avec des règles simples et un dépôt Markdown. Douze voix, c'est une cacophonie, sauf à inventer quelque chose qui n'existe pas encore.

Il manque, pour les projets mêlant beaucoup d'humains et beaucoup d'IA, un cadre de coordination : qui décide, comment on trace les contributions IA, comment on évite que chaque binôme humain–IA diverge silencieusement. Les outils actuels (Slack, Git, IDE avec agents) ne sont pas conçus pour ça. Nous avons bricolé une solution artisanale. Elle fonctionne à petite échelle. Pas au-delà.

Ce que nous en retenons

Trois enseignements, pour l'instant :

• Les modèles frontier sont des alliés crédibles en calcul scientifique, à condition de les tenir par la bride des tests et des mesures.
• Rust et Cargo offrent un socle de tests intégré idéal pour ce type de chantier : chaque refactor est vérifiable, reproductible, versionné.
• L'IA ne change pas seulement la vitesse de codage ; elle oblige à réinventer le mode projet. Communication, traçabilité, rôles : tout est à repenser quand chaque humain embarque son propre copilote.

Nous continuons d'explorer. Le spécialiste mathématiques s'éclate sur les pistes d'amélioration. Le portage GPU avance : gain mesuré, précision contrôlée, six espèces réactives encore à affiner en voie « fidèle » sur 24 h. La question ouverte (comment faire tenir ce modèle à plus grande échelle) reste entière. C'est probablement le prochain chantier : pas le calcul, mais l'organisation.

L'IA accélère la science et le code. Mais mener ce type de projet requiert encore un jugement humain, une méthode de validation rigoureuse, et une capacité à inventer des règles de collaboration que personne n'a encore écrites dans un manuel. C'est précisément là qu'un accompagnement expérimenté fait la différence.