Comment choisir l'observabilité full-stack pour les usines IA NVIDIA

Comment choisir l'observabilité full-stack pour les usines IA NVIDIA

Lorsqu'une usine IA s'étend sur des milliers de GPU NVIDIA, un réseau InfiniBand, un stockage distribué et un ordonnanceur qui lance des travaux par lots 24 heures sur 24, une pile de supervision ordinaire cesse de fonctionner. Vous n'avez plus quelques serveurs avec une poignée de métriques ; vous avez une machine où chaque couche — silicium, micrologiciel, pilote, runtime de conteneur, framework et orchestration — peut devenir un goulot d'étranglement le même jour. Un seul comportement silencieux, comme un GPU qui commence à limiter la fréquence de sa mémoire, peut ralentir tout un cycle d'entraînement, alors qu'aucun de vos tableaux de bord applicatifs ne le détectera.

L'observabilité full-stack pour les usines IA NVIDIA n'est pas simplement un tableau de bord plus grand. C'est un choix délibéré concernant les données à collecter, la manière de les relier entre les couches et la personne qui agira en conséquence. Cet article présente un cadre de décision pratique et montre comment mettre en place une pile de référence minimale, consciente des GPU, qui illustre le modèle full-stack avec de vraies commandes.

Ce que « full-stack » signifie dans une usine IA

Dans l'informatique traditionnelle, l'observabilité full-stack signifie généralement relier l'application, le runtime et le système d'exploitation hôte. Une usine IA ajoute plusieurs couches faciles à manquer :

• La couche silicium : l'utilisation du GPU, l'utilisation de la mémoire, la température, la consommation électrique, la limitation de fréquence et les erreurs exposées via les interfaces NVML et DCGM de NVIDIA.
• La couche système et réseau : le CPU et la mémoire hôte, la santé des NVMe, les problèmes de lien PCIe, et le réseau InfiniBand ou RoCE qui relie les GPU entre eux et au stockage. Un lien dégradé peut ralentir les opérations collectives sans qu'une seule erreur n'apparaisse dans les journaux applicatifs.
• La couche runtime et orchestration : le comportement d'ordonnancement de Kubernetes ou Slurm, la santé des conteneurs, le découpage temporel du GPU ou l'isolation MIG, et les temps d'attente dans les files qui précèdent chaque exécution d'entraînement.
• La couche application et framework : le nombre d'étapes d'entraînement par seconde atteint par la charge de travail, le débit du chargeur de données, les courbes de perte, et la santé des points de terminaison d'inférence depuis Triton ou un conteneur de service personnalisé.

La décision de conception centrale est la corrélation. Les métriques collectées indépendamment à chaque couche sont presque inutiles dans une usine IA, car les problèmes de production sont généralement transversaux. Une faible utilisation du GPU doit être jointe aux métriques du chargeur de données pour déterminer si les GPU sont inactifs à cause d'une famine d'E/S ou parce que l'ordonnanceur limite le travail. Choisir l'observabilité signifie donc choisir un modèle pour la manière dont la télémétrie des différentes couches sera connectée.

Exigences à définir avant de comparer les outils

Avant d'évaluer un produit, écrivez les exigences concrètes. Quatre sont particulièrement importantes pour les usines IA.

Premièrement, définissez les SLO qui comptent réellement pour vous. Pour l'entraînement, le principal objectif de niveau de service est une progression constante : les étapes par seconde doivent rester au-dessus d'un seuil, et le travail ne doit pas ralentir silencieusement. Pour l'inférence, les SLO sont la latence, le débit et l'utilisation du GPU de la flotte de service. Les outils d'observabilité doivent être évalués sur leur capacité à produire ces signaux exacts, et non pas un simple statut générique « système sain ».

Deuxièmement, décidez si vous avez besoin d'une visibilité en temps réel ou a posteriori. Une usine IA est un environnement à haute cardinalité : chaque travail possède son propre ensemble de conteneurs, de GPU et de processus. Vous devez décider combien de métriques par seconde le pipeline peut soutenir et pendant combien de temps les données doivent être conservées. Une télémétrie à fidélité complète à intervalles de 15 secondes sur 10 000 GPU est très différente d'une télémétrie échantillonnée conservée pendant un mois.

