Google annonce les TPU 8t Sunfish et TPU 8i Zebrafish

Lors de Google Cloud Next, Google a annoncé ses accélérateurs d'IA de nouvelle génération : le TPU 8t « Sunfish » pour l'entraînement et le TPU 8i « Zebrafish » pour l'inférence, ainsi que sa nouvelle architecture de datacenter Virgo. D'après les articles de blog de Google, il est clair que ces puces sont optimisées pour « l'ère des agents » : l'entraînement de modèles de pointe de type mélange d'experts à l'échelle de centaines de milliers de puces, puis le déploiement de ces mêmes modèles avec une faible latence et des objectifs de prix par jeton très compétitifs. Les TPU 8t et 8i sont deux puces à l'architecture distincte qui partagent une plateforme hôte et une architecture, mais divergent au niveau de la capacité mémoire, de la SRAM intégrée, de la topologie d'interconnexion et de la spécialisation sur la puce. Le TPU 8t est conçu pour la multiplication matricielle dense (matmul) à grande échelle, tandis que le TPU 8i est basé sur un cache KV sur silicium et une latence collective par jeton réduite.

Un seul superpod 8t peut gérer jusqu'à 9,600 3 puces, embarque 2 Po de mémoire HBM et offre une puissance de calcul FP4 de 121 EFLOPS, soit près de trois fois la puissance de calcul par superpod d'un Ironwood. Le 8i combine 288 Go de HBM et 384 Mo de SRAM embarquée (trois fois plus qu'Ironwood) dans un domaine d'extension à 3 1,152 puces et revendique un rapport performances/prix 80 % supérieur à celui d'Ironwood pour l'inférence LLM. Virgo intègre les deux familles de puces dans une infrastructure de centre de données unique, reliant plus de 134,000 4 puces 8t à une bande passante de bissection non bloquante de 47 Pb/s, avec une bande passante par accélérateur jusqu'à quatre fois supérieure et une latence à vide réduite de 40 % par rapport à la génération précédente.

Qu'est-ce qu'un TPU exactement ?

Avant d'aborder le silicium 8, voici quelques informations de base sur ce qu'est un TPU et en quoi il diffère d'un GPU, car les décisions de conception du 8 n'ont de sens que dans ce contexte.

Une unité de traitement tensoriel (TPU) est un circuit intégré spécifique (ASIC) que Google perfectionne depuis 2015. Chaque génération repose sur le même principe fondamental : contrairement aux GPU qui planifient dynamiquement des milliers de petits cœurs, la TPU s'appuie sur un petit nombre d'unités de multiplication matricielle (MXU) de grande taille. Ces MXU sont alimentées par une mémoire SRAM temporaire gérée par logiciel et pilotées par un compilateur AOT (Ahead-Of-Time). Chaque puce embarque quelques TensorCores, chacun construit autour d'une grande MXU à matrice systolique, ainsi qu'un ensemble plus restreint de SparseCores dédiés aux recherches de type « gather-scatter » irrégulières qui dominent les représentations vectorielles des recommandations. Les données circulent de la mémoire HBM vers la mémoire temporaire, puis vers la MXU, avant de retourner à la mémoire temporaire. Une unité de traitement vectoriel (VPU) gère simultanément les activations, les normalisations et les réductions. Il n'y a pas de planificateur de warp matériel, pas de hiérarchie de caches L1 ou L2 comme sur un GPU, ni de répartition dynamique des tâches.

L'avantage principal de cette conception réside dans son efficacité pour l'algèbre linéaire dense. Grâce à un compilateur AOT (Ahead-of-Time) qui détermine l'emplacement de chaque tenseur et le moment de chaque opération collective, il n'y a ni gigue due aux défauts de cache ni surcharge liée au planificateur de warp. Ce gain est crucial lorsque des dizaines de milliers de puces doivent rester synchronisées lors d'une opération collective. L'utilisation des FLOP (Flood-Performances) des modèles réels sur les TPU pour des charges de travail d'entraînement bien optimisées est généralement supérieure à celle des GPU traditionnels. En revanche, tout ce qui ne se prête pas à une modélisation mathématique dense de grande taille, notamment les formes dynamiques, les motifs de sparsité irréguliers, le routage MoE avec une distribution inégale des jetons ou les réseaux de neurones graphiques, est plus difficile à exprimer efficacement. Historiquement, les TPU embarquent également moins de mémoire HBM par puce que les GPU et bénéficient d'une compatibilité avec un nombre beaucoup plus restreint de frameworks. XLA et JAX sont des frameworks de premier plan ; PyTorch nécessitait, jusqu'à récemment, une couche de traduction ; de plus, le compilateur, l'environnement d'exécution, les bibliothèques réseau et la pile logicielle multi-pod restent propriétaires au sein de Google.

La sparsité est l'exemple le plus flagrant du fossé conceptuel entre les GPU et les TPU, et la raison est d'ordre structurel plutôt que marketing. NVIDIA prend en charge la sparsité structurée 2:4 sur les Tensor Cores depuis Ampere et, théoriquement, les performances pour les charges de travail sparses sont deux fois supérieures à celles des charges de travail denses. Un Tensor Core est fondamentalement une unité de répartition : il effectue des chargements d'opérandes explicites pour chaque instruction MMA. Par conséquent, l'ajout d'une variante MMA sparse acceptant un bloc compressé 2-sur-4 et des métadonnées d'index constitue une extension simple du jeu d'instructions existant. À chaque cycle, le matériel extrait uniquement les valeurs non nulles et leurs indices dans le tableau des multiplicateurs, ignorant implicitement les zéros.

Un réseau systolique fonctionne à l'inverse. Chaque élément de traitement (PE) effectue un calcul à chaque cycle, les opérandes parcourant le réseau de manière synchrone via des chemins directs de registre à registre d'un PE à l'autre. Ce flux de données déterministe est précisément à l'origine de l'avantage en termes d'efficacité énergétique par rapport à la technologie SIMT : absence de lectures SRAM répétées, absence de surcharge liée à la distribution des instructions et réutilisation maximale des opérandes. Cependant, cela signifie également que le matériel ne peut ignorer un élément de valeur nulle par cycle sans interrompre le pipeline.

Les TPU peuvent toujours exploiter la sparsité au niveau des tuiles ; si une tuile entière de la taille d'une MXU est composée uniquement de zéros, le compilateur ne planifie aucun traitement dessus. Cependant, le choix de Google de ne pas ajouter d'accélération matérielle pour la sparsité structurée est délibéré. ​​L'ajout d'une sparsité structurée M:N à un réseau systolique peut être réalisé à l'aide de plusieurs techniques, chacune présentant des compromis différents. L'une de ces techniques nécessite une unité de compression placée entre la SRAM et les ports d'entrée du réseau. Mais un réseau systolique est un pipeline, et non un répartiteur. Son efficacité est garantie par l'arrivée des opérandes à une cadence déterministe, chaque élément de traitement étant occupé à chaque cycle. Autoriser le saut d'opérandes entraîne l'un des deux coûts suivants : bloquer le pipeline sur les zéros, ce qui annule le gain d'efficacité qui a motivé l'architecture à l'origine ; ou ajouter un matériel de décompression dédié pour reconstruire un flux pleine largeur à partir de l'entrée compressée avant son entrée dans le réseau, ce qui consommerait de la surface sur la puce et ajouterait de la latence.

Certains accélérateurs associent des matrices systoliques à une prise en charge matérielle de la sparsité. AWS en a développé une à partir de NeuronCore-v3, le moteur de Trainium2 et Trainium3. Cette implémentation illustre la structure d'une matrice systolique à sparsité matérielle. Le moteur tensoriel NeuronCore-v3 est une matrice systolique 128×128 qui traite une matrice de poids stationnaire et une matrice d'activation en flux continu, la dimension de contraction étant alignée sur la dimension de partition de la matrice. En mode sparse, le chemin de données d'entrée passe de 2×128 éléments par cycle (pour les matrices denses BF16 et FP16) à 5×128 éléments par cycle, et la partie stationnaire utilise une représentation compressée de la matrice de poids au lieu des poids denses d'origine. À la compilation, le tenseur de poids est converti au format M:N. Sur chaque groupe de N éléments contigus le long de la dimension de contraction, seuls M sont conservés, avec un masque de bits compact indiquant les positions non nulles. Le tampon compressé ne stocke que les M valeurs, sa taille étant réduite d'un facteur N/M. Lors de l'exécution de l'instruction matmul, le matériel lit les poids compressés et utilise le masque de bits pour acheminer les activations correspondantes de la tuile stationnaire vers les éléments de traitement appropriés. Les éléments de traitement qui auraient multiplié par zéro ne reçoivent aucune tâche pour cet emplacement. Comme la recherche du masque de bits et l'acheminement sont effectués dans le décompresseur qui alimente le tableau, et non dans le tableau lui-même, le pipeline continue de fonctionner à plein débit pour les valeurs non nulles au lieu de se bloquer sur les zéros.

La multiplication de matrices denses n'est pas la seule fonction d'une TPU. Depuis plusieurs générations, les TPU intègrent un SparseCore en plus des TensorCores. Le SparseCore est un moteur dédié, conçu pour les accès irréguliers de type « gather-scatter » qui caractérisent les modèles de recommandation. Un modèle de classement YouTube ou un modèle de pertinence des annonces de recherche ne ressemble en rien à un transformateur dense. La plupart de ses paramètres résident dans des tables d'embeddings dont la taille peut atteindre plusieurs centaines de gigaoctets, voire plusieurs pétaoctets. L'essentiel du temps de calcul est consacré à effectuer de petites recherches dans ces tables, à transformer légèrement les valeurs extraites et à combiner les résultats. Ce type d'accès représente le pire cas pour une MXU et n'est que légèrement meilleur pour la hiérarchie de cache d'un GPU. Les SparseCores sont précisément optimisés pour cela : des opérations « gather-scatter » à haut débit sur des tables d'embeddings résidant dans la mémoire HBM, avec un support matériel pour les opérations de déduplication et de combinaison dont dépend le reste du pipeline d'embeddings. Le même matériel facilite également le routage expert MoE car, une fois que la sélection des k meilleurs experts produit des index d'experts, le reste du processus de routage (permutation des jetons par expert, leur distribution sur les puces, la collecte des sorties des experts et l'exécution de la réduction pondérée) suit le même modèle de collecte/dispersion/réduction que le pipeline d'intégration, la prise en charge du tri de SparseCore couvrant l'étape des k meilleurs experts elle-même.

Compte tenu de ce contexte, voici les annonces.

TPU 8t « Poisson-soleil »

La première annonce, le TPU 8t (nom de code Sunfish), concerne la puce d'entraînement. Cette évolution par rapport à Ironwood suit la trajectoire attendue à bien des égards : plus de mémoire, plus de bande passante et prise en charge native de types de données plus spécifiques. Chaque puce embarque un TensorCore alimenté par six modules HBM3e 12-Hi, totalisant 216 Go à 6.5 To/s, contre 192 Go répartis sur huit modules pour Ironwood. La mémoire SRAM Vmem intégrée reste à 128 Mo.

L'utilisation native du format FP4 dans l'unité de traitement MXU est à l'origine de l'essentiel du gain de puissance de calcul. L'exécution des multiplications mathématiques en 4 bits au lieu de 8 bits double le débit par cycle pour une même matrice physique, ce qui explique comment Google passe de 4.6 PFLOPS en FP8 pour Ironwood à 12.6 PFLOPS en FP4 pour 8t. L'entraînement en précision mixte conserve une copie principale des poids en FP32 pour l'étape d'optimisation ; le format FP4 réduit la taille des tenseurs de travail, qui consomment la majeure partie du temps de calcul.

L'interconnexion est simple. La bande passante ICI double pour atteindre 19.2 Tbit/s par puce, le superpod de 9 600 puces agrège 2 Po de mémoire HBM et 121 EFLOPS, et la topologie en tore 3D est conservée. Le tore est pertinent pour l'entraînement car les tâches de pointe sont dominées par des opérations collectives adaptées à l'architecture en anneau : des réductions globales pour le parallélisme de données et de tenseurs, des regroupements et des réductions-dispersions pour le FSDP, et des envois point à point parallèles au pipeline. Toutes ces opérations s'alignent parfaitement sur les axes du tore.

Google conserve également les SparseCores intégrés à chaque TPU depuis la version 4. Leur fonction initiale était de gérer les modèles de recommandation de type DLRM, où la majeure partie du temps de calcul est consacrée à des opérations de regroupement et de dispersion irrégulières sur d'immenses tables d'embeddings. Ce même matériel gère également le routage MoE. JAX expose les opérations « ragged all-to-all » et « ragged_dot » correspondantes comme des opérations de premier ordre, permettant à chaque puce d'envoyer un segment de taille différente à chaque pair. Ceci correspond à la structure réelle de la répartition MoE, car le routage top-k dépend des données et le nombre de jetons transmis à chaque expert varie à chaque étape. Le compilateur fusionne la communication irrégulière et la multiplication matricielle irrégulière des experts en une seule opération planifiée, tandis que le SparseCore gère le tri et la permutation environnants. L'architecture de type « mixing of experts » étant désormais dominante dans les modèles de pointe, ce matériel démontre sa valeur pour toutes les tâches d'entraînement modernes, et pas seulement pour les charges de travail publicitaires et de classement pour lesquelles il a été initialement conçu.

Il s'agit d'étapes évolutives. Les changements majeurs sont TPUDirect et le passage aux hôtes basés sur Axion, qui permettent tous deux de résoudre des problèmes de goulots d'étranglement qui ne deviennent visibles qu'à grande échelle.

TPUDirect RDMA et stockage TPUDirect

Les générations précédentes de TPU utilisaient un chemin d'accès réseau et de stockage via l'hôte : les paquets étaient d'abord stockés dans la DRAM de l'hôte, puis copiés dans la mémoire HBM du TPU par un DMA distinct. Cela impliquait deux transactions mémoire avec le processeur hôte. TPUDirect RDMA élimine ce tampon de rebond. La carte réseau lit et écrit directement dans la mémoire HBM du TPU via PCIe peer-to-peer, supprimant ainsi l'hôte du chemin de données. NVIDIA propose une fonctionnalité équivalente avec GPUDirect RDMA depuis des années et annonce une amélioration d'environ 10 fois par rapport au chemin d'accès via l'hôte. Google propose désormais une solution similaire pour les TPU.

TPUDirect Storage étend ce principe au stockage persistant. Les tenseurs sont transférés directement entre la mémoire HBM des TPU et Managed Lustre à un débit cumulé de 10 To/s, ce qui, selon Google, offre un accès au stockage 10 fois plus rapide que le chemin équivalent sur Ironwood. À grande échelle, lorsque les points de contrôle peuvent atteindre plusieurs centaines de téraoctets, la différence réside dans la capacité d'un entraînement de plusieurs semaines à traiter les points de contrôle et les ensembles de données à la vitesse de la ligne, ou à bloquer le pipeline MXU en attente d'E/S de l'hôte.

Hôtes Arm Axion

Chaque génération précédente de TPU fonctionnait sur des hôtes x86 tiers. La 8t est la première à utiliser le processeur Axion de Google, un CPU basé sur Arm Neoverse V2, comme processeur système. Le rôle du CPU hôte sur un pod TPU est crucial et se complexifie à grande échelle : il gère le pipeline d'entrée, décode et brasse des ensembles de données de plusieurs pétaoctets, gère le plan de contrôle JAX/XLA, assure la sérialisation des points de contrôle et coordonne la distribution SPMD sur des milliers de puces. En cas de blocage du CPU hôte, le MXU reste inactif.

Google met spécifiquement en avant l'isolation NUMA d'Axion sur la plateforme 8t comme mécanisme empêchant les fluctuations côté hôte de se répercuter sur les phases collectives synchronisées de l'entraînement. Avec 9 600 puces par pod, même de légères variations au niveau de chaque hôte entraînent une perte mesurable de débit utile. TPUDirect gère le chemin de données en excluant l'hôte des transferts de masse. Axion gère le chemin de contrôle en allouant à chaque TPU une bande passante CPU dédiée suffisante pour que le prétraitement ne devienne jamais un goulot d'étranglement. Google a également augmenté le nombre d'hôtes Axion physiques par serveur sur la plateforme de huitième génération, offrant ainsi à la surcharge d'orchestration, qui est proportionnelle au nombre de puces, une marge de manœuvre plus importante que celle offerte par la configuration hôte d'Ironwood.

TPU 8i « Poisson-zèbre »

La puce d'inférence partage la même plateforme hôte Axion que le 8t, le FP4 natif et la génération de mémoire HBM3e, mais le silicium sous-jacent cible un goulot d'étranglement différent. L'entraînement est limité par la puissance de calcul ; le décodage de l'inférence est limité par la bande passante mémoire. La plupart des différences architecturales du 8i en découlent.

Le changement majeur réside dans la SRAM intégrée. Le 8i embarque 384 Mo de mémoire virtuelle, soit trois fois plus que l'Ironwood. Ce gain est crucial pour le cache clé-valeur (KV). Lors du décodage à contexte long, chaque jeton généré nécessite la lecture des états clé-valeur accumulés des jetons précédents. Sur la plupart des accélérateurs, cette lecture s'effectue depuis la mémoire HBM, ce qui limite le débit de décodage à la bande passante mémoire plutôt qu'à la puissance de calcul. Le 8i est dimensionné pour intégrer une taille significative de cache KV entièrement sur silicium. La bande passante de la SRAM intégrée est environ dix fois supérieure à celle de la HBM ; ainsi, chaque lecture KV effectuée depuis la SRAM plutôt que depuis la HBM se traduit par une latence par jeton plus courte et un débit de jetons par seconde plus élevé à consommation énergétique égale.

La configuration TensorCore constitue l'autre différence majeure. Alors que le 8t utilise un seul TensorCore à 12.6 PFLOPS, le 8i répartit le calcul sur deux TensorCores pour une puissance combinée de 10.1 PFLOPS. Un débit de pointe inférieur peut sembler un inconvénient, mais il convient d'examiner le fonctionnement réel de l'inférence au niveau de la puce. Les charges de travail d'entraînement sont principalement basées sur le traitement par lots : les multiplications mathématiques importantes amortissent les coûts fixes, et une seule unité MXU de grande taille peut maintenir une utilisation proche du maximum. Le décodage d'inférence est l'inverse. La taille des lots est réduite, les fenêtres de calcul par jeton sont courtes, et la puce consacre une part importante de son temps aux opérations collectives, à l'échantillonnage et au routage plutôt qu'aux multiplications mathématiques pures. Un seul moteur de calcul de grande taille se bloque pendant ces intervalles irréguliers. La répartition sur deux TensorCores permet au 8i de chevaucher plus efficacement les phases de calcul, chaque TensorCore étant alimenté par ses quatre piles HBM directement connectées, totalisant 288 Go à 8.6 To/s pour l'ensemble du processeur. Il en résulte une utilisation plus soutenue pour les tailles de lots réellement utilisées en mode de service interactif.

Au niveau du domaine de montée en charge, les 1 024 puces actives d'un pod Boardfly totalisent environ 295 To de mémoire HBM, 384 Go de SRAM intégrée et une puissance de calcul FP4 de 10.3 EFLOPS. La capacité de SRAM est cruciale pour l'inférence : 384 Go de cache intégré suffisent à stocker un état KV conséquent sans solliciter la mémoire HBM, ce qui permet un service à contexte long avec une faible latence.

Le fonctionnement côté hôte suit la même logique. Google indique avoir augmenté le nombre d'hôtes Axion physiques par serveur sur 8i par rapport à Ironwood. Les serveurs d'inférence consacrent une part non négligeable du temps de traitement par jeton à la tokenisation, à la logique d'échantillonnage, au routage, au traitement par lots et à l'orchestration de l'exécution des agents. Ces surcharges augmentent avec la concurrence plutôt qu'avec la taille du modèle, et aux débits de requêtes générés par les charges de travail d'agents, l'hôte peut devenir le goulot d'étranglement. Augmenter la puissance de calcul de l'hôte par accélérateur est la solution la plus simple.

Moteur d'accélération des collectifs

L'autre changement majeur au niveau de la puce est le moteur d'accélération Collectives, qui remplace les quatre SparseCores présents sur l'Ironwood. Les SparseCores gèrent le routage MoE et les recherches d'intégration grâce à un matériel dédié de collecte et de diffusion ; leur suppression de la puce d'inférence indique que l'8i optimise un autre goulot d'étranglement.

Le principal goulot d'étranglement du CAE réside dans la latence collective. Chaque jeton décodé nécessite la synchronisation des puces participantes : les sorties d'attention doivent être réduites, les métadonnées de routage expert diffusées et les jetons échantillonnés propagés à l'étape suivante. Sur les GPU, cette coordination est logicielle et assurée par NCCL, qui planifie les collectifs sous forme de séquence de lancements de noyaux et d'opérations réseau. Sur 8i, le CAE est une puce dédiée, intégrée à sa propre puce aux côtés des TensorCores, et gère ces primitives de synchronisation matériellement.

Google revendique une latence collective sur puce jusqu'à 5 fois inférieure à celle d'Ironwood. Pour les lots d'entraînement, cette amélioration serait absorbée par le temps de calcul ; la latence collective ne représente qu'une petite fraction du temps de traitement. En revanche, pour les petits lots et les courtes fenêtres de traitement par jeton lors de l'inférence interactive, la latence collective peut devenir prépondérante par rapport au temps de traitement par jeton. La réduction d'un facteur 5 se traduit donc par une diminution du nombre de jetons par seconde et du prix par jeton.

8i abandonne également la topologie en tore 3D au profit de Boardfly, une topologie hiérarchique inspirée de Dragonfly, qui privilégie la latence globale à la bande passante collective. Nous examinerons Boardfly en détail ci-dessous.

Topologie Boardfly

8i utilise une topologie différente de celle de 8t car l'entraînement et l'inférence ont des modèles de communication différents.

Le tore 3D est idéal pour les opérations collectives en anneau : chaque puce a six voisines, les données circulent dans l’anneau et aucune puce ne traite un trafic arbitraire. L’entraînement est principalement basé sur ces modèles adaptés aux anneaux, ce qui explique pourquoi 8t conserve le tore. Une opération de réduction complète en anneau correspond parfaitement à un seul axe du tore. Les tâches de pointe répartissent généralement le parallélisme de données sur un axe, le parallélisme de tenseurs sur un autre et le parallélisme de pipelines sur le troisième. La topologie et la charge de travail sont ainsi parfaitement adaptées.

L'inférence au service d'un modèle MoE de grande envergure présente un profil de communication différent. Les experts sont répartis sur de nombreuses puces, et chaque jeton décodé déclenche une communication globale : les jetons doivent atteindre leurs experts assignés, dispersés sur le réseau, et les résultats des experts doivent être renvoyés. Il ne s'agit pas d'un réseau en anneau, mais d'un trafic point à point arbitraire. Sur un tore 3D de 1 024 puces, le chemin le plus long entre deux puces quelconques comporte 16 sauts. Google détaille ce calcul : « Dans un tore 3D, les nœuds sont disposés en grille, chaque dimension formant un anneau. Pour atteindre la puce la plus éloignée possible dans une configuration 8 × 8 × 16 (1 024 puces), un paquet doit parcourir la moitié de la distance de chaque anneau. »

Tore 3D = 8/2(X) + 8/2(Y) + 16/2(Z) = 16 sauts

Bien que le tore soit très efficace pour la communication de voisinage typique de l'apprentissage dense, il induit une latence pour les communications de type « tous à tous ». À l'ère des modèles de raisonnement et de l'Essai multi-éléments (MoE), où chaque puce peut avoir besoin de communiquer avec n'importe quelle autre pour acheminer un jeton, ce nombre de sauts devient crucial.

Pour les services interactifs sensibles à la latence, ces sauts supplémentaires repoussent la latence par jeton au-delà de son SLO.

Boardfly est une architecture hiérarchique inspirée de Dragonfly, conçue pour réduire le diamètre du réseau. Sa structure comporte trois niveaux. L'élément de base est un anneau de quatre puces doté de 16 connexions externes. Huit de ces éléments forment un groupe, entièrement interconnecté par câblage cuivre (11 liaisons par groupe). Trente-six groupes sont connectés par des commutateurs de circuits optiques pour former un pod. On obtient ainsi un domaine évolutif de 1 152 puces (1 024 actives) avec un maximum de 7 sauts entre deux puces, soit une réduction de 56 % par rapport au tore. Google affirme que cela permet d'améliorer la latence jusqu'à 50 % pour les charges de travail gourmandes en communication, comme les communications multi-processus (MoE).

L'augmentation de la capacité d'extension est également cruciale pour la réplication des experts. Un plus grand nombre de puces par infrastructure ICI permet de répliquer davantage chaque expert au sein d'un MoE étendu, ce qui atténue les déséquilibres de routage et maintient une latence de décodage constante malgré une distribution inégale des jetons. Le routage Top-k dépend des données ; certains experts verront plus de jetons que d'autres à chaque étape. La réplication absorbe cette variation. La bande passante ICI a été doublée pour atteindre 19.2 Tb/s par puce, notamment pour gérer le trafic généré.

Réseau Vierge

Un superpod de 9 600 puces est imposant, mais les entraînements de pointe nécessitent de plus en plus de ressources. Virgo est l'infrastructure d'extension horizontale qui connecte les superpods au sein d'un centre de données, gérant le trafic RDMA est-ouest entre les pods lorsqu'une tâche dépasse les capacités d'un seul domaine d'extension verticale.

Une seule infrastructure Virgo relie plus de 134,000 4 puces 8t à une bande passante bisectionnelle non bloquante de 47 Pb/s, soit jusqu'à quatre fois la bande passante par accélérateur et une latence à vide réduite de 40 % par rapport à la génération précédente. Son architecture repose sur une topologie plate à deux couches non bloquante, construite sur des commutateurs à haut degré de routage avec une conception multiplan et des domaines de contrôle indépendants.

Les architectures Clos traditionnelles surdimensionnent les niveaux supérieurs pour limiter le nombre de ports et les coûts. Cette approche fonctionne correctement lorsque la majeure partie du trafic est orientée nord-sud, comme c'est le cas dans le cloud généraliste : les clients accèdent aux équilibreurs de charge, qui à leur tour alimentent les serveurs d'applications, lesquels accèdent au stockage. Les charges de travail d'entraînement d'IA sont presque exclusivement orientées est-ouest, de puce à puce, à travers l'infrastructure, et les opérations collectives sont principalement basées sur la bisection. Toute sursouscription, quel que soit le niveau, impacte directement le temps d'entraînement. L'architecture plate à deux couches de Virgo, avec ses commutateurs à haut degré de puissance, élimine le goulot d'étranglement du niveau dorsal en concevant des commutateurs dotés d'un nombre suffisant de ports par ASIC pour terminer une fraction significative de l'infrastructure en deux sauts.

L'ingénierie de la fiabilité est cruciale à cette échelle et repose fortement sur les commutateurs de circuits optiques (OCS) MEMS de Google. L'OCS permet à Google de reconfigurer la topologie physique entre les tâches sans recâblage, et surtout, de contourner les puces ou les liaisons défaillantes en cours d'exécution. Lorsqu'une panne est détectée, l'OCS peut remapper la partie affectée du réseau en quelques millisecondes, éliminant ainsi le besoin d'intervention manuelle. La télémétrie, avec une résolution inférieure à la milliseconde, assure la détection automatique des processus lents et des blocages. La combinaison d'une détection rapide et d'un reroutage basé sur l'OCS optimise le temps moyen entre les interruptions et le temps moyen de récupération à l'échelle de plus de 100 000 puces, où la probabilité statistique d'une panne au cours d'une exécution de plusieurs semaines avoisine les 100 %. L'objectif de débit utile de 97 % annoncé par Google pour les pods 8t repose sur cette infrastructure. La même technologie OCS est présente dans toute la pile TPU : elle assemble les cubes en superpods au niveau de la couche ICI, connecte les groupes Boardfly au niveau de la couche de montée en charge 8i et gère le trafic inter-pods au niveau de la couche Virgo.

Avec 134 000 puces, la puissance de calcul agrégée atteint environ 1 690 EFLOPS en FP4, soit environ 1.7 ZFLOPS. Google indique que l'architecture prend en charge une mise à l'échelle quasi linéaire jusqu'à un million de puces dans un seul cluster d'entraînement logique, bien que les déploiements actuels n'aient pas encore atteint cette limite.

Échelle Jupiter et multi-centres de données

Virgo gère le trafic d'accélération est-ouest au sein d'un centre de données, mais ne constitue pas l'infrastructure de pointe. Jupiter, l'infrastructure nord-sud existante de Google, actuellement dans sa cinquième génération, gère le trafic frontal et l'accès aux ressources de stockage et de calcul distribuées. Jupiter n'a pas été annoncé lors de Cloud Next ; il s'agit de l'infrastructure existante sur laquelle repose la 8e génération.

La dernière version de Jupiter offre une bande passante bisectionnelle de 13 Pb/s par centre de données avec une disponibilité de 99.999 %, grâce à des commutateurs OCS MEMS Apollo consommant environ 108 W par OCS, contre environ 3 000 W pour un commutateur de paquets électrique équivalent. C'est cette infrastructure qui connecte les centres de données de Google au monde extérieur et entre eux.

Pour les entraînements dépassant les capacités d'un seul centre de données, Jupiter permet une mise à l'échelle sur plusieurs sites. L'architecture est composée de plusieurs couches : ICI au sein d'un pod, Virgo entre les pods d'un même site et Jupiter entre les sites. La suite logicielle Pathways de Google peut gérer les charges de travail sur ces environnements multi-centres de données comme un cluster logique unique.

Avec une puissance de calcul d'environ 1.7 ZFLOPS, un seul cluster Virgo représente le plus grand cluster d'entraînement d'IA jamais annoncé. Plusieurs clusters Virgo interconnectés par Jupiter peuvent gérer plus d'un million de puces TPU, soit l'échelle visée par Google, même si les déploiements actuels ne l'ont pas encore atteinte.

Débit utile et utilisation

La puissance de calcul brute (FLOPs) importe moins que la fraction de ces FLOPs qui produit un travail utile. Google annonce un objectif de débit utile de 97 % pour les superpods de 8 tonnes, ce qui signifie que 97 % du temps d'exécution est consacré au calcul productif plutôt qu'à la récupération, aux blocages ou à la surcharge de coordination. Ce taux dépend de la tolérance aux pannes basée sur OCS et de la télémétrie sub-milliseconde évoquée précédemment.

L'utilisation des FLOP du modèle (MFU) est l'autre variable. La MFU mesure la fraction des FLOP théoriques de pointe que la puce supporte réellement lors d'une charge de travail réelle. SemiAnalysis estime qu'à 40 % de MFU TPU, le coût par FLOP d'entraînement effectif diminue d'environ 62 % par rapport à GB300 NVL72, le seuil de rentabilité étant atteint à environ 15 % de MFU TPU. Les données économiques TPU publiées par Anthropic suggèrent un fonctionnement bien au-delà de ce seuil. La combinaison d'un débit utile élevé (garantissant le fonctionnement continu des puces) et d'une MFU compétitive (optimisant l'utilisation des puces en fonctionnement) est ce qui rend le coût total de possession (TCO) des TPU rentable à grande échelle.

Où 8 personnes s'assoient

Comparer la TPU 8 aux plateformes actuelles et futures de NVIDIA exige une attention particulière aux unités de mesure. NVIDIA indique la bande passante NVLink comme une bande passante agrégée bidirectionnelle ; une B200 à 1.8 To/s (NVLink 5) offre 900 Go/s par direction. Les performances FLOPs annoncées par NVIDIA correspondent généralement à un ratio de 2:4 pour les données éparses ; le ratio pour les données denses est deux fois plus élevé. Les chiffres de Google pour la TPU incluent les données denses et bidirectionnelles. Lors de toute comparaison, il est essentiel de vérifier si la bande passante est unidirectionnelle ou bidirectionnelle et si les performances FLOPs sont exprimées en données denses ou éparses.

 

La puissance de calcul FP4 par puce, 8t à 12.6 PFLOPS en mode dense, se situe entre les 10 PFLOPS en mode clairsemé (5 PFLOPS en mode dense) du GB200 et les 20 PFLOPS en mode clairsemé (15 PFLOPS en mode dense) du GB300. La comparaison par puce est pertinente. En revanche, la comparaison en termes d'échelle est différente. Un rack GB300 NVL72 embarque 72 GPU dans un seul domaine NVLink. Un superpod 8t est composé de 9 600 puces disposées dans un tore 3D. Cela représente 133 fois plus de puces dans un seul domaine collectif, ce qui constitue l'écart de performance entre les deux plateformes pour l'entraînement de nouvelles technologies.

NVIDIA ne reste pas inactive. La Vera Rubin sera disponible au second semestre 2026 avec 50 PFLOPS d'inférence NVFP4 par processeur (SemiAnalysis s'interrogeant toutefois sur la prise en compte de la compression adaptative dans ce chiffre), 288 Go de HBM4 à 22 To/s et NVLink 6 à 3.6 To/s bidirectionnel. La Rubin Ultra, prévue pour le second semestre 2027, combine quatre puces réticulaires pour atteindre jusqu'à 100 PFLOPS FP4 et 1 To de HBM4e par processeur. Le Kyber NVL576 permettra d'intégrer 576 GPU Rubin Ultra dans un seul rack, pour une inférence FP4 de 15 EFLOPS. Cela commence à réduire l'avantage de Google en matière d'évolutivité, même si 576 GPU restent nettement inférieurs à la capacité d'un superpod de 8 tonnes.

Où 8 mène : taille du domaine d'extension (9 600 puces contre 72 GPU, ou 576 après Kyber), échelle de tissu unique (plus de 134 000 puces à 47 Pb/s), latence déterministe de la planification XLA statique et TCO pour les charges de travail qui correspondent au modèle TPU.

Là où 8 pistes : capacité HBM par puce (216 Go contre 288 Go HBM4 pour Rubin), sparsité (NVIDIA dispose d'un chemin matériel 2:4, Google non), et étendue de l'écosystème (CUDA, cuDNN, TensorRT-LLM et la pile de service PyTorch débarquent d'abord sur NVIDIA ; PyTorch natif sur TPU est encore en avant-première).

Les deux plateformes connaissent une forte demande. Meta serait en pourparlers pour un contrat de plusieurs milliards de dollars visant à déployer des TPU Google dans ses centres de données dès 2027, avec la possibilité de louer des TPU Cloud dès 2026. Parallèlement, Google Cloud a annoncé des instances A5X basées sur NVIDIA Vera Rubin NVL72, pouvant atteindre 80 000 GPU Rubin sur un seul site et 960 000 GPU sur plusieurs sites. Google déploie ces deux technologies à grande échelle.

Emballer

La TPU de huitième génération est composée de deux puces au lieu d'une seule, conçue pour l'entraînement à grande échelle et l'inférence multi-agents actuels, plutôt que pour les charges de travail d'IA généralistes. La 8t permet une montée en charge jusqu'à 9 600 puces par superpod et une extension horizontale jusqu'à plus de 134 000 puces par architecture Virgo. La 8i remplace les SparseCores par du silicium à accélération collective et le tore 3D par Boardfly afin de répondre aux exigences de latence imposées par le déploiement à grande échelle de modèles multi-experts. La feuille de route de NVIDIA, avec Vera Rubin, Rubin Ultra et Kyber, réduira certains de ces écarts entre 2026 et 2027, mais l'avantage en matière de montée en charge persiste pour le moment. Pour les laboratoires de pointe exécutant des modèles multi-experts sur des centaines de milliers de puces, la 8 constitue une alternative crédible à Grace Blackwell, et les discussions de Meta suggèrent que le marché commence à intégrer cette caractéristique.