Les GPU à 100% ? L'illusion qui coûte des millions aux géants de l'IA

LE MYSTÈRE DE 2H DU MATIN : QUAND L'IA RALENTIT SANS RAISON APPARENTE

À 2 heures du matin, une équipe d'infrastructure reçoit une alerte : la latence d'inférence a soudain bondi de 60%. Pourtant, sur les tableaux de bord, tout semble normal. Les GPU affichent une utilisation élevée, la mémoire est saturée, les réseaux fonctionnent à plein régime. Rien ne semble catastrophique.

L'autoscaling se déclenche automatiquement. De nouveaux nœuds sont ajoutés. La facture cloud explose. La latence baisse à peine. Une heure plus tard, la cause réelle apparaît : trois nœuds sont entrés en mode reconstruction RAID sans que personne ne s'en aperçoive. Leur débit de stockage a chuté, affamant les tâches d'inférence voisines. Pourtant, le planificateur les considère encore comme « suffisamment sains » car les métriques des GPU et de la mémoire restent acceptables.

En termes simples : un des disques durs de ces machines est tombé en panne ou est devenu instable. Le serveur reconstruit alors les données perdues sur les disques restants. Les machines sont toujours en ligne. Elles ne sont pas « assez mortes » pour être retirées du service. Mais leur performance disque s'est effondrée.

L'ILLUSION DES GPU À 100% : LE PROBLÈME CACHÉ DES SYSTÈMES D'IA

Ce type de panne devient de plus en plus courant dans les infrastructures modernes d'IA. Et il révèle une illusion bien plus profonde, présente dans la plupart des systèmes de GenAI : l'idée que les GPU sont le seul goulot d'étranglement. En réalité, la performance dépend d'un écosystème bien plus large.

Quand un utilisateur envoie une requête à ChatGPT, Claude ou Gemini, la réponse arrive en quelques secondes. Derrière cette expérience fluide se cache un problème de coordination colossal. Les GPU exécutent des opérations de tenseurs. Les CPU alimentent les requêtes et déplacent les données. Les HBM stockent les activations et le cache KV. Les SSD diffusent les embeddings et le contexte de récupération. Les réseaux redistribuent les gradients et le trafic d'inférence entre les nœuds. Les systèmes de stockage absorbent les reconstructions, les réessais et les tâches en arrière-plan.

Au milieu de tout cela, un planificateur décide où exécuter les charges de travail. Ce planificateur détermine en silence si le cluster se comporte comme un système informatique cohérent ou comme un embouteillage coûteux.

UNE NOUVELLE Génération DE PLANIFICATEURS : LE CAS DE RAGP-I/O

Cet article s'appuie sur le concept de RAGP (Residual-Aware Geometric Packing), introduit par Kaarat et al. Il explore pourquoi les planificateurs modernes d'IA doivent désormais prendre en compte la bande passante de stockage, la pression I/O et le comportement dynamique des ressources, plutôt que de traiter les GPU comme des appareils de calcul isolés.

La leçon la plus importante dépasse un simple algorithme de planification. C'est un problème de système. Et de plus en plus, c'est aussi un problème économique.

LA MESURE LA PLUS TROMPEUSE : L'UTILISATION DES GPU

L'utilisation des GPU est l'une des métriques les plus surévaluées dans les infrastructures d'IA. Une utilisation élevée donne l'impression d'efficacité. Si les GPU sont majoritairement occupés, le cluster semble sain.

Mais les moyennes d'utilisation masquent la structure de ce qui reste disponible. Un cluster peut afficher une occupation élevée des GPU, des charges de travail actives et une mémoire saturée tout en ayant une capacité effective médiocre. Le problème n'est souvent pas que les ressources sont épuisées, mais que les ressources restantes ne sont disponibles que sous des combinaisons inutilisables.

Imaginez une grande ville en heure de pointe. Certaines routes sont vides. D'autres sont complètement bloquées. La ville dispose techniquement encore de capacité routière. Mais si les mauvaises intersections sont congestionnées, le trafic dans tout le système ralentit quand même.

Les systèmes d'IA distribués se comportent de la même façon. Un cluster peut encore contenir des GPU, de la mémoire HBM, du stockage et des CPU inutilisés, mais rester incapable d'accueillir efficacement la prochaine charge de travail réaliste. Pas parce que la capacité a disparu, mais parce que la capacité restante existe sous des formes inutilisables.

LA FRAGMENTATION DES RESSOURCES : QUAND LE CLUSTER A DES 'RESTES' INUTILISABLES

