Qu'est-ce qu'un centre de données IA ? [Vidéo et quiz]

En bref : un centre de données d’IA est un à haute densité où l’alimentation, le refroidissement, l’infrastructure et le stockage sont optimisés pour l’entraînement et le déploiement des modèles, et non une salle serveur avec des GPU supplémentaires. Ce sont les puces qui font la une ; c’est le bâtiment qui détermine leur bon fonctionnement. Si les images ne peuvent pas être exportées, il est possible d’aménager une petite cellule ; la plupart des équipes devraient louer un tel espace.

Points clés à retenir :

Puces contre construction : la puissance, le refroidissement, le tissu et le stockage déterminent si les accélérateurs fonctionnent.

Des espaces, pas des palais : modernisez deux baies lorsque les données ne peuvent pas sortir ; n’achetez pas un campus.

Moyenne vs médiane: Sur huit essais, la médiane a masqué les redémarrages ; utilisez la moyenne sur 18 heures.

Résistance à la mauvaise utilisation: Ne pas indiquer un PUE pour deux racks dans une salle mixte.

Résultats illustratifs : Huit passages correspondent à une petite carte, et non à une économie de production de 50 %.

Articles que vous pourriez aimer lire après celui-ci :

🔗 L'IA est-elle fiable ? Vidéo et quiz
Explorez la fiabilité de l'IA grâce à une vidéo captivante et un quiz interactif.

🔗 Comment utiliser l'IA au quotidien
Découvrez des façons pratiques dont l'IA peut simplifier les tâches et les routines quotidiennes.

🔗 Comment utiliser l'IA au travail ?
Découvrez des méthodes pratiques pour utiliser l'IA et améliorer la productivité au travail.

🔗 L’IA peut-elle penser par elle-même ?
Comprendre si l’intelligence artificielle peut véritablement penser ou raisonner de manière indépendante.

En quoi diffère-t-il d'un centre de données « normal » ?

Les salles de serveurs traditionnelles sont optimisées pour des charges de travail mixtes et une disponibilité maximale pour de nombreux petits services. La redondance est importante, bien sûr, tout comme le PUE ( l'énergie supplémentaire consommée par le bâtiment pour fournir un watt de puissance de calcul). En général, on ne conçoit pas chaque couloir autour d'une baie qui se comporte comme un véritable centre de chauffage mobile.

Les sites d'IA inversent les proportions. La densité augmente. Le réseau devient une infrastructure indispensable au bon déroulement de l'entraînement. Le stockage doit assurer la fluidité des points de contrôle, sous peine de voir les accélérateurs inactifs, tels des chevaux de course pris dans un embouteillage.

Il y a aussi une différence culturelle. Les opérations d'entreprise raisonnent en tickets et en fenêtres de modification. Les opérations d'IA raisonnent en files d'attente de tâches et avec la frustration de voir un nœud tomber en panne en fin de cycle. On pourrait toujours les appeler « centres de données », car ce sont bien des centres de données. L'appellation ne fait que masquer l'infrastructure.

Il ne s'agit pas d'un classement moral. Des machines différentes, mais une même famille.

GPU, accélérateurs et le rack qui consomme de l'énergie

Dans un plancher technique traditionnel, les rayonnages semblent presque polis. Dans une rangée de rayonnages automatisés, ils donnent l'impression de vouloir engloutir le bâtiment.

L'élément matériel le plus remarquable n'est pas un processeur sophistiqué, mais l'architecture d'accélération : des GPU ou autres puces d'IA, intégrés dans des serveurs, puis des racks, puis des rangées partageant une infrastructure à haut débit. L'interconnexion des GPU permet d'assembler les puces pour former un système qui simule un accélérateur géant ; l'architecture du cluster réalise la même opération à l'échelle des rangées. L'entraînement parallèle n'est possible que si ces liaisons restent performantes et prévisibles. Sans cela, votre « cluster » se réduit à un amas de stations de travail onéreuses partageant le même code postal.

L'alimentation suit les puces. Pas besoin d'un gros PDU de bureau. On parle de mégawatts de charge informatique dès qu'une salle est pleine – je ne donnerai pas de chiffre. La densité par rack est le point crucial. Moins de racks. Chacun d'eux est un véritable petit four. Le facteur limitant est souvent le poste de transformation, et non la liste de souhaits en GPU. Vous connaissez la chanson : le service des achats veut plus d'accélérateurs ; le fournisseur d'énergie veut une longue discussion et un gros chèque.

Une métaphore un peu farfelue me trotte dans la tête : le rack est comme un animal affamé. On peut en élever un plus rapide. Il faut toujours le nourrir et le nettoyer régulièrement. Si on néglige l’un ou l’autre, il devient un presse-papier très coûteux.

Puissance, chaleur et problème de refroidissement

On entre de l'électricité. On sort de la chaleur. Voilà toute la religion.

Les rayonnages haute densité dégagent une chaleur que l'air n'a jamais vraiment été amené à gérer. On peut certes augmenter la pression de l'air (échangeurs de chaleur à l'arrière, allées plus chaudes, confinement astucieux), mais cela fonctionne jusqu'à un certain point. Ensuite, les liquides apparaissent.

