GPU et IA : la fragmentation des ressources freine l'innovation

L'illusion de l'utilisation des GPU

Dans le domaine de l'intelligence artificielle, l'utilisation des GPU est souvent perçue comme un indicateur de performance. Un taux d'occupation élevé des GPU donne l'impression d'une infrastructure en bonne santé. Pourtant, cette apparence peut être trompeuse. Les moyennes d'utilisation cachent souvent une fragmentation des ressources, où les capacités restantes sont inutilisables de manière efficace.

Imaginez une ville où certaines routes sont vides tandis que d'autres sont embouteillées. De même, dans un cluster d'IA, des ressources peuvent être disponibles mais mal réparties, empêchant l'accueil efficace de nouvelles charges de travail.

Un cluster peut afficher une forte occupation des GPU, des charges de travail actives et une utilisation élevée de la mémoire tout en ayant une capacité effective médiocre. Le problème n'est souvent pas que les ressources soient épuisées, mais que les ressources restantes ne se présentent que sous des combinaisons inutilisables.

La fragmentation des ressources : un problème invisible

Prenons l'exemple de trois nœuds après des charges de travail variées :

• Node A : GPU disponible, HBM presque plein, stockage et bande passante I/O disponibles.
• Node B : GPU et HBM disponibles, stockage saturé, bande passante I/O disponible.
• Node C : GPU limité, HBM et stockage disponibles, bande passante I/O saturée.

Une nouvelle charge de travail nécessitant une bande passante de stockage et une capacité I/O saines ne trouve pas de place adéquate. C'est la fragmentation des ressources : le cluster n'est pas vide, mais les ressources sont fragmentées en combinaisons inefficaces.

Cette situation devient particulièrement dangereuse dans les systèmes GenAI, car les charges de travail modernes dépendent fortement des pipelines de récupération, de la croissance du cache KV, du débit de stockage et de l'efficacité globale du chemin de données. Un cluster peut sembler sain de loin tout en se dégradant silencieusement en profondeur.

Un cluster peut avoir des GPU disponibles et des files d'attente en hausse

C'est la partie la plus contre-intuitive de tout le problème. Un cluster peut simultanément avoir des temps de file d'attente en hausse, une latence qui s'aggrave, et un débit en déclin. À première vue, cela semble contradictoire. Ce n'est pas le cas.

Si les seuls GPU "libres" se trouvent sur des nœuds dont la bande passante de stockage est déjà surchargée, la profondeur de la file d'attente SSD explose, ou le CPU I/O est consommé par des travaux de fond, alors ces GPU ne sont pas réellement disponibles pour la prochaine charge de travail utile.

Un planificateur avide peut toujours y placer des tâches. Ces tâches augmentent alors la contention, prolongent les temps de file d'attente et laissent derrière elles une fragmentation encore pire. Cela crée un cercle vicieux : plus de fragmentation → plus de blocages → des temps d'exécution plus longs → plus de fragmentation. D'un point de vue opérationnel, le système s'étouffe lentement.

Pourquoi GenAI a changé le paysage des goulets d'étranglement

Les planificateurs traditionnels étaient conçus pour des environnements où le CPU, la mémoire, le GPU et le réseau dominaient les décisions de placement. Les systèmes modernes de GenAI ont changé la forme de la pression sur l'infrastructure :

• Les pipelines lourds en récupération peuvent saturer la bande passante SSD.
• Les travaux d'inférence accumulent du cache KV au fil du temps.
• Le chargement des points de contrôle peut frapper le stockage d'objets.
• Les charges de travail multimodales créent des mouvements de données par à-coups.
• Les tâches de maintenance en arrière-plan volent silencieusement des cycles CPU qui alimenteraient autrement les GPU.
• La dégradation du stockage au niveau du nœud peut réduire le débit effectif bien avant qu'un nœud ne tombe techniquement en panne.

Cela crée une nouvelle catégorie de pathologie d'infrastructure : le GPU n'est plus le seul goulet d'étranglement. Le chemin menant au GPU compte tout autant. Cela change ce que signifie réellement une "utilisation saine".

Un GPU affamé est toujours un GPU coûteux

