Tuesday, November 3, 2026
Home » Infrastructure de calcul IA : composants et guide de conception

Infrastructure de calcul IA : composants et guide de conception

Les équipes d’infrastructure ont adapté tant bien que mal des stockages conçus pour les fichiers et la sauvegarde d’entreprise afin de prendre en charge les charges de travail IA. Cette approche cède à grande échelle. L’infrastructure de calcul IA exige une architecture fondamentalement différente — construite autour de l’alimentation des GPU à haut débit, d’un stockage désagrégé et de niveaux alignés sur les charges. Bien concevoir ces composants dès le départ détermine si votre plateforme IA évolue ou cale.

Ce guide présente les composants de l’infrastructure de calcul IA, les principes de conception qui distinguent les déploiements fonctionnels de ceux qui se heurtent à un mur à l’échelle du pétaoctet, et la manière dont les plateformes de stockage modernes s’intègrent à l’ensemble de la pile de calcul.

Qu’est-ce que l’infrastructure de calcul IA ?

L’infrastructure de calcul IA est la combinaison de matériel, de réseau, de stockage et de logiciels d’orchestration qui prend en charge l’entraînement, l’inférence et la préparation des données (en anglais) du machine learning. Elle se distingue de l’infrastructure de calcul généraliste sur trois points : les charges sont centrées sur les GPU plutôt que sur les CPU ; les volumes de données croissent bien plus vite que ceux des applications d’entreprise traditionnelles ; et les profils d’E/S sont irréguliers, parallèles et sensibles à la latence à chaque étape du cycle de vie des données IA.

Un cluster d’entraînement qui lit un jeu de données de 100 To pendant des milliers d’heures-GPU n’a pas les mêmes besoins d’infrastructure qu’une base de données transactionnelle ou un serveur de fichiers. La bande passante mémoire, le débit de stockage et la fabric réseau doivent être conçus ensemble. Greffer des charges d’IA sur une infrastructure héritée produit toujours le même résultat : sous-utilisation des GPU, goulots d’étranglement à l’entraînement et ingénieurs qui consacrent leur temps à l’infrastructure plutôt qu’aux modèles.

Les composants clés de l’infrastructure de calcul IA

Cette infrastructure se compose de cinq couches. Chacune a des exigences de performance spécifiques, et elles doivent être conçues ensemble — et non assemblées à partir de ce qui est disponible.

ComposantRôleMétrique clé
Clusters GPUCalcul matriciel parallèle pour l’entraînement et l’inférenceUtilisation GPU (en anglais) en %, bande passante mémoire
Réseau haut débit / RDMADéplacement des données à faible latence entre calcul et stockageLatence (µs), bande passante (Tbit/s)
Niveaux de stockageAlimenter données d’entraînement, checkpoints, embeddings, cache d’inférenceDébit (Go/s), IOPS, capacité
Orchestration (Kubernetes / Slurm)Ordonnancer les tâches GPU, gérer la contention des ressourcesProfondeur de file des tâches, surcoût d’ordonnancement
Supervision et observabilitéSuivre la saturation des GPU, les E/S de stockage, l’avancement des tâchesVisibilité de bout en bout du pipeline

Clusters GPU

L’unité de calcul est le GPU, pas le CPU. L’entraînement IA moderne s’exécute sur des clusters de GPU de classe H100 ou A100 reliés par NVLink pour la communication au sein d’un nœud et par InfiniBand ou RoCE entre nœuds. La taille des clusters va de quelques nœuds pour le fine-tuning à des milliers de nœuds pour le pré-entraînement à grande échelle.

L’utilisation des GPU est la principale métrique d’efficacité. Toute utilisation soutenue inférieure à 80 % pendant un entraînement signale un goulot d’étranglement ailleurs — généralement dans le chargement des données ou les E/S de checkpoint. Les équipes d’infrastructure qui optimisent la couche de calcul sans traiter la couche de stockage constatent couramment une utilisation des GPU entre 40 et 60 %.

Réseau haut débit et RDMA

Le RDMA (Remote Direct Memory Access) est le mécanisme qui permet aux systèmes de stockage d’alimenter les GPU sans passer par le CPU. Le réseau TCP/IP traditionnel introduit une latence et une charge CPU qui deviennent un plafond ferme pour le débit à grande échelle. Les fabrics InfiniBand et RoCEv2 utilisant le RDMA suppriment ce surcoût et permettent l’accès GPU-direct au stockage.

