Google Cloud a dévoilé Ironwood, sa septième génération de TPU, accompagnée de nouvelles instances Axion basées sur ARM Neoverse — N4A (en avant-première) et C4A métal (bare metal ARM, « prochainement » en aperçu) —, marquant ainsi un changement de cycle dans le domaine de l’Intelligence Artificielle : un déplacement du focus du entraînement vers la fourniture d’inférences rapides, économiques et orchestrées dans les flux agentiques. La société affirme que ce bond en productivité n’est possible qu’avec un silicium conçu sur mesure et un co-découpage du système (hardware, réseaux et software conçus comme une seule entité), dans le cadre de sa superinformatique AI Hypercomputer.

Concrètement, Ironwood est prévu pour supporter des modèles de dernière génération avec latence minimale et élasticité complète, tandis que Axion renforce la puissance du calcul général avec un meilleur rapport prix/performance pour le « backbone » supportant ces applications : microservices, ingestion et préparation de données, APIs, bases de données et gestion de l’orchestration.

Ironwood : une TPU pensée pour l’inférence massive (tout en conservant la capacité d’entraîner à grande échelle)

Ironwood se positionne comme la TPU la plus puissante et efficiente de Google à ce jour. La société annonce une amélioration jusqu’à 10× en performance de pointe comparée à la TPU v5p, ainsi qu’un plus de 4× de performance par chip aussi bien en entraînement qu’en inférence par rapport à la TPU v6e (Trillium). Le message est clair : fournir des modèles génératifs et des agents à grande échelle nécessite de faire évoluer l’bande passante, la mémoire effective et la connectivité entre puces.

Le design d’Ironwood repose sur une approche « système d’abord ». Chaque déploiement regroupe des TPUs en pods, eux-mêmes assemblés en superpods interconnectés via ICI (Inter-Chip Interconnect) à 9,6 Tb/s. Dans cette topologie, un superpod peut rassembler jusqu’à 9 216 TPUs dans un domaine unique avec 1,77 PB de HBM partagée, minimisant ainsi les goulets d’étranglement pour les modèles volumineux. Au-dessus, le réseau Jupiter permet de lier ces superpods en clusters pouvant compter des centaines de milliers de TPUs, selon la charge.

Pour assurer la résilience, Google introduit l’optical switching (OCS) comme réseau reconfigurable capable de rerouter le trafic en cas d’interruption, sans interrompre le service. Sur la couche physique, il supporte également une refroidissement liquide à grande échelle, une technologie éprouvée dans ses data centers, garantissant des densités élevées avec une disponibilité « cinq neuf » depuis 2020.

Au-delà de la puissance brute, ce qui compte c’est l’usage. Ironwood fonctionne avec un software co-désigné pour exploiter l’architecture et simplifier la gestion

• GKE avec Cluster Director offre maintenance avancée et planification topologique pour des clusters plus résilients.
• MaxText, framework open-source pour LLM à haute performance, inclut des améliorations pour finetuning supervisé (SFT) et des optimisations RL telles que GRPO.
• vLLM supporte désormais TPU, avec la capacité d’alternance entre GPU et TPU via des ajustements minimes.
• GKE Inference Gateway offre un équilibrage intelligent entre serveurs TPU, pouvant selon Google, réduire le “time-to-first-token” (TTFT) jusqu’à 96 % et diminuer le coût de service jusqu’à 30 %.

L’objectif ultime est de boucler le processus entraînement → réglage → déploiement avec une expérience opérationnelle cohérente, où données, modèle et service cohabitent avec plus d’efficience et moins de obstacle.

Premiers signaux du marché : d’Anthropic à Lightricks et Essential AI

