Gestion des GPU : l’utilisation devient le coût caché de l’IA

Le prochain problème de l’IA en entreprise n’est pas forcément de trouver un modèle plus performant. Il peut être beaucoup plus prosaïque : éviter que des GPU coûteux restent sous-employés alors que leur coût, lui, continue de tourner.

Dans un article publié sur Hugging Face, l’équipe de Dharma-AI compare les GPU inutilisés aux avions immobilisés au sol. L’analogie est parlante : un avion génère des coûts même lorsqu’il ne vole pas, tandis que ses revenus sont liés à ses heures de vol. Pour un GPU détenu en propre, le mécanisme économique est similaire : investissement matériel, amortissement, énergie et refroidissement ne s’arrêtent pas quand la machine n’exécute aucune charge utile.

Cette lecture ne signifie pas que chaque GPU doit afficher 100 % d’occupation en permanence. Elle oblige plutôt à distinguer la capacité achetée, l’occupation mesurée et la valeur réellement produite. C’est là que se joue la gestion des GPU.

Le goulot d’étranglement se déplace des modèles vers le calcul

Selon la source, la première vague de l’IA d’entreprise s’est largement structurée autour de la qualité des modèles : taille, volumes de calcul à l’entraînement et résultats aux benchmarks. À mesure que les modèles deviennent exploitables dans des cas d’usage concrets, l’accès au calcul spécialisé prend davantage de place dans l’équation.

Le texte rappelle qu’en 2020, Microsoft avait construit pour OpenAI un supercalculateur dédié de plus de 10 000 GPU et 285 000 cœurs CPU, notamment pour l’entraînement de ce qui allait devenir GPT-3. Il souligne également que, six ans plus tard, les engagements de calcul restent un enjeu stratégique pour les laboratoires les mieux financés. Ces éléments illustrent une tension sur la capacité, mais ils ne permettent pas, à eux seuls, de quantifier la disponibilité mondiale des GPU ni de généraliser la situation à toutes les entreprises.

Pour les entreprises clientes de modèles via API, le problème se présente souvent autrement : la facture suit le volume de tokens consommés. Un prototype avec quelques milliers de requêtes mensuelles peut rester économique ; la même charge, une fois industrialisée, peut modifier fortement la structure de coûts. La source décrit donc un arbitrage : conserver une dépense variable liée à l’usage, ou acquérir des GPU et transformer une partie de cette dépense en investissement d’infrastructure.

Ce second choix n’est pas automatiquement moins cher. Il dépend du volume, de la régularité de la demande, des contraintes de confidentialité, des modèles visés et des compétences d’exploitation disponibles. En revanche, il crée un risque spécifique : surdimensionner l’infrastructure pour absorber les pointes, puis ne pas l’employer suffisamment le reste du temps.

Un cluster « occupé » n’est pas nécessairement bien utilisé

Le point le plus utile de l’article est sans doute la mise en garde contre une métrique trop simple. Un tableau de bord peut montrer un cluster très occupé tout en cachant une allocation inefficace. La raison : tous les travaux ne demandent pas le même profil de ressources ni le même niveau de service.

La source cite plusieurs charges susceptibles de cohabiter sur une même infrastructure :

• l’inférence temps réel, qui privilégie une faible latence ;
• l’inférence batch, qui tolère un délai mais recherche du débit ;
• l’entraînement, qui peut monopoliser des GPU pendant des heures ou des jours ;
• le fine-tuning, la quantification, la génération d’embeddings et l’évaluation de modèles.

Une tâche de génération batch peut accepter d’attendre. Une requête interactive, intégrée à un produit ou à un outil métier, ne le peut généralement pas. À l’inverse, réserver en permanence des GPU puissants à la faible latence peut pénaliser les travaux différables. Le problème ne se limite donc pas au nombre total de GPU : il concerne la bonne ressource, au bon moment, pour la bonne charge.

Dharma-AI relève qu’un scheduler conçu pour un type de workload peut mal allouer les autres. C’est une affirmation de principe cohérente avec les différences décrites entre charges, mais la portion fournie de la source ne détaille ni architecture de planification précise, ni métrique universelle, ni comparaison chiffrée de solutions.

Mesurer l’utilisation utile, pas seulement l’occupation

Pour piloter un parc GPU, un taux d’occupation moyen est un point de départ, pas une décision. Il faut le compléter par des indicateurs opérationnels qui révèlent les frictions derrière une moyenne flatteuse.

• Temps d’attente par classe de job : une file d’inférence temps réel ne doit pas être analysée comme une file batch.
• Taux de jobs en attente faute du bon profil de GPU : il signale une incompatibilité entre le parc et les demandes, même si d’autres cartes sont actives.
• Durée d’exécution et interruptions : elles permettent de voir si les tâches longues empêchent les charges prioritaires de passer.
• Répartition entre pics et creux : elle met en évidence la capacité achetée uniquement pour les périodes de forte demande.
• Coût par résultat métier : requête servie, lot traité, entraînement terminé ou délai de réponse respecté sont souvent plus parlants qu’un pourcentage brut.

Cette grille évite un piège courant : maximiser une métrique technique au détriment du service rendu. Une utilisation très élevée peut aussi signifier qu’il n’existe plus de marge pour absorber un pic ou une défaillance. À l’opposé, une faible utilisation n’est pas forcément un gaspillage si elle correspond à une réserve volontaire pour un engagement de latence. Le niveau cible dépend donc des SLA, des priorités métier et de la variabilité réelle de la demande.

Traiter le scheduling comme un sujet produit et financier

L’article insiste sur une séparation organisationnelle : l’achat de capacité a souvent un responsable et une échéance clairs ; l’utilisation efficace de cette capacité est répartie entre plusieurs équipes et moins rigoureusement mesurée. C’est précisément le point à corriger.

Une organisation qui exploite ses propres GPU gagne à formaliser quelques règles simples. Elle peut classer les workloads selon leur criticité et leur tolérance au délai, définir des quotas par équipe, isoler les charges de production des expérimentations, puis revoir régulièrement les créneaux où la capacité est inutilisée. Les tâches batch, les évaluations et certaines phases de préparation peuvent alors être orientées vers les périodes creuses, si leurs contraintes le permettent.

Il ne s’agit pas de promettre qu’un ordonnanceur résoudra tous les problèmes. La source ne fournit pas de recette technique exhaustive, et la bonne stratégie dépendra notamment du type de GPU, des frameworks, du modèle de déploiement et des objectifs de latence. Mais elle établit clairement le diagnostic : provisionner de la capacité et l’exploiter efficacement sont deux disciplines distinctes.

Avant d’acheter plus de GPU, audite ce qui est déjà là

Si tu envisages d’augmenter ta capacité, commence par cartographier les charges existantes pendant plusieurs semaines : qui consomme les GPU, à quelles heures, avec quelles contraintes et avec quels temps d’attente ? Compare ensuite les pointes observées aux pointes supposées. Tu pourras identifier si le blocage vient réellement d’un manque de matériel, d’une mauvaise répartition des jobs ou d’un mauvais découpage des priorités.

La leçon de l’analogie aéronautique est simple : posséder davantage d’actifs peut augmenter la capacité, sans améliorer mécaniquement l’économie de l’ensemble. Pour l’IA en production, la question n’est donc pas seulement « combien de GPU avons-nous ? », mais « quelle part de ces GPU produit un résultat utile, au moment où l’entreprise en a besoin ? ».