Google achète peut-être des cieux ne sait combien de GPU pour exécuter des charges de travail HPC et AI sur son cloud public éponyme, et il a peut-être récemment parlé de son engagement envers l’idée de pousser l’industrie à innover au niveau SoC et ne pas concevoir ses propres moteurs de calcul, mais la société construit toujours ses propres unités de traitement Tensor, ou TPU, pour prendre en charge son cadre d’apprentissage automatique TensorFlow et les applications qu’il gère au sein de Google et en tant que service pour les clients Google Cloud.

Si vous vous attendiez à obtenir une grande révélation de l’architecture TPUv4 du géant des moteurs de recherche et pionnier de l’apprentissage automatique lors de sa conférence Google I / O 2021 cette semaine, vous étiez sans aucun doute, comme nous, profondément déçu. Dans son discours liminaire de deux heures, que vous pouvez voir ici, Sundar Pichai, PDG de Google, également PDG de la société mère de Google, Alphabet, a très brièvement parlé du prochain ASIC personnalisé TPUv4 conçu par Google et vraisemblablement construit par Taiwan Semiconductor Manufacturing Corp comme tous les autres moteurs de calcul de pointe sur Terre. . Comme son nom l’indique, la puce TPUv4 est la quatrième génération de bêtes de traitement Bfloat d’apprentissage automatique de Google, qu’elle associe aux systèmes hôtes et au réseau pour créer ce qui équivaut à un supercalculateur personnalisé.

«C’est le système le plus rapide que nous ayons jamais déployé chez Google – une étape historique pour nous», a expliqué Pichai dans son discours. «Auparavant, pour obtenir un exaflops, vous deviez construire un supercalculateur personnalisé. Mais nous en avons déjà beaucoup déployé aujourd’hui. Nous aurons bientôt des dizaines de pods TPUv4 dans nos centres de données, dont beaucoup fonctionneront à 90% d’énergie sans carbone ou presque. Et nos pods TPUv4 seront disponibles pour nos clients cloud plus tard cette année. Il est extrêmement excitant de voir ce rythme d’innovation. »

Tout d’abord, peu importe ce que Pichai dit, ce que Google construit lorsqu’il installe les pods TPU dans ses centres de données pour exécuter ses propres charges de travail d’IA et aussi pour permettre à d’autres d’exécuter les leurs à l’aide de Google Cloud et de sa pile de plate-forme AI comme un service est absolument un supercalculateur personnalisé. Il est la définition même d’un supercalculateur personnalisé, En réalité. Nous avons certainement nos journées «besoin de plus de café» ici à La prochaine plateforme, comme en témoignent les fautes de frappe, les phrases brisées, etc., mais nous fonctionnons à grande vitesse tous les jours et nous n’utilisons pas Google avec une équipe de rédacteurs de discours et ne faisons pas un événement préenregistré. Prends encore du café, Sundar. Nous vous enverrons une carte Starbucks. Bonne gorgée et parlez-nous de la nouvelle puce TPUv4. (En fait, Urs Hölzle, vice-président senior de l’infrastructure technique chez Google, nous a promis un briefing sur TPUv4, et nous le lui rappelons officiellement ici, en ce moment.)

Pichai n’a pas beaucoup parlé de l’architecture TPUv4, mais nous pouvons déduire certaines choses du peu qu’il a dit – et nous n’aurons pas non plus besoin d’un ASIC TPU pour faire l’inférence.

Ce graphique nous a littéralement fait craquer avec sa rareté – et son inexactitude étrange à moins que vous ne puissiez déduire ce que Pichai a dû signifier, ce que nous pensons avoir. Il existe une simplification excessive au point de ridicule, et étant donné que c’est censé être le nerdfest Google I / O 2021, nous sommes, comme nous l’avons dit, un peu déçus. Dans tous les cas, le graphique montre en fait le TPUv3 avec cinq unités de performance et le TPUv4 avec dix unités de performance, ce qui équivaut précisément à 2X les performances. Mais l’étiquette dit «Plus de 2x plus vite», ce qui déroutera certains.