C'est ici que les enjeux économiques deviennent sérieux. L'infrastructure moderne de l'IA est coûteuse. Les prix publics pour l'accès aux NVIDIA H100 en 2026 varient généralement de quelques dollars par heure de GPU à plus de 10 $/heure, selon le fournisseur et le modèle d'engagement.

À l'échelle d'une grande flotte, un cluster de 1 000 GPU H100 fonctionnant à un coût moyen d'environ 3 $/GPU-heure coûte environ :

• 26 millions de dollars par an, avant les coûts de mise en réseau, de stockage, d'orchestration et de maintenance.

Imaginez maintenant que la fragmentation et les blocages I/O gaspillent silencieusement seulement 10 % du temps productif des GPU. Cela représente environ :

• 2,6 millions de dollars par an de dépenses d'infrastructure inefficaces. Pas parce que les GPU ont disparu, mais parce que le système a échoué à les utiliser efficacement.

Planification consciente des résidus

La plupart des planificateurs posent une question trompeusement simple :

• "Cette charge de travail peut-elle s'adapter à ce nœud ?"

La planification consciente des résidus pose une question plus importante :

• "Quel type de cluster résiduel cette affectation crée-t-elle ?"

Cette idée est au cœur de la planification géométrique consciente des résidus (RAGP). Au lieu de réduire un nœud à quelques compteurs scalaires, la RAGP traite la capacité résiduelle comme une forme multidimensionnelle.

À un niveau élevé :

• les nœuds non viables sont éliminés,
• le planificateur simule les ressources restantes après placement,
• il privilégie les placements dont les vecteurs de ressources résiduelles restent utiles pour les futures charges de travail.

Cette dernière étape est d'une importance capitale. Deux décisions de placement peuvent toutes deux sembler correctes immédiatement tout en créant des états de cluster futurs complètement différents. L'une préserve une capacité résiduelle saine. L'autre laisse les ressources dans des fragments inutilisables. Les métriques d'utilisation traditionnelles ne peuvent souvent pas faire la distinction entre ces résultats.

Un exemple concret

Supposons qu'une charge de travail entrante nécessite :

• une bande passante de stockage modérée,
• et une disponibilité CPU saine.

Après avoir placé provisoirement la charge de travail :

| Ressource résiduelle | Node A | Node B | |----------------------|--------|--------| | CPU | 0.2 | 0.1 | | GPU | 0.35 | 0.4 | | HBM | 0.3 | 0.3 | | Bande passante de stockage | 0.25 | 0.02 |

Un planificateur scalaire peut considérer les deux placements comme acceptables parce que :

• le GPU reste disponible,
• la mémoire reste disponible,
• et la charge de travail s'adapte techniquement.

La planification consciente des résidus préfère le Node A. Parce que le Node B laisse derrière lui une capacité de stockage presque inutilisable. Cela devient dangereux une fois que la prochaine charge de travail lourde en récupération ou en croissance de cache arrive. C'est la défaillance subtile cachée à l'intérieur de nombreux clusters modernes de GenAI : un placement peut être localement faisable tout en étant globalement nuisible.

Extension de RAGP en RAGP-I/O

La formulation originale de RAGP raisonnait principalement sur :

• la capacité de calcul.

Cela fonctionnait raisonnablement bien dans des environnements dominés par le calcul. Les charges de travail de GenAI ont changé le paysage des goulets d'étranglement. Dans les systèmes réels :

• la profondeur de la file d'attente de stockage,
• les états RAID dégradés,
• la pression de récupération,
• et la saturation du CPU I/O

peuvent influencer le débit tout aussi fortement que l'utilisation des GPU elle-même. Un nœud peut sembler sain en termes de calcul, de mémoire et de réseau tout en affamant silencieusement les charges de travail à travers des goulets d'étranglement de stockage.

RAGP-I/O étend l'espace de planification en incorporant explicitement :

• la bande passante de stockage,

Dans la logique de faisabilité et de placement. Au lieu de raisonner à travers cinq dimensions, le planificateur raisonne à travers sept : CPU, RAM, GPU SM, HBM, réseau, bande passante de stockage et CPU I/O.