Un investissement de plusieurs millions de dollars dans des GPU peut déjà être sous-performant avant même que le premier modèle ait terminé son entraînement.
Le problème n’est pas nécessairement un manque de capacité de calcul. Il peut plutôt provenir de l’infrastructure de stockage et de données qui alimente cette capacité et qui n’arrive pas à fournir les données assez rapidement ou de façon suffisamment constante pour maintenir les GPU pleinement actifs.
L’expérience de Meta à très grande échelle illustre bien ce problème. Dans un rapport d’ingénierie publié en juillet 2026, l’entreprise indique que les goulots d’étranglement liés au stockage demeurent l’une des principales causes de ralentissement des GPU dans les charges de travail d’IA.
Son environnement d’entraînement comprend des centaines de milliers de GPU qui accèdent de façon répétée à d’importants ensembles de données. Lorsqu’un seul GPU subit une récupération de données à forte latence, la synchronisation peut ralentir l’ensemble de l’étape d’entraînement.
Meta a donc repensé certaines composantes de son architecture de stockage et a rapporté un taux moyen de succès du cache de 80 % grâce à un cache de données distribué, réduisant ainsi le volume de données devant être récupérées directement depuis le stockage.
La leçon dépasse largement le cas de Meta.
À mesure que les entreprises investissent massivement dans le calcul accéléré, l’utilisation des GPU devient en partie une question d’architecture de stockage.
Pour les DSI, la question à poser avant d’ajouter une nouvelle tranche de GPU devient donc :
Sommes-nous réellement limités par notre capacité de calcul, ou nos GPU attendent-ils simplement les données?
Quand des ressources de calcul coûteuses attendent le stockage
L’entraînement des modèles d’IA exerce une pression inhabituelle sur le stockage.
Les GPU consomment des données en parallèle et accèdent continuellement aux ensembles de données d’entraînement, tandis que le système doit également gérer les poids des modèles, les fichiers intermédiaires et les points de contrôle.
La couche de stockage doit absorber l’ensemble de ces requêtes sans permettre à des pics de latence d’interrompre les calculs.
Meta a constaté que son ancienne architecture de stockage, qui avait évolué pour répondre aux besoins de charges de travail plus conventionnelles, comportait des recherches de métadonnées et des couches mandataires pouvant faire grimper la latence jusqu’à plusieurs centaines de millisecondes.
Ce niveau de latence peut être acceptable pour de nombreuses applications traditionnelles. Il devient toutefois problématique lorsqu’une charge de travail d’IA exige un accès prévisible et à faible latence au stockage flash.
Meta a par la suite consolidé son architecture de métadonnées et supprimé un mandataire du plan de données, permettant aux serveurs de stockage de transmettre directement les données aux clients.
Cette distinction est importante, car le débit moyen peut à lui seul masquer le véritable problème.
Une plateforme de stockage peut afficher une bande passante impressionnante tout en laissant certaines requêtes subir une latence suffisante pour ralentir une partie d’un processus d’entraînement distribué.
La création de points de contrôle ajoute également une autre source de pression. Pendant l’entraînement, l’état du modèle doit périodiquement être réécrit dans le stockage, ce qui génère des pointes d’entrées-sorties pouvant entrer en concurrence avec les lectures nécessaires pour alimenter les prochaines séries d’entraînement.
À grande échelle, il ne s’agit plus d’événements de stockage isolés. Ils deviennent une composante du calendrier de calcul lui-même.
Le résultat crée une équation d’infrastructure difficile à ignorer :
la performance de la grappe de GPU peut être limitée par la constance du chemin de données qui l’alimente.
L’utilisation des GPU est devenue un indicateur économique de l’infrastructure
L’utilisation des GPU devient ainsi beaucoup plus qu’une simple statistique d’ingénierie.
Lorsqu’un accélérateur passe une partie de son temps à attendre des données, l’organisation paie pour une capacité de calcul qu’elle ne peut pas exploiter pleinement.
Et contrairement à un manque réel de capacité de calcul, l’ajout de GPU ne règle pas nécessairement un goulot d’étranglement lié au stockage.
Il peut même aggraver le problème en augmentant le nombre de demandes simultanées sur le même chemin de données.
Stability AI offre un exemple concret de cette relation.
L’entreprise a constaté que certaines limites de son environnement Lustre dans le nuage laissaient une partie de son infrastructure GPU inactive tout en générant des coûts de stockage imprévus.
Après avoir modifié son architecture de stockage, Stability AI a rapporté un taux d’utilisation des GPU de 93 %, une réduction de 95 % du coût de stockage par téraoctet et une accélération de 35 % de l’entraînement des modèles.
L’entreprise a également indiqué avoir réduit la durée moyenne de ses cycles d’entraînement d’environ trois semaines.
L’élément important n’est pas la technologie de stockage particulière choisie par Stability AI.
C’est plutôt la relation économique que cet exemple met en évidence :
l’amélioration de la couche de données a augmenté la productivité d’un investissement GPU existant.
Cette réalité devrait influencer la façon dont les infrastructures d’IA sont évaluées.
Le stockage ne peut plus être évalué uniquement selon sa capacité ou son coût par téraoctet lorsque la rentabilité de l’ensemble de la plateforme dépend du taux d’utilisation des accélérateurs.
L’architecture doit suivre les besoins de la charge de travail d’IA
C’est ici que l’architecture de stockage pour l’IA commence à se distinguer du stockage d’entreprise conventionnel.
Les charges de travail d’entraînement nécessitent un accès parallèle à haut débit, une latence prévisible et des mouvements de données efficaces entre les ensembles de données, les caches et les accélérateurs.
Les systèmes de fichiers parallèles peuvent prendre en charge des accès fortement concurrents. Le stockage objet offre une capacité durable et évolutive pour les grands ensembles de données et les lacs de données. Le NVMe local et la mise en cache distribuée peuvent, quant à eux, rapprocher les données fréquemment utilisées des ressources de calcul.
La combinaison appropriée dépend donc du comportement de la charge de travail plutôt que d’un modèle de stockage privilégié.
L’architecture de Meta est particulièrement intéressante parce qu’elle repose sur plusieurs couches au lieu d’exiger d’un seul système de stockage qu’il remplisse toutes les fonctions.
Son environnement repensé combine du stockage régional, de la mémoire sur les hôtes et de la mise en cache sur mémoire flash, tandis que des mécanismes de préchargement rapprochent les données des GPU avant même qu’elles soient nécessaires.
Meta rapporte que son cache distribué permet d’absorber les pointes de trafic et atteint un taux moyen de succès du cache de 80 %.
Cette approche répond également à un coût moins évident : le déplacement des données.
Meta souligne que les chercheurs peuvent consacrer plusieurs heures à transférer des ensembles de données vers la région où les GPU sont disponibles.
À ce stade, l’architecture de stockage n’affecte plus seulement l’utilisation des GPU. Elle influence également la vitesse de la recherche et le nombre d’expériences qu’une équipe peut réaliser pendant une période donnée.
Le même principe s’applique à l’IA en entreprise.
Si chaque cycle d’entraînement nécessite d’importantes opérations de copie, de prétraitement ou de déplacement des données avant que le calcul puisse commencer, l’organisation paie à la fois pour l’infrastructure et pour le temps d’attente — un coût qui n’apparaît pas nécessairement sur la facture des GPU.
Que devrait mesurer un DSI avant d’acheter davantage de GPU?
La réponse n’est pas de cesser d’investir dans les GPU.
Il faut plutôt s’assurer que l’infrastructure qui les entoure permet de justifier cet investissement.
Cela signifie qu’il faut regarder au-delà du taux d’utilisation des GPU comme simple indicateur affiché dans un tableau de bord.
Les dirigeants technologiques devraient pouvoir analyser le temps de chargement des données, la latence du stockage, le débit d’entrées-sorties, la profondeur des files d’attente, la durée des points de contrôle, l’efficacité du cache et le volume de données déplacé entre les différents niveaux ou emplacements de stockage, parallèlement au taux d’utilisation des accélérateurs.
Ces mesures permettent de distinguer un véritable manque de capacité de calcul d’un goulot d’étranglement situé ailleurs dans le pipeline.
Elles changent également la conversation entourant les investissements.
Si les GPU attendent régulièrement le stockage, l’ajout d’une autre grappe de GPU peut augmenter les dépenses en immobilisations sans pour autant accroître la quantité de travail utile produite.
Si le problème se situe plutôt dans la livraison des données, l’amélioration du débit du stockage, de la localité des données, de la mise en cache ou du réseau entre les données et les ressources de calcul peut permettre de tirer davantage de valeur d’une infrastructure déjà acquise.
C’est une façon différente d’aborder l’infrastructure d’IA :
optimiser le système avant d’en augmenter les composantes.
La nouvelle équation de l’infrastructure d’IA
La croissance rapide du calcul accéléré rend de plus en plus difficile le maintien de l’ancienne séparation entre le calcul et le stockage.
Les charges de travail d’IA ne consomment pas des ressources de calcul indépendamment des données. Elles utilisent ces ressources à travers un pipeline de données continu.
L’expérience de Meta démontre ce qui se produit lorsque ce pipeline devient la principale contrainte.
L’entreprise ne s’est pas contentée d’ajouter davantage de matériel pour compenser les ralentissements des GPU. Elle a modifié la gestion des métadonnées, éliminé des intermédiaires inutiles dans le chemin de données, introduit une mise en cache distribuée et rapproché le stockage de ses ressources GPU réparties géographiquement.
Pour Open Storage Solutions, c’est là que se situe la conversation la plus importante en matière d’infrastructure.
Le stockage destiné à l’IA doit être évalué selon sa capacité à transformer efficacement des ressources de calcul coûteuses en travail productif : débit, latence, localité des données, évolutivité et capacité à gérer les modes d’accès générés par l’entraînement et l’inférence.
Le constat est donc clair : avant d’approuver un nouvel investissement majeur dans les GPU, il faut déterminer où se situe réellement la contrainte dans l’environnement actuel.
Si la réponse est le stockage, le réseau ou le déplacement des données, ajouter davantage de capacité de calcul risque simplement de rendre un goulot d’étranglement déjà coûteux encore plus dispendieux.
L’avenir de l’infrastructure d’IA ne sera pas déterminé par les organisations qui possèdent le plus grand nombre de GPU. Il sera déterminé par celles qui parviennent à maintenir leurs GPU constamment productifs.
Add your first comment to this post