C’est Google I/O 2022 cette semaine, entre autres choses, et nous espérions une plongée architecturale profonde sur les moteurs mathématiques matriciels TPUv4 que Google a évoqué lors de l’événement D’E/S de l’année dernière. Mais, hélas, pas une telle chance. Mais le géant des moteurs de recherche et de la publicité, qui se trouve également être l’un des plus grands innovateurs en IA de la planète en raison de la gigantesque quantité de données qu’il doit utiliser, a donné quelques informations supplémentaires sur les processeurs TPUv4 et les systèmes qui les utilisent.

Google a également déclaré qu’il installait huit pods des systèmes TPUv4 dans son centre de données du comté de Mayes, en Oklahoma, qui embrasse 9 exaflops de capacité de calcul agrégée, pour être utilisés par sa branche Google Cloud afin que les chercheurs et les entreprises aient accès au même type et à la même capacité de calcul que Google a pour faire son propre développement et production interne d’IA.

Google exploite des centres de données dans le comté de Mayes, au nord-est de Tulsa, depuis 2007 et a investi 4,4 milliards de dollars dans des installations depuis lors. Il est situé dans le centre géographique des États-Unis – bien un peu au sud et à l’ouest de celui-ci – et cela le rend utile en raison des latences relativement courtes pour une grande partie du pays. Et maintenant, par définition, le comté de Mayes possède l’un des plus grands assemblages de fer pour stimuler les charges de travail d’IA sur la planète. (Si les huit pods TPUv4 étaient mis en réseau ensemble et que le travail pouvait s’étendre simultanément, nous pourrions peut-être dire « le plus grand » sans équivoque. . . . Google l’a sûrement fait, comme vous le verrez dans la citation ci-dessous.)

Lors de son discours d’ouverture, Sundar Pichai, qui est directeur général de Google et de sa société mère, Alphabet, a mentionné en passant que les pods TPUv4 étaient en avant-première sur son cloud.

« Toutes les avancées que nous avons partagées aujourd’hui ne sont possibles que grâce à l’innovation continue dans notre infrastructure », a déclaré Pichai en parlant de certaines améliorations assez intéressantes du langage naturel et des moteurs de recherche de données immersifs qu’il a apportées et qui alimentent toutes sortes d’applications. « Récemment, nous avons annoncé notre intention d’investir 9,5 milliards de dollars dans des centres de données et des bureaux à travers les États-Unis. L’un de nos centres de données de pointe se trouve dans le comté de Mayes, en Oklahoma, et je suis ravi d’annoncer que nous y lançons le plus grand centre d’apprentissage automatique au monde accessible au public pour tous nos clients Google Cloud. Ce hub orienté vers la machine dispose de huit pods Cloud TPU v4, construits sur mesure sur la même infrastructure réseau qui alimente les plus grands modèles neuronaux de Google. Ils fournissent une puissance de calcul globale de près de 9 exaflops, offrant à nos clients une capacité sans précédent à exécuter des modèles et des charges de travail complexes. Nous espérons que cela alimentera l’innovation dans tous les domaines, de la médecine à la logistique en passant par la durabilité et plus encore. »

Pichai a ajouté que ce hub d’IA basé sur les pods TPUv4 a déjà 90% de sa puissance provenant de sources durables et sans carbone. (Il n’a pas dit combien il y avait de l’énergie éolienne, solaire ou hydroélectrique.)

Avant d’entrer dans les vitesses et les flux des puces et des pods TPUv4, il vaut probablement la peine de souligner que, pour tout ce que nous savons, Google a déjà des pods TPUv5 dans ses centres de données internes, et il pourrait avoir une collection considérablement plus grande de TPU pour piloter ses propres modèles et augmenter ses propres applications avec des algorithmes et des routines d’IA. Ce serait l’ancienne façon dont Google faisait les choses: Parler de génération N de quelque chose pendant qu’il vendait de la génération N-1 et était déjà passé à la génération N+1 pour ses charges de travail internes.

Cela ne semble pas être le cas. Dans un article de blog Écrit par Sachin Gupta, vice-président et directeur général de l’infrastructure chez Google Cloud, et Max Sapozhnikov, chef de produit pour les TPU Cloud, lorsque les systèmes TPUv4 ont été construits l’année dernière, Google y a donné un accès précoce aux chercheurs de Cohere, LG AI Research, Meta AI et Salesforce Research, et en outre, ils ont ajouté que les systèmes TPUv4 ont été utilisés pour créer le modèle PaLM (Pathways Language Model) qui sous-tend le traitement du langage naturel et la reconnaissance vocale des innovations qui étaient au cœur du discours d’aujourd’hui. Plus précisément, PaLM a été développé et testé sur deux pods TPUv4, qui ont chacun 4 096 des moteurs mathématiques matriciels TPUv4.

Si les nouveaux modèles les plus brillants de Google sont développés sur des TPUv4, il n’a probablement pas de flotte de TPUv5 cachés dans un centre de données quelque part. Bien que nous allons ajouter, il serait intéressant que les machines TPUv5 soient cachées, à 26,7 miles au sud-ouest de notre bureau, dans le centre de données Lenoir, montré ici depuis notre fenêtre:

La bande de gris en bas de la montagne, sous les feuilles de bouleau, est le Google datacenter. Si vous plissez les yeux et regardez au loin très fort, le centre de données Apple de Maiden est parti à gauche et considérablement plus loin sur la ligne.