Pour l’infrastructure de calcul IA, la fabric réseau relie trois plans : GPU à GPU pour les opérations collectives (AllReduce pendant l’entraînement), GPU vers stockage pour le chargement des données et l’écriture des checkpoints, et CPU vers orchestration pour l’ordonnancement des tâches. Chaque plan a ses propres exigences de latence et de bande passante, et les confondre sur une seule fabric crée de la contention.

Niveaux de stockage

Le stockage est le composant le plus souvent sous-spécifié de l’infrastructure de calcul IA. Les équipes surinvestissent dans le calcul GPU, puis découvrent que les entraînements manquent de données. Un niveau de stockage bien conçu fournit :

  • Niveau GPU-direct : flash à ultra-faible latence connectée via S3 over RDMA. Alimente les entraînements en cours, le cache KV pour l’inférence et l’écriture des checkpoints en temps réel. Latence cible : moins de 50 µs.
  • Niveau chaud : QLC ou NL-SSD haute densité pour les jeux de données actifs, les embeddings et les checkpoints récents. Délivre un débit agrégé de plusieurs téraoctets par seconde pour le chargement parallèle des données par les GPU.
  • Niveau tiède : pour les jeux de données moins fréquemment utilisés — données d’entraînement en attente, embeddings intermédiaires, index RAG.
  • Niveau froid : rétention longue durée des données d’entraînement brutes, des archives réglementaires et des artefacts de traçabilité des modèles.

Le modèle de conception du stockage hiérarchisé pour l’IA (en anglais) adapte la température des données à l’économie du stockage tout en préservant le débit dont le chemin critique a besoin.

Orchestration

Kubernetes et Slurm sont tous deux utilisés en production dans l’infrastructure de calcul IA, et ils servent des objectifs différents. Slurm domine les clusters d’entraînement de type HPC, où les tâches sont volumineuses, longues et exigent une réservation stricte des ressources. Kubernetes est privilégié pour le service d’inférence, les pipelines de préparation des données et les charges mixtes où l’ordonnancement dynamique compte.

Le choix de la couche d’orchestration influe sur la manière dont le stockage est provisionné. Les charges d’IA natives Kubernetes utilisent des persistent volume claims adossés à un stockage objet compatible S3. Les tâches Slurm montent généralement le stockage directement. Les équipes d’infrastructure qui construisent des pipelines d’infrastructure IA certifiés (en anglais) ont besoin d’un stockage qui fonctionne proprement avec les deux paradigmes.

Supervision et observabilité

La saturation des GPU indique si l’infrastructure fonctionne ; les E/S de stockage indiquent où se trouve le goulot d’étranglement. Une observabilité efficace couvre les métriques de calcul (utilisation des GPU, bande passante mémoire, débit NVLink), les métriques de stockage (débit en lecture/écriture par niveau, profondeur de file, taux de réussite du cache) et les métriques par tâche (temps de chargement des données, latence d’écriture des checkpoints, durée des epochs).

Principes de conception de l’infrastructure de calcul IA

Trois principes distinguent une infrastructure qui évolue d’une infrastructure qui exige une lutte permanente contre les incidents.

Désagrégation

La désagrégation consiste à séparer calcul et stockage pour que chacun évolue indépendamment. L’infrastructure hyperconvergée avait du sens pour les charges d’entreprise généralistes. Pour l’IA, elle impose un choix inconfortable : faire évoluer le stockage avec le calcul même lorsqu’on n’a besoin que de l’un, ou plafonner l’un pour l’aligner sur l’autre.

Les architectures désagrégées permettent d’ajouter des nœuds GPU sans acheter de stockage, et d’étendre la capacité de stockage sans ajouter de cycles GPU. Le cluster de stockage est relié au cluster de calcul par la fabric haut débit. C’est ainsi que sont conçus aujourd’hui les data centers IA à grande échelle.

Scale-out plutôt que scale-up

Pour les charges d’IA, la mise à l’échelle horizontale par ajout de nœuds l’emporte sur la mise à l’échelle verticale par des nœuds plus gros. Les clusters de stockage objet scale-out offrent une croissance linéaire du débit à mesure que des nœuds sont ajoutés. Une grosse tête NAS unique devient un goulot d’étranglement à l’échelle du pétaoctet ; un stockage objet distribué, non.

Pour les entraînements qui lisent simultanément des centaines de fichiers sur des milliers de GPU, la bande passante d’E/S agrégée d’un cluster scale-out est la seule architecture qui évite que le stockage devienne le goulot d’étranglement.

Des niveaux de stockage alignés sur les charges

Toutes les charges d’IA n’ont pas les mêmes exigences de stockage. Les E/S de checkpoint pendant l’entraînement exigent un débit d’écriture élevé et une faible latence. L’ingestion des jeux de données exige une bande passante de lecture élevée et soutenue. La récupération RAG exige des lectures aléatoires rapides. L’archivage des modèles à long terme exige densité et durabilité, pas vitesse.