S’il s’agissait d’une présentation technique réelle, ce que Pichai aurait pu dire, c’est que le TPUv4 a deux fois plus d’unités de calcul fonctionnant à la même vitesse d’horloge grâce à un processus de réduction qui permet à chaque socket TPU d’avoir deux fois plus d’éléments de calcul – et vraisemblablement à au moins deux fois plus de mémoire HBM2 et au moins deux fois plus de bande passante agrégée pour l’équilibrer. Mais Pichai n’a rien dit de cela.

Mais nous le sommes, et c’est ce que nous pensons que Google a fait, en substance. Et franchement, ce n’est pas tellement d’étirement, technologiquement parlant, si c’est tout ce que Google a fait pour passer du TPUv3 au TPUv4. J’espère qu’il y en a plus. C’est un processeur scalaire / vectoriel avec un tas de moteurs mathématiques matriciels 128 × 128 Bfloat16 attachés et de la mémoire HBM2.

Un examen s’impose peut-être, puis nous aborderons ce que pourrait signifier la chose «Plus de 2x plus rapide».

Voici un tableau qui résume les unités TPUv2 et TPUv3 précédentes et les cartes serveur qui les utilisaient:

Le cœur TPU de base est une unité scalaire / vectorielle – ce que nous appelons un processeur ces jours-ci étant donné que les processeurs Intel, AMD, Power et Arm ont tous une combinaison de ces éléments – qui a une unité mathématique de matrice Bfloat, que Google appelle un MXU . Il y a deux cœurs sur une puce TPU. Ce MXU peut traiter 16 384 opérations en virgule flottante au format Bfloat par horloge, et avec le noyau TPUv2 pourrait conduire 23 téraflops d’opérations Bfloat, ce qui correspond à 46 téraflops par puce. Nous n’avons jamais connu la vitesse d’horloge, mais nous supposons qu’elle se situe quelque part au nord de 1 GHz et au sud de 2 GHz, tout comme un GPU. Notre estimation pour le TPUv2 est de 1,37 GHz, en fait, et pour le TPUv3, elle est d’environ 1,84 GHz. Nous plongé dans les architectures TPUv2 et TPUv3 ici, si vous voulez vraiment y entrer ainsi que les subtilités du format Bfloat, qui est très intelligent, lisez ça. Les estimations des watts du TPUv3 étaient très faibles. Nous pensons que TPUv2 a été gravé dans des processus de 20 nanomètres et que TPUv3 a été gravé dans des processus de 16 nanomètres ou peut-être 12 nanomètres, et nous supposons que Google a fait une réduction à 7 nanomètres avec TPUv4 tout en restant dans l’enveloppe thermique de 450 watts par prise que son Pods TPUv3 requis. Nous ne pensons pas qu’il y ait beaucoup de place thermique pour augmenter la vitesse d’horloge avec TPUv4. Pardon.

Quoi qu’il en soit, avec TPUv3, la réduction du processus a permis à Google de placer deux MXU contre l’unité scalaire / vectorielle, doublant les performances brutes par cœur à fréquence constante; nous soupçonnons que Google a également pu réduire un peu les vitesses d’horloge. Le TPUv3 avait deux cœurs par puce et doublait la mémoire jusqu’à 16 Go de HBM2 par cœur contre 8 Go par cœur pour la puce TPUv2.

Donc, en utilisant notre règle dandy pratique et un multiplicateur 2X, nous pensons que Google est passé à 7 nanomètres et obtient quatre cœurs sur un dé. Il peut le faire en créant une puce TPUv4 monolithique, ou il peut expérimenter avec des puces et créer une interconnexion qui relie deux ou quatre puces les uns aux autres dans une prise. Cela dépend vraiment de la façon dont les charges de travail sensibles à la latence se trouvent dans un socket. Parce que la mémoire HBM2 est suspendue aux MXU, tant que les MXU ont tous leur propre contrôleur HBM2, nous ne pensons vraiment pas que cela compte beaucoup. Donc, si nous faisions cela et que nous voulions augmenter le rendement de la matrice TPUv4 et réduire également le coût des puces (mais en rembourserons une partie sur l’emballage des puces), nous prendrions quatre cœurs TPUv3 et les décomposerions en puces pour les fabriquer. une prise TPUv4.

