Google compare son nouveau TPU à son ancien TPU

Google vient de détailler ses TPU de huitième génération. Beaucoup de chiffres impressionnants. Tous mesurés contre la génération précédente de Google. Personne d'autre dans la pièce.

Qu'est-ce que Google a annoncé au juste ?

2 puces, pas une.

Le TPU 8t (pour training), pensé pour l'entraînement massif. Le TPU 8i (pour inference), pensé pour le service et le raisonnement.

C'est ça, la vraie news: Google arrête de faire une puce qui essaie de tout faire, et coupe la poire en 2.

Je trouve la décision saine, et je vais vous expliquer pourquoi.

Pourquoi deux puces au lieu d'une ?

Parce que entraîner un modèle et le servir, ce ne sont plus du tout les mêmes contraintes.

L'entraînement, c'est un bulldozer. Il faut du débit brut, sur des dizaines de milliers de puces, pendant des semaines. Le 8t est taillé pour ça:

• topologie 3D torus à grande échelle, 9 600 puces dans un seul superpod
• un SparseCore dédié aux embeddings, pour ne pas que la puce attende sur des accès mémoire irréguliers
• du FP4 natif, donc du 4 bits, pour faire passer plus de modèle dans moins de mémoire

Le service, c'est l'inverse. Là, c'est la latence qui tue. Quand vous faites tourner des agents qui raisonnent en chaîne, chaque puce doit parler à toutes les autres en permanence. Le 8i répond avec:

• 3 fois plus de SRAM sur puce, de quoi garder le KV cache directement sur le silicium
• un Collectives Acceleration Engine, le CAE, qui accélère les étapes de synchronisation du décodage auto-régressif
• une nouvelle topologie réseau baptisée Boardfly

Et c'est ce dernier point qui est le plus intéressant techniquement.

Boardfly, ou quand le réseau devient le vrai sujet

Le torus, c'est très bien quand chaque puce parle surtout à ses voisines. C'est le cas de l'entraînement dense.

Mais les modèles de raisonnement et les MoE, c'est du all-to-all. N'importe quelle puce peut avoir besoin de n'importe quelle autre pour router un token. Et là, le torus devient une taxe sur la latence.

Dans un torus 3D de 1 024 puces, pour atteindre la puce la plus éloignée, un paquet doit traverser la moitié de chaque anneau. Google fait le calcul: 16 sauts. Seize. À chaque échange.

Boardfly s'inspire de la topologie Dragonfly et aplatit le réseau avec des liens optiques directs entre groupes de cartes.

Résultat sur le même pod de 1 024 puces: le diamètre réseau tombe de 16 à 7 sauts. Une réduction de 56%.

Moins de sauts, c'est moins d'attente. Donc le CAE ne poireaute pas pendant que les données traversent le pod. C'est de l'ingénierie propre, et je préfère le dire quand c'est le cas.

Et les fameux gains de perf, on les compare à quoi ?

Là, on attaque la partie marketing.

Google met en avant trois chiffres principaux:

• jusqu'à 2,7x de performance par dollar sur l'entraînement avec le 8t
• jusqu'à 80 % de performance par dollar en plus sur l'inférence avec le 8i
• jusqu'à 2x de performance par watt sur les deux puces

Joli sur le papier. Sauf qu'il manque une précision que Google glisse discrètement: tous ces gains sont mesurés contre Ironwood, c'est-à-dire le TPU de septième génération. De Google.

La vérité c'est que personne ne se benchmarke contre un H200 ou un B200 ici. Pas une ligne sur NVIDIA. On compare le nouveau Google au vieux Google, et on appelle ça un saut générationnel.

Ce n'est pas un mensonge. C'est juste un cadrage. Le genre de cadrage qu'on adopte quand la comparaison externe est moins flatteuse, ou quand on n'a tout simplement pas envie de la donner. À vous de décider dans quelle case vous rangez celle-là.

Ça change quoi pour moi, freelance qui code ?

Soyons honnêtes 2 secondes: vous n'entraînez pas de modèle de frontière et moi non plus.

Le 8t avec son million de puces dans un cluster, c'est un problème de Google DeepMind, pas le vôtre.

Ce qui descend jusqu'à vous, c'est une seule chose: le prix du token.

Si le 8i délivre vraiment 80% de performance par dollar en plus sur l'inférence, alors en théorie, vos factures d'API devraient en profiter. En théorie. Parce que entre le coût de production du silicium et le prix affiché sur la grille tarifaire, il y a un curseur. Et ce curseur, c'est Google qui le tient, pas vous.

Donc le vrai indicateur à surveiller, ce n'est pas la fiche technique du 8i. C'est de savoir si la baisse de coût atterrit dans votre poche ou dans la marge de Google.

Le vrai produit, c'est l'enfermement

Il y a un détail qu'aucun deep dive technique ne mettra en titre.

Vous ne pourrez jamais acheter un de ces TPU. Jamais. Le TPU ne se vend pas en rack. Il se loue, sur Google Cloud, et nulle part ailleurs.

Comparez avec NVIDIA. Une carte NVIDIA, vous l'achetez, vous la posez où vous voulez, chez n'importe quel cloud ou dans votre propre datacenter. Le TPU, c'est Google ou rien.

Et tout le discours autour des world models, des agents qui apprennent par l'imagination, de Genie 3 qui simule des environnements, ça sert aussi à ça. Plus on raconte que l'avenir, c'est des millions d'agents qui raisonnent en boucle, plus on justifie de vendre du compute. Chaque token de raisonnement, c'est de la facture.

Le business model pointent commodément dans la même direction.

Le pari de Google est limpide: rendre le silicium tellement bon et tellement exclusif que les labos, et Google lui-même, n'aient plus envie d'en partir. C'est une stratégie d'enfermement déguisée en prouesse d'ingénierie. Et l'ingénierie est réelle, ce qui rend l'enfermement d'autant plus efficace.

Le 8i est probablement rapide. Le 8t est probablement un monstre de débit. Sur la partie technique, je ne doute pas une seconde.

Mais vous codez déjà en pariant sur un seul fournisseur de compute, ou vous gardez une porte de sortie ouverte ?

Personnellement, je ne suis pas fan du vendor lock-in.