Dans un cloud de plate-forme idéal, vous ne sauriez pas ou ne vous soucieriez pas du matériel sous-jacent et de la façon dont il était composé pour exécuter vos applications HPC – et maintenant IA. Le matériel sous-jacent dans un cloud aurait un mélange de différents types de calcul et de stockage, un réseau tout-à-tout l’arrachant ensemble, et tout ce dont vous avez besoin pourrait être composé à la volée.
C’est précisément le genre de cloud de calcul que Google voulait construire en avril 2008 avec App Engine et, en fin de compte, que très peu d’organisations voulaient acheter. Les entreprises se souciaient – et se soucient toujours – de l’infrastructure sous-jacente, mais en même temps, Google croit toujours en son cœur dans le cloud de la plate-forme. Et c’est l’une des raisons pour lesquelles ses moteurs de calcul Tensor Processing Unit, ou TPU, ne sont disponibles que sur Google Cloud. (Bien que vous puissiez soutenir que les unités mathématiques de la matrice GroqChip disponibles via Groq sont autant une copie architecturale du TPU que Kubernetes l’est pour le conteneur Borg et le contrôleur de cluster de Google, Hadoop est pour l’analyse et le stockage de données MapReduce de Google, ou CockroachDB est pour la base de données SQL Spanner de Google.)
Lorsque vous placez un cluster de 2 048 cœurs TPU sur un réseau maillé toroïdal étroitement couplé et que vous disposez d’une mémoire HBM2 combinée de 32 To et de plus de 100 pétaflops de mathématiques à virgule flottante de précision unique (avec un support de précision mixte pour faire de l’inférence) sur le cloud pour que les gens puissent exécuter des applications, il est naturel que les personnes exécutant des applications HPC modifient leurs codes pour utiliser le TPU.
Au cours des dernières années, des expériences ont été menées, et la dernière en date a été réalisée par Google lui-même montrant comment accélérer la dynamique des fluides associée à la prévision des inondations de rivières. Il y a beaucoup d’autres exemples, dont nous discuterons dans un instant, et il sera intéressant de voir si le TPU et ses clones trouvent un foyer dans le HPC ou s’il ne s’agit que d’un tas de projets scientifiques d’investigation dignes.
Nous soulignons qu’en 2006, c’est précisément ainsi que les algorithmes mathématiques puis des portions de codes HPC ont été déchargés des CPU vers les GPU, déclenchant toute une révolution dont l’explosion de l’IA plusieurs années plus tard a bénéficié. Maintenant, c’est l’IA qui pilote des technologies comme le TPU et c’est le HPC qui peut en bénéficier.
L’article le plus récent de Google, qui vous pouvez lire ici, les chercheurs ont porté les mathématiques sous-jacentes aux modèles hydrodynamiques des processeurs aux TPU et ont mesuré les performances du cœur TPU par rapport à un cœur de processeur X86 relativement moderne. (Les comparaisons avec les GPU n’ont pas été données, et évidemment grâce à Google Cloud, qui vend de la capacité GPU brute, ainsi que des fermes gpu internes massives que Google utilise pour diverses parties de sa pile de formation à l’apprentissage automatique. Pendant que le moteur matriciel TPUv4 est en développement et en préproduction depuis un certain temps déjà, pour autant que nous sachions, il n’a pas été déployé sur Google Cloud et les moteurs matriciels TPUv3, que nous avons profilé ici, sont les seuls sur lesquels les gens peuvent donner des coups de pied dans les pneus.
Voici la chose intéressante qui est ressortie lorsque nous avons lu cet article: les codes HPC pour exécuter la simulation d’inondation n’ont pas été portés à partir d’une pile parallèle exécutant, par exemple, le code Fortran et utilisant OpenMP et MPI. Google est allé directement aux équations aux dérivées partielles en eau peu profonde de Saint-Venant utilisées pour simuler l’écoulement de liquide sur la topographie et les a implémentées en Python sur son framework d’apprentissage automatique TensorFlow, en utilisant son compilateur d’algèbre linéaire accélérée (XLA). Il est important de noter que Google a créé un modèle entièrement 2D de l’inondation des rivières plutôt qu’un modèle hybride 1D-2D qui est généralement effectué sur des systèmes à processeur uniquement qui sont faibles en calcul par rapport à un groupe de TPU. Voici à quoi ressemble le flux de simulation TPU pour cette simulation d’inondation :
Google a ouvert le code derrière cette simulation pour aider les chercheurs HPC à voir comment fonctionne ce modèle d’inondation et peut-être à faire leur propre travail dans d’autres parties du secteur HPC. Vous pouvez téléchargez ce code ici. Il y a des choses délicates que vous devez faire pour créer les conditions initiales aux bords de toute simulation, et cette application créée par Google gère cela. Et les opérations collectives dans le cadre TensorFlow et rendues possibles par le réseau TPUv3 semblent faire du bon travail, basées sur l’inspection visuelle de l’imagerie et la comparaison avec les données réelles obtenues à partir d’une inondation réelle qui a été simulée, de déterminer la hauteur de l’eau et son flux à travers la topologie simulée.
Comme c’est le cas avec toute simulation d’écoulement de fluide, la résolution est importante, mais elle a un coût de calcul élevé. Les modèles basse résolution vous donnent une sensation, mais les modèles haute résolution vous donnent quelque chose qui a l’air et ressemble plus à des données. Google exécute donc ses simulations sur des cœurs de processeur X86 et des cœurs TPU à des résolutions de grille de 8 mètres, 4 mètres et 2 mètres, puis pousse un quart de pod de TPU pour fournir une résolution de grille de 1 mètre. La simulation a été réalisée sur une section de la rivière Arkansas qui a été inondée en mai 2019. Google a testé la mise à l’échelle de la résolution par rapport à différentes tranches de taille du pod TPU, allant d’un seul cœur TPU jusqu’à un quart de pod avec 512 cœurs TPU. Les ensembles de données allaient de 15,5 millions de points de grille à la résolution de 8 mètres à 1 milliard de points de grille à la résolution de 1 mètre.
Voici comment la simulation d’inondation fluviale s’est déroulée sur différentes tailles de calcul TPU et à différentes résolutions:
Pour une raison quelconque, Google n’a pas exécuté cette simulation d’inondation sur un pod TPU entier. Comme vous pouvez le voir dans le tableau ci-dessus, il y a eu des rendements décroissants passant de 128 cœurs TPU à 512 cœurs TPU à la résolution de 8 mètres, mais aux résolutions inférieures, la mise à l’échelle se portait toujours assez bien à mesure que plus de calcul était ajouté. Mais la mise à l’échelle diminuait assez rapidement, et peut-être que Google ne voulait pas en parler. OK, nous pensons que Google je ne voulais certainement pas en parler. Mais nous nous rendons compte qu’il est difficile de faire des simulations à l’échelle de tout le fer dans n’importe quel superordinateur et qu’à un deuxième passage, Google serait sans aucun doute en mesure de faire mieux à plus grande échelle. Tout comme les vrais magasins HPC le font avec leurs simulations.
Alors, dans quelle mesure le TPU a-t-il réussi à prédire l’inondation? Assez bon pour dire aux intervenants d’urgence où allaient se trouver les points chauds, nous pensons. Voici l’inondation aérienne sur une section de la rivière Arkansas à une résolution de 1 mètre montrant l’étendue de l’inondation réelle:
Et voici où la simulation a prédit où l’inondation serait basée sur un débit de rivière similaire à celui qui s’est produit pendant l’inondation:
L’autre élément intéressant de la recherche effectuée par Google a été d’exécuter la même simulation sur les processeurs ainsi que sur ses TPU, en utilisant la même pile de code et en remplaçant simplement le compilateur XLA utilisé pour le TPU par la bibliothèque de modèles Eigen C++ pour l’algèbre linéaire pour les processeurs fonctionnant sous Linux.
Voici comment le processeur s’est empilé par rapport au TPU au niveau par cœur :
Le processeur en question ici est un Xeon SP-8273CL Platinum « Cascade Lake », qui a 28 cœurs fonctionnant à 2,2 GHz et évalué à environ 2 téraflops à fp32 simple précision. (Les indices de performance en virgule flottante de précision unique pour les formats IEEE FP32 que les TPU n’ont jamais été publiés.) La différence de performance par cœur est bien supérieure à 500X, ce qui va de soi compte tenu du nombre et de la taille des unités mathématiques de la matrice MMX dans les cœurs TPU. Chaque cœur TPUv3 a deux unités mathématiques matricielles 128×128, et chaque puce TPUv3 a deux cœurs; il y a quatre puces TPUv3 par carte mère et 256 cartes mères par pod TPUv3. (Soit dit en passant, le TPUv2 avait deux fois moins de mémoire HBM par cœur, à 8 Go, et deux fois moins d’unités MMX par cœur, à un chacun, par rapport au TPUv3. Ainsi, l’accélération du fer TPUv2 qui est toujours disponible sur le Google Cloud serait environ deux fois moins élevée par cœur par rapport au fer X86.
Google n’a pas montré comment les serveurs X86 pouvaient être mis en cluster et mis à l’échelle. Et il n’a certainement pas parlé du coût d’exécution de la simulation sur un cluster CPU par rapport à un cluster TPU dans un certain temps, comme vous en avez besoin pour les simulations de gestion des conditions météorologiques et des urgences. Mais, compte tenu de ces données et de beaucoup de suppositions, les magasins HPC peuvent commencer à réfléchir à ce que cela pourrait être. (Nous pourrions faire ce travail nous-mêmes lorsque le flux de nouvelles ralentira en juillet, juste pour le plaisir, en découvrant comment un cluster plus moderne utilisant des processeurs AMD « Milan » Epyc 7003 pourrait se comparer à la capacité louée sur les pods TPUv3 et TPUv4. Hmmmm.)
Comme nous l’avons souligné ci-dessus, le nombre de codes HPC qui ont été portés sur le TPU pour les accélérer est en augmentation, et Google ne fait pas tout le travail parce que la communauté HPC est curieuse. Voici les articles que nous pourrions trouver sans trop nuire au moteur de recherche:
- Algèbre linéaire distribuée à grande échelle avec unités de traitement tensorielle, Google, décembre 2021
- Simulations de dynamique moléculaire sur les plateformes de cloud computing et d’apprentissage automatique, Université de l’Indiana, novembre 2021
- Transformée de Fourier rapide non uniforme sur les TPU, Google, Mass General, Université Harvard, avril 2021
- Transformée de Fourier discrète à grande échelle sur les TPU, Google, décembre 2020
- Accélérer la reconstruction IRM sur les TPU, Google, juin 2020
- Unités de traitement tensorielles pour Le Monte Carlo Financier, Google, janvier 2020
- Simulation Monte Carlo haute performance du modèle Ising sur des clusters TPU, Google, Nonfévrier 2019
Ne serait-il pas drôle si, après avoir parcouru tout cela avec des processeurs et des accélérateurs, nous nous retrouvions avec une architecture qui ressemble à un processeur 80286 avec un ensemble massivement parallèle de coprocesseurs 80287 pour faire ses devoirs de mathématiques? IBM a fait la même chose avec les mainframes System/3090 à six voies et en frappant une unité mathématique vectorielle sur chaque moteur en 1989, alors que nous commencions tout juste dans ce racket de centre de données et que Cray gagnait pour la première fois des clients commerciaux dans l’entreprise. Tout dépendra du logiciel qui sera développé, bien sûr.
Et une dernière réflexion : tout code créé pour accélérer le HPC sur les TPU serait probablement relativement facile à déplacer vers des moteurs mathématiques matriciels créés par Cerebras, SambaNova et GraphCore ainsi que Groq.