Nous pousserions également les thermiques aussi haut que possible. Le TPUv2 pesait 280 watts et le TPUv3 montait jusqu’à 450 watts pour générer 123 téraflops de performances. (Ce qui implique une augmentation de 33,7% de la vitesse d’horloge passant de TPUv2 à TPUv3, mais en payant pour cela avec une augmentation de 60,7% de la puissance de 280 watts à 450 watts.)

Nous pensons que la mémoire HBM du périphérique TPUv4 a doublé, mais la mémoire HBM2 par cœur pourrait être la même à 16 Go par cœur. Ce serait 64 Go par appareil, et c’est beaucoup. (Oui, nous savons que Nvidia peut faire 80 Go par appareil.) Il y a une chance extérieure que Google puisse pousser cela jusqu’à 128 Go par appareil, ou 32 Go par cœur. Cela dépend vraiment des thermiques et du coût. Mais ce que nous savons avec certitude, c’est que Google et d’autres chercheurs en IA souhaitent vraiment que plus de mémoire HBM2 soit disponible sur ces appareils. Nous pensons qu’il est très peu probable que la vitesse d’horloge de l’appareil TPUv4 augmente beaucoup. Qui veut une pièce de 600 watts?

Maintenant, parlons de ce commentaire «Plus de 2x plus vite» ci-dessus. Juillet dernier, Google a publié quelques premières données comparer les performances TPUv4 sur la suite MLPerf de benchmarks AI aux appareils TPUv3. Regarde:

Sur divers composants des benchmarks de formation MLPerf Machine Learning, l’augmentation des performances passant des machines TPUv3 avec 64 puces (128 cœurs) aux machines TPUv4 également avec 64 puces (et 128 cœurs) variait de 2,2X à 3,7X, et était en moyenne d’environ 2,7X pour ces cinq tests. Cela pourrait donc être le « Plus de 2x plus rapide » dont parle Pichai. Mais ce n’est pas ce que montre son graphique. La différence entre la capacité de performances de pointe matérielle 2X et l’augmentation moyenne de 2,7X des performances MLPerf est – vous l’avez deviné – l’optimisation logicielle.

Les pods TPU sont découpés virtuellement de la manière suivante. Voici le pod TPUv2:

Et voici le pod TPUv3:

La plus grande image TPUv2 comptait 512 cœurs et 4 To de mémoire HBM2 et la plus grande image TPUv3 comptait 2 048 cœurs et 32 ​​To de mémoire.

Maintenant, Pichai a déclaré que le pod TPUv4 aurait «4 096 puces» et en supposant qu’il ne parlait pas de cœurs, cela pourrait signifier qu’il a 1 024 sockets et que chaque socket a quatre puces. Nous ne pensons pas que Pichai voulait dire que le pod TPUv4 avait 4 096 sockets. À 1024 sockets TPU – comme avec les pods TPUv3 – et quatre puces par socket, cela représenterait 4096 puces. Nous pensons que l’instance TPU pourra évoluer sur tous ces chiplets dans une seule image système, avec au moins 64 To de mémoire HBM2 agrégée. Ce serait juste au-dessus d’un exaflops des performances brutes de Bfloat16 si les vitesses d’horloge et les thermiques pour le socket TPUv4 sont à peu près les mêmes que le socket TPUv3. Et grâce aux améliorations logicielles, une plus grande partie de ce pic entraînera les charges de travail. Nous verrons combien quand Google nous en dira plus.

Une dernière chose: Pichai a également déclaré que le pod TPUv4 avait «10 fois la bande passante d’interconnexion par puce à grande échelle par rapport à toute autre technologie de réseau». En comparant la carte serveur TPUv4 à la carte TPUv3 dans les schémas ci-dessus, il semble que chaque socket TPUv4 possède sa propre interface réseau; la carte TPUv3 avait quatre sockets partageant deux interconnexions. (Ou, cela ressemble à ça. Nous ne sommes pas certains que ce soit correct. Il pourrait s’agir de puces de routeur à deux ports.) Nous avons hâte d’en savoir plus sur l’interconnexion TPUv4.