Dharma-AI compare un allocateur de GPU sensible aux contraintes à un ordonnanceur FIFO. À matériel et charges identiques, l’ordre de placement améliore l’utilisation et la valeur pondérée par priorité dans ses scénarios de benchmark.
Un cluster GPU peut être à moitié occupé sans être réellement disponible. C’est le paradoxe mis en avant par l’équipe de Dharma-AI dans un benchmark publié sur Hugging Face : à matériel et charges identiques, un changement d’ordonnancement a fait progresser l’utilisation jusqu’à 33,4 points. Dans le scénario le plus favorable, la valeur produite, pondérée par la priorité des tâches, a plus que doublé.
Le sujet n’est donc pas seulement de « garder les GPU occupés ». Il consiste à décider quel job obtient quel GPU, à quel moment et selon quelle priorité. Cette distinction devient déterminante dès lors que l’entraînement, l’inférence batch et l’inférence temps réel se disputent une capacité limitée.
Selon les résultats rapportés par Dharma-AI, la capacité d’un cluster ne dépend pas uniquement de son nombre de GPU. La réservation statique pour l’inférence temps réel et l’ordre FIFO peuvent laisser de la capacité inutilisée ou l’attribuer à des tâches moins prioritaires.
Pourquoi FIFO perd de la capacité sous contention
Le point de comparaison retenu est un ordonnanceur FIFO (first in, first out). L’inférence temps réel y dispose d’une réservation fixe, tandis que les autres tâches sont placées dans l’ordre de leur arrivée, sans prise en compte de leur priorité.
Cette approche reste acceptable lorsqu’il y a suffisamment de marge dans le cluster : toutes les demandes finissent par tenir, quel que soit l’ordre de placement. Mais quand les ressources deviennent disputées, deux mécanismes dégradent le résultat.
Le premier concerne l’inférence temps réel. Elle ne peut pas attendre qu’un GPU se libère au moment où le trafic monte. Dans une logique de réservation fixe, il faut donc immobiliser toute la capacité correspondant au pic quotidien, y compris pendant les creux. L’exemple donné par les auteurs est simple : une application qui nécessite six GPU à midi et seulement deux GPU à 4 heures du matin conserve six GPU réservés pendant toute la journée.
Le second mécanisme est l’ordre d’arrivée. FIFO ne tient compte ni de la valeur relative des jobs, ni des besoins qui devront encore trouver leur place plus tard dans l’horizon de planification. Une tâche longue ou large, arrivée tôt, peut fragmenter la capacité restante et empêcher l’exécution d’un travail plus prioritaire.
Des charges aux contraintes incompatibles sur le même cluster
Le benchmark distingue quatre familles de charges : l’entraînement, l’inférence temps réel, l’inférence batch et la quantification. Elles n’occupent pas les GPU de la même manière.
- Entraînement, inférence batch et quantification : ces tâches sont décrites comme « batch-like ». Une fois lancées, elles demandent un bloc contigu de GPU, conservé sans interruption jusqu’à la fin du job.
- Inférence temps réel : elle est élastique. Son besoin varie à chaque pas de temps selon une courbe de demande liée au trafic.
Cette cohabitation est difficile à régler avec des règles locales. Un job batch a besoin de continuité ; une application temps réel doit absorber une demande variable ; un travail déjà en cours ne doit pas être interrompu. Les auteurs indiquent aussi que les jobs d’entraînement peuvent aller de quelques heures à plusieurs jours et mobiliser d’un GPU à plusieurs dizaines de GPU pour un même modèle de base.
Le problème devient donc global : il faut organiser une grille où chaque cellule associe, ou non, un GPU à un job pour un instant donné. La source précise trois des contraintes prises en compte : un GPU ne sert qu’un job par pas de temps, chaque job respecte sa plage de demande et les tâches déjà démarrées sont maintenues. Le texte fourni s’interrompt ensuite dans l’énumération des contraintes ; il ne permet pas de documenter précisément l’ensemble du modèle ni sa méthode de résolution.
Jusqu’à 33 points d’utilisation en plus dans les scénarios testés
Dharma-AI oppose à FIFO un allocateur « sensible aux contraintes ». Son principe : affecter l’inférence temps réel à partir de sa demande à chaque pas de temps, plutôt qu’à partir de son maximum journalier, puis utiliser les périodes creuses pour les tâches batch. Le placement des jobs batch se fait, lui, par priorité sur l’ensemble de l’horizon, et non selon leur ordre d’arrivée.
Dans cinq scénarios conçus pour créer une contention réelle, les auteurs rapportent une utilisation passant d’une plage de 52–85 % avec FIFO à 72–88 % avec leur allocateur. La valeur pondérée par priorité progresse de 24,6 % à 105,1 %, pour une moyenne annoncée de 52 %.
Le cas le plus favorable est un scénario dominé par l’entraînement, avec huit GPU : l’utilisation passe de 53,6 % à 87,0 %, soit 33,4 points de plus, tandis que la valeur pondérée par priorité augmente de 105 %. Les auteurs attribuent ce gain à la récupération de capacité auparavant immobilisée pour le temps réel, ainsi qu’au placement des tâches selon leur priorité.
Ces chiffres sont des résultats de benchmark publiés par les auteurs de l’allocateur. La source ne fournit pas, dans l’extrait disponible, les données brutes, le code d’évaluation, les paramètres détaillés des scénarios ni une comparaison avec d’autres ordonnanceurs avancés. Ils ne suffisent donc pas à prédire un gain identique sur un cluster de production.
Un taux d’occupation identique peut produire moins de valeur
Le résultat le plus utile pour une équipe plateforme n’est peut-être pas celui des 33 points d’utilisation. Dans un test à plus grande échelle, comportant 30 jobs sur 64 GPU, FIFO et l’allocateur atteignent exactement le même taux d’utilisation : 44,9 %. Ils terminent également le même nombre de tâches : 27 sur 30.
Pourtant, l’allocateur délivre 15,9 % de valeur pondérée par priorité en plus, selon la métrique retenue par les auteurs. Autrement dit, un dashboard centré sur l’occupation et le débit peut conclure à une égalité, alors que le cluster a exécuté des travaux de valeur relative différente.
Cette métrique de « valeur pondérée par priorité » mérite toutefois d’être lue avec prudence. La source affirme qu’elle traduit les priorités des jobs, mais l’extrait ne donne ni la formule complète ni les règles de pondération. Pour l’utiliser en entreprise, il faut expliciter ce que représente une priorité : un SLA client, un revenu, une échéance produit, un risque opérationnel ou un coût de retard.
Ce que tu peux tester avant de remplacer ton ordonnanceur
Le message opérationnel n’est pas de bannir FIFO dans tous les cas. Si ton cluster dispose régulièrement de capacité libre, le coût de l’ordre d’allocation est limité. En revanche, si des équipes attendent des GPU pendant que des réservations temps réel restent sous-utilisées, il vaut la peine de mesurer le problème autrement.
- Trace la demande réelle de l’inférence temps réel par tranche de temps, et compare-la aux réservations fixes et aux pics.
- Classe les jobs batch selon une priorité explicite, documentée et révisable plutôt que selon leur simple heure de soumission.
- Mesure la fragmentation : des GPU libres isolés ne sont pas forcément utilisables par un job qui exige un bloc contigu.
- Ajoute un indicateur de valeur à côté de l’utilisation : respect des SLA, tâches prioritaires terminées, revenu protégé ou délai évité.
- Teste en simulation sur des traces réelles avant d’autoriser une allocation dynamique en production, en particulier si tes contraintes de bascule ou de non-préemption sont strictes.
Le benchmark de Dharma-AI ne démontre pas qu’un modèle d’allocation unique conviendra à toutes les infrastructures. Il établit en revanche un point concret : sous contention, l’ordre des décisions peut affecter à la fois le taux d’occupation et la qualité économique du travail exécuté. Pour piloter une flotte GPU coûteuse, regarder seulement le pourcentage d’utilisation ne suffit pas.