Troisièmement, réglez la question de la multi-location. Dans de nombreuses usines, plusieurs équipes partagent le cluster. Les données d'observabilité peuvent involontairement divulguer des informations sur les charges de travail d'autres utilisateurs — par exemple, la consommation électrique exacte d'un travail voisin peut révéler des schémas d'activité. Choisissez une pile qui prend en charge des tableaux de bord limités à chaque locataire et qui conserve les métriques brutes détaillées dans un entrepôt de données avec des contrôles d'autorisation.

Quatrièmement, identifiez le propriétaire opérationnel. L'observabilité full-stack échoue lorsque personne ne possède la pile complète. En pratique, les administrateurs de cluster possèdent les métriques de silicium et de réseau, les équipes de plateforme ML possèdent les métriques des frameworks, et les équipes applicatives possèdent les courbes d'entraînement. Les outils sélectionnés doivent définir des frontières de propriété claires tout en permettant à une seule équipe de remonter d'un pic de perte directement à un message d'erreur XID.

Ce qu'il faut instrumenter : des erreurs XID au débit de données

Une erreur courante consiste à n'instrumenter que l'utilisation du GPU. Le DCGM de NVIDIA expose un ensemble de métriques bien plus riche, notamment l'utilisation de la mémoire, l'occupation des SM, la consommation électrique, la température, les raisons de limitation de fréquence et les compteurs d'erreurs. Sous Linux, vous pouvez rapidement inspecter la santé des GPU de votre nœud avec l'interface de gestion système de NVIDIA :

# How to Choose Full-Stack Observability for NVIDIA AI Factories
nvidia-smi

# List detailed metrics for every GPU in JSON format
nvidia-smi --query-gpu=index,uuid,temperature.gpu,utilization.gpu,utilization.memory,power.draw,clocks.sm --format=csv

Cependant, l'inspection manuelle n'est pas de l'observabilité. L'important est la collecte continue. DCGM prend également en charge un mode de vérification de santé plus rigoureux :

# Run DCGM's diagnostic suite once to identify hardware issues
dcgmi diag -r 1

Ces commandes illustrent pourquoi la question du full-stack concerne autant la taxonomie des métriques que les outils. Avant de choisir un fournisseur, établissez lesquels de ces signaux sont obligatoires :

• les erreurs XID et les fautes au niveau du pilote, qui indiquent des conditions de panne matérielle ou logicielle ;
• les raisons de limitation, puisqu'un GPU peut être à 100 % d'utilisation de calcul tout en étant limité à 70 % de sa fréquence ;
• les erreurs de réseau, qualifiées de corrigées (bénignes) ou non corrigées (fatales) ;
• les débits de lecture/écriture PCIe et HBM, qui révèlent une saturation de la bande passante mémoire ;
• les métadonnées de niveau travail provenant de l'ordonnanceur, afin que chaque métrique puisse être attribuée à un propriétaire de charge de travail.

Si un outil proposé ne peut pas capturer ces signaux à une granularité raisonnable, ce n'est pas une solution full-stack pour une usine IA. Le reste n'est que décoration.

Installation de référence étape par étape

Il n'existe pas de pile d'observabilité « correcte » unique, mais il existe un modèle open source bien établi qui démontre tous les principes ci-dessus : DCGM-Exporter pour les métriques GPU, Prometheus pour la collecte et le stockage, et Grafana pour les tableaux de bord. Les commandes ci-dessous sont une implémentation de référence illustrative. Utilisez un espace de noms de supervision dédié et figez les versions exactes des images de conteneur dans votre propre environnement, car les versions changent fréquemment.

Étape 1 — Démarrer un exportateur de métriques GPU.

NVIDIA publie DCGM-Exporter sous forme d'image de conteneur. Il lit la télémétrie depuis les pilotes hôtes et l'expose sous forme de métriques au format Prometheus sur le port 9400. La commande suivante l'exécute sur un nœud avec les pilotes NVIDIA installés :

# Start the DCGM-Exporter on the default port
docker run -d --gpus all --rm \
  --name dcgm-exporter \
  -p 9400:9400 \
  nvcr.io/nvidia/k8s/dcgm-exporter:latest