Prenons l'exemple de trois nœuds après une série de charges de travail GenAI variées. Supposons qu'une nouvelle tâche d'inférence arrive, nécessitant :

• 2 GPU
• 16 Go de mémoire HBM
• 10 Go/s de bande passante de stockage
• 2 CPU dédiés

À l'échelle du cluster, les ressources totales nécessaires existent encore. Mais aucun nœud individuel ne dispose de la bonne combinaison de ressources restantes. La tâche ne peut être placée nulle part de façon optimale.

C'est la fragmentation des ressources. Le cluster n'est pas vide. Il est fragmenté en restes difficiles à utiliser de manière productive.

Ce phénomène devient particulièrement dangereux 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 vu de loin tout en se dégradant en silence sous la surface.

LE PARADOXE DES MÉTRIQUES : UN CLUSTER PEUT ÊTRE À LA FOIS 'PLEIN' ET 'VIDE'

C'est la partie la plus contre-intuitive de tout le problème. Un cluster peut simultanément avoir :

• Des GPU inutilisés
• Une mémoire disponible
• Un réseau sous-exploité
• Mais des nœuds dont la bande passante de stockage est surchargée
• Une profondeur de file d'attente SSD explosive
• Des CPU consommés par des tâches en arrière-plan

À 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 file d'attente SSD explose ou les CPU sont consommés par des travaux en arrière-plan, alors ces GPU ne sont pas réellement disponibles pour la prochaine charge de travail utile.

Un planificateur avide peut encore y placer des tâches. Ces tâches subissent alors des ralentissements massifs. Les noyaux passent un temps précieux à attendre que les données arrivent depuis le stockage ou les pipelines de données.

Cela crée un cercle vicieux : plus de fragmentation → plus de ralentissements → des temps d'exécution plus longs → encore plus de fragmentation. Depuis les tableaux de bord, le cluster semble toujours occupé. En réalité, le système s'étouffe lentement lui-même.

L'ÉCONOMIE CACHÉE : POURQUOI 10% DE GASPILLAGE COÛTENT DES MILLIONS

Les planificateurs traditionnels ont été 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 GenAI modernes ont changé la donne : la pression sur l'infrastructure ne vient plus seulement des GPU.

Cela crée une nouvelle catégorie de pathologie d'infrastructure : le GPU n'est plus le seul goulot d'étranglement. Le chemin qui alimente le GPU compte tout autant. Cela change ce que signifie une « utilisation saine ».

C'est là que les enjeux économiques deviennent sérieux. Les infrastructures modernes d'IA sont coûteuses. En 2026, le prix public d'accès à un GPU NVIDIA H100 varie généralement de quelques dollars par heure à plus de 10 dollars, selon le fournisseur et le modèle d'engagement.

Un cluster de 1 000 GPU H100 fonctionnant à un coût moyen d'environ 3 dollars par heure coûte environ :

• 3 000 dollars par heure
• 72 000 dollars par jour
• 21,9 millions de dollars par an

Sans compter le réseau, le stockage, l'orchestration et les frais d'ingénierie.

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

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

C'est le changement clé que de nombreuses équipes d'infrastructure commencent à réaliser : la vraie métrique n'est pas l'allocation des GPU. C'est les heures GPU productives.

DEUX QUESTIONS POUR UN PLANIFICATEUR : L'ALLERGIE À LA FRAGMENTATION

La plupart des planificateurs posent une question en apparence simple : « Où placer cette tâche pour utiliser au mieux les ressources disponibles ? »

Le planificage résiduel (RAGP) pose une question bien plus importante : « Quel type de cluster résiduel cette décision de placement va-t-elle créer ? »

Cette idée est au cœur du RAGP (Residual-Aware Geometric Packing), proposé par Kaarat et al. Au lieu de réduire un nœud à quelques compteurs scalaires, RAGP traite la capacité résiduelle comme une forme multidimensionnelle.

Deux décisions de placement peuvent sembler correctes immédiatement tout en créant des états futurs de cluster complètement différents. L'une préserve une capacité résiduelle saine. L'autre isole des ressources en fragments inutilisables. Les métriques d'utilisation traditionnelles ne peuvent souvent pas distinguer ces résultats.

Un planificateur scalaire peut traiter les deux placements comme acceptables car :

• Le nœud A libère 1 GPU et 8 Go de mémoire
• Le nœud B libère 1 GPU et 20 Go/s de bande passante de stockage

