Réseaux pour l'IA dans Google Cloud : goodput, double plan et routage conscient du modèle

L'équation de départ de « AI Infrastructure: Networking Techniques », de Google Skills, est courte : une infrastructure sur mesure, c'est des GPU ou TPUs puissants, plus un stockage efficace, plus une connectivité haute vitesse. Et elle vient avec sa métaphore : le compute est le moteur, le storage le carburant et le networking le système de livraison. Le point qui soutient le reste du texte est que le réseau est le composant qui décide si cette capacité de calcul et de stockage est utilisée ou gaspillée.

Ce qui suit parcourt les trois phases du pipeline d'IA et leurs exigences réseau, l'architecture des machines accélérées, l'ingestion massive de données, le multi-cloud, l'entraînement distribué, l'inférence des modèles génératifs et les pratiques de sécurité du réseau.

Le pipeline : trois phases, trois exigences

flowchart TD
    I[Ingestion : elephant flows To, bande passante] --> E[Entraînement : gradient updates, latence ultra-faible]
    E --> F[Inférence : millisecondes, disponibilité mondiale]

Ingestion et préparation. Déplacer des datasets à l'échelle des téraoctets depuis l'on-premises ou d'autres clouds. La latence compte moins que la bande passante totale, et le produit de référence est Google Cloud Interconnect, dans ses variantes Dedicated et Cross-Cloud.

Entraînement. L'étape la plus intensive en réseau : une bande passante énorme et une latence ultra-faible entre des centaines ou milliers d'accélérateurs, pour passer les gradient updates. Un retard réseau arrête tout le travail. Le produit associé est High Bandwidth Cluster Network.

Inférence. Prédiction en millisecondes, quel que soit l'emplacement, avec haute disponibilité ; Low Latency Inference gérée globalement avec Google Cloud Load Balancing, en acheminant vers le point de service le plus proche.

Goodput : la métrique qui gouverne

Une grande partie du discours s'organise autour du goodput : le progrès effectif qu'un système fait sur une tâche d'entraînement d'ML. Il offre plus d'informations que le débit brut car il suit spécifiquement combien de temps les GPU passent à calculer plutôt qu'à attendre des données. L'architecture hiérarchique rail-aligned se conçoit justement pour cela : minimiser la surcharge de communication et améliorer le goodput.

Rail-aligned : sub-blocks, blocks et clusters

Les familles récentes de GPU (A3-ultra, A4-high et A4X) s'organisent en une hiérarchie de trois niveaux, comptée en sauts réseau. Sub-blocks : le bloc fondamental, des hôtes physiquement colocalisés dans un même rack, avec une communication à un saut entre n'importe quelle paire de GPU via le switch top-of-rack en utilisant RoCE (RDMA over Converged Ethernet). Blocks : plusieurs sub-blocks interconnectés, avec n'importe quel GPU atteignable en au plus deux sauts via un fabric non bloquant. Clusters : des blocks connectés avec un saut supplémentaire, montant à des milliers de GPU avec haut débit et prévisibilité.

Les métadonnées de cette hiérarchie sont exposées aux orchestrateurs (Slurm ou GKE) pour le placement optimal des travaux.

Le double plan de trafic

Toutes les machines GPU utilisent une architecture à double plan. Le trafic général (Cloud Storage, gestion, services Google) est géré par les Titanium NICs de Google. La communication dédiée GPU-to-GPU est fournie par RoCE, les NICs NVIDIA et la topologie rail-aligned du centre de données.

NVLink crée des routes directes ultra-haute vitesse entre GPU d'une même machine. NVSwitch gère la communication entre plusieurs GPU : avec A4X il permet de naviguer entre 72 puces (quatre par nœud) dans un même rack, en partageant le même NVSwitch. Et le NCCL amélioré est optimisé pour la topologie rail-aligned de Google dans les opérations collectives comme all-reduce.

La stack dépend du type de machine choisi. GPUDirect RDMA, la route directe sans CPU via RoCE, sur A4X, A4 et A3 Ultra. GPUDirect-TCPXO sur A3 Mega, qui double la bande passante réseau par rapport à TCPX en déchargeant le protocole TCP sur l'interface. GPUDirect-TCPX sur A3 High.

Multi-VPC par famille, et la preuve qui le confirme

