Google profite de sa conférence Next ’23 pour présenter ses nouveaux TPU de 5e génération : les v5e. Ils ne misent pas sur la performance brute (ils sont d’ailleurs en dessous des v4), mais sur la rentabilité avec une forte amélioration du rapport performances/prix. On a aussi les TPU v4e et v5 sur Google Kubernetes Engine et Multislice.
C’est quoi un TPU ?
Avant d’entrer dans le vif du sujet, un rappel important sur les TPU (Tensor Processing Unit) de Google. Ce sont « des circuits intégrés spécifiques aux applications (ASIC) conçus par Google pour accélérer les charges de travail de machine learning ». On peut les utiliser via des frameworks tels que TensorFlow, Pytorch et JAX.
Dans chaque TPU, on retrouve un ou plusieurs TensorCore (cela évolue en fonction des générations et des versions), eux-mêmes constitués d'une ou de plusieurs unités matricielles, d'une unité vectorielle et d'une unité scalaire. Plusieurs puces TPU peuvent aussi être interconnectées entre elles pour former un pod, que l’on peut de nouveau assembler. De plus amples détails sont disponibles sur cette page
Les premiers TPU ont été annoncés par Google en 2016, puis nous avons eu les v2 (2017), v3 (2018) et v4 (2021). Cette année, le géant du Net présente le premier représentant de sa 5e génération de Tensor Processing Unit : le v5e. Selon Google, il s’agit du « compromis idéal entre performances et rentabilité ».
Voici les TPU v5e, avec un meilleur ratio perfs/dollar
À défaut de détails techniques, on a droit à quelques promesses dans le communiqué : « par rapport aux TPU v4, les v5e offrent des performances sur l’entrainement des modèles jusqu'à deux fois supérieures par dollar et des performances d'inférence jusqu'à 2,5 fois supérieures par dollar pour les LLM et les modèles d’IA générative ».
On avait droit à un discours bien différent lors du passage de la v3 à la v4 : « Les TPU v4 surpassent les v3 de 2,1 fois en moyenne par puce et améliore le ratio performances/watt de 2,7 fois ». Il était alors question de performances brutes et d’efficacité énergétique. Avec les v5e, Google met en avant la rentabilité. Nous allons voir que la nuance est importante.
TPU v5e du côté technique : un TensorCore, quatre MXU
Alors que les TPU v3 et v4 contiennent chacun deux TensorCore, le v5e n’en a qu’un seul. Chaque TensorCore de la puce (que ce soit en v3, v4 ou v5e) comporte quatre unités de multiplication matricielle (MXU), une unité vectorielle et une unité scalaire.
Afin de mieux comprendre la différence entre les v4 et v5e, voici un diagramme des deux puces :
Diagramme du TPU v5e à gauche et du v4 à droite. On voit bien la différence de nombre de TensorCore
Dans le but de comparer plus rapidement les caractéristiques techniques des différentes générations, nous avons regroupé dans un tableau celles que nous connaissons pour le moment sur les v5e, aux côtés des v3 et v4.
On peut d’ores et déjà voir que la quantité de mémoire HBM2 est divisée par deux (mais il y a aussi deux fois moins de TensorCore dans les v5e) avec une bande passante inférieure à celle des TPU v3 et v4. La signification du « e » n’est pas précisée, mais cela pourrait être pour « efficience ».
Des péta/tera/exa opérations par seconde
Quoi qu’il en soit, jusqu’à 256 puces TPU v5e peuvent être interconnectées pour former un pod, avec une bande passante totale de 400 Tb/s, pour des performances de 100 PetaOP (OP pour opérations par seconde) en INT8 (des entiers sur 8 bits), selon le communiqué de Google.
Sur cette page, le géant du Net revendique 197 TeraFLOP (FLOP pour opérations en virgule flottante par seconde) en Bfloat16 et 393 TeraOP en INT8. Si on multiplie 393 TerOP par 256 puces TPU v5e, on arrive bien aux 100 PetaOP annoncés pour le pod (vous suivez ?).
Ce n’est pas la même chanson avec les TPU v4. Ils sont annoncés par Google à 275 TFLOP en Bfloat16 (bien au-dessus des v5e donc)… mais aussi à 275 TFLOP en INT8, et donc en dessous des v5e dans ce cas.
Avec 4 096 puces et donc 1 126 PetaFLOP de puissance totale (Bfloat16 ou INT8), un pod de TPU v4 dépasse largement un pod de TPU v5 qui arrive « seulement » à 50 PetaFLOP en Bfloat16 ou 100 PetaFLOP en INT8. Dans le cas des entiers, les performances sont divisées par 10, mais il y a 16 fois moins de puces.
Cette puce V5e laisse donc de la place à Google pour lancer un TPU v5 « complet »… avec (au moins) deux TensorCore comme les v4 et v3 ? Selon Dylan Patel de SemiAnalysis, les TPU v5 (alias Viperfish) pourraient également être regroupés par paquet de 16 384, si le rythme actuel est maintenu : 256 sur les v2, 1 024 sur les v3, 4 096 sur les v4, soit x4 à chaque génération.
Des travaux sur TPU v5 avaient été annoncés en juin 2021 par Anna Goldie, qui était alors chez Google Brain. De telles puces peuvent très bien être utilisées par l’entreprise, sans avoir été annoncées pour le moment.
Google Kubernetes Engine sur TPU v4 et v5e et Multislice
À l’occasion de l’annonce des TPU v5e, l’entreprise en profite pour faire une annonce autour de Google Kubernetes Engine (GKE) : « Les clients peuvent maintenant améliorer la productivité lors de développement de l'IA en exploitant GKE pour gérer l'orchestration des charges de travail à grande échelle sur TPU v5e et v4 ».
Google présente aussi sa technologie Multislice. Elle était déjà utilisée en interne pour les grands modèles de langage (LLM) et débarque désormais en preview pour tous les clients. « Jusqu'à présent, les entrainements utilisant des TPU étaient limitées à une seule tranche de puces TPU, limitant la taille des plus gros entrainements à une tranche de 3 072 puces au maximum avec les TPU v4 ».
Dorénavant, il est possible d’exploiter « jusqu'à des dizaines de milliers de puces via inter-chip interconnect (ICI) au sein d'un seul pod, ou bien sur plusieurs pods via le datacenter network (DCN) ». Multislice n’est compatible qu’avec les TPU v4, v5e et le framwork JAX précise la documentation.
Commentaires (11)
#1
J’ai du mal à saisir la différence entre le ratio perf/watt et le perf/dollar ?
Car de toute façon quand on utilise ce type de matos c’est en location via google et donc on paye grosso modo la R&D (amortie par le volume) et la conso.
Et puis sur le coté perf pure (désolé je suis un noob sur ce domaine de tpu) ne peut on pas juste mettre plus de v5 pour obtenir les mêmes perfs qu’avec les v4 pour moins chère ?
#2
Image de l’article –> https://www.reddit.com/r/cableporn/
#3
Intéressant. On fait donc des processeurs spécifiques aux IA, j’ignorais. Rapport avec les mathématiques des tenseurs ou ils ont pris le nom tensor pour faire classe ?
#3.1
C’est probablement une référence à TensorFlow qui est le framework de machine learning de Google.
Et oui c’est une référence aux Tenseurs puisque les calculs de machine learning sont généralement décrits comme des opérations sur des tenseurs, et le but du framework est d’optimiser et de “vectoriser” les opérations pour le CPU/GPU/TPU, et le TPU ou GPU va exécuter la même opération sur de nombreuses données en parallèle en exploitant le fait que les calculs sont décrits comme des opérations sur des tenseurs.
#3.2
Je ne connais pas les TPU de Google mais chez NVIDIA les “tensor cores” sont des unités spécialisées dans la multiplication matrice-matrice de petites tailles en faible précision. Je suppose que c’est pareil chez Google.
#3.3
Dans le cas présent, la définition de tenseurs est une généralisation à n dimension du vecteur qui va d’un simple scalaire (dimension=0) à des tables de très grande dimension (un tenseur de dimension 2 est assimilable à une matrice). Plus précisément, c’est une structure de donnée.
Sur de nombreux aspects, un tenseur dans pytorch ou tensorflow (les 2 principales bibliothèques de deep learning dont le cœur est la manipulation d’un graphe de fonction sur des tenseurs) sont très similaires avec les ndarray (n dimension array) de numpy.
Je ne connais pas l’origine de l’utilisation du terme tenseur avec cette définition, mais c’est assez général.
Pour expliquer rapidement : le deep learning et les réseaux de neurones sont massivement des transformations linéaires (multiplication matricielle) qui s’enchainent les unes après les autres en appliquant une opération non linéaire (par exemple une fonction sigmoïde ou une ReLu (x=max(x,0) )) entre 2. Du coup, oui, il y a plein de matos spécialisé dans ce genre d’opération depuis des années. Les RTX de NVidia ont apporté les Tensor Core, il y a les TPU de Google, dans les puces ARM de ton téléphone il y a surement un module (Tensor accelerators sur les puce Qualcomm ou les Core Neural Engine sur les puces M1 et M2 d’Apple)…
#3.4
#4
Sémantiquement, il n’est pas correct de parler de “MFLOPS” quand on calcule sur des INT. On devrait plutôt parler de MIPS (Mega Instructions Per Second - - ou GIPS, TIPS, etc.).
“Avant”, quand la surface sur les puces était très limitée, un FLOP coûtait un paquet d’instructions entières, et donc de cycles, d’où le fait de travailler plutôt en virgule fixe pour éviter tout le travail d’alignement des (pseudo-)mantisses.
Aujourd’hui, avec des millions de transistors dédiés à l’unité flottante, on peut livrer un FLOP par cycle en scalaire, et donc un FLOP coûte le même temps qu’une instruction entière (mais clairement pas la même énergie ! ). Cependant, la représentation n’est pas identique, d’où le maintien nécessaire de la différence de terme.
#5
Perf/dollar : à performance identique, plus il grimpe, moins tu payes cher à l’achat/location.
Perf/watt : à performance identique, plus il grimpe, moins tu consommes.
#6
Article pas très clair qui passe sans explication de TeraFLOP à TerFLOP à TFLOP et surtout à TeraOP et TerOP sans explication du passage de FLOP à OP entre INT8 et INT16
Parler un instant de TEraOP en INT8 et dans le paragraphe du dessous de TeraFLOP en INT8 en laissant le soin de comparer les deux c’est .. gonflé ou c’et moi qui lit mal ?
#7
Merci beaucoup pour toute vos précisions.