Google sort deux puces IA distinctes pour faire baisser la facture cloud : TPU 8t à 121 exaflops pour entraîner les modèles et TPU 8i à 384 Mo de SRAM pour les servir moins cher

Google dévoile une huitième génération de puces maison pour l’IA, avec une rupture claire: deux modèles distincts, TPU 8t pour l’entraînement et TPU 8i pour l’inférence.

La promesse est chiffrée, plus de puissance utile, moins de temps perdu, et une facture cloud qui doit baisser quand les clusters grossissent. Google annonce un saut d’échelle avec des superpods capables d’aligner 9 600 puces et d’atteindre 121 exaflops en FP4. Le contexte est simple, les modèles deviennent plus longs à entraîner, plus coûteux à servir, et les entreprises regardent la consommation électrique, la mémoire et les interruptions comme des postes de dépenses à part entière. Google met donc en avant des gains concrets, près de 3x la puissance de calcul par pod pour l’entraînement face à la génération précédente, et +80% de performance par dollar sur l’inférence. La disponibilité est annoncée pour plus tard en 2026.

Google sépare entraînement et inférence avec TPU 8t et TPU 8i

Jusqu’ici, la ligne TPU a longtemps cherché à couvrir deux mondes avec une même puce, entraîner de grands modèles et les faire tourner en production. Avec TPU 8t et TPU 8i, Google acte une spécialisation qui colle à la réalité des déploiements, les équipes training saturent la mémoire et le réseau, les équipes serving se battent contre la latence et le coût par requête. La séparation vise à optimiser chaque étape au lieu de viser un compromis.

Dans les usages, l’écart est concret. Un laboratoire qui entraîne un modèle de langage doit faire circuler des jeux de données massifs, écrire des checkpoints, et synchroniser des dizaines de milliers d’accélérateurs. À l’inverse, un service client automatisé qui répond en temps réel doit garder des caches proches du calcul et réduire les allers-retours mémoire. TPU 8i met précisément l’accent sur cette logique de service, quand TPU 8t vise la montée en charge et la tenue de charge.

Le discours de Google insiste aussi sur le fait que le coût ne dépend pas seulement du prix d’une puce, mais du temps productif d’un cluster. Quand un job s’arrête parce qu’un lien inter-puce flanche, la facture grimpe sans que le modèle avance. Google met donc en avant un objectif de 97% de “goodput”, c’est-à-dire du calcul utile, pas du calcul bloqué par des pannes, des goulots d’étranglement ou des redémarrages.

Marc, architecte cloud dans une grande entreprise de services, résume l’intérêt avec des mots simples, on ne paie pas l’exaflop théorique, on paie les heures de cluster qui tournent et les équipes qui attendent. Il ajoute une nuance, la spécialisation est séduisante, mais elle oblige aussi à bien choisir selon les charges, sinon on se retrouve à provisionner deux types d’infra et à complexifier l’exploitation. Le pari de Google Cloud est que les gains d’efficacité compensent cette complexité.

TPU 8t vise 121 exaflops et des pods à 9 600 puces

Sur l’entraînement, TPU 8t est présenté comme le moteur des très gros clusters. Google décrit un superpod qui peut monter à 9 600 puces et délivrer 121 exaflops de calcul FP4. Le point clé n’est pas seulement le chiffre, mais la capacité à maintenir les puces occupées en continu. Dans un entraînement moderne, le calcul attend souvent la donnée, la synchronisation, ou la reprise après incident.

Google annonce un saut de performance, près de 3x la puissance de calcul par pod face à la génération Ironwood, et un gain de 2x en performance par watt selon les caractéristiques détaillées. La puce affiche 216 Go de HBM, une bande passante HBM de 6 500 Go/s et 128 Mo de SRAM embarquée. Sur le papier, cela vise à réduire les blocages liés aux accès mémoire pendant les phases intensives.

Un autre point technique vise les charges d’entraînement qui ne se résument pas à des multiplications de matrices. Google introduit SparseCore, un accélérateur destiné aux accès mémoire irréguliers, typiques des recherches d’embeddings et de certaines opérations collectives. L’objectif affiché est d’éviter des zero-op bottlenecks, des moments où le calcul tourne à vide faute de données prêtes. Pour des équipes qui entraînent des modèles multimodaux, ce type de détail peut se traduire par des heures gagnées sur des runs longs.

La promesse de goodput revient ici comme un argument commercial autant qu’ingénierie. Amin Vahdat, cadre de Google sur l’IA et l’infrastructure, insiste sur la coordination à l’échelle de la nanoseconde et sur un fait brut, si un composant lâche, un job peut s’arrêter. Google met en avant des mécanismes automatiques de détection et de contournement de liens ICI défaillants, avec reconfiguration sans intervention humaine. Pour les clients, l’enjeu est de réduire les jours perdus sur un entraînement qui s’étire.

TPU 8i mise sur 384 Mo de SRAM pour réduire la latence

Pour l’inférence, TPU 8i vise le coût par requête et la rapidité de réponse. Google annonce +80% de performance par dollar par rapport à Ironwood. Le chiffre parle aux équipes produit, car la facture d’un assistant IA en production dépend du nombre de requêtes, de la longueur des contextes et du taux de cache. Si l’inférence coûte trop cher, le service est bridé, ou l’entreprise répercute le coût sur ses clients.

