TPU 8t et TPU 8i : Google bifurque son infrastructure IA pour l’ère agentique

Le 23 avril 2026, lors de Google Cloud Next, Google a annoncé sa huitième génération de puces TPU en rompant avec la tradition d’une architecture unifiée. Pour la première fois, deux designs distincts coexistent : la TPU 8t, conçue pour l’entraînement à grande échelle, et la TPU 8i, optimisée pour l’inférence à faible latence. Ce choix architectural n’est pas anecdotique : il reflète une bifurcation profonde des usages et des contraintes propres aux modèles de nouvelle génération, notamment les agents IA qui doivent à la fois apprendre et répondre en temps réel.

Pour les entreprises qui entraînent ou déploient des LLM, cette distinction change concrètement les arbitrages FinOps, les choix d’architecture cloud et l’efficacité des pipelines ML. Voici ce que cette annonce implique.

Deux puces, deux philosophies d’architecture

La rupture entre TPU 8t et TPU 8i n’est pas qu’une décision marketing. Elle traduit la reconnaissance d’une réalité technique : les besoins de l’entraînement et de l’inférence sont fondamentalement antagonistes.

L’entraînement exige un débit brut maximal sur des batches massifs, une cohérence mémoire à très grande échelle et une tolérance aux latences de communication inter-puces. L’inférence, à l’inverse, est sensible à la latence de réponse, mobilise des contextes longs et génère des patterns de communication all-to-all entre tokens qui saturent rapidement les interconnects classiques.

La TPU 8t est construite autour d’un interconnect 3D torus éprouvé, adapté aux superpods de grande taille. Elle dispose de 216 Go de HBM par puce et d’un SRAM on-chip de 128 Mo. Sa force réside dans sa capacité à monter en échelle de façon quasi linéaire : un superpod assemble jusqu’à 9 600 puces, délivrant 121 ExaFLOPs en FP4 et 2 pétaoctets de mémoire partagée. Le réseau Virgo, qui relie jusqu’à 134 000 puces, porte la performance totale d’un cluster d’entraînement à 1,6 million d’ExaFLOPs. (Source : Google Cloud Blog)

La TPU 8i adopte une logique radicalement différente. Avec 288 Go de HBM et surtout 384 Mo de SRAM on-chip — soit trois fois plus que la génération précédente — elle est conçue pour maintenir en cache les poids des modèles les plus lourds et réduire les allers-retours mémoire lors de l’inférence. Sa topologie réseau Boardfly remplace la structure 3D torus par un graphe qui réduit le diamètre réseau de 16 à 7 sauts, soit une réduction de 56 % de la latence de communication entre puces. (Source : Google Blog)

Les gains concrets par rapport à la génération précédente

Google compare ses nouvelles puces à la génération Ironwood (TPU 7), annoncée un an plus tôt et déjà considérée comme une avancée majeure pour l’inférence.

• TPU 8t : 2,7× meilleur rapport performance/prix pour l’entraînement par rapport à Ironwood ; bande passante inter-chip doublée ; accès au stockage 10× plus rapide via TPUDirect Storage (accès direct entre HBM et NIC, sans passer par le CPU hôte).
• TPU 8i : 80 % de performance supplémentaire par dollar pour l’inférence ; latence des opérations collectives réduite de 5× grâce au Collectives Acceleration Engine (CAE), qui agrège les résultats entre cores avec une latence quasi nulle.
• Les deux puces : efficacité énergétique jusqu’à 2× meilleure par watt par rapport à Ironwood, et hébergées sur des CPU hôtes ARM Axion développés par Google.

Ces chiffres placent les TPU de 8e génération dans une catégorie à part pour les workloads d’IA à très grande échelle, à condition que les entreprises disposent déjà d’une maturité suffisante pour exploiter JAX, PyTorch natif, vLLM ou SGLang dans un environnement Google Cloud. (Source : Google Cloud Blog — Technical Deep Dive)

L’enjeu agentique : pourquoi cette architecture arrive maintenant

La bifurcation entre les deux puces répond directement à la montée en puissance des agents IA. Un agent n’est plus un simple pipeline de traitement séquentiel : il planifie, raisonne sur des contextes longs, exécute des actions en parallèle et interagit avec d’autres agents. Cela crée deux charges computationnelles très distinctes qui coexistent dans la même infrastructure.