• Refroidissement direct sur la puce

• Des circuits de refroidissement qui donnent à la salle des machines l'apparence d'une usine chimique

• L'immersion dans quelques designs, qui surprennent encore les personnes qui pensent que l'eau et les serveurs ne devraient pas partager une phrase

Rien de tout cela n'est glamour. C'est le produit dans son ensemble, car un accélérateur qui bride la puissance est un produit que vous avez déjà payé et que vous ne pouvez pas utiliser pleinement.

Le PUE reste important. C'est un ratio, pas une caractéristique intrinsèque. Les opérateurs s'y intéressent de près car chaque watt consommé par les ventilateurs et les pompes est un watt qui ne serait pas alloué au GPU. Je ne citerai pas de valeur « typique » ; le climat et la définition des limites de l'installation peuvent l'influencer, et une précision illusoire est pire que l'absence de précision. L'eau joue également un rôle. Certaines plantes absorbent l'eau, d'autres la dévorent. Le refroidissement par évaporation est efficace jusqu'à ce qu'une catastrophe comme une rivière ou une sécheresse le rende problématique.

Réseaux : pourquoi l’infrastructure est aussi importante que les puces

On photographie les cartes graphiques. On devrait photographier les commutateurs.

L'entraînement est un dialogue. Des milliers d'accélérateurs échangent des gradients, des paramètres et des fragments de modèle, en parfaite synchronisation. Si le réseau présente une instabilité, l'ensemble du processus est bloqué sur la liaison la plus lente. C'est pourquoi les centres de recherche en IA privilégient les réseaux à haut débit, la faible latence et les topologies qui ne s'effondrent pas en cas de panne. On parle alors de réseaux de type InfiniBand, d'Ethernet jouant le même rôle, d'interconnexions GPU internes et d'un câblage qui doit être irréprochable dès la première installation.

L'inférence est un tout autre sujet. Le déploiement de modèles se concentre sur la latence de fin de réponse (la réponse la plus lente, pas la moyenne). Le traitement par lots ou en temps réel crée une différence fondamentale. Un cluster d'entraînement privilégie un flux important et collectif de données. Un parc de serveurs de déploiement, quant à lui, privilégie de nombreuses requêtes plus petites et l'isolation, afin d'éviter la saturation du répartiteur de charge.

Le problème, tant que j'y suis : on considère le réseau comme de la plomberie et la cuisine comme un restaurant. Dans cet immeuble, la plomberie, c'est le restaurant. Si vous ne tenez pas compte de ça, vous vous retrouvez avec une cuisine incapable de recevoir une livraison.

Entraînement vs inférence : deux bâtiments, parfois littéralement

L'entraînement est une véritable campagne. On assemble un cluster, on l'alimente en données, on effectue des sauvegardes régulières, on le laisse tourner pendant des heures, voire des semaines, en espérant que tout se déroule sans accroc. Un traitement par lots intensif, gourmand en bande passante, et d'une patience à toute épreuve – jusqu'à ce qu'une panne de nœud vienne perturber l'exécution. Un seul accélérateur défaillant dans une tâche étroitement couplée peut paralyser tout le système.

L'inférence est une vitrine. Les modèles, déjà entraînés, répondent aux questions, classent les images et génèrent du texte. La latence est cruciale. Un accélérateur un peu plus ancien, situé près du client, peut surpasser un accélérateur dernier cri à l'autre bout du monde.

On se retrouve donc avec une situation divergente. Les campus d'entraînement privilégient la puissance, l'espace et la densité. Les sites d'inférence, quant à eux, privilégient la latence et la présence. Il existe aussi des salles hybrides, car les ressources ne sont pas illimitées. Enfin, pas toujours deux bâtiments. Parfois, une seule salle avec un cordon de velours et deux systèmes de refroidissement.

C'est également à ce stade que se rejoignent la colocation, les campus hyperscale et l'infrastructure sur site. Les hyperscalers construisent à des échelles qui nous font passer, nous autres, pour de simples meubles. Les centres de données vendent la densité au rack. L'infrastructure sur site reste la solution lorsque les données ne peuvent pas quitter le réseau.

