La configuration des centres de données GPU s'avère être un casse-tête
La vue d'ensemble : Il s’avère que si l’on change complètement la façon dont les centres de données ont été construits au cours des 10 dernières années, on ne peut s’empêcher de rencontrer quelques difficultés de croissance. Si tous les gros titres parlent de l’essor de l’IA, la réalité sur le terrain est riche en maux de tête.
Lorsque nous parlons aux intégrateurs de systèmes et à d’autres personnes qui développent de grands systèmes de calcul, nous entendons un flux constant de plaintes concernant les difficultés à rendre opérationnels de grands clusters de GPU.
Le problème principal est le refroidissement liquide. Les systèmes GPU chauffent et les racks consomment des dizaines de milliers de watts. Le refroidissement par air traditionnel est insuffisant, ce qui a conduit à l'adoption généralisée des systèmes de refroidissement liquide. Cette évolution a fait grimper le cours des actions d'entreprises comme Vertiv, qui déploient ces systèmes.
Note de l'éditeur :
Jonathan Goldberg, auteur invité, est le fondateur de D2D Advisory, un cabinet de conseil multifonctionnel. Jonathan a développé des stratégies de croissance et des alliances pour des entreprises des secteurs de la téléphonie mobile, des réseaux, des jeux et des logiciels.
Cependant, le refroidissement liquide est encore relativement nouveau pour les centres de données et peu de personnes sont familiarisées avec son installation. Par conséquent, le refroidissement liquide est devenu la principale cause de pannes dans les centres de données. Il existe de nombreuses raisons à cela, mais elles se résument toutes essentiellement au fait que l'eau et l'électronique ne font pas bon ménage. L'industrie finira par régler ce problème, mais c'est un parfait exemple des difficultés de croissance que connaissent les centres de données.
La configuration des GPU présente également de nombreux défis. Cela n'est pas surprenant : la plupart des professionnels des centres de données ont une grande expérience de la configuration des CPU, mais pour beaucoup d'entre eux, les GPU sont un domaine inconnu.
De plus, Nvidia a tendance à vendre des conceptions complètes, ce qui introduit tout un ensemble de complications. Par exemple, les systèmes de firmware et de BIOS de Nvidia ne sont pas entièrement nouveaux, mais ils sont simplement différents et suffisamment sous-développés pour entraîner des retards et un nombre inhabituellement élevé de bugs. Ajoutez à cela la couche réseau de Nvidia, et il est facile de comprendre à quel point le processus est devenu frustrant. Il y a tout simplement beaucoup de nouvelles technologies que les professionnels doivent maîtriser dans un délai très court.
Dans l’ensemble, il ne s’agit là que de quelques obstacles. Aucun de ces problèmes n’est suffisamment grave pour freiner le développement de l’IA, mais à court terme, ils vont probablement devenir plus prononcés et plus visibles. Nous nous attendons à ce que les hyperscalers retardent ou ralentissent le déploiement de leurs GPU pour relever ces défis. Pour être plus précis, nous allons probablement entendre parler davantage de ces retards, car ils ont déjà commencé.
Le récent pari de 5 milliards de dollars d'AMD sur les centres de données
Récemment, on nous a demandé quelle était la logique derrière l'acquisition de ZT Systems par AMD. Étant donné que cela et la complexité croissante de l'installation de clusters d'IA sont étroitement liés, nous pouvons utiliser ZT comme une lentille pour visualiser les problèmes plus larges de l'industrie.
Supposons qu'Acme Semiconductor souhaite entrer sur le marché des centres de données. L'entreprise dépense quelques centaines de millions de dollars pour concevoir un processeur. Elle essaie ensuite de le vendre à son client hyperscaler, mais ce dernier ne veut pas seulement une puce, il veut un système fonctionnel pour tester son logiciel.
Acme se rend donc chez un ODM (Original Design Manufacturer) et paie quelques centaines de milliers de dollars pour concevoir un serveur fonctionnel, avec stockage, alimentation, refroidissement, réseau et tout le reste. Acme construit quelques dizaines de ces serveurs et les distribue à ses meilleurs prospects. À ce stade, Acme a perdu environ 1 million de dollars et ils constatent que leur puce ne représente que 20 % du coût du système.
Les hyperscalers passent ensuite quelques mois à tester le système. L'un d'eux apprécie suffisamment les performances d'Acme pour le soumettre à un test plus rigoureux, mais il ne veut pas d'un serveur standard ; il en veut un conçu spécifiquement pour les opérations de son centre de données. Cela signifie une nouvelle conception de serveur avec une configuration complètement différente du stockage, du réseau, du refroidissement, etc. L'hyperscaler souhaite également qu'Acme construise ces systèmes de test avec son ODM préféré.
Souhaitant conclure l’affaire, Acme prend en charge la facture de cette nouvelle conception, mais au moins l’hyperscaler paie les systèmes de test – Acme a enfin un revenu, peut-être 100 000 $. Alors que le premier hyperscaler effectue son évaluation sur plusieurs mois, un deuxième client exprime son intérêt. Bien entendu, il souhaite disposer de sa propre configuration de serveur avec son propre ODM préféré. Acme, ayant besoin de ce marché, prend également en charge le coût de cette conception.
Acme contacte tous les fabricants d'équipement d'origine pour voir si l'un d'entre eux est prêt à concevoir un système de catalogue pour rationaliser le processus. Les fabricants d'équipement d'origine sont tous très amicaux et intéressés par ce que fait Acme. Bon travail, mais ils ne s'engageront à concevoir qu'une fois qu'Acme aura obtenu plus de contrats.
Finalement, un client souhaite acheter en volume, ce qui représente un gros avantage pour Acme. Cette fois, comme il s'agit d'un véritable volume, l'ODM accepte de réaliser la conception. Cependant, le nouveau serveur utilisera les puces de réseau et de sécurité conçues en interne par l'hyperscaler, qui ont été gardées secrètes. Acme ne les a jamais vues et sait peu de choses sur le nouveau serveur, qui a été conçu directement entre le client et l'ODM. L'ODM construit un ensemble de serveurs, puis les connecte à l'intérieur du centre de données de l'hyperscaler, allume l'interrupteur, et les choses commencent immédiatement à se détériorer.
C'est normal : les bugs sont partout. Mais très vite, tout le monde commence à blâmer Acme pour les problèmes, ignorant le fait qu'Acme a été largement exclu du processus de conception. Leur puce est le composant le moins connu de l'ODM et du client. Acme a travaillé avec le client pour éliminer les bugs pendant le cycle d'évaluation, mais c'est différent.
Une grande partie du système est nouvelle et les enjeux sont bien plus élevés, donc tout le monde travaille sous pression. Acme envoie ses ingénieurs de terrain dans le centre de données ultra-éloigné pour se familiariser avec le système. Les trois équipes travaillent sur les bugs, en trouvant d'autres au fur et à mesure. Finalement, il s'avère que le processeur d'Acme entre dans un mode d'erreur obscur lors de l'interaction avec la puce de sécurité de l'hyperscaler, que les composants réseau sont fragiles et fonctionnent bien en dessous des spécifications, et bien sûr, que chaque puce exécute un firmware différent, qui est incompatible avec les autres.
Pour couronner le tout, le refroidissement liquide, un élément avec lequel personne dans l'équipe de débogage n'a travaillé auparavant, est probablement à l'origine de 50 % des problèmes. Le déploiement traîne en longueur pendant que les équipes résolvent les problèmes. À un moment donné, un élément important doit être entièrement remplacé, ce qui ajoute des retards et des coûts supplémentaires. Mais après des mois de travail, le système entre enfin en production. Puis le deuxième client d'Acme décide de procéder à une évaluation plus approfondie, et tout le processus recommence.
Et si cela ne semble pas assez douloureux, nous n’avons même pas mentionné les avocats.
Pour lancer le projet, Acme a dû passer neuf mois à négocier des conditions difficiles avec l'hyperscaler, alors qu'il était en position de faiblesse. Lorsqu'il s'est agi de concevoir le serveur personnalisé, les trois entreprises (Acme, l'ODM et le client) ont probablement passé six semaines à négocier l'accord de confidentialité.
C'est ainsi que les serveurs sont construits depuis des années. Puis Nvidia est entré sur le marché, en proposant ses propres conceptions de serveurs. En plus de cela, ils ont proposé des conceptions pour des racks entiers. Nvidia conçoit des systèmes depuis 25 ans, depuis son travail sur les cartes graphiques. Son équipe construit également ses propres centres de données, elle dispose donc d'une équipe interne expérimentée dans la gestion de tous ces problèmes.
Pour concurrencer Nvidia, AMD peut soit passer cinq ans à copier l'équipe de Nvidia, soit acheter ZT. En théorie, ZT peut aider AMD à éliminer presque toutes les frictions décrites ci-dessus. Il est trop tôt pour dire si cela fonctionnera bien dans la pratique, mais AMD est devenu assez bon en matière d'intégration de fusions. Et honnêtement, nous serions heureux de payer 5 milliards de dollars pour éviter de négocier à nouveau un accord de confidentialité à trois et un accord de service principal.