Les machines accélérées haute performance demandent un environnement multi-VPC, et le compte change par famille. A4X, A4 et A3 Ultra (GPUDirect RDMA) nécessitent trois VPC : celle par défaut, une additionnelle pour le trafic hôte et une Shared VPC pour tout le trafic GPU-to-GPU avec le profil de réseau RDMA activé. A3 Mega (TCPXO) utilise huit VPC séparées, dédiées aux huit NIC GPU. A3 High (TCPX) quatre.

Le test NCCL du matériel matérialise le design : une VPC de gestion avec MTU 8 896 et des règles de firewall pour le trafic interne, SSH et ICMP ; huit VPC additionnelles pour les huit NIC ; un instance template avec A3 Mega (huit H100) et un managed instance group de deux nœuds ; CUDA 12.2, Fabric Manager, libnccl et Open MPI. Le test all_reduce_perf, avec des messages de 8 Mo à 8 Go, a mesuré près de 383 Go/s sur un seul nœud. Ensuite, SSH sans mot de passe et mpirun avec 16 processus pour le test distribué entre nœuds : la bande passante de bus est sortie inférieure, ce qui est attendu entre machines, avec TCP-XO comme alternative pour exploiter les huit NIC.

Et la composition de bande passante de A4 et A3 Ultra explique pourquoi le plan séparé compte : 3 200 Gbps avec huit NVIDIA ConnectX-7 exclusivement pour la communication GPU-to-GPU basse latence, avec NUMA aligné 1:1 avec chaque GPU et aucun trafic général par-dessus, plus 400 Gbps sur deux gVNIC pour internet, Cloud Storage, d'autres services et la gestion. Total, 3 600 Gbps agrégés, avec NVLink bridge all-to-all entre les huit GPU.

Ingestion : quatre piliers et une limite honnête

La phase d'ingestion se résume en quatre piliers. Capacité de mouvement des données : planification de capacité d'Interconnect, liens 400G et MTU/Jumbo pour les transferts massifs, avec l'avertissement honnête que la limite dure du débit d'ingestion est la NIC d'une VM, la réponse est donc de passer à l'échelle horizontalement. Sécurité : MACsec, IPS, chiffrement en transit et protection contre les malwares sur le stockage de fichiers. QoS : façonnage et application awareness d'Interconnect, avec SLA. Observabilité : perte et latence.

Application awareness mérite une ligne à part : il classe les flux de trafic selon des priorités métier et les ordonne dans une de six classes prédéfinies, avec des politiques de priorité stricte ou de partage de bande passante, pour sauvegarder le critique et éviter la surprovisionnement.

Multi-cloud : Interconnect, Cross-Cloud Network et Agent Platform

Cloud Interconnect connecte l'on-premises. Cross-Cloud Interconnect couvre le multi-cloud jusqu'à 100 Gbps, avec SLA de 99,99 % et chiffrement de bout en bout. Cross-Cloud Network offre une connectivité any-to-any centrée sur les services, et le matériel cite un rapport IDC selon lequel 66 % des entreprises listent la gen AI et l'IA/ML comme principaux cas d'usage des réseaux multi-cloud. Network Connectivity Center fonctionne comme un hub, et Service Landing VPC avec Private Service Connect donne accès à Agent Platform, avec plus de 130 modèles, plus des modèles DIY sur TPU ou GPU et une inférence distribuée entre clouds.

Entraînement et les trois générations d'offloads

De l'entraînement restent quatre idées : fiabilité avec datapath direct GPU/TPU et fenêtres de maintenance ; performance avec RDMA via profil de réseau, connectivité full mesh et topologies ajustables ; scalabilité avec GKE mega-clusters et jusqu'à 40 000 endpoints GPU par VPC ; et observabilité avec flow logs annotés RDMA.

Et l'architecture d'offloads de Titanium, en trois générations. Sans offloads : la VM exécute la charge et tous les services d'infrastructure, et les CPU de la charge perdent des cycles à gérer paquets, politiques et E/S de stockage. Gen 1 : une SmartNIC dédiée sur l'hôte absorbe sécurité, réseau et stockage. Gen 2 : accélérateurs smart on-host pour les tâches de base basse latence, plus une couche de serveurs off-host scale-out, souvent sur Google Borg. Les avantages déclarés sont la scalabilité massive, le prix/performance (matériel spécialisé partagé comme Hyperdisk) et un périmètre de sécurité plus fort en centralisant et isolant les fonctions d'infrastructure.

