Google TPU 8t/8i : L’Architecture Double Puce qui Refaçonne le Calcul IA Enterprise en 2026

Pourquoi Google a Divisé la Huitième Génération en Deux Puces

Le TPU Ironwood de septième génération de Google était un accélérateur polyvalent conçu pour gérer à la fois l’entraînement de modèles et l’inférence sur une seule architecture. À Google Cloud Next 2026 en avril, Google a annoncé que la huitième génération abandonne totalement cette approche. Le TPU 8t est conçu spécifiquement pour l’entraînement de modèles à grande échelle. Le TPU 8i est conçu spécifiquement pour l’inférence à faible latence et haute concurrence. Les deux puces partagent des en-têtes CPU Arm Axion et la pile logicielle Google Cloud — mais leurs architectures internes sont fondamentalement différentes, optimisées pour des patterns computationnels fondamentalement différents.

Cette bifurcation reflète une inflexion de maturité dans le marché IA enterprise. L’entraînement et l’inférence ne sont pas seulement différents en échelle — ils sont différents dans leur caractère computationnel. L’entraînement exige un débit soutenu maximal sur des milliers de puces en communication synchronisée : le goulot d’étranglement est la bande passante inter-puce et la bande passante mémoire pour les lookups d’embeddings. L’inférence exige une latence minimale pour les requêtes individuelles à haute concurrence : le goulot d’étranglement est la taille du cache KV (qui détermine la capacité de la fenêtre de contexte) et la vitesse des opérations collectives.

L’analyse du Register sur l’annonce décrit la division comme « Google sur deux voies TPU 8 pour conquérir l’entraînement et l’inférence » — un cadrage qui capture l’intention compétitive : Google ne construit pas seulement du meilleur silicon IA, il construit une fosse d’infrastructure IA plus défendable.

TPU 8t : Ce que 9 600 Puces dans un Pod Permettent Réellement

Le superpod TPU 8t contient 9 600 puces connectées via la topologie réseau 3D torus de Google, livrant 121 exaflops de calcul et 2 pétaoctets de mémoire HBM partagée. Selon la plongée technique de Google, chaque puce porte 216 Go de HBM à une bande passante de 6 528 Go/s.

Deux fonctionnalités définissent ce que le 8t permet que les générations précédentes ne pouvaient pas. D’abord, SparseCore : un accélérateur dédié pour les patterns d’accès mémoire irréguliers des lookups d’embeddings dans les grands modèles de langage. Ensuite, le FP4 natif : le floating point à 4 bits double le débit MXU tout en maintenant la précision du modèle pour les runs de pré-entraînement. La combinaison produit une amélioration de 2,7x performance-par-dollar sur Ironwood pour l’entraînement à grande échelle.

Au niveau du cluster, le tissu réseau Virgo de Google connecte 134 000 puces TPU 8t dans un tissu non bloquant unique dans un seul centre de données, et s’étend à plus d’un million de TPUs sur des sites distribués. TPUDirect Storage fournit un accès au stockage 10x plus rapide que sur Ironwood en permettant un accès mémoire direct entre les puces TPU et le stockage Managed Lustre de Google.

TPU 8i : L’Architecture d’Inférence Construite pour les Charges de Travail Agentiques

Le TPU 8i fait un ensemble différent de compromis. Son HBM par puce est de 288 Go — 33 % de plus que le 8t — et sa SRAM on-chip est de 384 Mo, soit trois fois plus que la génération précédente. Cette expansion de SRAM est la décision architecturale centrale : elle permet au cache KV pour l’inférence à contexte long de résider entièrement sur le silicon, éliminant la latence d’accès HBM qui limite la vitesse de réponse dans les déploiements d’inférence actuels.

La deuxième innovation majeure est la topologie réseau Boardfly. Les réseaux 3D torus traditionnels ont un diamètre réseau maximum de 16 sauts pour une configuration de 1 024 puces. Boardfly réduit cela à 7 sauts maximum, coupant le diamètre réseau de 56 %. Le Collectives Acceleration Engine (CAE) réduit la latence on-chip des opérations collectives de 5x. Combiné, le TPU 8i livre une amélioration de 80 % performance-par-dollar sur Ironwood pour les grands modèles MoE à objectifs de faible latence.