Concevoir un niveau de stockage unique qui tente de tout gérer est coûteux et inefficace. Des niveaux alignés sur les charges adaptent le profil de stockage aux exigences de chaque charge, puis s’appuient sur l’automatisation du cycle de vie pour déplacer les données entre niveaux sans intervention manuelle. Les charges de stockage de données IA multimodales en particulier bénéficient de cette approche — les jeux de données d’images, de vidéos et de texte ont des profils d’accès très différents.

Conception du stockage pour les charges de calcul IA

Le cycle de vie des données IA comporte cinq étapes, chacune avec des exigences de stockage distinctes.

Ingestion et préparation : les données d’entraînement brutes arrivent de sources externes, de data lakes ou de flux d’instruments. Le stockage d’ingestion exige une bande passante d’écriture élevée et une capacité suffisante pour conserver de gros jeux de travail. La préparation des données — nettoyage, tokenisation, mise en forme — exécute des tâches intensives en CPU qui lisent et réécrivent les données à plusieurs reprises. Un stockage objet à espace de noms plat gère cela efficacement à grande échelle ; le modèle d’un stockage de données IA sans obstacles (en anglais) détaille le chemin de l’ingestion à l’entraînement.

Jeux de données d’entraînement : une fois préparées, les données sont lues à répétition par les entraînements sur de nombreuses epochs. Le système de stockage doit soutenir un débit agrégé élevé pour des lectures parallèles simultanées depuis de nombreux GPU. La mise en cache des jeux de données chauds sur des niveaux flash réduit sensiblement la latence de relecture.

Checkpoints : les entraînements écrivent périodiquement des checkpoints pour pouvoir reprendre après une panne. Ces écritures sont irrégulières, à forte bande passante et sensibles à la latence — un checkpoint lent bloque tout l’entraînement. Le niveau GPU-direct est généralement utilisé pour les checkpoints en cours ; les checkpoints terminés sont promus vers le niveau chaud.

Service d’inférence : l’inférence a des exigences de stockage différentes de l’entraînement. Les poids des modèles doivent se charger rapidement au démarrage. Le cache KV pour l’inférence à long contexte exige des lectures aléatoires à ultra-faible latence. Le stockage des bases de données vectorielles et le stockage pour la génération augmentée par récupération des pipelines RAG résident sur le niveau chaud, avec des profils de performance plus proches d’une base de données que d’un système de fichiers.

Rétention et archivage : les modèles entraînés, les résultats d’évaluation et les jeux de données bruts sont soumis à de longues exigences de rétention, dictées par la gouvernance, la reproductibilité et la conformité réglementaire. Un stockage de niveau froid offrant de fortes garanties de durabilité et des politiques de cycle de vie automatisées s’en charge sans surcoût de gestion manuelle des données.

Comment Scality ADI s’intègre à l’infrastructure de calcul IA

Scality ADI (Autonomous Data Infrastructure) est conçue pour la couche de stockage de l’infrastructure de calcul IA. Elle répond aux modes de défaillance spécifiques qui apparaissent lorsqu’un stockage généraliste doit gérer des charges d’IA à l’échelle du pétaoctet.

Architecture. Scality ADI repose sur l’architecture désagrégée RING10 — un moteur de stockage distribué natif objet conçu pour les environnements extrêmes, du pétaoctet à l’exaoctet. RING10 fournit un espace de noms unifié, une forte durabilité et une gestion automatisée du cycle de vie sur tous les niveaux de stockage. ScalityOS est l’environnement d’exécution durci et standardisé qui offre une expérience de type appliance sur l’ensemble de la pile matérielle, en réduisant la fragmentation du cycle de vie et en simplifiant l’exploitation. La relation entre les couches : Scality RING est le moteur, ScalityOS le châssis, Scality ADI la plateforme.

Quatre niveaux de stockage alignés sur les charges. Scality ADI est livrée avec quatre niveaux préconfigurés correspondant aux étapes du cycle de vie des données IA décrites ci-dessus :

  • Niveau GPU-Direct — flash TLC avec S3 over RDMA. Latence inférieure à 50 µs pour les entraînements en cours, les E/S de checkpoint et le cache KV. Se connecte directement à la fabric GPU sans passer par le CPU.
  • Niveau Hot — QLC et NL-SSD offrant un débit agrégé de plusieurs téraoctets par seconde. Pour les jeux de données d’entraînement actifs, les embeddings et les checkpoints récents.
  • Niveau Warm — pour les jeux de données en attente, les index RAG et les embeddings intermédiaires.
  • Niveau Cold — capacité haute densité pour les archives de données brutes, la rétention réglementaire et la traçabilité des modèles.