Inférence : pourquoi le round-robin ne suffit plus

Le tableau comparatif entre trafic gen AI et web traditionnel explique presque tout ce qui suit. Taille de réponse bursty et dynamique, avec grandes images, vidéo et raisonnement. Une requête LLM qui peut consommer 100 % du calcul de l'accélérateur. Attente sur des ressources GPU/TPU coûteuses et limitées. Latence de secondes à minutes. Cache moins efficace, à cause du contenu unique généré. Et coût : routage intelligent vers le modèle bon marché ou cher selon la requête. La conclusion est que le round-robin et les techniques basées sur l'utilisation sont obsolètes pour l'inférence d'IA.

flowchart TD
    P[Requête vers la passerelle] --> M{File de requêtes et KV-cache}
    M -->|round-robin| R1[Réplique saturée, requêtes en file]
    M -->|routage par KV-cache| R2[Réplique moins chargée, sans files]

Le Cloud Load Balancing, avec plus d'un million de requêtes par seconde, ajoute des service extensions (votre logique dans le data path : blocage de prompts qui les empêche de consommer des GPU/TPU rares et routage vers le bon modèle en analysant le header de la requête) et des custom metrics, qui relient la performance de l'application au routage réseau.

Le GKE Inference Gateway est l'étape suivante : au lieu de ne regarder que l'utilisation, il surveille la file de requêtes en attente et l'utilisation du KV-cache, et achemine vers la réplique la moins chargée. Ses extensions sont le body-based routing (extrait l'identifiant du modèle du corps de la requête), la security (politiques par modèle avec Model Armor ou d'autres fournisseurs) et l'endpoint picker, le cœur, qui choisit la réplique optimale en considérant même les adaptateurs LoRA en mémoire. Les bénéfices déclarés : jusqu'à 40 % de débit en plus et jusqu'à 60 % de temps de réponse en moins. Et l'inférence l'a vérifié avec un load test : en round-robin, l'utilisation du KV-cache avait beaucoup de variance, certains serveurs saturaient complètement, les nouvelles requêtes filaient en file et un pic de time-to-first-token apparaissait ; avec le routage par KV-cache, la charge est restée régulière, sans saturation ni files.

Sécurité du réseau, en quatre réglages

Les derniers conseils sont pratiques et valent d'être ajoutés au checklist avant le premier déploiement. Un compte de service dédié, pas celui par défaut de Compute Engine, avec les rôles minimaux (compute.admin, iam.serviceAccountUser, storage.admin et logging.admin) vérifiés avec gcloud : les permissions insuffisantes sont une cause fréquente d'échecs de déploiement dans les environnements sécurisés. Accès public restreint et règles de firewall durcies, avec l'avertissement que des firewalls restrictifs peuvent causer des échecs de setup qui ne se voyaient pas en tests. DNS zonal comme DNS interne par défaut, pour la résilience face à une panne DNS mondiale. Et les IPs externes désactivées où c'est possible, en testant d'abord en staging, car des services comme les nœuds publics GKE ou les managed instance group peuvent en dépendre.

Ce que le répertoire laisse et ce qui est resté non exécuté

Ce qui survit aux changements d'interface, ce sont trois critères : mesurer le réseau d'IA avec le goodput et non le débit brut, séparer le plan général du GPU-to-GPU, et acheminer l'inférence par métriques de modèle (file et KV-cache) plutôt que par utilisation générique.

Ce qui est resté non exécuté dans cette documentation : le quiz n'a ni été ouvert ni soumis, la credential n'a pas été réclamée, plusieurs leçons du bundle amènent du texte de gabarit sans contenu extractible, les cours externes cités (Cloud GPUs, Cloud TPUs et la référence architecturale du load balancer) n'ont pas été téléchargés, et le test NCCL du matériel n'a pas été reproduit ici : ses chiffres sont ceux du parcours documenté, pas des mesures propres.

---

*Source : « AI Infrastructure: Networking Techniques », de Google Skills (cours google.networking-techniques).*