Les premières indications aident à saisir l’ambition derrière cette annonce. Anthropic, qui ne cesse de faire progresser sa famille Claude, vise jusqu’à 1 000 000 de TPUs, positionnant Ironwood comme levier pour accélérer la transition du laboratoire au service destiné à des millions d’utilisateurs. Lightricks apprécie particulièrement le potentiel en qualité et fidélité d’image et vidéo pour ses produits créatifs ; Essential AI souligne la simplicité d’intégration de la plateforme pour un déploiement sans délai. En somme, le fil conducteur reste la relation coût/performance et la capacité à évoluer sans compromettre la fiabilité.

Axion : CPU ARM pour le « travail quotidien » qui rend l’IA possible

L’autre volet de l’annonce concerne Axion, la gamme de CPU ARM Neoverse de Google Cloud. Le déploiement s’effectue en double :

• N4A (en avant-première) : la VM plus efficace en prix/performance de la série N à ce jour, avec jusqu’à 64 vCPU, 512 GB de mémoire DDR5 et 50 Gbps de capacité réseau. Compatible avec Custom Machine Types et stockage Hyperdisk Balanced/Throughput, elle cible microservices, containers, bases open-source, traitement par lots et analytics, ainsi que environnements de développement et serveurs web. Google garantit jusqu’à 2× en prix/performance par rapport aux VMs x86 actuelles.
• C4A métal (bare metal ARM, en aperçu prochainement) : jusqu’à 96 vCPU, 768 GB de DDR5, Hyperdisk et 100 Gbps de réseau. Conçue pour hyperviseurs, développement natif ARM (dont Android/automobile), logiciel sous licence stricte ou grandes fermes de test et simulations complexes.

En complément, la gamme Axion comprend aussi la C4A (VM) — jusqu’à 72 vCPU, 576 GB DDR5, 100 Gbps, Titanium SSD local jusqu’à 6 TB et des options avancées de gestion — couvrant aussi bien les charges sensibles à la latence que celles nécessitant une capacité continue. La philosophie reste l’ajustement des ressources à la charge réelle pour réduire la facture sans modifier le modèle opérationnel.

Les premiers retours des clients sont encourageants : Vimeo annonce +30 % de performance sur sa transcodification comparée à des VMs x86 similaires ; ZoomInfo évoque +60 % en prix/performance sur Dataflow et ses services Java en GKE ; et Rise combine C4A et Hyperdisk pour réduire consommation de calcul et latence dans sa plateforme publicitaire, tout en expérimentant N4A pour des charges critiques exigeant flexibilité.

La synergie essentielle : accélérateurs IA + CPU efficaces pour toutes les autres tâches

Dans le contexte actuel, marqué par des architectures de modèles évolutives toutes les quelques mois, des techniques innovantes (avec agents planificateurs et acteurs dans des environnements complexes), et des pics de demande imprévisibles, il est crucial de définir où faire tourner quoi. La stratégie de Google privilégie un marriage :

• A accelerateurs spécialisés (Ironwood TPU) pour entraîner et servir des modèles avancés avec une bande passante et une mémoire suffisantes, ainsi qu’un réseau évolutif et résilient.
• CPU Axion pour tout le reste : applications, API, ingestion/preparation de données, ETL, files d’attente, services web et microservices orchestrant des flux IA. Ce niveau généraliste joue un grand rôle dans le coût total et, s’il est optimisé, libère des budgets pour la composante accélérateurs là où c’est crucial.

Pour les plateformes, cela signifie une flexibilité opérationnelle : pouvoir mélanger accélérateurs et CPU selon la phase (pré-entraînement, finetuning, inférence) ou le profil de la charge. Avec le soutien de GKE, vLLM et MaxText, l’objectif est de réduire au minimum les changements de code et la friction lors du déplacement des charges entre GPU et TPU, ou lors du rééquilibrage interne avec Axion.

Questions essentielles pour une prise de décision

Bien que cette annonce trace une voie claire, les entreprises devraient l’ancrer dans la pratique avec une checklist pragmatique :