Débit de stockage, points de contrôle et puces gourmandes en ressources

Personne ne met le système de fichiers parallèles en couverture d'une brochure.

Les données d'entraînement doivent arriver suffisamment vite pour éviter que les GPU ne soient surchargés. Les points de contrôle doivent être enregistrés pour qu'un plantage ne compromette pas une semaine de données. Les poids du modèle doivent être chargés avant la mise en service d'une réplique. Le débit de stockage, et non seulement la capacité, constitue le véritable goulot d'étranglement. On peut dépenser une fortune en accélérateurs et les sous-dimensionner avec un système de stockage optimisé pour les machines virtuelles.

Le schéma est bien connu : un cluster rutilant, une file d’attente de tâches et une attente d’E/S qui vous fixe du regard comme une facture impayée. Clusteriser les calculs sans clusteriser le chemin des données, c’est s’exposer à une inactivité très coûteuse. Alimentez correctement les ressources ou admettez que vous avez investi dans une sculpture.

Logiciels, orchestration et la couche opérationnelle peu glamour

Le matériel est la vedette. Les planificateurs font le travail.

Un centre de données d'IA est inutile si les tâches ne trouvent pas de GPU, si deux équipes ne peuvent pas partager un cluster sans se disputer violemment, si un serveur défaillant ne peut pas être remplacé, si le firmware dérive jusqu'à ce que l'infrastructure tombe en panne au ralenti. Orchestration, observabilité, limitation de la consommation : la couche opérationnelle, souvent ingrate, mais essentielle.

J'ai un faible pour cette couche. Et puis, quand une carte réseau mal configurée fait passer un problème de refroidissement pour une panne pendant tout un après-midi… on s'en rend compte à ses dépens.

Lorsqu'un nœud tombe en panne en cours d'exécution

