Le planificateur GPU d’Ai2 répartit le temps entre les projets de recherche

Dans un billet publié le 9 octobre 2026, Ai2 a présenté le système de planification qu’il a développé pour répartir les tâches sur les clusters GPU de son institut de recherche. Son infrastructure compte des milliers de GPU NVIDIA H100, B200 et B300 ; la taille des clusters varie de 88 à 1 024 GPU. Selon Ai2, la demande de ressources des quelque 150 chercheurs qui les utilisent peut atteindre 2 à 3 fois la capacité disponible. La nouvelle approche consiste à attribuer aux projets des budgets de temps GPU, plutôt qu’à répartir durablement le matériel entre les équipes.

Des budgets de temps plutôt que des niveaux de priorité

Dans l’ancien système d’Ai2, les tâches étaient classées par niveau de priorité, et certaines ne pouvaient pas être interrompues. D’après le billet de l’institut, au fil du temps, les priorités élevées se sont généralisées, tandis que les tâches moins prioritaires peinaient à obtenir des ressources. Réserver des GPU à certaines équipes n’était pas toujours efficace non plus : les besoins de recherche évoluant au fil du temps, les ressources allouées pouvaient rester inutilisées.

Dans le nouveau modèle, les administrateurs répartissent le temps GPU entre projets et équipes de recherche. La demande de GPU est associée à un budget afin de bénéficier d’une protection contre les interruptions. Le droit d’utilisation est ainsi lié aux priorités du projet ; les tâches sans budget peuvent, quant à elles, être interrompues dès le départ. Ai2 vise ainsi à continuer d’utiliser la capacité disponible lorsque certaines ressources seraient autrement inoccupées.

Fenêtre glissante et conditions d’interruption

Par défaut, le planificateur suit, sur une période glissante de 7 jours, la quantité de GPU utilisée par les projets par rapport au temps qui leur a été alloué. Les tâches des groupes dont l’utilisation est inférieure à leur part peuvent être prioritaires par rapport à celles des groupes qui l’ont dépassée. Tant qu’il y a de la demande, cette comparaison vise à permettre aux équipes d’accéder au fil du temps à la part prévue dans leur budget.

Lorsqu’il soumet une tâche, l’utilisateur indique également la durée minimale d’exécution nécessaire pour obtenir des résultats significatifs. La tâche est protégée contre les interruptions pendant cette période ; ensuite, le système peut l’arrêter et la remettre en file d’attente afin de rééquilibrer les ressources. La possibilité de redémarrer une tâche fait également partie du flux de travail. Si la durée minimale est définie sur zéro, la tâche n’est pas décomptée du budget, mais peut être interrompue à tout moment par une tâche bénéficiant d’une allocation. Ai2 précise avoir fixé à 8 heures la durée maximale d’exécution minimale.

L’institut indique que ces règles permettent de libérer les tâches exécutées sur les serveurs nécessitant une maintenance, une fois leur durée minimale d’exécution écoulée. Selon Ai2, les réparations nécessitant une intervention humaine ont ainsi diminué de 74 %. Ce résultat constitue un indicateur mesuré dans le cadre de la maintenance de l’infrastructure, en plus de la méthode de répartition du temps GPU.

Effets sur les flux de travail en architecture et en visualisation

Le système présenté par Ai2 n’est pas décrit comme un produit destiné aux agences d’architecture ou aux logiciels de visualisation ; il s’agit d’une approche de gestion de différentes charges de travail sur des clusters de recherche. L’idée de définir à l’avance la part des ressources attribuée aux tâches et les conditions d’interruption peut néanmoins intéresser les équipes qui partagent des serveurs GPU. Lorsque des tâches aux besoins différents en ressources et en durée utilisent la même infrastructure, des règles d’allocation transparentes peuvent faciliter la planification.

Cela dit, le billet d’Ai2 ne précise pas si les tâches de rendu architectural sont compatibles avec ce planificateur. Le comportement des logiciels de rendu ou de conception après une interruption n’y est pas non plus abordé. Avant d’évaluer un système similaire, les équipes d’architecture et de visualisation devraient donc vérifier les besoins matériels, la compatibilité avec les logiciels utilisés et la capacité des tâches à tolérer les interruptions. L’annonce ne fournit pas non plus d’informations sur les licences, les tarifs ou l’ouverture à des utilisateurs externes.