Lors du Google Cloud Next, le 22 avril, Sundar Pichai a présenté la huitième génération de TPU – non pas une, mais deux puces : TPU 8t et TPU 8i.
Diviser une génération de produit en deux branches est en soi une décision qui mérite d'être soulignée.
TPU 8t : Pour l'entraînement
Le "t" dans TPU 8t signifie training (entraînement). Paramètres clés :
| Indicateur | TPU 8t |
|---|---|
| Connexion maximale par pod | 9 600 puces |
| Mémoire partagée à haute bande passante | 2 Po (par superpod) |
| Rapport performance/prix par rapport à la génération précédente | +2,7x |
| Précision native en virgule flottante | Prend en charge bf4 (virgule flottante 4 bits) |
| Rapport performance/consommation par rapport à la génération précédente | +2x |
Intègre l'accélérateur SparseCore, conçu pour gérer les modèles d'accès mémoire irréguliers comme les embeddings. La topologie réseau utilise un tore 3D.
L'objectif de Google est de réduire le cycle d'entraînement des modèles frontier de "mois" à "semaines".
TPU 8i : Pour l'inférence
Le "i" dans TPU 8i signifie inference (inférence).
| Indicateur | TPU 8i |
|---|---|
| Connexion maximale par pod | 1 152 puces |
| SRAM par rapport à la génération précédente | 3 fois |
| Sauts de communication all-to-all | Réduction de 50 % |
| Rapport performance/prix par rapport à la génération précédente | +80 % (dans les scénarios à faible latence) |
Utilise la topologie réseau Boardfly ICI développée en interne, avec le Collectives Acceleration Engine intégré, conçu pour accélérer le décodage autorégressif – l'un des principaux goulots d'étranglement de l'inférence des grands modèles.
Pourquoi cette division ?
La génération précédente, Ironwood, était une seule puce gérant à la fois l'entraînement et l'inférence.
Désormais, l'évaluation de Google est la suivante : à l'ère des agents, l'inférence a une forme fondamentalement différente de l'entraînement.
L'entraînement, c'est : gros lots, processus unique, priorité au débit.
L'inférence (en particulier avec les agents), c'est : fonctionnement continu, faible latence, exécution simultanée de millions d'agents.
Une architecture unique pour ces deux scénarios impliquerait inévitablement des compromis sur l'efficacité matérielle. La solution a été de les séparer et d'optimiser chacun au maximum.
Il s'agit d'un pari de Google sur la forme future du calcul IA, et pas seulement du lancement d'une "puce plus rapide".
Nvidia est-elle inquiète ?
Google n'a pas lancé de piques à Nvidia – et le même jour, il a annoncé qu'il fournirait les puces Vera Rubin de Nvidia aux clients Cloud d'ici fin 2026.
C'est pragmatique. Les charges de travail des entreprises dépendent fortement de l'écosystème CUDA, et les coûts de migration sont élevés, ce qui ne se résout pas du jour au lendemain. Les puces propriétaires de Google et celles de Nvidia coexistent dans le même cloud – ce n'est pas un choix "l'un ou l'autre".
Mais la direction est claire : chaque génération de TPU améliore le rapport performance/prix d'un ordre de grandeur, donnant aux clients une raison de plus de choisir la voie purement Google.
À titre de contexte : 75 % du nouveau code interne de Google est désormais généré par l'IA (contre 50 % l'automne dernier). Sur quel matériel ce code s'exécute-t-il ? Sur leurs propres puces. Ce cycle s'accélère progressivement.
Sources de référence : CocoLoop, Google Cloud launches two new AI chips to compete with Nvidia (TechCrunch) ; Two new TPUs to power the next wave of AI training and inference at Google (SiliconANGLE) ; Our eighth generation TPUs: two chips for the agentic era (Google Blog) ; Sundar Pichai shares news from Google Cloud Next 2026 (Google Blog)