TPU 8tx et 8i Max : ce que Google prépare pour l’IA
Découvrez les TPU 8tx et 8i Max de Google : sécurité des inférences, grands contextes et enjeux concrets pour les entreprises qui déploient des agents IA.
TPU 8tx et 8i Max : Google adapte ses accélérateurs aux agents IA
Les agents d'intelligence artificielle ne se limitent plus à répondre à une question isolée. Ils enchaînent des étapes, consultent des outils, manipulent des données métier et peuvent garder du contexte sur une durée assez longue. Du coup, les contraintes changent : la puissance de calcul reste centrale, mais la mémoire, la latence, la sécurité des données et le coût d'une infrastructure pas toujours utilisée au maximum prennent aussi une place majeure.
Google ajoute deux nouvelles configurations à sa huitième génération de TPU : TPU 8tx, pensé notamment pour l'inférence confidentielle, et TPU 8i Max, destiné aux charges qui demandent beaucoup de mémoire et de bande passante. L'entreprise indique aussi avoir présenté quatre systèmes TPU en une seule année - chacun associé à une étape différente du cycle de vie des modèles et des agents. En parallèle, elle annonce des changements logiciels pour faciliter l'utilisation de ces puces par les développeurs.
Dans cet article : ce que Google essaie de résoudre, ce qu'on peut (et ne peut pas) déduire des chiffres annoncés, et les décisions qu'une entreprise devrait prendre avant de se lancer sur ce type d'infrastructure.
Ce que Google annonce avec les TPU 8tx et 8i Max
Google complète sa huitième génération de TPU avec deux configurations supplémentaires. L'entreprise avait déjà présenté TPU 8t pour l'entraînement à grande échelle et TPU 8i pour le raisonnement à faible latence. TPU 8tx vise l'inférence sensible, tandis que TPU 8i Max s'adresse aux traitements limités par la mémoire.
Ce qui frappe, c'est le rythme : Google dit avoir introduit quatre systèmes TPU en une année. Mais il faut distinguer le nombre de « systèmes » du nombre de nouvelles puces. Les deux configurations annoncées reposent sur des choix d'assemblage et d'architecture autour de composants déjà existants, plutôt que sur deux nouvelles générations de silicium.
Deux problèmes concrets : protéger les données et alimenter le modèle
Le premier sujet, c'est la protection des données pendant leur traitement. Le chiffrement protège en général les données stockées ou en transit. Mais pour calculer, il faut aussi y accéder. C'est là que les organisations qui traitent des informations sensibles cherchent à combler les trous de la chaîne.
Google présente TPU 8tx comme un système de calcul confidentiel : une protection intégrée au niveau matériel, pour isoler données et poids du modèle pendant l'exécution. La configuration combine le même silicium que TPU 8t avec des processeurs hôtes AMD EPYC de cinquième génération et un réseau à faible latence. Selon Google, elle peut réduire la latence d'environ moitié par rapport à TPU 8t, avec une pénalité de performance proche de zéro.
Le second sujet, c'est la quantité de données dont un modèle (ou un ensemble d'agents) a besoin à un instant donné. Selon les cas, cela peut vite devenir le facteur limitant : analyse d'un dépôt logiciel, longues séquences vidéo, ou historique métier volumineux. TPU 8i Max met deux puces TPU 8i dans un même boîtier. Google annonce le double de calcul, de mémoire SRAM et de bande passante HBM par rapport à TPU 8i.
Des annonces à lire avec le bon niveau de prudence
Ces éléments décrivent une architecture et des objectifs. Mais ils ne suffisent pas à estimer le coût réel d'un projet. Dans la pratique, tout dépendra du modèle, de la longueur effective des requêtes, du nombre d'utilisateurs simultanés, du logiciel d'inférence et du taux d'utilisation du matériel.
Google publie aussi des résultats sur des benchmarks d'inférence et d'agents, en insistant sur son environnement logiciel. Utile pour repérer des pistes, ce matériau ne remplace pas un test qui ressemble vraiment à vos charges. Un benchmark de génération de code ne dit pas à lui seul comment se comportera un assistant juridique français, un système de support, ou un outil interne connecté à plusieurs bases de données.
À retenir : les deux systèmes visent des goulots d'étranglement différents. 8tx se concentre sur la confidentialité et l'exécution rapide d'agents sensibles, tandis que 8i Max vise à mieux absorber les charges longues, avec davantage de mémoire disponible.
Pourquoi concevoir un système plutôt qu'une puce
Une puce est un composant. Un système, lui, combine ce composant avec sa mémoire, son réseau, son conditionnement, ses processeurs hôtes et ses couches logicielles. Cette distinction aide à comprendre l'annonce : Google ne parle pas uniquement de « nouvelle capacité de calcul », mais de configurations faites pour des usages distincts.
Construire un processeur prend du temps, avec des contraintes physiques fortes. À l'inverse, les logiciels évoluent plus vite : les architectures de modèles changent, les fenêtres de contexte s'allongent, et les agents introduisent des parcours de calcul moins réguliers. Une infrastructure trop « rigide » peut donc devenir moins adaptée avant même que le matériel soit amorti.
La modularité comme réponse au décalage des cycles
Google présente ses TPU comme des éléments modulaires, intégrés à son AI Hypercomputer. L'objectif : faire évoluer plus rapidement l'équilibre entre calcul, mémoire, interconnexion et sécurité, sans attendre une nouvelle génération complète de puces. L'approche peut faciliter la disponibilité d'une configuration spécialisée. Mais elle ne supprime pas les contraintes liées aux centres de données, à la capacité disponible ni aux migrations côté logiciel.
Dans un projet concret, tout revient au goulot d'étranglement. Si le modèle passe la majorité du temps à attendre des données, ajouter des unités de calcul ne changera pas grand-chose. Si l'inférence est limitée par les transferts entre accélérateurs, un réseau plus rapide - ou une disposition différente des composants - peut apporter plus que « plus de puissance » sur le papier.
C'est aussi le sens de la spécialisation : TPU 8t vise l'entraînement à grande échelle ; TPU 8i le raisonnement à faible latence ; 8tx ajoute un angle « calcul confidentiel » ; 8i Max augmente les ressources pour les charges qui demandent beaucoup de mémoire.
Ce que cela implique pour un acheteur
Chercher « la puce la plus puissante » n'est généralement pas une méthode fiable. Il vaut mieux regarder la performance utile de bout en bout : temps de réponse, débit réellement soutenu, précision du modèle, consommation, occupation des accélérateurs, puis coût par tâche effectivement exécutée.
Il faut aussi intégrer les coûts de mise en œuvre. Une configuration spécialisée peut être plus efficace sur un workload précis, mais moins pertinente si l'équipe doit gérer plusieurs piles logicielles, déplacer les données souvent, ou réserver une capacité qui reste sous-utilisée. Le bon choix est souvent celui qui réduit le coût total d'exploitation, pas celui qui affiche le plus gros chiffre de calcul.
Pour une organisation européenne, le « calcul confidentiel » peut aider à structurer une architecture de protection. Mais ça ne suffit pas pour satisfaire à lui seul au RGPD : il faut toujours définir les finalités et bases légales, maîtriser les accès, cadrer la conservation, vérifier la localisation éventuelle des données, gérer les contrats de sous-traitance et documenter les mesures de sécurité. La protection d'un composant ne remplace pas la gouvernance du service.
À quels usages correspondent les quatre systèmes TPU
La gamme se comprend surtout comme une réponse à des besoins différents, pas comme une échelle où chaque modèle serait « meilleur » que le précédent. Chaque configuration vise une phase ou une contrainte précise. Une entreprise peut n'en utiliser qu'une, ou répartir ses charges entre plusieurs environnements selon ses exigences.
Entraîner, raisonner, protéger ou élargir le contexte
- TPU 8t est positionné comme le système pour l'entraînement des grands modèles. Google met l'accent sur le « goodput » : le travail utile rapporté à l'énergie consommée, plutôt que le débit théorique.
- TPU 8i vise le raisonnement et l'inférence à faible latence. L'architecture est pensée pour limiter les délais de communication entre puces, un point important quand les requêtes doivent être traitées vite.
- TPU 8tx combine des capacités adaptées à l'entraînement à petite échelle et à l'inférence confidentielle. Il intéressera ceux qui veulent personnaliser un modèle à partir de données privées sans multiplier les transferts entre clusters. Google cite notamment le fine-tuning, la distillation et l'apprentissage par renforcement pour des agents.
- TPU 8i Max s'adresse aux charges qui demandent plus de mémoire et de bande passante. Le doublement annoncé par rapport à 8i sert à limiter le risque que les unités de calcul attendent des données.
Ces catégories ne garantissent pas un choix unique. Dans une entreprise, un agent peut mobiliser plusieurs profils : entraîner un modèle, le personnaliser avec des données internes, puis servir le résultat avec une contrainte de latence. Mais déplacer modèles, états de session et données entre environnements augmente la complexité. C'est précisément pour ça que l'annonce de 8tx insiste sur la possibilité de combiner personnalisation et exécution sécurisée dans un même système.
Comment choisir selon son workload
Avant de comparer le matériel, il faut mesurer le problème. Pour l'inférence : relever le temps de réponse médian, la latence en pic, le débit par accélérateur, la taille de contexte et le coût par requête. Pour les agents : regarder les pauses entre étapes, la fréquence d'appel aux outils et le nombre d'étapes nécessaires pour terminer une tâche.
Ensuite, relier le symptôme à une hypothèse technique :
- Le modèle est lent malgré une charge modérée : vérifiez la latence réseau, le temps de préremplissage du contexte et les échanges entre accélérateurs avant de vouloir « plus de capacité ».
- Les longues requêtes réduisent le débit : mesurez la pression sur la mémoire et la taille des caches d'attention ; un essai avec 8i Max peut être pertinent.
- Les données ne doivent pas être exposées pendant le calcul : examinez le calcul confidentiel, et en parallèle vérifiez les garanties contractuelles et les contrôles d'accès.
- Le coût augmente quand les agents attendent : regardez comment les sessions sont suspendues et reprises, plutôt que de provisionner uniquement pour un pic théorique.
Cette démarche évite de choisir un accélérateur à partir de la taille d'un modèle seul ou d'un chiffre issu d'un benchmark « propre ». Elle pousse aussi à comparer des tâches complètes, avec des exigences de qualité et de sécurité identiques.
Ce que l'ouverture logicielle change pour les entreprises
Un accélérateur performant ne sert pas à grand-chose si l'équipe doit réécrire toute l'application, adopter un framework mal maîtrisé, ou passer des mois à optimiser des kernels. Google met donc en avant des outils pour réduire ces frictions : PyTorch, diffusion de modèles, et orchestration de clusters.
Google annonce l'ouverture de TorchTPU pour exécuter nativement du code PyTorch et des modèles Hugging Face sur TPU, ainsi que des intégrations avec des moteurs d'inférence comme vLLM et SGLang. L'entreprise décrit aussi une suite d'agents logiciels pour faciliter l'intégration et le diagnostic, un moteur de serving en C++ et des outils de gestion de l'état des modèles et des ressources.
Réduire le coût d'adoption, pas seulement le coût du calcul
Si vous êtes déjà très investi sur PyTorch, la compatibilité peut réduire le travail de portage. Mais « sans réécriture » ne veut pas dire « sans validation ». Il faut tester les opérateurs réellement utilisés, la précision numérique, les bibliothèques, la stabilité des versions et le comportement en production. Une application qui « démarre » n'est pas automatiquement une application optimisée, ni équivalente en qualité.
Google parle aussi d'un Agent Compute Engine qui suspend et reprend les sessions d'agents inactives, et de TPU Sync, une couche visant à coordonner mémoire, stockage et réseau. Ces fonctions répondent à deux problèmes opérationnels : éviter de payer pour un agent en attente d'un outil externe, et limiter les transferts inutiles d'état entre ressources différentes. L'intérêt dépendra des durées d'inactivité, des exigences de reprise et du volume de données conservé en mémoire.
Cloud Pathways et le découpage dynamique des ressources TPU sont présentés comme des moyens de gérer des calculs répartis sur plusieurs groupes d'accélérateurs, de reprendre des tâches après incident et de réorganiser les ressources plus vite. Pour une équipe plateforme, ces mécanismes peuvent compter autant que la puce : temps de démarrage, récupération après panne et utilisation réelle du parc pilotent le coût d'un entraînement à grande échelle.
Les questions à poser avant un pilote
Un pilote doit porter sur une tâche métier représentative, avec des critères d'arrêt clairs. L'objectif n'est pas de prouver que le matériel fonctionne, mais de vérifier qu'il améliore le résultat dans vos conditions d'exploitation.
Avant de démarrer le test, précisez :
- La charge à comparer : modèle, données, taille de contexte, concurrence et fréquence d'utilisation.
- Le résultat attendu : latence, qualité, débit, coût par tâche ou niveau d'isolation.
- Les coûts complets : capacité réservée, stockage, réseau, ingénierie, supervision et éventuelle migration.
- Les conditions de sortie : réversibilité des données et des modèles, dépendances logicielles et impact d'un changement de fournisseur.
- Les contrôles de sécurité : accès opérateur, journaux, chiffrement, séparation des environnements et responsabilités contractuelles.
Les résultats publiés par un fournisseur servent à repérer des hypothèses à tester. Ils ne répondent pas aux questions pour votre organisation. La décision doit s'appuyer sur un benchmark interne, avec des scénarios comparables et une mesure du coût par résultat utile.
Conclusion : choisir une infrastructure selon le goulot d'étranglement
TPU 8tx et TPU 8i Max montrent une évolution importante de l'infrastructure IA : on ne parle plus seulement d'entraîner des modèles toujours plus grands. La confidentialité pendant l'exécution, la mémoire disponible pour les contextes longs, la latence des agents et l'utilisation réelle des ressources deviennent des critères de conception à part entière.
Google associe aussi un profil à chaque système : entraînement avec 8t, raisonnement à faible latence avec 8i, inférence confidentielle avec 8tx, et charges à forte demande mémoire avec 8i Max. Cette spécialisation peut être utile si vos contraintes mesurées correspondent vraiment à ce que le système vise à résoudre.
Pour trancher, partez de vos workloads, définissez un coût par tâche utile, puis testez qualité, latence, sécurité et réversibilité dans des conditions proches de la production. Le meilleur accélérateur n'est pas celui qui affiche le chiffre le plus impressionnant : c'est celui qui lève votre vraie contrainte sans rendre l'exploitation plus coûteuse ou plus fragile.