Contexte et enjeux

Le groupe d’infrastructure IA d’Ai2 gère plusieurs clusters composés de plusieurs milliers de GPU NVIDIA H100, B200 et B300, avec des tailles variant de 88 à 1024 unités. Ces ressources servent environ 150 chercheurs internes travaillant sur des entraînements distribués de LLM, VLM, robotique RL et d’applications scientifiques. La demande dépasse largement l’offre : à tout instant, les requêtes accumulées représentent 2 à 3 fois le nombre de GPU disponibles. Le planificateur initial, basé sur des priorités fixes et une option de préemptabilité, a engendré des pathologies telles que le « GPU squatting », l’inflation des priorités et des interventions d’ingénierie pour arrêter des tâches non préemptables.

Architecture du nouveau planificateur

Le nouveau système repose sur trois piliers : budgets de temps GPU, allocation hiérarchique en partage équitable (fair‑share) et un contrat de découpage temporel (time‑slicing). Au lieu d’attribuer des GPU fixes à chaque équipe, les responsables définissent une part proportionnelle du temps total, par exemple 35 % de la capacité globale pour le projet A1. Cette hiérarchie traduit la stratégie de recherche en quota temporel garanti, évitant le problème du sac à dos (knapsack) où l’on tente d’ajuster des besoins dynamiques à un planning statique. Le scheduler utilise ces quotas pour classer les travaux entrants, assurant que les charges à fort impact obtiennent les ressources avant les tâches à faible priorité, tout en maintenant une occupation élevée grâce à la préemptabilité contrôlée et au découpage en créneaux courts.

Analyse des résultats et limites

Depuis le déploiement, le métrique d’impact – fréquence à laquelle les travaux jugés les plus précieux sont exécutés – a augmenté, tandis que le taux d’occupation reste stable grâce à la capacité du scheduler à réallouer les créneaux libérés. Le modèle budgétaire a également réduit le temps passé par les ingénieurs à négocier l’arrêt de tâches non préemptables, libérant ainsi des ressources humaines pour le support opérationnel. Cependant, la prévision précise des besoins futurs demeure impossible : les quotas sont fixés avant la soumission des travaux, ce qui peut entraîner des périodes de sous‑utilisation si les projets ne consomment pas leur part allouée. De plus, le système dépend fortement de la discipline de reporting des managers, sans quoi les allocations pourraient ne plus refléter la valeur réelle des recherches. Enfin, la mise en œuvre d’un contrat de time‑slicing impose une surcharge de coordination au niveau du runtime, ce qui peut introduire de légères latences lors du basculement entre tâches préemptibles.