D’un côté, les world models — comme Genie 3 de Google DeepMind — nécessitent des cycles d’entraînement massifs sur des simulations où des millions d’agents apprennent par imagination plutôt que par essai-erreur direct sur le monde réel. C’est le terrain de la TPU 8t, avec ses superpods capables d’absorber ce type d’entraînement distribué à très grande échelle.

De l’autre, le serving de ces agents en production — répondre en quelques dizaines de millisecondes à des requêtes complexes impliquant des fenêtres de contexte de centaines de milliers de tokens — est le domaine de la TPU 8i. La SRAM de 384 Mo réduit les accès HBM lors de l’inférence sur des modèles à très grande fenêtre de contexte, ce qui se traduit directement en latence perçue par l’utilisateur final.

Google précise que les deux puces seront fabriquées sur le procédé 2 nm de TSMC, dont la disponibilité est attendue pour fin 2027. La disponibilité générale des deux puces dans Google Cloud est prévue pour plus tard en 2026, selon des modalités d’accès progressif. (Source : Google Blog)

Ce que cela change pour les entreprises

Cette annonce a des implications directes sur trois dimensions décisionnelles :

1. Architecture LLMOps et choix de stack

La distinction entraînement/inférence n’est plus seulement une question de sizing de cluster : elle devient un choix d’architecture matérielle. Les équipes qui gèrent des pipelines ML complets — de la phase de fine-tuning au serving en production — devront penser deux environnements distincts, potentiellement avec des contrats et des configurations différentes. Cela renforce la pertinence des approches hybrides, où l’entraînement tourne sur des superpods TPU 8t et le serving est assuré par des pods TPU 8i dédiés à la latence.

2. FinOps et optimisation des coûts d’inférence

Le gain de 80 % de performance par dollar sur la TPU 8i est structurellement important pour les entreprises dont le coût dominant est l’inférence — c’est-à-dire la quasi-totalité des organisations qui déploient des assistants IA, des agents conversationnels ou des systèmes de recommandation basés sur des LLM. Cette amélioration permet soit de réduire les coûts à volume constant, soit d’augmenter le volume servi à budget constant. Dans un contexte où les charges d’inférence explosent avec la multiplication des agents, c’est un levier FinOps direct.

L’amélioration de l’efficacité énergétique (2× par watt) a également un impact sur le coût total de possession pour les organisations qui opèrent leurs propres datacenters ou négocient des contrats cloud à long terme incluant des composantes liées à la consommation électrique.

3. Observabilité et goodput

Google annonce que la TPU 8t vise un taux de goodput supérieur à 97 % — c’est-à-dire la proportion du temps de calcul effectivement consacré au travail utile, par opposition aux pauses liées aux interruptions matérielles, aux synchronisations ou aux rechargements mémoire. Ce chiffre est particulièrement significatif pour les équipes qui mesurent l’utilisation effective de leur infrastructure et cherchent à réduire le gaspillage computationnel dans leurs pipelines d’entraînement distribué.

Mise à jour Méthode Virtuose

La bifurcation TPU 8t / TPU 8i illustre un principe que nous défendons dans la Méthode Virtuose : optimiser par usage, pas par défaut. De même qu’il n’existe pas de modèle IA universel adapté à toutes les tâches — et qu’il convient de choisir un modèle selon la nature de la requête, son volume et ses contraintes de latence — il n’existe pas d’infrastructure IA universelle. Les décisions d’architecture doivent suivre les contraintes réelles de chaque maillon de la chaîne : entraîner, affiner, inférer. Cette logique s’applique aussi bien au choix des puces qu’au design des pipelines de production IA dans les organisations.

La vraie question posée par l’annonce de Google n’est pas technique : c’est celle de la maturité organisationnelle. Seules les entreprises qui ont déjà segmenté leurs charges computationnelles — et qui disposent d’équipes capables de piloter deux environnements distincts — pourront tirer parti de cette bifurcation. Pour les autres, c’est le signal qu’il est temps de structurer cette distinction avant que la prochaine génération de puces ne la rende incontournable.