1. Disponibilité régionale et quotas : Dans quels pays ou régions pourra-t-on réserver Ironwood ? Quelles limitations ou SLO accompagnent N4A et C4A métal en avant-première ?
2. Compatibilité et portabilité : Quels outils (vLLM, MaxText, frameworks courants) seront supportés nativement ? Quels ajustements sont nécessaires pour migrer de GPU vers TPU ?
3. Coûts et packaging : Comment budgétiser les superpods et les fenêtres de forte utilisation? Quel rôle joue Hyperdisk dans Axion, notamment avec ses profils IOPS et sa taille ?
4. Résilience et gouvernance : Comment suivre et auditer l’OCS et Jupiter ? Quelles métriques de TTFT, MTTR et coût par token le stack de déploiement fournit-il ?
5. Plan d’adoption : Quels pilotes à faible risque permettent de valider rapidement des améliorations (par ex., un service d’inférence sur Ironwood ou un pipeline de données sur N4A) avant d’engager de plus grandes ressources ?

Se baser sur des chiffres concrets plutôt que seulement sur des fiches techniques fera la différence entre une promesse séduisante et une véritable avance compétitive.

Implications pour le secteur

Ce lancement place Google au centre d’un débat stratégique : il ne s’agit plus uniquement de savoir qui entraine le plus gros modèle, mais qui le sert de la manière la plus efficace et économique en production. Ironwood s’attaque frontalement au goulot d’étranglement du serving grâce à une interconnexion massive, une mémoire partagée et un équilibrage intelligent. Axion vise principalement la gestion des coûts, qui représente une grande part de la rentabilité des produits IA. Pour le client, le véritable avantage réside non seulement dans la consommation en watts par token, mais aussi dans la discipline systémique : orchestrer un pipeline qui passe aisément de l’expérimentation à la mise en production à l’échelle globale.

Si cette approche de co-optimisation perdure et si l’écosystème logiciel s’adapte, cette configuration pourrait devenir un modèle opérationnel pour de nombreux équipes plateformes : TPU pour la capacité en bande passante et mémoire réellement nécessaire, ARM pour la gestion courante des activités quotidiennes. L’enjeu repose en fin de compte sur une vision intégrée du tout, plutôt que sur un composant unique.

Questions fréquemment posées (FAQ)

Qu’est-ce exactement qu’Ironwood, et pour quel type de charges est-il conçu ?
Il s’agit de la septième génération de TPU de Google, conçue pour l’entraînement de modèles volumineux, apprentissage par renforcement (RL), ainsi qu’en particulier pour l’inférence et le serving à grande échelle avec une latence très faible. Son point fort réside dans l’interconnexion de milliers de puces (jusqu’à 9 216 dans un superpod) et l’accès à 1,77 PB de HBM partagée.

Quelles différences entre N4A, C4A et C4A métal d’Axion ?
N4A privilégie le rapport prix-performance avec jusqu’à 64 vCPU, 512 GB de mémoire DDR5 et 50 Gbps, idéal pour les microservices, bases open-source et analytics. La C4A (VM) garantit performance soutenue avec jusqu’à 72 vCPU, 576 GB, 100 Gbps, en équipant localement de Titanium SSD jusqu’à 6 TB. La C4A métal (bare metal) est conçue pour hyperviseurs, développement natif ARM, ou applications avec exigences de licence ou hardware dédié : jusqu’à 96 vCPU, 768 GB, 100 Gbps.

Comment le logiciel (GKE, vLLM, MaxText) optimise-t-il l’exploitation d’Ironwood ?
GKE intègre Cluster Director pour une planification raisonnée et un entretien topologique. vLLM facilite la migration ou l’alternance GPU/TPU avec peu d’effort. MaxText contribue à accélérer finetuning et RL. Enfin, GKE Inference Gateway peut déployer un équilibrage de charge intelligent capable de réduire significativement le TTFT et les coûts liés au déploiement.

Quand seront disponibles Ironwood et Axion ?
Ironwood sera disponible en général dans les semaines à venir. N4A est déjà en avant-première, et C4A métal sera prochainement accessible en aperçu. La disponibilité par région et les quotas seront déployés progressivement.

Source : cloud.google