- Le Google TPU v1 est un ASIC développé en 15 mois à partir de fin 2013 pour absorber le coût et l’échelle de l’inférence des services de deep learning, avec un objectif de performance par coût 10 fois supérieur à celui des GPU
- Son principe clé consiste à implémenter le réseau systolique décrit en 1978 par H.T. Kung et Charles E. Leiserson sous la forme d’une structure MAC 256×256, afin de réduire les allers-retours en mémoire des résultats intermédiaires pendant les multiplications matricielles
- Le TPU v1 communique avec l’hôte via PCIe et stocke les poids dans de la DDR3-2133 ; le flux d’inférence repose sur un petit nombre d’instructions comme
Read_Host_Memory, Read_Weights, Matrix_Multiply / Convolve, Activate et Write_Host_Memory
- Les multiplications entières 8-bit×8-bit et la quantification évitent le coût en surface de die des calculs en virgule flottante, tandis que des User Space Driver et Kernel Driver intégrés à TensorFlow contrôlent l’exécution
- Les Intel Haswell CPU et Nvidia K80 GPU étaient les références de comparaison de l’époque ; le TPU v1 était environ 15 à 30 fois plus rapide en inférence, avec une performance/Watt incrémentale relative 25 à 29 fois supérieure à celle des GPU, mais ce n’était pas un dispositif destiné à l’entraînement
Le point de départ du TPU v1 pour réduire le coût de l’inférence
- L’objectif du projet TPU v1 était de créer rapidement un ASIC d’inférence afin de réduire les coûts matériels à grande échelle requis par les services fondés sur le deep learning
- La cible était une performance par coût 10 fois supérieure à celle des GPU en inférence
- Il fallait à la fois un développement rapide, des performances élevées, un déploiement à grande échelle, la prise en charge immédiate de nouvelles charges de travail et une bonne efficacité économique
- Le nom TPU vient du fait qu’il s’agit d’un dispositif accélérant les opérations sur tenseurs
- En pratique, les calculs centraux pris en charge par le matériel TPU v1 sont principalement des opérations sur vecteurs et matrices
- Les couches cachées et de sortie d’un réseau de neurones peuvent être exprimées comme le résultat de l’application d’une fonction d’activation au produit d’un vecteur d’entrée et d’une matrice de poids
- Lorsque plusieurs données d’entrée arrivent, cela revient à appliquer la fonction d’activation à chaque élément du résultat de la multiplication matricielle
Traiter les multiplications matricielles avec un réseau systolique
- Le TPU v1 utilise le concept de système systolique présenté dans l’article de 1978 de H.T. Kung et Charles E. Leiserson, Systolic Arrays (for VLSI)
- Il s’agit d’une structure dans laquelle plusieurs processeurs calculent et transmettent les données selon un rythme régulier
- Chaque processeur effectue de courts calculs tout en faisant continuellement entrer et sortir les données
- Dans une multiplication matricielle simple 2×2, si les entrées sont fournies par le haut et par la gauche dans le bon ordre, le résultat sort naturellement du réseau MAC 2×2
- Chaque MAC effectue une multiplication et une accumulation
- Les sommes partielles sont stockées à l’intérieur du réseau, et le résultat final apparaît sous forme de diagonales en déplacement
- L’exemple 2×2 nécessite 4 étapes, mais en pratique, dès que le MAC en haut à gauche se libère, la multiplication matricielle suivante peut commencer, ce qui permet une nouvelle multiplication toutes les 2 cycles
- Le point essentiel est que, si l’on alimente le réseau systolique avec les données dans le bon ordre, le flux des valeurs et des résultats crée lui-même l’ordre de calcul nécessaire
- Il n’est pas nécessaire de stocker les résultats intermédiaires en mémoire principale puis de les relire
- Grâce à la structure de l’unité de multiplication matricielle et à l’ordre des entrées, les résultats intermédiaires deviennent automatiquement disponibles au moment voulu
Composition du système TPU v1
- Le TPU v1 communique avec l’ordinateur hôte via le bus série haut débit PCIe et accède directement à sa propre DRAM DDR3
- Les principaux composants sont les suivants
- DDR3 DRAM / Weight FIFO
- Les poids sont stockés dans des puces de RAM DDR3 connectées via une interface DDR3-2133
- Après avoir été préchargés depuis la mémoire hôte via PCIe, ils sont déplacés vers la Weight FIFO pour être utilisés par la Matrix Multiply Unit
- Matrix Multiply Unit
- Il s’agit d’un réseau systolique composé de 256×256 MAC
- Il reçoit 256 poids par le haut et 256 entrées de données par la gauche
- Accumulators
- Ils stockent les résultats sortant par le bas de l’unité matricielle systolique
- Activation
- Cette étape applique la fonction d’activation du réseau de neurones
- Unified Buffer / Systolic Data Setup
- Il stocke les résultats après application de la fonction d’activation et prépare leur réinjection en entrée de la Matrix Multiply Unit pour le calcul de la couche suivante
Formats de calcul et jeu d’instructions
- La Matrix Multiply Unit du TPU v1 effectue des multiplications entières 8-bit×8-bit
- Elle utilise la quantification afin d’éviter les calculs en virgule flottante, qui nécessitent une surface de die plus importante
- Le jeu d’instructions est une conception CISC comprenant environ 20 instructions
- Les instructions ne sont pas lues depuis la mémoire ; elles sont envoyées par l’ordinateur hôte via PCIe
- La majeure partie du flux d’inférence repose sur 5 instructions principales
Read_Host_Memory
- Lit les entrées depuis la mémoire hôte vers l’Unified Buffer via PCIe
Read_Weights
- Lit les poids depuis la mémoire des poids vers la Weight FIFO
Matrix_Multiply / Convolve
- Envoie les entrées de l’Unified Buffer vers les Accumulators et effectue une multiplication matricielle ou une convolution
- Multiplie une entrée B×256 par une entrée de poids constants 256×256 pour produire une sortie B×256, en B cycles de pipeline
Activate
- Applique aux entrées des Accumulators des fonctions non linéaires de neurones artificiels comme ReLU ou Sigmoid, puis écrit le résultat dans l’Unified Buffer
Write_Host_Memory
- Écrit les résultats de l’Unified Buffer vers la mémoire hôte via PCIe
- Ce flux peut être représenté approximativement ainsi
Read_Host_Memory
Read_Weights
Loop_Start
Matrix_Multiply
Activate
Loop_End
Write_Host_Memory
- L’unité matricielle utilise une exécution systolique pour réduire les lectures et écritures dans l’Unified Buffer et économiser de l’énergie
- Les données entrent par la gauche, et les poids sont chargés par le haut
- Les opérations MAC sur 256 éléments traversent la matrice comme un front d’onde diagonal
TensorFlow et la pile de pilotes
- Pour utiliser le matériel TPU v1 dans des services réels, il fallait une pile logicielle compatible
- Comme Google développait et utilisait TensorFlow, créer des pilotes permettant à TensorFlow de fonctionner avec le TPU v1 était une étape clé
- La pile logicielle TPU devait être compatible avec les piles destinées aux CPU et aux GPU
- Les applications devaient pouvoir être portées rapidement vers le TPU
- La partie de l’application exécutée sur TPU est généralement écrite avec TensorFlow et compilée vers une API exécutable sur GPU ou TPU
- Comme pour les GPU, la pile TPU est divisée entre User Space Driver et Kernel Driver
- Le Kernel Driver reste léger : il ne gère que la gestion mémoire et les interruptions, avec un objectif de stabilité à long terme
- Le User Space Driver évolue fréquemment et prend en charge la configuration et le contrôle de l’exécution TPU, le reformatage des données dans l’ordre attendu par le TPU, la conversion des appels d’API en instructions TPU et la génération des binaires applicatifs
Procédé 28 nm et agencement du die
- Le TPU v1 est fabriqué avec le procédé 28 nm relativement mature de TSMC
- Les puces Intel Haswell CPU et Nvidia K80 GPU utilisées à l’époque dans les datacenters de Google étaient fabriquées avec des procédés plus avancés
- Selon Google, la surface de die du TPU v1 est inférieure à la moitié de celle de ces puces
- L’ISA simple a réduit l’overhead de die nécessaire au décodage et aux tâches associées
- La zone
control n’occupe que 2 % de la surface du die
- La Matrix Multiply Unit en occupe 24 %, et l’Unified Buffer 29 %
Comparaison des performances et limites claires
- Le TPU v1 est un dispositif d’inférence destiné à utiliser plus efficacement des modèles déjà entraînés dans les services réels de Google à grande échelle
- Il n’a pas été conçu pour améliorer la vitesse ou l’efficacité de l’entraînement
- L’inférence et l’entraînement posent des problèmes différents dans le développement de matériel spécialisé
- En 2013, les principales références de comparaison étaient les Intel Haswell CPU et Nvidia K80 GPU
- Le TPU v1 dispose de 25 fois plus de MAC que le K80 GPU
- Le TPU v1 possède 3,5 fois plus de mémoire on-chip que le K80 GPU
- Le TPU v1 est environ 15 à 30 fois plus rapide en inférence que le K80 GPU et le Haswell CPU
- Sa performance/Watt incrémentale relative par rapport au GPU est 25 à 29 fois supérieure
- Grâce à son architecture sur mesure, le TPU v1 a obtenu des performances d’inférence plus élevées et une consommation d’énergie plus faible que les CPU et GPU de l’époque
- Comme cette conception de première génération se concentrait sur un objectif unique, l’inférence rapide et l’efficacité énergétique, sa limite demeure qu’elle n’a pas été conçue pour l’entraînement
1 commentaires
Commentaires sur Hacker News
Le CEO de Groq, Jonathan Ross, a récemment raconté dans une interview en podcast comment les premiers TPU ont été créés chez Google : à l'origine, c'était un FPGA qu'il avait développé sur ses 20 % de temps libre, assis près d'une équipe qui avait des problèmes de vitesse d'inférence
Une fois qu'ils ont obtenu quelque chose de fonctionnel, Jeff Dean a fait les calculs et ils ont décidé de passer à un ASIC
Aujourd'hui, Google devrait selon moi scinder l'équipe TPU en société distincte. C'est le seul concurrent vraiment crédible face à Nvidia, et son support logiciel est probablement le meilleur après celui de Nvidia
https://open.spotify.com/episode/0V9kRgNS7Ds6zh3GjdXUAQ?si=q...
Mais chacun de ces avantages a ses faiblesses. Les capacités de fonderie sont tendues, mais Nvidia peut sacrifier le marché des GPU grand public si cela lui permet de vendre davantage de puces IA plus chères. Cet avantage disparaît si un concurrent parie massivement plusieurs années à l'avance, ou si une entreprise disposant d'une grande capacité de production, comme Intel, change ses priorités
Un logiciel propriétaire est pratique quand il devient le standard de facto du secteur, mais son importance réelle dépend beaucoup des cas d'usage. Le matériel conçu pour les TPU semble intrinsèquement bien plus simple que les GPU : pas besoin de ray tracing, de texture samplers ou de rasterization, il suffit surtout de beaucoup de multiplication de matrices et de mémoire
Les relations clients sont utiles pour rester dans la conversation, mais sur un marché où le moindre avantage compte, le fournisseur proposant le plus de FLOPS par dollar trouvera assez de clients pour remplir sa capacité de production. Donc, d'ici quelques années, la concurrence pourrait devenir bien réelle assez vite
Cela dit, les TPU restent une ressource de calcul relativement rare même à l'intérieur de Google, et il leur serait probablement déjà difficile de satisfaire la demande interne
Je dis rarement que je respecte une entreprise à ce point, mais j'ai vraiment du respect pour Groq
Google a inventé le TPU et Google Research a même publié les articles sur les LLM, alors je ne comprends pas pourquoi NVDA et les startups IA ont capté presque 100 % de la valeur
Dans le cas de Google, on peut faire l'analogie suivante : proposer quelque chose comme ChatGPT à grande échelle risquerait de cannibaliser les liens sponsorisés du moteur de recherche et les revenus publicitaires de sites que les utilisateurs n'auraient plus besoin de visiter. Il est donc possible qu'ils aient choisi de ne l'introduire prudemment, de manière moins perturbatrice, que lorsque la concurrence l'a rendu nécessaire
La réalité n'est sans doute pas aussi simple, mais si c'était bien la raison, ce serait assez drôle
https://www.linkedin.com/posts/eolver_googles-defense-agains...
Je travaille chez Google, et si vous n'avez pas regardé les TPU depuis un moment, je vous recommande de jeter un œil au v5. Il prend désormais en charge PyTorch/JAX, donc c'est bien plus facile à utiliser qu'à l'époque où c'était réservé à TensorFlow
Cet article reliait très bien plusieurs éléments abstraits dispersés en montrant comment tout cela circule réellement dans le silicium
J'ai particulièrement aimé voir à quel point des instructions CISC simples correspondent presque directement aux étapes d'inférence des LLM
C'est peut-être une question stupide qui révèle mon ignorance, mais côté grand public, j'entends sans cesse dire que les puces M1 à M4 sont bonnes pour certaines tâches d'IA
Aujourd'hui, ce qui compte le plus pour moi, ce sont des outils comme Photoshop et Resolve, et j'ai vu qu'ils tournent bien plus vite sur les nouvelles puces propriétaires d'Apple que sur mon ancienne machine
Cela ne se traduit peut-être pas vraiment par ce que cette puce ou un H100 peut faire, mais je me demande s'il y a au moins un certain lien. Bien sûr, Apple ne vend pas ses puces séparément, donc pour en faire un produit pratique il faudrait sans doute proposer quelque chose comme un serveur externe bourré de GPU et de puces IA
Les puces M* utilisent de la mémoire unifiée et, surtout pour les versions Pro/Max/Ultra, leur bande passante mémoire est très élevée, même comparée à des GPU comme la 1080. La bande passante mémoire du M1 Ultra se situe à peu près entre celle d'une 2080 et d'une 3090
Avec de petites tailles de batch, en particulier le batch 1 comme dans la plupart des usages locaux, l'inférence est limitée par la bande passante mémoire plutôt que par la capacité de calcul. C'est pourquoi on dit que les puces M* sont bonnes en machine learning
Mais les H100 servent surtout à l'entraînement avec des tailles de batch énormes, et entraîner de grands modèles demande beaucoup d'interconnexions. À cette échelle, l'intensité arithmétique est très élevée, donc même si l'on pouvait mettre les puces M* en réseau, elles ne seraient pas très compétitives. Elles occupent simplement un autre point sur la courbe de Pareto puissance/efficacité que des puces très énergivores comme les H100
Ce que Google devrait vraiment faire, c’est entrer dans le domaine du 2 nm EUV et descendre sous les 2 nm.
Que ce soit la lithographie électronique ou la technologie qu’ASML grave sur les puces, s’ils mettaient la main sur ce genre de capacité, ils deviendraient vraiment redoutables. On dirait qu’il leur faudrait un projet moonshot hardcore façon Google X.
Ou alors ils ont peut-être bien 500 millions de dollars à mettre dans l’achat d’un seul équipement. Si le TPU est vraiment si bon, une intégration verticale avec leur propre technologie et même leur propre fab pourrait devenir un bon business.
Si les fabs de pointe sont rentables aujourd’hui, c’est parce qu’elles fabriquent des dispositifs de calcul génériques pour divers clients et usages, avec des décennies de talents et d’ingénierie accumulés. En plus, les clients poussent indépendamment l’innovation dans des domaines clés, comme l’amélioration des rendements chip-on-chip HDI chez Micron, ou les fabrics de communication inter-die et les conceptions de substrats multi-puces chez Xilinx.
Le TPU ne produira jamais les volumes nécessaires, et n’attirera pas non plus de clients capables de créer des économies d’échelle rentables. Google devrait aussi proposer des prix attractifs face à la concurrence.
S’il y avait un modèle économique vraiment convaincant, les fabs existantes seraient ravies de leur allouer des volumes. Le TPU est encore très loin d’être convaincant à ce point.
J’ai écouté une présentation de Jim Keller de TensTorrent expliquant une autre approche pour concevoir des cœurs IA. L’idée est d’avoir cinq cœurs RISC-V : un pour charger les données, un pour les envoyer, et les autres dédiés aux opérations matricielles.
Il a aussi mentionné le Google TPU, en disant que le programmer revenait un peu à manipuler du VLIW, et qu’environ 500 personnes travaillaient sur le compilateur.
Dans le texte d’origine, il est écrit que le « TPU v1 est une conception CISC avec environ 20 instructions », et je trouve ça amusant de voir comment CISC/RISC est passé d’une observation pertinente à un programme de recherche, puis à une technologie révolutionnaire, ensuite à un mot à la mode marketing, avant de finir en formule complètement vide de sens.
On pourrait appeler ça le cycle de vie d’un terme.
Donc même si le TPU a peu d’instructions, il pourrait être CISC si chacune est assez complexe. Cela dit, le dernier cours d’architecture des ordinateurs que j’ai suivi remonte à 15 ans, en master, donc mes souvenirs sont flous. J’ai aussi passé l’essentiel du semestre à travailler sur Itanium, ce qui n’a plus vraiment d’utilité aujourd’hui.
La demande de capacité chez les fondeurs semble énorme, donc je me demande comment Microsoft ou Google font pour passer tout en haut de la file quand ils conçoivent leur propre puce et ont besoin de production.
Est-ce que c’est suffisamment simple pour être fabriqué dans des fabs « anciennes et moins demandées » ? Je crois savoir qu’Apple et Nvidia ont déjà réservé une grande partie des capacités des fondeurs.
https://en.wikipedia.org/wiki/Tensor_Processing_Unit#Product...
Ils ont aussi une présence significative et des dépenses importantes dans des domaines comme la HBM, et il y a de bons articles à ce sujet chez SemiAnalysis.
Je me demande comment le hardware évoluerait si les LLM s’imposaient vraiment massivement avec une quantification en -1, 0, 1.