Aller au contenu

TechniquePratique

HPC IA : observabilité et sécurité, architecture de référence

Pour : ingénieurs et SRE · architectesPrérequis : Notions de base sur le HPC : nœud, ordonnanceur, interconnect.

Mode de lecture

Le HPC (High Performance Computing) assemble des centaines à des milliers de machines pour résoudre des problèmes trop grands pour un seul ordinateur. Depuis le début des années 2020, l’entraînement des grands modèles est devenu une charge majeure, dominante sur les clusters dédiés à l’IA. Ce module donne une architecture de référence pour les observer et les sécuriser avec une pile open source autohébergée.

Lire le texte de la vidéo

87 % utilisation GPU affichée.

Le tableau de bord est au vert. Pourtant, l’entraînement du modèle avance lentement. Où passe le temps ?

Un CPU a quelques cœurs puissants : il enchaîne des tâches variées, une à une. Un GPU a des milliers de petits cœurs : ils font la même opération, tous en même temps. Or un réseau de neurones, c’est surtout des multiplications de matrices : des milliards de calculs identiques. Le modèle loge dans la mémoire du GPU : 80 Go, lus à 3,35 To/s sur un H100.

Un modèle de 70 milliards de paramètres pèse environ 140 Go, rien que ses poids. Il ne tient pas dans un seul GPU. Et l’entraîner ? Environ 1,7 million d’heures de GPU pour Llama 2 70B (Meta, 2023).

Il faut donc faire travailler des centaines de GPU ensemble : c’est un cluster. Dans un serveur, 8 GPU reliés par NVLink : l’autoroute interne, 900 Go/s. Entre les serveurs, InfiniBand : un réseau très rapide, 400 Gb/s par port. Autour : un stockage partagé qui nourrit les GPU et Slurm qui distribue le travail.

À chaque pas, chaque GPU calcule sur sa part des données… … puis tous mettent leurs résultats en commun avant de continuer. Mais si un seul GPU est plus lent… … tous les autres l’attendent. Et pendant l’attente, ils sont comptés « occupés ». Voilà où disparaissent les heures de GPU.

L’observabilité mène l’enquête. Les métriques GPU, rattachées au job, montrent quel GPU ralentit chaque pas. Les traces de chaque GPU montrent dans quelle phase le temps se perd. Le contexte du job dit à qui parler et quoi vérifier : données, réseau ou matériel. Quel job, quel GPU, quelle phase : la réponse tient sur un seul écran.

Mais personne ne peut enquêter à la main sur chaque job. La réponse : faire de l’observabilité un service de la plateforme. Chemin balisé : le label du job est injecté au lancement, sans rien demander au chercheur. Libre-service : chaque chercheur voit son propre job, sans ouvrir de ticket. Objectifs de service : attente en file, jobs réussis, efficacité réelle des GPU. Refacturation : les heures de GPU vraiment utiles, équipe par équipe. Garde-fous par défaut : la sécurité est fournie par la plateforme.

Un cluster partagé attire aussi des menaces propres au HPC IA. Certaines échappent aux outils classiques, comme le trafic RDMA, invisible pour un pare-feu. Elles se détectent avec la même pile d’observabilité.

À retenir :

  1. Un GPU « occupé » n’est pas forcément un GPU qui calcule.
  2. Observer le job, le GPU et la phase, pas seulement la machine.
  3. La plateforme rend cette observabilité automatique, pour tous.

Mots-clés :

  • Matrice : tableau de nombres ; les poids d’un modèle en sont faits
  • HBM : mémoire empilée tout contre le processeur du GPU
  • Paramètres : les nombres appris par le modèle ; 2 octets chacun en 16 bits
  • NVLink : liaison directe entre les GPU d’un même serveur
  • InfiniBand : réseau à très faible latence entre serveurs
  • Slurm : ordonnanceur : il attribue les GPU aux jobs
  • Passes avant et arrière : calcul de la prédiction, puis des corrections à apporter
  • AllReduce : mise en commun des résultats de tous les GPU
  • Trace : le parcours détaillé d’une opération, étape par étape
  • Platform engineering : une équipe fournit aux autres des outils internes en libre-service
  • SLO : objectif chiffré de qualité de service
  • RDMA : accès direct à la mémoire d’un autre serveur, sans passer par son système

Explorez le cluster sur le schéma interactif : www.meantimetolearn.com.

Musique : « Radar Focus », Blue Saga (Epidemic Sound).

RepèreOrdre de grandeur
Calcul d’entraînement de GPT-3 (2020)environ 3 640 pétaflop/s-jours, soit des centaines d’années-GPU
Mémoire pour charger les poids de Llama 3 70B en 16 bitsenviron 140 Go (70 milliards x 2 octets)
Bande passante mémoire HBM d’un H100 SXM53,35 To/s
Portable courant16 Go de RAM, 8 Go de mémoire GPU

En 16 bits, les seuls poids d’un modèle de 70 milliards de paramètres (140 Go) ne tiennent pas dans la mémoire d’un GPU de 80 Go. Ils tiendraient sur un GPU de 141 Go ou de 192 Go, ou en 8 bits, mais l’entraînement demande plusieurs fois plus de mémoire que les poids : gradients, états de l’optimiseur, activations. Il faut donc répartir le travail sur plusieurs GPU, plusieurs nœuds et les faire travailler ensemble à chaque pas.

CPUGPU
Cœursde 8 à 192 cœurs puissants selon le modèle (192 sur un AMD EPYC 9965)des milliers de cœurs CUDA simples (16 896 sur un H100 SXM, par exemple)
Fréquence2 à 5 GHz1 à 2 GHz
Point fortbranchements, accès mémoire arbitraires, orchestration, entrées-sortiesla même opération simple sur des milliers de données à la fois
Rôle en IAorchestrer, charger les données, contrôlerles multiplications de matrices au cœur des modèles

Les nombres de cœurs sont des exemples : les maxima augmentent à chaque génération.

  1. Architecture d’un cluster : les cinq couches et ce que chacune expose.
  2. Anatomie d’un pas d’entraînement : chargement, passes avant et arrière, AllReduce, optimiseur et l’effet traînard.
  3. La pile d’observabilité : collecte, stockage, visualisation et eBPF pour observer sans instrumenter.
  4. La surface d’attaque : six vecteurs propres au HPC IA et leur détection.

Révisé le 2 octobre 2026 : place des grands modèles dans les clusters datée correctement, mémoire nécessaire pour un modèle de 70 milliards de paramètres précisée, nombres de cœurs présentés comme des exemples et mis à jour, exemple 87 % et 19 % présenté comme illustratif.