L’automatisation du cycle de vie déplace les données entre niveaux sans créer de nouveaux silos de stockage. La comparaison de la consommation électrique haute densité entre HDD et flash QLC (en anglais) détaille l’économie des transitions du tiède vers le froid.

GPU-direct via S3 over RDMA. Scality ADI prend en charge l’accès GPU-direct au stockage via S3 over RDMA : les nœuds GPU lisent les données d’entraînement directement depuis la fabric de stockage, sans passer par le CPU. Cela supprime le goulot d’étranglement CPU qui limite le débit des architectures de stockage basées sur TCP, et c’est le mécanisme qui permet de maintenir une utilisation des GPU supérieure à 90 % pendant les entraînements intensifs en données.

Des profils logiciel-matériel alignés sur les charges. Plutôt que d’obliger les équipes d’infrastructure à régler la configuration du stockage pour chaque type de charge, Scality ADI est livrée avec des profils prévalidés qui adaptent la configuration matérielle aux exigences des charges. Une équipe qui déploie un nouveau cluster de fine-tuning choisit le profil approprié ; la plateforme configure automatiquement le bon niveau, les paramètres réseau et les réglages de durabilité.

Les équipes d’infrastructure qui construisent une infrastructure de stockage pour l’IA agentique sur Scality ADI disposent d’une plateforme qui gère l’ensemble du flux de données IA — de l’ingestion à la préparation, en passant par les charges RAG et VSS, les checkpoints, les embeddings, les journaux et la rétention longue durée — sans la complexité opérationnelle de systèmes de stockage distincts pour chaque étape.

Découvrez comment Scality ADI s’intègre à l’infrastructure de calcul IA →

Questions fréquentes

Qu’est-ce que l’infrastructure de calcul IA ?

L’infrastructure de calcul IA est la pile intégrée de clusters GPU, de réseau haut débit, de niveaux de stockage et de logiciels d’orchestration qui prend en charge l’entraînement, l’inférence et la préparation des données du machine learning à grande échelle. Elle se distingue de l’infrastructure de data center généraliste par des charges centrées sur les GPU, des volumes de données en croissance rapide et des profils d’E/S irréguliers et parallèles tout au long du cycle de vie des données IA.

Quels sont les composants clés de l’infrastructure de calcul IA ?

Les cinq composants principaux sont les clusters GPU (calcul parallèle), le réseau haut débit compatible RDMA (déplacement des données à faible latence), les niveaux de stockage alignés sur les charges (alimentation et rétention des données), les logiciels d’orchestration comme Kubernetes ou Slurm (ordonnancement des tâches et gestion des ressources) et les outils de supervision et d’observabilité (suivi de l’utilisation des GPU et des performances d’E/S). Le stockage est souvent le composant le plus sous-spécifié et la cause la plus fréquente de sous-utilisation des GPU.

En quoi l’infrastructure de calcul IA diffère-t-elle de l’infrastructure de data center traditionnelle ?

L’infrastructure de data center traditionnelle est conçue pour des charges centrées sur le CPU, tolérantes à la latence, avec des E/S modérées et prévisibles. L’infrastructure de calcul IA doit soutenir un débit de stockage agrégé extrêmement élevé pour alimenter les clusters GPU, absorber les rafales d’écriture de checkpoints sans bloquer les entraînements et faire évoluer la capacité de stockage indépendamment du calcul. La fabric réseau diffère aussi : l’infrastructure IA exige des fabrics compatibles RDMA pour supprimer la charge CPU sur le chemin des données, là où les data centers traditionnels utilisent TCP/IP partout.

Quelle architecture de stockage convient le mieux aux charges de calcul IA ?

Un stockage objet désagrégé et scale-out, avec des niveaux alignés sur les charges, offre les meilleures performances pour les charges de calcul IA. Le cluster de stockage est relié au cluster de calcul par une fabric RDMA haut débit plutôt que colocalisé avec les nœuds GPU. Plusieurs niveaux — flash GPU-direct, chaud en QLC/NL-SSD, tiède et froid — servent les différentes étapes du cycle de vie des données IA. L’automatisation du cycle de vie déplace les données entre niveaux sans intervention manuelle. Cette architecture évite les plafonds de débit des conceptions hyperconvergées et évolue horizontalement à mesure que le cluster GPU grandit. Consultez la planification de la capacité de stockage pour dimensionner chaque niveau.

Pour aller plus loin