Ce que les DIT Enterprise Doivent Faire avec Cette Information

1. Auditer Votre Mix Actuel de Charges de Travail IA et Segmenter en Entraînement vs. Inférence Avant Votre Prochain Renouvellement de Contrat Cloud

La division TPU 8t/8i crée une décision commerciale qui n’existait pas avec les déploiements GPU polyvalents ou Ironwood : les équipes enterprise choisissent maintenant différents silicons pour différents types de charges de travail, avec des profils de prix et de disponibilité différents. Avant de renouveler les contrats AI Google Cloud, auditez votre portefeuille de charges de travail IA par caractère computationnel. Les charges de travail exécutant moins de 50 runs d’entraînement par mois avec un trafic d’inférence en production important devraient déplacer la capacité d’inférence vers des réservations TPU 8i. Les charges de travail exécutant du fine-tuning continu ou du pré-entraînement à grande échelle devraient prioriser l’accès au superpod TPU 8t.

2. Reconfigurer les Modèles de Budget IA Agentique pour Tenir Compte des Pics d’Inférence — les Pods TPU 8i Verront des Hausses d’Utilisation de 4 à 8x Pendant les Flux de Travail Agents

Les charges de travail IA agentiques — raisonnement multi-étapes, chaînes d’utilisation d’outils, analyse de documents à contexte long — génèrent des patterns de trafic d’inférence fondamentalement différents des modèles de requêtes simples. Un agent de révision juridique traitant un contrat de 200 pages peut invoquer le modèle 40 à 80 fois par document dans une séquence de raisonnement en chaîne de pensée. Sur la tarification d’inférence à la demande traditionnelle, cela génère des pics de coûts de 4 à 8 fois le coût équivalent par requête unique par document traité. Les réservations TPU 8i avec des contrats de débit engagé fournissent une prévisibilité des coûts pour les flux de travail agentiques que la tarification à la demande ne peut pas offrir.

3. Évaluer la Pile JAX/Pathways de Google vs. la Compatibilité PyTorch Avant de S’Engager sur TPU 8t pour l’Entraînement

Le TPU 8t livre son amélioration de 2,7x performance-par-dollar dans la pile logicielle JAX et Pathways de Google. Le support PyTorch natif est actuellement en préversion — pas en disponibilité générale. Les équipes enterprise avec des pipelines d’entraînement PyTorch existants qui évaluent le TPU 8t pour l’efficacité des coûts doivent évaluer le coût de migration : JAX n’est pas un remplacement direct de PyTorch, et la réécriture des pipelines d’entraînement à grande échelle est un projet d’ingénierie de 2 à 6 mois selon la complexité du modèle.

Le Tableau d’Ensemble : La Fin du Silicon IA Polyvalent

L’annonce TPU 8t/8i est architecturalement significative au-delà de la gamme de produits de Google. Elle signale que les principaux fournisseurs d’infrastructure IA ont conclu que le silicon polyvalent — les puces conçues pour être adéquates à la fois pour l’entraînement et l’inférence — laisse trop de performance et d’efficacité sur la table à l’échelle où le calcul IA est économiquement significatif.

La décision de Google de diviser la génération huit en puces dédiées est une thèse compétitive : que l’optimisation matérielle dédiée à cette échelle surpasse l’optimisation logicielle des charges de travail sur silicon polyvalent par des marges suffisamment grandes pour modifier les décisions d’infrastructure des clients. L’amélioration d’entraînement de 2,7x et l’amélioration d’inférence de 80 % représentent des réductions de coûts d’infrastructure suffisamment importantes pour modifier l’économie du développement de modèles pour toute enterprise exécutant des charges de travail IA à une échelle significative.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Plongée Technique TPU 8t et TPU 8i — Google Cloud Blog
• Nos TPUs de Huitième Génération : Deux Puces pour l’Ère Agentique — Google Blog
• Résumé Google Cloud Next 2026 — Google Cloud Blog
• Google sur Deux Voies TPU 8 pour Conquérir Entraînement et Inférence — The Register
• Deux Nouveaux TPUs pour Alimenter la Prochaine Vague IA chez Google — SiliconAngle