Contexte technique
J'ai regardé l'annonce de Google et j'ai immédiatement noté le point principal : ils ne vendent plus l'idée d'une puce unique et universelle. La huitième génération de TPU est d'emblée divisée en TPU v8t pour l'entraînement et TPU v8i pour l'inférence. Pour ceux qui s'occupent de l'implémentation de l'IA et de la construction de pipelines agentiques, c'est une bifurcation très judicieuse.
Le TPU v8t est conçu pour les entraînements à grande échelle. Google annonce un superpod pouvant atteindre 9600 puces, 121 ExaFLOPS en FP4 natif et 2 Po de mémoire HBM totale. De plus, la bande passante inter-puces est doublée par rapport à la génération précédente et la montée en charge atteint 19,2 Tbps, ce qui signifie qu'ils ciblent clairement non seulement le calcul, mais aussi l'ancien goulot d'étranglement de l'échange de données.
J'ai trouvé le TPU v8i encore plus intéressant. Il dispose de 288 Go de HBM, 384 Mo de SRAM sur la puce, un moteur d'accélération des opérations collectives dédié et promet une latence jusqu'à 5 fois plus faible sur les opérations globales. Pour les systèmes agentiques, où un modèle ne se contente pas de répondre mais effectue plusieurs étapes de raisonnement, appelle des outils et maintient le contexte, ce n'est plus un gadget marketing, mais une fonctionnalité très pratique.
Autre point important : Google construit clairement une architecture IA verticalement intégrée autour de ses processeurs Axion Arm, de NUMA, de la topologie réseau Boardfly et de sa propre infrastructure cloud. Le TPU v8i peut évoluer jusqu'à 1152 puces, le v8t jusqu'à 9600, et toute l'histoire ressemble à une tentative d'abattre deux murs à la fois : l'entraînement coûteux et l'inférence lente. Le chiffre de '80% de meilleur rapport performance/prix' semble agressif, mais sans grille tarifaire publique, je le considérerais pour l'instant comme une indication plutôt que comme l'économie finale du projet.
Ce que cela change pour les entreprises et l'automatisation
Sans fioritures, les gagnants sont ceux qui construisent des systèmes multimodaux lourds et de l'inférence agentique sur Google Cloud. C'est particulièrement vrai là où l'important n'est pas une seule belle démo, mais une automatisation stable avec l'IA en charge : support, analytique, orchestration des processus internes, et copilotes avec des outils.
Les perdants sont les équipes qui recherchent une portabilité maximale entre les clouds et la pile NVIDIA/CUDA. L'intégration ici est forte, mais le prix à payer est évident : une dépendance étroite à GCP.
En pratique, cela pousse les décisions architecturales vers une séparation des préoccupations : d'un côté l'entraînement, de l'autre le service à faible latence. C'est précisément ce genre de goulots d'étranglement que nous analysons chez nos clients au Nahornyi AI Lab : où nous heurtons-nous à la latence, où le coût par étape de l'agent est-il trop élevé, où la mémoire est-elle le problème, ou bien où le problème ne vient-il pas du tout du modèle mais d'une configuration environnante défectueuse.
Si votre agent met déjà plus de temps à 'réfléchir' qu'il n'en faut à un employé pour effectuer la tâche manuellement, c'est le bon moment pour reconstruire le système. Au Nahornyi AI Lab, j'aide à mettre en place l'automatisation par l'IA sans 'romantisme matériel' : j'examine votre flux de travail, je calcule la rentabilité et je construis une architecture qui fonctionne réellement en production.