Un nœud tombe en panne. Les fenêtres de modification continuent de se heurter aux cycles d'entraînement qui ne tiennent pas compte de votre calendrier. Vous planifiez les tâches importantes en groupe, isolez les pools d'inférence, rédigez des procédures pour les pannes qui ressemblent à un simple ralentissement de la tâche, jusqu'à ce qu'elles deviennent irrémédiablement interrompues. La redondance reste essentielle (alimentation, refroidissement, chemins d'accès, stockage), mais la gestion des pannes est moins simple qu'avec l'ancien système de disponibilité de 99,7 %. Inférence : répliquer, décharger le nœud défaillant, et poursuivre la réponse. L'entraînement exige des points de contrôle, pas de l'optimisme.

Emplacement, eau, réseau électrique et voisins

On ne dépose pas un de ces trucs à côté d'un chalet pour profiter de la vue.

Le raccordement au réseau est souvent le véritable critère de choix d'un site. Le terrain est facile à appréhender comparé à un poste de transformation et à un réseau électrique qui dessert d'autres clients. L'eau pour le refroidissement, si vous en utilisez, devient un problème de voisinage dès que les pluies sont abondantes. Bruit. Imposante présence visuelle. Chaleur au niveau de la clôture mitoyenne. Les commissions d'urbanisme se penchent sur le projet dès qu'il nécessite un terrain et une rivière.

La latence joue en sens inverse. L'inférence est optimisée pour la proximité des utilisateurs et des interconnexions. L'entraînement peut se dérouler dans des régions où l'énergie est moins chère et le climat plus frais. Le secteur parle comme s'il existait un site idéal. Or, il n'en existe pas. Un compromis est nécessaire, comme le suggère un communiqué de presse.

Chaleur résiduelle et fournaise intempestive

Les brochures adorent ce passage. « Récupérer la chaleur résiduelle dans les maisons, les piscines, les serres » : une belle phrase. Parfois, le système de recyclage est efficace. Parfois, le campus est mal situé et la chaleur se dissipe quand même dans l'air. Je suis sceptique quant à la version des brochures ; je ne remets pas en question le principe physique.

Qui en a besoin (et qui devrait plutôt en louer un)

La plupart des gens n'ont pas besoin de posséder une de ces salles.

La liste sans détour :

• Les hyperscalers, car le produit est la flotte

• Dans les laboratoires, lorsque le temps d'attente constitue le goulot d'étranglement ou que les données ne peuvent pas être transférées

• Une banque, un groupe hospitalier, un gouvernement ou un fabricant possédant des données confidentielles (sur site ou dans un centre de données privé) peut avoir une approche rationnelle, même si cela implique des complications

Tous les autres devraient louer. Colocation avec une densité adaptée à l'IA. Une réservation cloud. Un cluster géré. Vous bénéficiez des accélérateurs sans devenir exploitant de centrale électrique. Le charme s'estompe dès que quelqu'un demande qui est de garde pour le circuit de refroidissement à 3 heures du matin.

Il y a une question de fierté, je l'admets. Posséder ce cluster, c'est comme posséder les moyens de prédire l'avenir. Puis arrive la facture d'électricité, et la fierté retombe comme un soufflé.

À quoi sert le bâtiment ?

Alors, qu'est-ce qu'un centre de données IA ? Un campus spécialisé à haute densité où accélérateurs, alimentation, refroidissement, infrastructure et stockage sont organisés autour des modèles d'entraînement et de déploiement – ​​et non pas un centre informatique classique avec un GPU dans un coin. Il ressemble à un entrepôt. Son fonctionnement est comparable à celui d'une centrale électrique dédiée aux calculs mathématiques.

Si vous ne devez retenir qu'une chose : les puces font la une ; ce sont la sous-station, le système de refroidissement et le réseau qui déterminent si ces puces étaient une bonne idée. Formation et analyse peuvent coexister, mais elles exigent des méthodes différentes. La plupart des organisations devraient louer. Quelques-unes devraient construire. De toute façon, le voisinage ne passera pas inaperçu.

Le nuage a toujours eu un bâtiment. De nos jours, le bâtiment a des opinions.

Exemple concret : une cellule d’entraînement à deux racks lorsque les images ne peuvent pas sortir

Scénario

Tomos est responsable de l'infrastructure chez Kestrel Precision, une entreprise manufacturière de 400 personnes située dans les West Midlands. Ils disposent déjà d'une petite salle sur site : ERP, partage de fichiers, machines virtuelles, le même environnement hétéroclite que celui décrit en introduction de cet article. Refroidissement par air. Ethernet standard. Un SAN parfaitement adapté aux disques de bureau.

L'équipe de vision industrielle doit entraîner un modèle d'inspection sur des clichés de production. Ces clichés ne peuvent pas quitter le site. Ils illustrent un processus que l'entreprise refuse de stocker sur un serveur cloud, même privé. La solution proposée par le service des achats : quatre serveurs à double accélération et une présentation intitulée « Notre centre de données IA ». Les serveurs seront installés dans deux baies existantes, faute de place, car l'espace semblait être la principale contrainte.

Non. En deux semaines, les GPU s'activent puis ralentissent discrètement. Les tâches s'exécutent au ralenti lorsqu'un point de contrôle atteint le SAN. Un nœud tombe en panne à la onzième heure et l'exécution est tout simplement… interrompue. Tomos n'a pas manqué d'acheter des puces. Il a acheté une pile de stations de travail coûteuses partageant le même code postal. Le bâtiment était encore un hall d'entreprise.

Ils n'ont besoin ni de campus, ni de nouvelle sous-station électrique, ni de rivière. Il leur faut une petite cellule fonctionnant comme un centre de données d'IA miniature : une alimentation électrique adaptée aux capacités des racks, une dissipation thermique efficace sans endommager les puces, un réseau permettant la communication entre les tâches d'entraînement, un stockage capable de créer des points de contrôle et un manuel d'exploitation pour la gestion des pannes de nœuds. Les images étant sensibles à la migration, louer un espace de colocation à quarante minutes de là n'est pas la solution. La rénovation de deux racks, en revanche, l'est.

Ce dont la cellule a besoin

• Un budget énergétique précis pour cette ligne, basé sur les PDU, et non sur les besoins en GPU. Si la capacité disponible ne suffit pas à alimenter les quatre serveurs en pleine charge d'entraînement, la discussion s'arrête là et on envisage une colocation plus dense, sans solution miracle

• Le refroidissement de l'air n'a jamais été envisagé à cette densité : des échangeurs de chaleur à l'arrière sont nécessaires si la salle le permet, ou un petit circuit de liquide si elle le permet. Sinon, les serveurs ne sont pas installés

• Il s'agit d'une infrastructure dédiée à haut débit entre les quatre nœuds, et non du réseau Ethernet du bureau. Si le fournisseur ne propose qu'un commutateur 10 Gb/s dans son catalogue, il ne s'agit pas d'un cluster

• Stockage local rapide pour les points de contrôle et les partitions d'entraînement, et non le SAN de la VM

• Un planificateur, un intervalle de points de contrôle et une procédure de redémarrage écrite. Le matériel est la vedette. Cette couche, c'est le travail

• Une enceinte d'inférence délimitée pour la chaîne de production, séparée des échanges liés à la formation, car le service requiert une latence résiduelle et une isolation, et non un fonctionnement collectif

• Autorisation d'enregistrer la consommation électrique, la fréquence des GPU, les événements de limitation de fréquence et le temps d'exécution des tâches. S'ils ne peuvent pas les inspecter, ils photographieront les GPU et ne remarqueront pas les commutateurs

Exemple d'instruction

Tomos l'exprime dans le document relatif aux installations, en langage courant :

N'appelez pas cela un campus d'IA. Aménagez une cellule d'entraînement à deux racks dans le hall existant pour quatre serveurs à double accélérateur. Les images d'usine restent sur place. Le succès est garanti : les quatre nœuds exécutent un cycle d'entraînement et d'inspection de 12 époques sans limitation thermique, créent un point de contrôle en quelques minutes (et non en dizaines de minutes) et reprennent l'entraînement à partir de ce point de contrôle lorsqu'un nœud est volontairement arrêté. Le refroidissement doit maintenir les GPU à leurs fréquences d'entraînement. Le réseau doit être une infrastructure partagée par les quatre serveurs, et non un chemin passant par le réseau principal. Le stockage doit alimenter les puces. Si des échangeurs de chaleur à l'arrière ne peuvent être installés, signalez-le et arrêtez le projet. Ne donnez pas de PUE pour deux racks dans un hall mixte. Ce chiffre serait purement spéculatif.

Il intègre ensuite cela dans le poste de formation lui-même :

Effectuez un point de contrôle toutes les 30 minutes vers le pool rapide local. Si un personnage meurt, reprenez à partir du dernier point de contrôle réussi. N'attendez pas sur le SAN. N'interrompez pas l'entraînement tant que les horloges ont chuté à cause de la chaleur. Enregistrez la progression et arrêtez-la afin que nous puissions constater le blocage.

Une bonne heure se déroule ainsi : les huit GPU fonctionnent à leurs fréquences d'entraînement, le fichier de point de contrôle est enregistré et la tâche se poursuit de manière synchronisée. Une mauvaise heure se déroule ainsi : les ventilateurs tournent à plein régime, les fréquences chutent, le point de contrôle est écrit à 2 % après dix minutes et quelqu'un au bureau annonce que « le cluster est opérationnel ». Or, « opérationnel » ne signifie pas « entraînement ».

Comment le tester

Ils rédigent le test avant la mise à niveau, ce qui est tout l'intérêt de ne pas se fier à une démonstration.

• La même recette en 12 époques, les mêmes alambics de contrôle à 120 000 exemplaires, huit coulées

• Le temps d'exécution correspond au temps réel jusqu'à la fin de la recette, y compris tout redémarrage, mesuré entre la soumission de la tâche et le dernier point de contrôle de l'époque 12

• Gestion de la chaleur : la fréquence du GPU reste à la valeur cible d'entraînement pendant toute la durée de l'exécution. Une limitation de fréquence est considérée comme un échec, même si la tâche finit par se terminer

• Analyse du stockage : temps d’écriture des points de contrôle, médian et pire, d’après le journal des tâches

• Une transmission sur le tissu : le travail ne reste pas en suspens tant qu'un rang est en bonne santé. S'ils ne peuvent pas voir cette attente, l'instrumentation n'est pas terminée

• Deux des huit parties voient leur rang réduit à un stade précis, intentionnellement, afin de tester la procédure de redémarrage

• L'inférence est un test distinct de 200 images, effectué entre la chaîne de production et la zone de service délimitée. La réussite de l'entraînement n'est pas prise en compte pour la réussite du service

• Ils enregistrent la puissance des racks provenant des PDU par échantillons de 15 minutes, ce qui évite d'avoir à inventer un mégawatt

Acceptation de l'appellation « prêt pour l'IA » pour la cellule : 8 recettes sur 8 se terminent ; 0 sur 8 présentent une limitation thermique ; les deux exécutions interrompues reprennent ; les points de contrôle restent inchangés (en minutes). S'ils ne respectent pas ces critères, ils disposent toujours d'une salle serveur équipée de cartes graphiques haut de gamme.

Résultat

Résultat illustratif, tiré d'un test fictif à huit essais, et non d'une figure publiée par Kestrel.

Hypothèses : quatre serveurs à double accélérateur dans deux racks ; un modèle d’inspection ; 120 000 images fixes ; huit exécutions d’une recette fixe de 12 époques ; le temps d’exécution inclut les redémarrages jusqu’à la fin de la recette ; la limitation correspond à une perte enregistrée dans le temps d’entraînement ; l’heure du point de contrôle correspond à l’écriture, et non à la valeur souhaitée ; la puissance du rack correspond aux échantillons PDU, et non à la puissance d’entrée du campus.

Avant la modernisation, les GPU étaient installés dans des racks à refroidissement par air ordinaires sur le réseau Ethernet du bureau et le SAN des machines virtuelles :

• Cinq des huit courses ont été terminées du premier coup. Durée médiane de ces cinq courses : 14 heures

• Sur 8 processus, 3 ont dû être relancés suite à un blocage survenu aux alentours de la 11e heure (deux suite à la défaillance d'un nœud avec un point de contrôle obsolète, et un suite à la saturation du SAN par un point de contrôle). Nouvelle tentative immédiate, sans attente nocturne : 11 heures perdues, plus 14 heures pour une seconde tentative, soit 25 heures nécessaires pour finaliser ces trois processus

• Temps moyen de préparation d'une recette (reprises comprises) : 18 heures. (Cinq recettes ont duré 14 heures, trois 25 heures. La médiane est de 14 heures, ce qui masque les reprises. C'est pourquoi la moyenne sert de référence.)

• Limitation thermique enregistrée sur 7 des 8 essais. Temps médian à horloge réduite : 3 heures sur une tentative de 14 heures

• Écriture du point de contrôle : durée médiane de 22 minutes

• Le test de qualification des tirs mortels n'était pas à leur portée. Ils n'avaient pas de procédure. Les deux morts accidentelles furent la constatation

• Charge informatique maximale sur les deux racks pendant l'entraînement : environ 18 kW. La rangée disposait de la puissance nécessaire. Elle ne disposait ni du refroidissement ni du tissu

Après les échangeurs de chaleur à l'arrière de ces deux racks, une infrastructure dédiée entre les quatre nœuds, un petit pool NVMe pour les points de contrôle, un point de contrôle toutes les 30 minutes et un manuel de redémarrage :

• 8 sur 8 réussies du premier coup. Temps médian : 9 heures

• Régulateur thermique : 0 sur 8

• Écriture du point de contrôle : médiane de 90 secondes. Pire résultat : 3 minutes

• Les deux éliminations délibérées ont repris à partir du dernier point de contrôle de 30 minutes. Temps supplémentaire pour ces deux sessions : environ 40 minutes chacune, diagnostic inclus, ce qui porte leur durée totale à près de 9 heures et 40 minutes. Moyenne sur huit sessions : 9 heures

• La charge informatique de pointe reste aux alentours de 18 kW. Mêmes puces. Comportement différent du bâtiment

Sur cet échantillon, le temps moyen de préparation d'une recette a diminué de 18 heures à 9 heures, soit 9 heures par recette, pour un total de 72 heures sur huit essais. Le taux de réussite du premier coup est passé de 5 sur 8 à 8 sur 8. Le taux d'utilisation excessive du turbo a chuté de 7 sur 8 à 0 sur 8. Ce dernier chiffre est révélateur de l'efficacité de ces investissements. Ils ne qualifieront pas cette amélioration de 50 % d'économie de production. Huit essais constituent un échantillon simple et facile à analyser.

Ces chiffres constituent une estimation indicative basée sur le test décrit, un petit échantillon, un seul modèle et une seule salle mixte. Ils ne représentent ni un PUE, ni la puissance utile d'un campus, et ne prouvent en rien que Kestrel devrait construire un site de formation sur le terrain. L'analyse des journaux a été effectuée dans les 9 heures ; cela n'a pas été dissimulé. La valeur de 18 kW correspond à une mesure arrondie de l'unité de distribution d'énergie (PDU), et non à une facture d'électricité. Le coût des 72 heures n'a pas été calculé, car le tarif d'électricité moyen de l'usine aurait rendu l'analyse de rentabilité fallacieuse.

Le contrôle du service était distinct et plus court : 200 images de lignes dans la zone délimitée, le tout sur place. Il s’agit d’une déduction, et non d’un entraînement. Mélanger les deux aurait été une erreur similaire à celle commise dans une salle hybride, mais en miniature.

Qu'est-ce qui peut mal tourner ?

• Le service des achats continue de désigner quatre serveurs comme « le centre de données IA ». Cette appellation masque l'infrastructure, et le prochain achat concernera davantage de GPU pour ce même rayon défaillant

• Les échangeurs de porte arrière sont installés et personne ne met en service le côté eau. Les ventilateurs hurlent toujours. Les horloges continuent de baisser

• L'infrastructure est constituée d'un seul commutateur sans chemin de secours. Une seule liaison défaillante et le « cluster » se réduit à nouveau à quatre postes de travail

• Les points de contrôle restent sur le SAN car le pool NVMe était en « phase deux ». La phase deux n'arrive pas avant le prochain nœud défaillant

• Ils indiquent un PUE pour deux racks dans une salle mixte. Le climat, les limites de la zone et le reste de la rangée ERP rendent ce ratio difficile à évaluer

• La formation et le service sont étroitement liés. Un afflux de clients aux points de contrôle ralentit la chaîne de production. La latence en fin de chaîne est le produit disponible, pas la densité

• Un nœud tombe en panne et quelqu'un traite l'incident comme un ticket d'indisponibilité au lieu d'un redémarrage par point de contrôle. Les équipes d'exploitation et d'IA communiquent sans s'écouter pendant tout un après-midi

• Ils auraient pu louer une cage, sauf que les images ne peuvent pas sortir. Oublier cette contrainte les entraîne dans une conversation virtuelle qu'ils devront démêler

Points pratiques à retenir

Un centre de données IA, tel que nous le concevons, n'est ni un entrepôt, ni une facture de GPU. C'est la cellule qui permet aux accélérateurs de terminer leur cycle : une alimentation électrique suffisante, une dissipation thermique efficace, une infrastructure dédiée, un point de contrôle et une personne responsable en cas de panne d'un processeur. Kestrel n'avait pas besoin d'un campus. Deux racks suffisaient pour mettre fin aux manœuvres dilatoires. La plupart des équipes devraient adopter cette approche. Quelques-unes, disposant de données confidentielles et d'une infrastructure capable de supporter la chaleur, devraient construire leur propre cellule et refuser les solutions de facilité.

FAQ

Qu'est-ce qu'un centre de données IA ?

Un site de calcul haute densité où l'alimentation, le refroidissement, le réseau et le stockage sont optimisés pour l'entraînement parallèle et le déploiement de modèles, et non pour des rangées ordonnées de serveurs classiques. Il est conçu pour permettre à un grand nombre d'accélérateurs d'entraîner et de déployer des modèles sans surchauffe, sans saturation du réseau ni attente de disque. Un hall d'entreprise classique est un environnement hétérogène. Un hall dédié à l'IA est une monoculture dont l'unité de valeur est l'accélérateur, comme les GPU ou les puces de type TPU. Il ressemble à un entrepôt et fonctionne comme une centrale électrique dédiée aux calculs.

En quoi un centre de données dédié à l'IA diffère-t-il d'un centre de données classique ?

Les centres de données traditionnels sont optimisés pour des charges de travail mixtes et une disponibilité maximale pour de nombreux petits services. Les sites dédiés à l'IA inversent ces proportions : la densité augmente, le réseau devient une infrastructure indispensable au bon déroulement des tâches d'entraînement, et le stockage doit assurer la continuité des points de contrôle, sous peine de voir les accélérateurs inactifs. Les opérations d'entreprise raisonnent en termes de tickets et de fenêtres de maintenance. Les opérations d'IA, quant à elles, raisonnent en termes de files d'attente et de frustration lorsqu'un nœud tombe en panne en fin de cycle. On pourrait qualifier les deux de centres de données. L'appellation masque simplement l'infrastructure.

Pourquoi les centres de données d'IA consomment-ils autant d'énergie ?

Le matériel le plus remarquable n'est pas un processeur sophistiqué, mais plutôt le plateau d'accélération : des GPU ou autres puces d'IA, intégrés dans des serveurs, puis des baies, puis des rangées partageant une infrastructure à haut débit. La densité par baie est la clé : moins de baies, chacune étant un véritable concentré de puissance. La charge informatique atteint des mégawatts dès qu'une salle est pleine, mais il serait inutile d'avancer une valeur typique. Le facteur limitant est souvent la sous-station électrique, et non le nombre de GPU souhaité.

Comment les centres de données d'IA sont-ils refroidis ?

Les racks haute densité dissipent la chaleur d'une manière que l'air n'a jamais vraiment été sollicité. On peut optimiser le refroidissement par air grâce à des échangeurs de chaleur situés à l'arrière, des allées plus chaudes et un confinement efficace. Puis, le refroidissement liquide fait son apparition : refroidissement direct sur la puce, circuits de refroidissement et, dans certaines conceptions, refroidissement par immersion. Un accélérateur dont les performances sont bridées est un accélérateur que vous avez déjà payé et que vous ne pouvez pas exploiter pleinement. Le PUE reste important car chaque watt consommé par les ventilateurs et les pompes est un watt qui ne sera pas alloué au GPU. L'eau joue également un rôle : certaines plantes absorbent l'eau par petites gorgées, d'autres par grandes quantités.

Pourquoi le réseau est-il aussi important que les GPU ?

L'entraînement est un dialogue : des milliers d'accélérateurs échangent des gradients, des paramètres et des fragments d'un modèle en parfaite synchronisation. Si le réseau est perturbé, toute la tâche est bloquée sur le maillon le plus lent. C'est pourquoi les centres de recherche en IA privilégient les réseaux à haut débit, à faible latence, les architectures de type InfiniBand ou Ethernet, et les topologies qui ne sont pas paralysées par une panne de liaison. L'inférence, quant à elle, se soucie de la latence de queue, de la multiplication des petites requêtes et de l'isolation. Dans ce domaine, l'infrastructure est primordiale.

À quoi sert un centre de données d'IA : à l'entraînement ou à l'inférence ?

L'entraînement est une opération complexe : assembler un cluster, l'alimenter en données, effectuer des sauvegardes régulières et le laisser tourner pendant des heures, voire des semaines. L'inférence, quant à elle, est une vitrine : les modèles, déjà entraînés, répondent immédiatement, avec une latence critique. Les campus d'entraînement privilégient la puissance, l'espace et la densité. Les sites d'inférence, eux, privilégient la latence et la disponibilité. Les halls hybrides existent car les ressources sont limitées ; on trouve parfois un seul hall avec deux circuits de refroidissement. Un accélérateur légèrement plus ancien, situé à proximité du client, peut s'avérer plus performant qu'un accélérateur de pointe situé à l'autre bout du monde.

Pourquoi le stockage est-il important dans un centre de données d'IA ?

Les données d'entraînement doivent arriver suffisamment vite pour éviter que les GPU ne soient surchargés. Les points de contrôle doivent être enregistrés pour qu'un plantage ne compromette pas une semaine de données. Les poids du modèle doivent être chargés avant la mise en service d'une réplique. Le débit de stockage, et non seulement la capacité, constitue le véritable goulot d'étranglement. On peut dépenser une fortune en accélérateurs et les sous-dimensionner avec une configuration optimisée pour les machines virtuelles.

Que se passe-t-il lorsqu'un nœud tombe en panne en cours d'exécution ?

Une panne d'accélérateur dans un processus d'entraînement étroitement couplé peut bloquer tout le système. L'entraînement nécessite des points de contrôle, pas de l'optimisme. L'inférence décharge le nœud défaillant, maintient une réplique opérationnelle et reste en fonctionnement. Les fenêtres de modification peuvent toujours entrer en conflit avec les exécutions d'entraînement qui ne tiennent pas compte de votre calendrier. La redondance reste importante pour l'alimentation, le refroidissement, les chemins d'accès et le stockage, mais le mode de défaillance est moins propre que l'ancien système de disponibilité de 99,7 %.

Quel est l'impact d'un centre de données d'IA sur le réseau électrique, l'eau et le voisinage ?

Le raccordement au réseau est souvent le véritable critère de choix d'un site. Le terrain est plus facile à trouver qu'un poste de transformation ou un réseau électrique ayant d'autres clients. L'eau pour le refroidissement, si vous en utilisez, devient une source de problèmes de voisinage dès que les pluies sont fortes, sans parler du bruit, de l'encombrement visuel et de la chaleur dégagée par la clôture mitoyenne. La formation peut être facilitée par des marchés de l'électricité moins chers et des climats plus frais. L'inférence préfère être à proximité des utilisateurs. Il n'existe pas de site idéal. Un compromis est toujours possible.

Ai-je besoin de posséder un centre de données d'IA, ou devrais-je en louer un ?

La plupart des gens n'ont pas besoin de posséder une telle infrastructure. Les hyperscalers construisent car leur produit, c'est leur parc de serveurs. Les laboratoires construisent lorsque le temps d'attente est un goulot d'étranglement ou que les données ne peuvent pas quitter le système. Une banque, un hôpital, un gouvernement ou un fabricant disposant de données confidentielles peut justifier l'utilisation d'une infrastructure sur site ou d'un espace de colocation privé. Tous les autres devraient louer : colocation adaptée à l'IA, réservation dans le cloud ou cluster géré. Vous bénéficiez ainsi des accélérateurs sans devenir exploitant d'une centrale électrique.

Références

1. AIE - www.iea.org

2. LBNL - datacenters.lbl.gov

3. Le Réseau Vert - www.thegreengrid.org

4. LBNL - datacenters.lbl.gov

5. LBNL - datacenters.lbl.gov

6. Uptime Institute - journal.uptimeinstitute.com

7. NVIDIA - developer.nvidia.com

8. NVIDIA - docs.nvidia.com

9. NVIDIA - docs.nvidia.com

10. NVIDIA - docs.nvidia.com

11. Google Cloud - docs.cloud.google.com

Découvrez les dernières fonctionnalités d'IA sur la boutique officielle des assistants IA

À propos de nous