Assez de cela. Parlons de quelques flux et vitesses. Voici, enfin, quelques capacités qui comparent le TPUv4 au TPUv3 :

L’année dernière, lorsque Pichai faisait allusion au TPUv4, nous avons deviné que Google passait à des processus de 7 nanomètres pour cette génération de TPU, mais compte tenu de cette très faible consommation d’énergie, il semble qu’il soit probablement gravé à l’aide de processus de 5 nanomètres. (Nous avons supposé que Google essayait de garder l’enveloppe de puissance constante, et il voulait clairement la réduire.) Nous avons également deviné qu’il doublait le nombre de cœurs, passant de deux cœurs sur le TPUv3 à quatre cœurs sur le TPUv4, ce que Google n’a pas confirmé ou nié.

Doubler les performances tout en doublant les cœurs permettrait au TPUv4 d’atteindre 246 téraflops par puce, et passer de 16 nanomètres à 7 nanomètres permettrait de doubler à peu près la même enveloppe de puissance avec à peu près la même vitesse d’horloge. Passer à 5 nanomètres permet à la puce d’être plus petite et de fonctionner un peu plus rapidement tout en réduisant la puissance consommée – et en ayant une puce plus petite avec un rendement potentiellement plus élevé à mesure que les processus de 5 nanomètres mûrissent. Que la consommation moyenne d’énergie a diminué de 22,7%, et que cela se heurte à une augmentation de 11,8% de la vitesse d’horloge compte tenu du nœud de processus à deux et changement passe de TPUv3 à TPUv4.

Il y a des choses très intéressantes dans ce tableau et dans les déclarations que Google fait dans ce blog.

Mis à part les cœurs 2X et la légère augmentation de la vitesse d’horloge engendrée par le processus de fabrication de puces pour le TPUv4, il est intéressant de noter que Google a maintenu la capacité de mémoire à 32 Go et n’est pas passé à la mémoire HBM3 que Nvidia utilise avec les accélérateurs GPU « Hopper » GH100. Nvidia est obsédé par la bande passante mémoire sur les appareils et, par extension avec son NVLink et NVSwitch, la bande passante mémoire dans les nœuds et maintenant sur les nœuds avec un maximum de 256 appareils dans une seule image.

Google n’est pas aussi préoccupé par les atomes de mémoire (pour autant que nous le sachions) sur l’interconnexion TPU propriétaire, la bande passante mémoire de l’appareil ou la capacité de mémoire de l’appareil. Le TPUv4 a la même capacité de 32 Go que le TPUv3, il utilise la même mémoire HBM2 et il n’a qu’une augmentation de 33% de la vitesse à un peu moins de 1,2 To / sec. Ce qui intéresse Google, c’est la bande passante sur l’interconnexion du pod TPU, qui passe à une conception de tore 3D qui couple étroitement 64 puces TPUv4 avec des « connexions enveloppantes » – ce qui n’était pas possible avec l’interconnexion de tore 2D utilisée avec les pods TPUv3. La dimension croissante de l’interconnexion du tore permet d’attirer davantage de TPU dans un sous-réseau plus étroit pour les opérations collectives. (Ce qui soulève la question, pourquoi pas un tore 4D, ou 5D, ou 6D alors?)

Le pod TPUv4 a 4 fois plus de puces TPU, à 4 096, et a deux fois plus de cœurs TPU, que nous estimons à 16 384; nous pensons que Google a maintenu le nombre d’unités mathématiques de la matrice MXU à deux par cœur, mais ce n’est qu’une intuition. Google pourrait garder le même nombre de cœurs TPU et doubler les unités MXU et obtenir les mêmes performances brutes; la différence serait la quantité de traitement scalaire/vectoriel frontal qui doit être effectuée sur ces MXU. Quoi qu’il en soit, au format à virgule flottante BrainFloat (BF16) 16 bits créé par l’unité Google Brain, le pod TPUv4 délivre 1,1 exaflops, contre seulement 126 pétaflops chez BF16. Il s’agit d’un facteur de calcul brut 8,7 fois plus élevé, contrebalancé par un facteur d’augmentation de 3,3 fois de la bande passante de réduction totale à travers le pod et une augmentation de 3,75 fois de la bande passante bi-section à travers l’interconnexion TPUv4 à travers le pod.

Cette phrase du blog nous a intrigués : « Chaque puce Cloud TPU v4 a ~2,2x plus de FLOPs de pointe que Cloud TPU v3, pour ~1,4x plus de FLOPs de pointe par dollar. » Si vous faites le calcul sur cette déclaration, cela signifie que le prix de la location de TPU sur Google Cloud a augmenté de 60% avec le TPUv4, mais il fait 2,2 fois le travail. Ces sauts de prix et de performances sont absolument cohérents avec le type d’amélioration du rapport prix/performances que Google attend des ASIC de commutateur qu’il achète pour ses centres de données, qui offrent généralement 2 fois la bande passante pour 1,3 fois à 1,5 fois le coût. Le TPUv4 est un peu plus cher, mais il a un meilleur réseau pour exécuter des modèles plus grands, et cela a aussi un coût.

Les pods TPUv4 peuvent fonctionner dans des machines virtuelles sur Google Cloud dont la taille varie de quatre puces à des « milliers de puces », et nous supposons que cela signifie sur l’ensemble d’un pod.