Mais le nœud B laisse derrière lui une capacité de stockage presque inutilisable.

Cela devient dangereux dès que la prochaine charge de travail nécessitant une récupération ou une croissance de cache arrive. C'est l'échec subtil caché dans de nombreux clusters GenAI modernes : un placement peut être localement réalisable tout en étant globalement nuisible.

AU-DELÀ DES 5 DIMENSIONS : RAGP-I/O INTÈGRE LE STOCKAGE ET L'I/O

La formulation originale de RAGP raisonnait principalement sur :

• CPU
• RAM
• GPU
• Réseau

Cela fonctionnait raisonnablement bien dans des environnements dominés par le calcul.

Mais dans les systèmes GenAI modernes, la pression sur l'I/O influence la débit tout aussi fortement que l'utilisation des GPU.

Un nœud peut sembler sain en termes de calcul, de mémoire et de réseau tout en asphyxiant les charges de travail via des goulots d'étranglement de stockage.

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

• Bande passante de stockage
• CPU dédié à l'I/O

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

Conceptuellement, cela ressemble à une petite extension. En pratique, cela change significativement le comportement du planificateur dès que le stockage devient une contrainte active.

TESTER UN PLANIFICATEUR DANS UN MONDE PARFAIT (ET DANS LA RÉALITÉ)

Les clusters d'IA de production sont des environnements difficiles et dangereux pour tester des planificateurs expérimentaux. Pour évaluer le comportement des planificateurs dans des conditions contrôlées, l'étude utilise un simulateur d'événements discrets synthétique.

Les scénarios les plus révélateurs sont ceux où le stockage est sous forte pression. Cela reflète étonnamment bien les systèmes GenAI réels.

LE RÉSULTAT QUI COMPTE : RAGP-I/O RÉDUIT LA FRAGMENTATION DE 50%

Le résultat le plus important n'est pas simplement « RAGP-I/O a produit moins de fragmentation ». Le résultat le plus profond est le suivant :

Dès que le stockage et l'I/O deviennent des contraintes dominantes, des planificateurs autrement sensés sont systématiquement induits en erreur si ces dimensions sont omises.

Parce que les charges de travail GenAI sont de plus en plus axées sur la récupération, sensibles au stockage et dynamiques, le planificateur ne peut plus traiter le GPU comme un appareil de calcul isolé. Tout le chemin de données compte.

Dans des scénarios équilibrés, irréguliers et sous forte pression de stockage, RAGP-I/O a systématiquement produit :

• Une fragmentation moyenne inférieure de 40 à 50%
• Des ralentissements GPU réduits de manière significative

Comparé à l'équilibrage scalaire, au packing Tetris et à la variante RAGP-5D sans conscience I/O.

Les gains les plus importants sont apparus sous forte pression de stockage. Dans les expériences sous stress de stockage, la fragmentation moyenne pour RAGP-I/O est restée autour de 0,04-0,06, tandis que les méthodes de base restaient proches de 0,09-0,12. Le ralentissement GPU a chuté de manière spectaculaire, dans certains cas approchant zéro pour RAGP-I/O, tout en restant significatif pour les autres planificateurs.

Le scénario D montre le même schéma dans des conditions plus difficiles : RAGP-I/O maintient une faible fragmentation, réduit drastiquement le ralentissement total des GPU et maintient un débit dans la même gamme générale que les planificateurs plus simples.

LE PIÈGE DE RAGP-5D : POURQUOI IGNORER L'I/O RESTE DANGEREUX

Le résultat le plus important est tout aussi important. RAGP-5D reste meilleur que les méthodes de base plus simples, mais dès que le stockage devient la contrainte dominante, omettre la conscience I/O laisse le planificateur partiellement aveugle. L'intuition géométrique est bonne. La visibilité est incomplète.

La fragmentation seule n'est pas le problème opérationnel. Le symptôme le plus douloureux est le ralentissement.

Les tâches semblent « en cours d'exécution », mais les progrès significatifs ralentissent car le nœud ne peut pas alimenter efficacement le GPU. Une charge de travail d'inférence peut afficher une occupation élevée des GPU et une utilisation saine de la mémoire, tandis que les noyaux passent un temps précieux en temps réel à attendre le déplacement des données, la récupération ou les pipelines de données côté CPU.

En pratique, les équipes d'infrastructure remarquent souvent le problème de manière comportementale avant de l'identifier métriquement. Elles commencent parfois à vider manuellement ces nœuds bien avant que les tableaux de bord n'expliquent clairement pourquoi. C'est généralement le signe d'une contention cachée quelque part dans le chemin de données.