Si vous préférez ne pas utiliser de conteneur, DCGM-Exporter est également disponible sous forme de binaire autonome sur la page de versions du projet sur GitHub. Vérifiez qu'il fonctionne en interrogeant son point de terminaison de métriques :

# Confirm that GPU metrics are being exported
curl -s http://localhost:9400/metrics | head -20

Vous devriez voir des noms de métriques commençant par DCGM_FI_DEV_, comme DCGM_FI_DEV_GPU_UTIL et DCGM_FI_DEV_MEM_COPY_UTIL.

Étape 2 — Configurer Prometheus pour collecter les métriques de l'exportateur.

Créez un fichier de configuration Prometheus minimal. Le détail clé est d'attacher une étiquette identifiant le nœud physique, afin que lorsqu'un travail s'exécute sur n'importe quel nœud du cluster, ses métriques restent attribuables au bon hôte :

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "dcgm"
    static_configs:
      - targets: ["gpu-node-01:9400", "gpu-node-02:9400"]
        labels:
          cluster: "ai-factory-east"

Ensuite, exécutez Prometheus :

# Run Prometheus with the configuration above
docker run -d --name prometheus \
  -p 9090:9090 \
  -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus:latest

Étape 3 — Fournir un tableau de bord Grafana.

Grafana peut extraire les métriques directement de la source de données, donc aucun démon d'agent n'est nécessaire :

# Start Grafana and connect it to the Prometheus instance on port 9090
docker run -d --name grafana \
  -p 3000:3000 \
  -e GF_SECURITY_ADMIN_PASSWORD=admin \
  grafana/grafana:latest

Une fois les conteneurs en cours d'exécution, ouvrez l'interface web Grafana sur le port 3000, connectez-vous, ajoutez une source de données Prometheus pointant vers http://prometheus:9090, et créez un tableau de bord avec des panneaux qui interrogent les métriques DCGM_FI_DEV_GPU_UTIL et DCGM_FI_DEV_POWER_USAGE.

Exemples d'utilisation

La véritable valeur de la pile apparaît lorsque vous commencez à poser des questions transversales. Voici trois modèles utiles.

1. Détecter une limitation de fréquence GPU qui n'apparaît pas comme une faible utilisation.

Un GPU fonctionnant à 100 % de sa limite de fréquence actuelle peut toujours tourner plus lentement que sa vitesse maximale déclarée. Python, utilisant l'API Prometheus, peut exposer cet écart. L'exemple ci-dessous interroge l'occupation de la fréquence SM et les raisons de limitation :

import requests

prometheus_url = "http://localhost:9090/api/v1/query"

queries = {
    "throttle_reasons": 'DCGM_FI_DEV_CLOCK_THROTTLE_REASONS',
    "sm_clock": 'DCGM_FI_DEV_SM_CLOCK',
}

for name, query in queries.items():
    response = requests.get(prometheus_url, params={"query": query}).json()
    for result in response["data"]["result"]:
        print(name, result["metric"].get("gpu_uuid"), result["value"][1])

Un masque de bits de raison de limitation non nul vous indique ce qui limite la puce — thermique, puissance ou autres facteurs — et la valeur de la fréquence SM vous indique ce que le GPU a décidé de faire à ce sujet.

2. Corréler un travail lent avec la couche de chargement des données.

Supposons que votre travail s'exécute à 300 étapes par seconde au lieu des 450 attendues. L'utilisation du GPU semble correcte, ce qui est suspect. La requête ci-dessous calcule l'utilisation moyenne de la copie mémoire de chaque GPU au cours des cinq dernières minutes, ce qui révèle souvent un blocage du chargement des données :

import requests

prom = "http://localhost:9090/api/v1/query"
query = 'avg_over_time(DCGM_FI_DEV_MEM_COPY_UTIL[5m])'

response = requests.get(prom, params={"query": query}).json()
for result in response["data"]["result"]:
    metric = result["metric"]
    print(metric.get("kubernetes_pod_name"),
          metric.get("gpu_uuid"),
          round(float(result["value"][1]), 2))

