4 La plupart des programmes d’infrastructure IA n’échouent pas au stade du prototype. Ils échouent la première fois que l’équipe tente de passer d’une baie de GPU à dix, ou d’un cluster d’entraînement à une empreinte multisite. La mise à l’échelle du calcul IA est le moment où les hypothèses intégrées à l’architecture initiale portent leurs fruits ou s’effondrent. Pour un responsable d’infrastructure, la mise à l’échelle n’est pas un problème d’avenir. Les décisions prises dans les 90 premiers jours d’un déploiement IA — topologie des nœuds, interconnexion, hiérarchisation du stockage et conception de l’espace de noms — fixent le plafond de toutes les charges de travail qui suivront. Si elles sont mauvaises, l’équipe passera des années à les contourner. Ce guide explique ce que recouvre réellement la mise à l’échelle du calcul IA, les deux axes de croissance, les techniques de parallélisme qui répartissent le travail entre les nœuds, les modèles de clusters multi-nœuds utilisés en production, et pourquoi un stockage qui évolue avec le calcul est la contrainte que la plupart des équipes sous-estiment. Qu’est-ce que la mise à l’échelle du calcul IA ? La mise à l’échelle du calcul IA consiste à faire croître la capacité d’entraînement et d’inférence pour suivre des modèles plus grands, des jeux de données plus volumineux et une concurrence plus élevée, tout en maîtrisant l’utilisation et l’économie. C’est la discipline qui consiste à ajouter de la capacité sans ajouter de frein proportionnel — opérationnel, financier ou architectural. La mise à l’échelle se distingue de l’efficacité. L’efficacité demande combien de travail utile on peut tirer des GPU dont on dispose déjà. La mise à l’échelle demande comment ajouter de la capacité — plus de GPU, plus de nœuds, plus de sites — sans que la nouvelle capacité se comporte différemment de l’ancienne. Un cluster qui fonctionne bien à 32 nœuds et cale à 256 n’a pas été mis à l’échelle. Il a simplement été agrandi. Trois forces imposent aujourd’hui la mise à l’échelle : La taille des modèles. Le nombre de paramètres et les fenêtres de contexte des modèles de pointe ont progressé bien plus vite que la mémoire par GPU. La taille des jeux de données. Les jeux de données multimodaux franchissent couramment le seuil du pétaoctet ; les données d’entreprise de longue traîne franchissent celui de l’exaoctet sur un horizon de plusieurs années. La concurrence. L’inférence en production, les workflows agentiques et le cache KV centralisé pour l’inférence distribuée poussent les volumes de requêtes concurrentes bien au-delà de ce qu’un seul nœud peut servir. Chacune suffit à imposer une décision de mise à l’échelle. En pratique, les équipes d’infrastructure rencontrent les trois à la fois. Mise à l’échelle horizontale ou verticale Il existe deux axes de croissance, et la plupart des programmes d’IA en production utilisent les deux. AxeCe que cela signifieQuand c’est adaptéLimitesMise à l’échelle verticale (scale-up)Plus de ressources par nœud : GPU plus puissants, plus de mémoire GPU, interconnexion locale plus rapideEntraînement d’un modèle unique où la communication collective domine ; inférence sensible à la latenceLimitée par la feuille de route du silicium, l’enveloppe électrique par baie et le rayon d’impact (en anglais) d’une panne au niveau du nœudMise à l’échelle horizontale (scale-out)Plus de nœuds, reliés par une fabric haut débitJeux de données et modèles qui dépassent un nœud ; pipelines d’ingestion et de préparation ; inférence multi-locataireLimitée par la topologie d’interconnexion, le débit du stockage et le coût de coordination de l’orchestration Quand la mise à l’échelle verticale est pertinente La mise à l’échelle verticale est le bon point de départ lorsque la charge tient confortablement sur un nœud. Un entraînement sur un seul nœud bénéficiant d’une bande passante GPU à GPU de classe NVLink évite totalement le surcoût de coordination de l’entraînement distribué. Pour l’inférence, un nœud plus puissant réduit la latence (en anglais) de queue en maintenant le modèle entier en HBM. Le plafond vertical est pourtant bien réel. La mémoire par GPU progresse de génération en génération, mais moins vite que la taille des modèles produits par la recherche. L’alimentation et le refroidissement par baie sont des contraintes fermes dans la plupart des data centers. Et un gros nœud unique est aussi un gros domaine de défaillance unique — sa perte peut interrompre un entraînement qui accumulait de l’état depuis des jours. Quand la mise à l’échelle horizontale est pertinente La mise à l’échelle horizontale est ce que fait réellement l’IA d’entreprise une fois la phase d’essai passée. Les entraînements répartis sur des dizaines ou des milliers de GPU exigent une fabric scale-out. Les plateformes d’inférence qui servent des milliers d’utilisateurs simultanés ont besoin d’un niveau scale-out de réplicas, souvent précédé d’un cache KV partagé lui-même hébergé sur un stockage scale-out. Le modèle horizontal déplace le goulot d’étranglement du silicium vers la coordination. La latence d’interconnexion, le surcoût de communication collective et les E/S de stockage à travers la fabric deviennent tous déterminants. C’est là que les choix de stockage faits tôt commencent à compter à chaque frontière de charge de travail. Techniques de parallélisme : comment le travail se répartit réellement Dès lors que l’on choisit d’aller au-delà d’un seul nœud, la question devient : comment répartir le travail ? Deux modèles dominent. Parallélisme de données Dans le parallélisme de données, chaque GPU détient une copie complète du modèle et traite une partition différente des données d’entraînement. Après chaque lot, les GPU échangent leurs gradients via une opération collective AllReduce et mettent à jour leurs copies du modèle de manière synchronisée. Le parallélisme de données passe bien à l’échelle lorsque : Le modèle tient confortablement dans la mémoire d’un seul GPU. Le jeu de données d’entraînement est assez volumineux pour que les partitions par GPU restent des lots significatifs. L’interconnexion peut absorber l’AllReduce des gradients au rythme de chaque étape d’entraînement. Les implications du parallélisme de données sur le stockage sont importantes. Chaque GPU du cluster lit le même jeu de données. Un cluster de 1 024 GPU en entraînement parallèle de données génère 1 024 flux de lecture concurrents vers le niveau de stockage. C’est le débit agrégé, et non le débit par flux, qui détermine si les GPU restent alimentés. C’est le mode de défaillance qui transforme un benchmark de 10 Go/s par nœud en une réalité de 3 Go/s sous charge. Parallélisme de modèle Lorsque le modèle lui-même ne tient plus dans la mémoire d’un seul GPU, le parallélisme de modèle le répartit entre plusieurs GPU. Deux variantes sont courantes : Le parallélisme tensoriel répartit des couches individuelles entre GPU — une même multiplication matricielle s’exécute simultanément sur plusieurs équipements. Le parallélisme en pipeline répartit le modèle en étapes, différents GPU détenant différentes couches successives, et des micro-lots circulant dans le pipeline. Le parallélisme de modèle est la seule option pour les modèles de pointe, mais il est très gourmand en communication. Le parallélisme tensoriel en particulier exige des liaisons à très faible latence et très haut débit entre les GPU concernés. C’est pourquoi les groupes en parallélisme de modèle sont généralement maintenus au sein d’un seul nœud ou d’un petit ensemble de nœuds reliés par une fabric de classe NVLink, tandis que le parallélisme de données s’applique entre les nœuds. Parallélisme hybride Les entraînements de production à grande échelle combinent les deux. Un modèle courant est le parallélisme 3D : parallélisme tensoriel au sein d’un nœud, parallélisme en pipeline sur un petit groupe de nœuds et parallélisme de données sur de nombreux groupes de ce type. Chaque axe a son propre schéma de communication, et chacun interagit différemment avec le niveau de stockage. Pour approfondir la manière dont ces modèles façonnent la couche de données, consultez le stockage des pipelines d’entraînement IA et le stockage des données d’entraînement des LLM. Clusters GPU multi-nœuds : le modèle de mise à l’échelle qui compte Un cluster GPU multi-nœuds est l’unité standard de mise à l’échelle du calcul IA en entreprise. Le modèle est bien connu, mais ce sont les détails qui déterminent si le cluster évolue linéairement ou se heurte à des murs de coordination. Topologie d’interconnexion Au sein du nœud, les GPU communiquent via NVLink ou un équivalent. Entre les nœuds, la fabric est généralement InfiniBand ou RoCEv2. La topologie compte : les conceptions fat-tree, dragonfly et optimisées par rail présentent chacune des compromis différents pour la communication collective selon la taille du cluster. Un cluster de 64 nœuds tolère des choix de topologie qu’un cluster de 1 024 nœuds ne peut pas se permettre. Domaines de défaillance Un cluster multi-nœuds tombe en panne au niveau des nœuds, des baies, des commutateurs, des zones de refroidissement et du niveau de stockage. Les longs entraînements ne survivent pas à une organisation négligente des domaines de défaillance — la panne d’un seul commutateur peut bloquer toutes les tâches en cours. Le même principe s’applique au stockage. Un système de stockage à petit domaine de défaillance qu’il faut reconstruire fréquemment devient la principale source d’indisponibilité du cluster. C’est l’un des domaines où une architecture de stockage à l’échelle de l’exaoctet porte ses fruits. Un niveau de stockage conçu pour des domaines de défaillance de plusieurs pétaoctets à l’exaoctet, avec protection multisite et erasure coding intégrés, n’arrête pas le cluster chaque fois qu’un disque ou un tiroir tombe en panne. Pour en savoir plus, consultez la durabilité des données dans les systèmes de stockage haute densité (en anglais). Orchestration Slurm domine les clusters d’entraînement de type HPC. Kubernetes est privilégié pour l’inférence, la préparation et les charges mixtes. À grande échelle, les deux approches révèlent la même exigence : la couche de stockage doit apparaître identique à chaque nœud, avec une sémantique et des performances cohérentes, quel que soit le nombre de tâches planifiées simultanément. Mise à l’échelle du stockage : la contrainte que la plupart des équipes sous-estiment Le constat est le même dans tous les programmes d’IA d’entreprise décrits par les analystes du secteur : les équipes font évoluer le calcul et découvrent que le stockage est le mur. La mise à l’échelle du stockage ne peut pas être une réflexion après coup. Elle doit être conçue en même temps que la feuille de route du calcul, dès le premier jour. Pourquoi le stockage doit évoluer sur plusieurs axes Le calcul n’est pas la seule dimension qui croît. Le stockage doit évoluer indépendamment sur trois axes : La capacité — des pétaoctets aujourd’hui, de plusieurs pétaoctets à l’exaoctet demain, à mesure que s’accumulent données brutes, embeddings, checkpoints de modèles et artefacts d’audit. Le débit — une bande passante agrégée de plusieurs téraoctets par seconde pour alimenter les clusters GPU multi-nœuds sans affamer les GPU. La concurrence — un accès S3 à forte concurrence pour des milliers de lecteurs simultanés, entre parallélisme de données, accès au cache KV et réplicas d’inférence. Un niveau de stockage qui fait évoluer la capacité mais pas le débit est une cible de sauvegarde. Un niveau qui fait évoluer le débit mais pas la capacité manque de place avant la fin de l’entraînement. Un niveau qui fait évoluer les deux mais ne gère pas l’accès S3 concurrent à l’échelle du cluster bloque dès l’entrée. Les trois doivent croître ensemble. Hiérarchisation multi-température Tous les octets n’ont pas leur place sur le niveau le plus chaud. Le cycle de vie des données IA fait circuler le travail entre températures : ingestion brute, jeux d’entraînement préparés, jeux de données actifs chauds, checkpoints, embeddings et rétention longue durée ont chacun des profils d’accès différents. Une architecture de stockage évolutive adapte le support à l’étape au lieu d’imposer la flash premium pour tout. Pour le contexte, consultez le stockage hiérarchisé pour l’IA (en anglais) et les niveaux de stockage du data center. Des mises à niveau sans impact Mettre à l’échelle signifie que le stockage sera étendu, remplacé et rééquilibré à plusieurs reprises au cours de la vie du cluster. Si chaque extension est une interruption planifiée, le coût opérationnel s’accumule à chaque cycle de croissance. Une plateforme de stockage aux mises à niveau sans impact — ajouts de capacité, renouvellements matériels et rééquilibrages sans mise hors ligne de l’espace de noms — est le seul modèle qui tienne sur des feuilles de route IA pluriannuelles. La place de Scality ADI dans la mise à l’échelle du calcul IA Les décisions de mise à l’échelle du stockage engagent souvent l’équipe pour des années. Scality ADI (Autonomous Data Infrastructure) est conçue pour que ces décisions tiennent dans la durée. Scality ADI est une infrastructure de données pour l’IA d’entreprise, la cyber-résilience et le contrôle souverain, qui aligne de manière autonome et durable les bons supports de stockage sur chaque étape du cycle de vie des données, de l’échelle multi-pétaoctet à l’exaoctet. Pour la mise à l’échelle du calcul IA en particulier, quatre propriétés comptent. Un espace de noms S3 à quatre niveaux qui évolue avec le cluster. Scality ADI couvre un niveau GPU-Direct (flash TLC avec S3 over RDMA, latence inférieure à 50 µs), un niveau Hot (QLC et NL-SSD avec un débit de plusieurs téraoctets par seconde), un niveau Warm (NL-SSD, NL-HDD, HDD) et un niveau Cold (bande et archivage adjacent au cloud) sous un espace de noms unique. À mesure que l’empreinte GPU grandit, le stockage grandit avec elle sur l’axe qui compte — capacité, débit ou concurrence — sans obliger l’équipe à copier des données entre plateformes distinctes. Des domaines de défaillance à l’échelle de l’exaoctet. L’architecture RING10 qui sous-tend Scality ADI est conçue pour des domaines de défaillance de plusieurs pétaoctets à l’exaoctet, avec erasure coding, protection des métadonnées et protection multisite intégrés à l’architecture plutôt qu’ajoutés ensuite. Un cluster d’entraînement scale-out n’est pas arrêté par un disque, un tiroir ou un nœud. Des mises à niveau sans impact et une exploitation de type appliance. ScalityOS fournit un environnement d’exécution standardisé qui absorbe la fragmentation du cycle de vie. Ajouts de capacité, renouvellements de supports et mises à niveau de version se font sans mise hors ligne de l’espace de noms. Pour une équipe d’infrastructure qui fait évoluer un cluster GPU sur plusieurs années et plusieurs générations de matériel, c’est la différence entre frein opérationnel et stabilité opérationnelle. Des profils alignés sur les charges, pas une solution unique. La couche opérationnelle autonome formule analyses et recommandations dans le cadre des politiques définies par le client, afin que le bon profil de stockage atteigne la bonne charge à mesure que le cluster grandit. Découvrez comment Scality ADI soutient l’IA d’entreprise à grande échelle. Bonnes pratiques de mise à l’échelle du calcul IA Une courte liste, tirée des modèles ci-dessus. Concevez le niveau de stockage en même temps que le niveau de calcul — pas après. Les deux évoluent ensemble, ou n’évoluent pas du tout. Choisissez le modèle de parallélisme qui correspond à votre goulot d’étranglement, pas celui qui paraît le plus moderne. Le parallélisme de données convient lorsque le modèle tient en mémoire ; le parallélisme de modèle seulement lorsqu’il n’y tient plus. Planifiez explicitement les domaines de défaillance. Sachez ce qu’une panne de commutateur, de nœud, de baie ou de tiroir de stockage fait aux tâches en cours. Évitez la flash premium pour chaque octet. Adaptez le support à la température des données. Le niveau froid existe pour une raison. Traitez les mises à niveau du stockage comme une priorité. Si chaque extension est une interruption planifiée, le plan est mauvais. Instrumentez chaque axe. L’utilisation des GPU indique que le cluster est occupé. Le débit de stockage par niveau indique s’il est occupé à un travail utile ou en attente d’E/S. Questions fréquentes La mise à l’échelle horizontale ou verticale est-elle préférable pour les charges IA ? Les deux, successivement. Commencez par la verticale pour les prototypes et l’entraînement à petite échelle. Passez à l’horizontale lorsque le modèle dépasse un nœud, que le jeu de données dépasse le stockage local ou que la concurrence dépasse un réplica unique. La plupart des environnements d’IA d’entreprise en production utilisent la mise à l’échelle verticale au sein des nœuds et horizontale entre eux. Quelle est la différence entre parallélisme de données et parallélisme de modèle ? Le parallélisme de données conserve une copie complète du modèle sur chaque GPU et répartit les données d’entraînement entre eux. Le parallélisme de modèle répartit le modèle lui-même entre GPU, soit par couche (pipeline), soit au sein d’une couche (tensoriel). Le parallélisme de données passe le plus proprement à l’échelle ; le parallélisme de modèle devient nécessaire lorsque le modèle ne tient plus sur un GPU. Comment le stockage limite-t-il la mise à l’échelle du calcul IA ? En étant insuffisant sur l’un des trois axes : capacité, débit ou concurrence. Un cluster GPU multi-nœuds est affamé dès que le stockage ne peut alimenter tous les GPU en parallèle. Un stockage qui évolue indépendamment sur les trois axes — et qui survit aux pannes de nœuds et de sites sans arrêter le cluster — est le prérequis pour faire évoluer le calcul au-delà d’une seule baie. Quel est le rôle de Scality ADI dans la mise à l’échelle de l’infrastructure IA ? Scality ADI fournit un espace de noms S3 à quatre niveaux qui fait évoluer indépendamment capacité, débit et opérations, avec des domaines de défaillance à l’échelle de l’exaoctet et des mises à niveau sans impact. Elle est conçue pour que la couche de stockage ne devienne jamais la contrainte qui fixe le plafond du cluster GPU. Pour aller plus loin Infrastructure de calcul IA : composants et guide de conception Pipelines de données IA : architecture, étapes et bonnes pratiques Mise à l’échelle multidimensionnelle du stockage cloud (en anglais) Stockage à l’échelle du pétaoctet Stockage GPU-direct Scality ADI : infrastructure de données pour l’IA Conclusion La mise à l’échelle du calcul IA n’est pas une question d’achat de matériel. C’est une question d’architecture. Les équipes qui réussissent traitent le calcul, l’interconnexion et le stockage comme une conception unique — et non comme trois cycles d’achat indépendants. La couche de stockage est l’endroit où la plupart des programmes de mise à l’échelle échouent discrètement. Capacité, débit et concurrence doivent tous croître, chacun sur son axe, sans mise hors ligne de l’espace de noms et sans briser les hypothèses de domaines de défaillance dont dépendent les tâches d’entraînement. Scality ADI est conçue pour ce profil : une plateforme, quatre niveaux, des domaines de défaillance à l’échelle de l’exaoctet, des mises à niveau sans impact et un modèle d’exploitation de type appliance qui tient à mesure que l’empreinte GPU grandit. Le cluster évolue parce que le stockage évolue avec lui.