Le choix architectural mis en avant concerne la mémoire sur puce. TPU 8i embarque 384 Mo de SRAM, soit trois fois plus que la génération précédente. L’intérêt est très concret pour les grands modèles, garder un KV cache plus gros au plus près du calcul, ce qui limite les accès à la mémoire externe et accélère les réponses quand le contexte s’allonge. Google annonce aussi 288 Go de HBM et 8 600 Go/s de bande passante HBM, des chiffres orientés débit.

En capacité de calcul, Google communique 10,1 petaflops FP4 de pic pour TPU 8i. Ce n’est pas uniquement un concours de téraflops, car l’inférence dépend de la stabilité de latence et de la façon dont la mémoire alimente les unités de calcul. Sur des usages comme les agents logiciels qui enchaînent des appels, la variabilité de latence devient un problème visible côté utilisateur, pages qui chargent lentement, réponses qui arrivent en plusieurs secondes, ou timeouts.

Claire, responsable d’une équipe qui déploie des modèles conversationnels, explique le point de douleur, notre coût explose dès qu’on augmente la fenêtre de contexte, parce que le cache grandit et la mémoire devient le goulot. Elle voit dans la SRAM un levier, mais ajoute une critique, les chiffres sont donnés face à Ironwood, pas face aux alternatives du marché, donc on attendra des tests en conditions réelles. C’est aussi le choix de Google, communiquer sur l’efficacité interne plutôt que sur un duel frontal.

Réseau, stockage Rapid Storage et “goodput” au centre du design

Google insiste sur un point souvent invisible dans les annonces de puces, le système compte autant que le silicium. Sur TPU 8t, l’entreprise met en avant des améliorations de stockage et de réseau pour éviter que les accélérateurs attendent les données. Le vocabulaire est révélateur, garder les puces busy au lieu de bloquer sur des transferts. Dans un entraînement, un pipeline de données mal dimensionné peut annuler une partie des gains de calcul.

Sur le stockage, Google met en avant Rapid Storage, basé sur le système de fichiers Colossus, avec des transferts annoncés jusqu’à 15 To/s vers des systèmes GPU ou TPU, contre 6 To/s auparavant. Google mentionne aussi une capacité à servir 20 millions de requêtes par seconde avec une latence sous la milliseconde dans cette configuration. Pour les équipes ML, cela compte au moment de charger des datasets et surtout lors des checkpoints, quand un modèle écrit régulièrement son état.

La notion de “goodput” revient comme une métrique qui parle aux directeurs financiers autant qu’aux SRE. Google vise plus de 97% de temps de calcul productif, en réduisant les arrêts liés aux pannes et aux goulots. Dans des clusters de dizaines de milliers de puces, selon les propos de Google, une petite panne devient statistiquement fréquente. L’idée est de rerouter automatiquement autour de liens défaillants, sans stopper le job, et de reconfigurer le matériel de façon autonome.

Il y a tout de même une nuance à garder en tête, ces gains supposent une intégration serrée dans la pile Google. Les bénéfices de Rapid Storage et des mécanismes d’auto-réparation se voient surtout quand le client adopte l’architecture recommandée, plutôt que d’assembler des briques hétérogènes. Marc le formule sans détour, c’est puissant, mais ça te verrouille dans une façon de faire. Pour des entreprises qui veulent éviter une dépendance trop forte à un fournisseur, ce point pèsera dans les arbitrages.

Google Cloud Next 2026: une pression accrue sur Nvidia et les coûts IA

L’annonce intervient dans une bataille de fond, l’infrastructure IA est largement dominée par Nvidia, et aucun acteur ne le déloge à court terme. Google ne cherche d’ailleurs pas à afficher une comparaison directe de performances avec le leader. La stratégie est plus prudente, mettre en avant des gains par rapport à sa propre génération précédente, et proposer une alternative crédible aux clients qui veulent diversifier leurs accélérateurs. Les TPU ont déjà servi en interne, notamment pour Gemini, et Google veut étendre cette base.

Le découpage training et inference répond aussi à l’essor des agents IA, ces systèmes qui planifient, appellent des outils, et tournent en continu. Amin Vahdat explique que la communauté bénéficierait de puces spécialisées pour l’entraînement et le service. Dans la pratique, cela peut permettre à une entreprise de réserver des pools TPU 8t pour entraîner ou affiner des modèles, et des pools TPU 8i pour servir des milliers de requêtes par seconde, avec une logique de coûts distincte.

Un autre choix technique mis en avant touche au CPU hôte. Les TPU 8 s’appuient sur le CPU ARM maison Axion, avec un ratio annoncé d’un CPU pour deux TPU, alors qu’Ironwood utilisait un CPU x86 pour quatre TPU. Google présente cette approche full-stack comme un levier d’efficacité. Pour les clients, cela signifie que l’optimisation se fait à plusieurs niveaux, CPU, interconnect, mémoire, stockage, et pas seulement sur l’accélérateur. L’intérêt est une meilleure cohérence, le risque est un écosystème plus spécifique.

Sur le calendrier, Google annonce une disponibilité plus tard en 2026. D’ici là, la question sera la tarification réelle et la facilité d’accès, car une puce efficace ne suffit pas si les quotas cloud, les outils et les chaînes de déploiement ne suivent pas. Claire anticipe déjà le sujet, si le prix par token baisse vraiment, on peut ouvrir des fonctionnalités qu’on garde aujourd’hui derrière un paywall. Dans le même temps, elle prévient, si l’accès est limité, on restera sur ce qu’on a. Entre promesse technologique et réalité commerciale, la marge est souvent là.