Si l'utilisation de la copie mémoire est élevée alors que l'utilisation de calcul n'est que modérée, la charge de travail passe presque certainement son temps à copier des tenseurs entre l'hôte et le périphérique, ou à l'intérieur du réseau, plutôt qu'à calculer.

3. Créer une alerte simple pour les pannes GPU silencieuses.

Une alerte fiable peut être écrite directement en PromQL, en utilisant les métriques dcgm_exporter pour signaler un GPU dont le compteur d'erreurs augmente au fil du temps :

increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0

Cette alerte est bien plus exploitable qu'une alerte générique « nœud down », car elle nomme le GPU et le travail qui le partage via les étiquettes attachées.

Ce qu'il faut normaliser et qui en est propriétaire

La partie la plus difficile du choix de l'observabilité full-stack n'est pas l'installation ; c'est la normalisation des noms et l'organisation de la propriété.

Premièrement, normalisez l'étiquetage sur toutes les métriques. Si votre exportateur GPU, votre exportateur Kubernetes et votre ordonnanceur utilisent tous le même identifiant de travail, vous pouvez les joindre au moment de l'interrogation. Choisissez un petit ensemble d'étiquettes — job_id, cluster, node, gpu_uuid — et imposez la convention au moment de l'ingestion.

Deuxièmement, décidez qui supprime les métriques. Une usine IA génère un flux continu de télémétrie qui est précieuse pendant un incident actif et le plus souvent inutile après la clôture de l'incident. Établissez une politique de rétention par niveau : métriques à haute résolution pour les derniers jours, métriques sous-échantillonnées pour quelques mois, et journaux bruts d'erreurs GPU pour une année afin de soutenir les litiges de garantie matérielle.

Troisièmement, réfléchissez attentivement au compromis entre surcharge de collecte et fidélité. Les métriques DCGM sont peu coûteuses à collecter, mais les métriques au niveau du réseau et des trames sont plus coûteuses. N'instrumentez les couches profondes que sur les nœuds où vous avez des travaux d'entraînement actifs, pas sur tout le cluster, et vous maintiendrez votre surcharge proche de zéro.

Pièges à éviter

Plusieurs erreurs courantes expliquent pourquoi les usines IA se retrouvent avec des piles de supervision impressionnantes mais qui échouent en pratique. L'une consiste à instrumenter les GPU comme s'ils étaient des CPU, ce qui produit des tableaux de bord montrant une utilisation moyenne — une métrique dénuée de sens lorsqu'un travail occupe quatre GPU beaucoup plus intensément qu'un autre. Une autre consiste à ne collecter que vers une seule destination, comme une instance Prometheus unique, et à perdre des données lorsque le réseau du centre de données a un soubresaut. Une troisième consiste à choisir un outil qui offre une visualisation magnifique mais qui force votre télémétrie à passer par un agent propriétaire que votre équipe de sécurité refuse à juste titre d'installer.

Il existe également un piège purement administratif : acheter une plateforme d'observabilité et supposer qu'elle résoudra le problème organisationnel. L'outil ne décidera pas qui remédie à une erreur réseau ; c'est l'équipe des opérations de l'usine qui doit le faire. Si votre organisation ne peut déjà pas répondre à la question « Qui possède le réseau ? », aucun produit ne vous aidera à voir le réseau assez clairement pour le réparer.

Conclusion

L'observabilité full-stack pour les usines IA NVIDIA est une décision en couches. Définissez vos SLO, décidez de la télémétrie que vous pouvez vous permettre et de la durée de conservation nécessaire, confirmez que l'outil candidat fait remonter les signaux NVIDIA de bas niveau tels que les raisons de limitation et les erreurs XID, puis corrélez ces signaux avec les données de l'ordonnanceur et de l'application. Une pile de référence minimale construite à partir de DCGM-Exporter, Prometheus et Grafana est un moyen fiable de tester ces exigences dans votre propre environnement avant de vous engager dans un déploiement plus large. Commencez par les métriques au niveau du silicium, ajoutez les métadonnées du réseau et des travaux, et imposez une convention d'étiquetage stricte dès le premier jour. L'usine GPU fonctionne à un rythme différent de celui de l'infrastructure informatique normale, et son observabilité doit être conçue pour suivre le rythme.