LE COÛT CACHÉ DE LA CONSCIENCE I/O : STABILITÉ ET ÉQUITÉ

Un planificateur conscient de l'I/O n'est pas gratuit. Ajouter plus de dimensions introduit :

• Une complexité accrue dans les calculs de placement
• Des risques d'instabilité dans les systèmes de contrôle

Les planificateurs eux-mêmes peuvent devenir des systèmes de contrôle instables sous une télémétrie bruyante. Un planificateur réagissant de manière agressive aux métriques de stockage fluctuantes peut surcorriger :

• Préférer certains nœuds de manière excessive
• Osciller dans ses comportements de placement
• Amplifier les déséquilibres ailleurs

L'équité et l'application des politiques multi-locataires deviennent également plus difficiles à mesure que la logique de placement devient plus sophistiquée. Ce sont de réels compromis d'ingénierie. L'objectif n'est pas que le planificage conscient de l'I/O résolve magiquement l'inefficacité de l'infrastructure. L'objectif est que ignorer le stockage et l'I/O devient de plus en plus coûteux.

AU-DELÀ DES PLANIFICATEURS : LES SYSTÈMES S'ADAPTENT OU MEURENT

Cet article ne porte pas seulement sur les planificateurs. Il porte sur le comportement des systèmes. Les systèmes sains ne sont pas définis uniquement par l'utilisation. Ils sont définis par un flux coordonné. Ce schéma apparaît partout :

• Dans une ville, le trafic ne dépend pas seulement du nombre de voitures, mais de la fluidité des feux et des routes
• Dans une chaîne d'approvisionnement, l'efficacité ne dépend pas seulement du nombre de camions, mais de la synchronisation des livraisons

L'optimisation locale n'est pas la même chose que l'optimisation globale. Un planificateur optimisé uniquement pour un placement immédiat peut endommager silencieusement le débit à long terme. Un cluster qui semble occupé peut encore être économiquement inefficace. Et un GPU qui semble actif peut encore passer un temps précieux à attendre le système autour de lui.

VERS UNE NOUVELLE MÉTRIQUE : LES HEURES GPU RÉELLEMENT PRODUCTIVES

L'utilisation des GPU seule n'est plus suffisante. Une surveillance sérieuse de l'infrastructure GenAI nécessite désormais une visibilité sur :

• Le débit réel du stockage
• La pression sur les pipelines I/O
• La fragmentation des ressources
• Les goulots d'étranglement cachés

Si les charges de travail finissent systématiquement 20%, 30% ou 40% plus lentement sur certains nœuds malgré des métriques d'utilisation apparemment saines, le planificateur devrait traiter ces nœuds différemment. C'est souvent là que vit l'inefficacité cachée.

L'EXPÉRIENCE UTILISATEUR MASQUE UNE RÉALITÉ COMPLEXE

Les infrastructures modernes d'IA cachent une chaîne logistique colossale de calcul, de stockage, de mémoire, de réseau et de coordination sous une expérience utilisateur remarquablement fluide. Les utilisateurs voient des requêtes et des réponses. Les tableaux de bord montrent des pourcentages de GPU. Quelque part entre les deux, un planificateur décide en silence si le cluster est vraiment sain ou s'il ne fait que paraître occupé.

Cette distinction compte plus que jamais. Parce que dans les systèmes GenAI modernes, la vraie question n'est plus « Combien de GPU avons-nous ? » mais « Combien de travail utile nos GPU produisent-ils vraiment ? »

CE QUE LES AUTEURS VEULENT QUE VOUS RETENIEZ

Les vues et opinions exprimées dans cet article sont celles des auteurs et ne reflètent pas nécessairement la politique ou la position officielle d'un employeur, d'une institution ou d'un éditeur. Toutes les expériences et simulations sont réalisées à des fins de recherche et d'illustration uniquement et ne doivent pas être traitées comme des conseils pour un déploiement en production sans validation indépendante.

POUR ALLER PLUS LOIN : RAGP, LE CODE ET LES SIMULATIONS

Si le concept de packing géométrique résiduel, le modèle de simulation ou le code utilisé dans cet article vous intéressent, n'hésitez pas à contacter les auteurs à l'adresse : [email protected].

Kaarat, A., Batthula, V. J. R., & Segall, R. « Fitting the Void: Residual‑Aware Geometric Packing for GenAI Workloads ». IEEE, 2025