Google a dévoilé son architecture TPU de huitième génération, divisée en deux puces distinctes — Ironwood pour l'inférence à grande échelle et Gemini Flow pour les charges de travail agentiques. Cette annonce signale que la course à l'infrastructure est désormais explicitement façonnée par les exigences des agents IA, pas seulement l'entraînement de modèles.
Contexte
Pendant plus d'une décennie, Google a conçu des tensor processing units (TPU) personnalisées pour alimenter son infrastructure IA. Chaque génération s'est concentrée principalement sur rendre l'entraînement de modèles plus rapide et plus efficace. TPU v4 et v5 étaient optimisées pour les demandes computationnelles massives du pré-entraînement de modèles fondamentaux — le goulot d'étranglement qui a défini l'ère 2022-2024 de la montée en puissance IA.
Mais le paysage a changé. Tandis que les modèles frontier deviennent commoditisés et que les alternatives open-weight comme Llama, Qwen et Mistral prolifèrent, le goulot d'étranglement stratégique passe de l'entraînement à l'inférence et l'orchestration. Les entreprises ne font plus seulement du fine-tuning de modèles — elles déploient des agents autonomes qui chaînent plusieurs appels d'inférence, maintiennent un état à travers les sessions et interagissent avec des outils externes en temps réel. Ce changement demande un profil hardware fondamentalement différent.
Ce qui change
La huitième génération de TPU de Google rompt avec la tradition en livrant deux puces séparées au lieu d'une. La première, Ironwood, est un accélérateur d'inférence brute-force conçu pour le serving haute-débit, faible-latence des modèles de langage. Elle se concentre sur la maximisation des tokens par seconde par watt — la métrique qui compte le plus quand vous exécutez des millions de requêtes d'inférence concurrentes.
La seconde puce, Gemini Flow, est spécialement conçue pour ce que Google appelle les "charges de travail agentiques". Ce sont des processus IA multi-étapes où un modèle doit planifier, exécuter des appels d'outils, attendre des réponses externes et reprendre le raisonnement — souvent sur des horizons temporels étendus. Gemini Flow privilégie la bande passante mémoire et la planification flexible par rapport au débit brut en virgule flottante. Elle est conçue pour maintenir l'état des agents résidant en mémoire haute-bande passante, minimisant la pénalité de latence du changement de contexte entre étapes dans une boucle d'agent.
Les détails techniques clés de l'annonce incluent des améliorations significatives de la bande passante d'interconnexion inter-puces, permettant un couplage plus serré à travers les pods pour l'orchestration d'agents distribués. Google a aussi mis en avant le nouveau support pour le décodage spéculatif au niveau hardware et les patterns d'attention sparse natifs — deux techniques qui réduisent le coût computationnel des interactions d'agents long-contexte.
Les puces seront disponibles via Google Cloud, intégrées aux outils agent builder de Vertex AI. Google positionne ceci comme une offre full-stack : hardware optimisé pour les agents, associé à des frameworks logiciels pour les construire et les déployer.
Implications
Pour les builders et CTOs, cette annonce porte plusieurs conséquences pratiques.
Premièrement, elle valide la thèse que l'IA agentique est le paradigme de déploiement dominant en avant. Quand un hyperscaler redessine le silicium autour des charges de travail d'agents, cela signifie que l'industrie s'attend à ce que les systèmes IA multi-étapes utilisant des outils deviennent la norme — pas seulement une curiosité de recherche. Les investissements d'infrastructure suivent les signaux de demande, et Google parie des milliards que les agents sont là où ira le compute.
Deuxièmement, cela élève la barre de performance pour les applications agentiques. Si du hardware dédié peut réduire la latence d'une boucle d'agent 10-étapes de 30 secondes à moins de 5, cela débloque des cas d'usage auparavant impraticables : assistants de coding temps réel qui refactorisent des bases de code entières, agents de service client qui résolvent des tickets complexes de bout en bout, et workflows de recherche autonome qui tournent sans supervision pendant des heures. Les fondateurs construisant dans ces catégories devraient factoriser l'accélération hardware dans leurs hypothèses de roadmap.
Troisièmement, cela intensifie la compétition entre fournisseurs cloud sur la couche inférence et orchestration. AWS investit dans ses puces Trainium et Inferentia ; Microsoft développe Maia. Mais Google est le premier à diviser explicitement sa stratégie puce selon l'axe entraînement-versus-agents. Cela force les concurrents à articuler leur propre histoire d'infrastructure agentique — ou risquer de perdre la prochague vague de startups IA-native au profit de Google Cloud.
Enfin, pour les équipes faisant tourner des agents sur des modèles open-weight, cela compte car les prix TPU de Google Cloud ont historiquement été compétitifs pour l'inférence par batch. Si Ironwood et Gemini Flow tiennent leurs promesses d'efficacité, faire tourner des systèmes agentiques sur GCP pourrait devenir significativement moins cher que les alternatives basées GPU — un avantage de coût qui se compose à l'échelle.
Notre analyse
La décision de Google de concevoir une puce spécifiquement pour les charges de travail agentiques est le signal le plus clair que le centre de gravité de l'industrie passe de l'entraînement de modèles au déploiement et à l'orchestration de modèles. Il ne s'agit pas de hype — il s'agit de silicium. Les cycles de conception hardware sont longs et coûteux ; on ne fait pas de tape-out d'une puce personnalisée pour une tendance qu'on s'attend à voir s'estomper.
Ceci dit, le vrai test sera dans les détails. "Charges de travail agentiques" reste une catégorie définie de manière lâche, et il reste à voir si l'architecture de Gemini Flow fournit des avantages significatifs par rapport aux GPU haut de gamme avec suffisamment de mémoire. La preuve viendra quand les benchmarks indépendants compareront la latence et le coût des boucles d'agents à travers les plateformes.
Ce qui est clair, c'est que la couche infrastructure est désormais façonnée par l'hypothèse que les agents IA — pas les chatbots, pas les pipelines batch — sont les consommateurs principaux du compute d'inférence. Les builders devraient prendre note : le hardware est construit pour vous. La question est de savoir si vos architectures d'agents sont prêtes à en tirer avantage.