Google Cloud Next '25 : l'inférence, maître mot des annonces infra

L'IA, ombrelle idéale pour du stockage objet zonal, du réseau 400G et des clusters SLURM managés ?

Google a choisi un tel angle de communication lors de la Cloud Next '25. Ces trois briques ont rejoint la marque fédératrice AI Hypercomputer, au sein de laquelle le groupe américain place toutes ses technos d'infrastructure orientées vers l'exécution de workloads IA.

Le blogpost de Thomas Kurian souhaitant la "bienvenue à la Google Cloud Next '25" fait la part belle aux évolutions du portefeuille AI Hypercomputer. Y sont mentionnés, notamment, les puces Ironwood, les VM A4 et A4X, l'inférence sur GKE et le runtime Pathways. Un post spécifique les reprend, en les détaillant plus ou moins et en ajoutant, entre autres, le réseau 400G. Le calendrier de disponibilité n'est, en revanche, pas toujours précis... quand il est annoncé.

Les GB200 en preview ; Ironwood dans les cartons

La disponibilité générale des VM A4 avait été officialisée mi-mars à la GTC (conférence NVIDIA). Une configuration est pour le moment proposée, à 8 GPU B200 (1440 Go de mémoire), 224 vCPU (3968 Go de mémoire VM), 12 To de SSD et 3600 Gbit/s de bande passante.
Lancées également à cette occasion mais en preview, les VM A4X le restent. Chacune réunit 4 puces GB200.

Il faudra attendre "plus tard cette année" pour la disponibilité des ASIC Ironwood, 7^e génération des TPU Google. Sont annoncées des configurations à 256 et à 9126 puces par pod. À 42,5 exaflops, cette dernière est plus puissante que le supercalculateur El Capitan, nous affirme-t-on. Sauf que cette performance est mesurée dans un format de calcul bien moins précis : FP8, guère adapté qu'aux charges de travail IA.
Par rapport aux TPU de 6^e génération, le rapport performance par watt est doublé, prétend Google. Qui souligne aussi l'amélioration des coeurs dits SparseCores (processeurs qui s'appuient sur les représentations vectorielles continues qu'on peut trouver dans les modèles de recommandation).

Quand Google parle de "firewall RDMA"...

Il faudra également patienter pour accéder à une option 400G sur Cloud Interconnect et Cross-Cloud Interconnect. Le premier donne accès à une interconnexion réseau physique entre VPC Google Cloud et infras sur site. Le deuxième, à la même chose mais avec les infras d'autres CSP. Pour le moment, le lien peut monter à 100 Gbit/s.

Sur la feuille de route, il y a aussi un "firewall RDMA". Google n'entre pas dans les détails du concept, mais l'idée est d'appliquer des politiques de sécurité au niveau de cette interface.

... et compte en exaoctets

D'ici à fin juin, on devrait pouvoir expérimenter, sur le stockage bloc Hyperdisk, les dénommés Exapools. Ils sont une variante à plus grande échelle des pools de stockage Hyperdisk lancés voilà un an. La promesse : pouvoir provisionner des exaoctets et bénéficier d'un débit en téraoctets par seconde.
Les pools "traditionnels" sont eux-mêmes étendus pour supporter non plus jusqu'à 1 Po, mais jusqu'à 5 Po. Toujours avec le même principe : réserver une capacité, un débit et des IOPS à répartir ensuite entre workloads.

Le stockage objet zonal est pour le moment en preview privée, sous la marque Rapid Storage. Concurrent d'Amazon S3 Express One Zone, il semble consister en un wrapper du système de fichier Colossus, avec interface gRPC. Google annonce des performances "jusqu'à 20 fois supérieures" en lecture aléatoire par rapport à des buckets régionaux.

Dans le même esprit, Anywhere Cache - disponible - permet de créer des caches dans la même zone que les charges de travail. Chaque cache dessert les clients de la même zone, évitant les frais de transfert associés à la lecture de données dans des buckets multirégionaux.

Ne dites plus Hypercompute Cluster, mais Cluster Director

Changement de marque pour l'orchestrateur Hypercompute Cluster. Il s'appelle désormais Cluster Director. Le principe ne change pas : piloter de façon unifiée des flottes d'accélérateurs, via les API Compute Engine ou via GKE, sur des VM colocalisées.
Cluster Director pour GKE est disponible. Google promet d'y ajouter, cette année, des fonctionnalités axées en particulier sur l'observabilité et sur la continuité. Il existe aussi une version pour les clusters SLURM, mais pour le moment en accès anticipé.

Pousser l'inférence vers Kubernetes

Autre preview publique : celle de capacités "spéciales inférence" sur la passerelle GKE. Parmi elles :

• Exploitation des métriques des serveurs de modèles (utilisation du cache KV, de la longueur de la file d'attente, etc.) pour l'autoscaling et le load balacing
• Multiplexage des modèles LoRA sur un même accélérateur
• Observabilité des requêtes
• Routage des requêtes selon les spécifications d'API du cluster

Phase expérimentale également pour GKE Inference Quickstart. Cet utilitaire permet de spécifier des exigences métier d'inférence et d'obtenir des configurations Kubernetes optimisées tenant compte des bonnes pratiques de Google.

Pathways ouvert au-delà de Gemini

Pour entraîner ses modèles Gemini, Google recourt à un runtime maison : Pathways. À renfort de dataflow asynchrone, il peut orchestrer des workloads avec un client JAX unique, facilitant la mise en oeuvre de patterns de parallélisme.

Le voilà ouvert - au dernier pointage, en pré-GA - aux clients Google Cloud, parallèlement à l'activation de vLLM sur les TPU. Et de l'extension du planificateur de charges de travail dynamique d'AI Hypercomputer. Celui-ci supporte désormais les puces Trillium et les TPU V5e, ainsi que les VM A3 Ultra (H200) et A4 (B200). En preview pour commencer, sur le mode Flex Start (capacité à la demande). Puis, "plus tard ce mois-ci", sur le mode Calendar (réservation de créneaux d'une durée définie).

Illustration © Araki Illustrations - Adobe Stock