Ce que Google a réellement annoncé à Next ’26
Google Cloud Next 2026 a produit l’une des annonces d’infrastructure les plus techniquement détaillées de l’histoire récente des conférences cloud. Les divulgations couvrent le calcul, le réseau, le stockage et les couches applicatives. Cet article se concentre sur le niveau infrastructure où les décisions architecturales se composeront pendant des années.
TPU 8t (entraînement) : La puce d’entraînement de huitième génération regroupe 9 600 puces dans un seul superpod délivrant 121 exaflops de puissance de calcul et 2 pétaoctets de mémoire partagée. La bande passante d’interconnexion inter-puces (ICI) est doublée par rapport à la génération précédente. À l’échelle des clusters, le réseau Virgo connecte 134 000 puces TPU 8t dans un seul centre de données et peut s’étendre à plus d’un million de puces sur plusieurs installations.
TPU 8i (inférence) : La variante optimisée pour l’inférence embarque 384 Mo de SRAM sur puce (triplée par rapport à la génération précédente), 288 Go de mémoire à haute bande passante (HBM) et 19,2 Tb/s de bande passante ICI (doublée). Un Collectives Acceleration Engine (CAE) réduit la latence sur puce jusqu’à 5 fois. Google indique 80 % de meilleures performances par dollar pour les charges de travail d’inférence par rapport à la génération précédente.
Architecture réseau Virgo : La caractéristique déterminante de Virgo est sa conception à fabric effondré, qui élimine la « taxe de mise à l’échelle » — la dégradation de latence et de bande passante qui se produit typiquement à mesure que les clusters de GPU ou de TPU grandissent. Virgo offre 4 fois la bande passante de la génération de réseau précédente tout en maintenant des caractéristiques de performance constantes sur l’ensemble du fabric de 134 000 puces dans un seul centre de données.
Google Cloud Managed Lustre : L’annonce stockage est peut-être la plus sous-estimée de Next ’26. Managed Lustre offre désormais 10 To/s de bande passante — une amélioration de 10 fois en glissement annuel et 20 fois plus rapide que le concurrent le plus proche déclaré par Google. La capacité est de 80 pétaoctets. Pour les charges de travail d’entraînement d’IA, le débit de stockage est fréquemment la contrainte déterminante.
Implications au niveau applicatif : GKE a vu une amélioration de 4 fois du démarrage des nœuds et jusqu’à 80 % de réduction du temps de démarrage des pods. La latence de l’Inference Gateway a diminué de 70 % pour le temps-vers-premier-token sans réglage manuel.
Publicité
Ce que les architectes cloud d’entreprise devraient faire avec ces informations
1. Réévaluer le coût de vos charges de travail d’entraînement IA face à l’économie du TPU 8t
L’amélioration de 80 % du coût d’inférence sur TPU 8i comprimera les coûts d’entraînement et d’inférence d’IA d’entreprise d’une manière qui n’était pas intégrée dans la plupart des budgets cloud 2025. Si votre organisation a différé l’affinage de grands modèles ou le déploiement de pipelines RAG parce que le coût de calcul était prohibitif à l’échelle actuelle, réévaluez ces charges de travail par rapport aux tarifs d’inférence TPU 8i — pas par rapport à l’économie de la génération précédente. L’amélioration de la bande passante ICI et de la SRAM sur le TPU 8i réduit spécifiquement le nombre de puces nécessaires pour servir une charge d’inférence donnée, ce qui se traduit directement en coût.
2. Comparer votre architecture de stockage aux 10 To/s de Managed Lustre
La plupart des pipelines d’IA d’entreprise sont limités par le stockage avant d’être limités par le calcul. Si votre organisation exécute actuellement des charges de travail d’entraînement sur du stockage objet cloud standard (compatible S3, débit typique 10-50 Go/s), l’existence d’un Managed Lustre à 10 To/s change la conversation architecturale. Ce n’est pas un signal pour migrer immédiatement — Managed Lustre comporte une tarification premium — mais c’est un signal pour mesurer l’utilisation réelle du débit de stockage pendant les exécutions d’entraînement.
3. Évaluer le fabric effondré de Virgo comme décision d’engagement pluriannuel
Le fabric effondré de Virgo est architecturalement distinct des topologies de commutation multi-niveaux standard, et ses caractéristiques de performance à 134 000 puces ne peuvent pas être répliquées avec un réseau standard. Si votre entreprise s’engage sur des charges de travail d’entraînement à l’échelle où l’avantage de bande passante de Virgo se matérialise — typiquement au-delà de 1 000 puces pour l’entraînement distribué — vous prenez un engagement architectural pluriannuel sur la conception réseau propriétaire de Google Cloud. Évaluez cela par rapport au coût de portabilité de la construction de pipelines d’entraînement équivalents sur AWS Trainium2 ou des clusters Azure NDH100v5.
4. Intégrer les améliorations de démarrage des pods GKE dans la modélisation du coût d’inférence
La réduction de 80 % du temps de démarrage des pods GKE et l’accélération de 4 fois du démarrage des nœuds ont un impact financier spécifique : elles réduisent le coût de calcul inactif pendant les périodes de passage à zéro pour les charges de travail d’inférence. Modélisez l’impact financier des nouvelles performances de démarrage GKE par rapport au nombre minimal de nœuds actuels de votre cluster d’inférence — pour beaucoup de charges de travail, le temps de démarrage amélioré permet un plancher minimal plus bas.
La leçon structurelle : l’infrastructure hyperscaler comme course aux armements pour l’ère d’entraînement
Les annonces TPU 8t et réseau Virgo représentent un schéma cohérent chez les trois hyperscalers majeurs depuis 2023 : l’investissement dans l’infrastructure d’entraînement d’IA n’est plus régi par des signaux de demande commerciale mais par le positionnement stratégique pour la prochaine génération de modèles.
À 121 exaflops par superpod et un million de puces par cluster, Google ne construit pas d’infrastructure dimensionnée à la demande actuelle des entreprises. Les charges de travail d’IA d’entreprise à grande échelle — l’affinage de grands modèles, l’exécution de pipelines d’inférence multi-milliards de paramètres — consomment des centaines à des milliers de puces, pas des millions. L’échelle du million de puces est dimensionnée pour le développement de modèles frontière : la prochaine génération de Gemini et les modèles qui lui succéderont.
Ce que cela signifie pour les architectes d’entreprise : les capacités du superpod TPU 8t seront accessibles aux clients d’entreprise via une infrastructure mutualisée multi-locataires à des prix compétitifs, non pas parce que Google vend des superpods aux entreprises, mais parce que Google utilisera des superpods pour entraîner la prochaine génération de modèles auxquels les clients d’entreprise accèdent via API. L’investissement d’infrastructure remonte en amont ; le bénéfice pour l’entreprise descend en aval via une meilleure qualité de modèle et des coûts d’inférence par jeton plus bas.
Questions Fréquemment Posées
En quoi le réseau Virgo diffère-t-il du réseau conventionnel de cluster GPU ?
Les clusters GPU conventionnels utilisent une commutation hiérarchique : les GPU individuels se connectent à un commutateur de tête de rack, qui se connecte à un commutateur d’agrégation, qui se connecte à un commutateur central — chaque couche ajoutant de la latence. Au fur et à mesure que les clusters grandissent, le nombre de niveaux de commutation augmente et la bande passante se dégrade. Virgo utilise une architecture à fabric effondré qui élimine les niveaux intermédiaires dans la limite d’un centre de données de 134 000 puces. Le résultat est 4 fois la bande passante de la génération précédente sans « taxe de mise à l’échelle ».
Que signifient 10 To/s de Managed Lustre en termes pratiques pour l’entraînement d’IA ?
À 10 To/s, un jeu de données d’entraînement de 10 To peut être diffusé depuis le stockage en 1 seconde. Pour un contexte, un GPU A100 peut consommer des données à environ 2 To/s en mode lié au calcul lors de grandes opérations matricielles. L’avantage de Managed Lustre se matérialise lors des phases de chargement des données et des opérations de point de contrôle, qui sont les goulets d’étranglement de stockage réels dans l’entraînement distribué.
Les entreprises devraient-elles envisager le TPU 8i plutôt que les alternatives GPU pour l’inférence ?
L’amélioration de 80 % du rapport performance/dollar de Google sur le TPU 8i est significative, mais la comparaison qui compte pour les achats est celle des infrastructures d’inférence basées sur GPU concurrentes — AWS Trainium2 ou les clusters NVIDIA H100/H200 sur Azure ou AWS. Le TPU 8i est optimisé pour la diffusion de modèles basée sur JAX et les modèles de la famille Gemini. Les organisations dont le pipeline d’inférence est basé sur PyTorch font face à des coûts de migration qui compensent partiellement l’avantage de prix par jeton.
—
Sources et lectures complémentaires
- Google Cloud Next ’26 Recap — Blog Google
- AI Infrastructure at Next ’26: TPU 8t and Virgo — Google Cloud Blog
- Eighth-Generation TPU for the Agentic Era — Blog Google
- What’s New in Cloud Networking at Next ’26 — Google Cloud Blog
- Google Cloud Next ’26: Gemini Enterprise Agent Platform Leads AI-Centric News — Virtualization Review
