GPU monitoring : monitoring des GPU pour l’IA et les environnements hybrides

Au bon vieux temps, comme diraient certains, lorsqu’il n’était pas nécessaire de contracter un prêt immobilier pour en acheter une, le GPU (Graphics Processing Unit) était ce composant qui n’intéressait que ceux qui voulaient jouer à Crysis en pleine résolution. Aujourd’hui, c’est le réacteur à antimatière qui propulse la moitié de l’industrie : entraînement de modèles d’IA, inférence, machine learning, simulation, rendu, analyse de données et HPC (High-Performance Computing). Sans GPU, pas d’IA, et sans IA, selon les visionnaires (qui la vendent), pas d’avenir. Un avenir qui, selon ces mêmes personnes, pourrait de toute façon être détruit par cette même intelligence artificielle.
Mais dans de nombreux cas, le cœur de diamant de l’infrastructure reste sans supervision.
Les serveurs, les CPU, le réseau, les services… sont monitorés avec un œil de faucon, mais les GPU restent l’angle mort le plus coûteux, celui qui, s’il est laissé sans surveillance, peut se transformer en gouffre financier.
C’est pourquoi le véritable défi n’est pas seulement de mesurer le GPU, mais de l’intégrer au monitoring des infrastructures on-premise, hybrides et cloud.
Voyons comment.

Pourquoi le GPU monitoring est important dans les infrastructures d’IA

Les GPU servent à accélérer les opérations critiques d’une organisation, mais comme rien n’est gratuit dans la vie, ils introduisent en contrepartie de nouveaux risques opérationnels. Cela en fait à la fois le moteur de tout projet d’IA et son talon d’Achille.
Pourquoi ?

• Parce qu’il s’agit de ressources de plus en plus coûteuses et limitées. Chaque carte inactive ou saturée, tout comme chaque minute de downtime, représente de l’argent qui part à l’égout.
• La saturation affecte l’inférence et l’entraînement. Un GPU qui souffle à la limite ralentit les réponses et allonge des tâches qui, déjà, prennent du temps.
• Le manque de mémoire provoque des erreurs ou une dégradation. Une erreur out of memory au milieu d’un entraînement, c’est l’écran bleu de la mort de notre époque, mais en beaucoup plus coûteux.
• La température a un impact sur les performances et la disponibilité, car, comme chez les humains, la chaleur dégrade, et trop de chaleur finit par tout arrêter.
• La sous-utilisation rend plus difficile la justification de l’investissement et oblige à fournir des explications lorsque la direction regarde la colonne des dépenses qui occupe trois feuilles de papier continu.
• L’historique permet de prendre des décisions de capacité, mais le manque de visibilité complique les opérations dans les environnements hybrides, on-premise et cloud.

La conclusion est que laisser le GPU en dehors de la photo de famille du monitoring relève de la folie à notre époque.

Le véritable angle mort : GPU monitoring pour les environnements on-premise, hybrides et enterprise

Il existe une croyance répandue selon laquelle l’IA vit dans le cloud, dans un centre de données géré par d’autres et qui dévaste un écosystème éloigné du nôtre. Pourtant, de très nombreuses organisations exploitent des GPU dans leurs propres datacenters, dans des environnements hybrides, des centres de recherche, l’industrie, des instances cloud avec GPU…
Et beaucoup de ces organisations opèrent sous des exigences de confidentialité, de souveraineté des données ou de réglementations sur celles-ci, où une solution 100 % cloud n’est pas viable, sous peine d’amende ou de risque de fuites dangereuses.
Dans ces cas, il ne suffit pas d’installer Ollama ou des outils similaires puis d’oublier le sujet, et la documentation du moment d’un fournisseur cloud ne suffit pas non plus pour opérer avec garantie et efficacité.
Il nous faut une plateforme capable de surveiller l’ensemble, les GPU et le reste de l’infrastructure, que ce soit sur des serveurs propres ou dans des environnements virtuels.
Le débat sans fin entre on-premise et SaaS, ou les exigences des infrastructures hyperconvergées, renforce notre besoin de contrôle. Car un GPU peut vivre on-premise, dans un écosystème hybride ou dans une instance cloud, mais son impact touche les services, le réseau, les processus, les API, les applications….
D’où la nécessité de se rapprocher un peu pour que le GPU entre dans cette photo de famille et de l’inclure dans le monitoring global, et non comme une métrique isolée dans un onglet que personne n’ouvre.
Et en parlant d’elles…

Les métriques clés du GPU monitoring

Nous devons surveiller, très bien, mais quoi exactement ?
Les métriques d’une stratégie de GPU monitoring digne de ce nom sont, en plus de leur nombre et de leurs noms :

• État du GPU (son état opérationnel).
• Utilisation du GPU (en pourcentage d’utilisation).
• Mémoire du GPU utilisée / libre / totale (état général de la mémoire, aussi bien en valeur brute qu’en pourcentage).
• Température du GPU pour savoir si le réacteur de distorsion de l’IA va exploser ou non.
• Énergie consommée et limite de puissance pour éviter des factures grandes comme la cape de Superman.
• Vitesse du ventilateur lorsque cela s’applique, bien sûr, comme nous allons le voir tout de suite.
• Erreurs critiques.
• Versions du driver NVIDIA et de CUDA.

Quelques nuances, car c’est là que se cachent les détails qui nous éviteront de mauvaises surprises.
Les erreurs critiques ne sont pas une métrique universelle. Dans un centre de données avec prise en charge ECC, comme les A100, H100, Tesla ou RTX PRO, elles sont pertinentes, mais sur des cartes grand public, comme une GeForce RTX ou des modèles similaires, l’utilitaire en ligne de commande de NVIDIA nvidia-smi peut renvoyer N/A pour les erreurs ECC.
Ainsi, notre plugin Pandora FMS, par exemple, émettra 0 par conception. Ce zéro éternel ne signifie pas que la carte est immortelle, simplement qu’il n’y a rien à compter.
D’autre part, la vitesse du ventilateur n’a de sens que sur les cartes avec ventilation active (D’oh, comme dirait Homer Simpson). Sur des GPU serveur ou des environnements fanless, elle ne s’applique évidemment pas.
C’est pourquoi un plugin de monitoring comme le nôtre permet d’ignorer ce module avec –include-fan=false, car la télémétrie avancée consiste aussi à savoir quoi ne pas mesurer pour ne pas saturer le système avec du bruit.

nvidia-smi, DCGM et plateformes de monitoring : ce que chacune apporte

Nous avons déjà vu le quoi, il est maintenant temps de voir comment nous monitorons et aussi de différencier les outils, car ils se confondent facilement.
Analysons ce que chacun apporte.
D’un côté, nous avons nvidia-smi, qui a déjà pointé le bout de son nez et qui est l’utilitaire en ligne de commande permettant de consulter les informations des GPU NVIDIA. Il s’agit de leur utilisation, mémoire, température, consommation, processus, driver, CUDA…
C’est le tricordeur du GPU : vous le pointez, vous lisez une valeur et vous continuez votre chemin. Parfait pour un diagnostic ponctuel ou un script lancé au cœur de la nuit.
NVIDIA DCGM est orienté vers la gestion des GPU dans les centres de données, les clusters et les déploiements avancés. Nous disposons ici de capteurs plus étendus pour notre vaisseau spatial, car il est utile lorsqu’il y a beaucoup de GPU ou une intégration avec des stacks d’observabilité.
Les deux sont de bons outils, mais la vérité est que ni nvidia-smi ni DCGM ne vont résoudre toute l’exploitation IT à notre place.
Ils ne centralisent pas l’infrastructure, ne remplacent pas les dashboards d’entreprise, n’apportent pas de reporting historique orienté métier et ne corrèlent pas à eux seuls GPU avec CPU, RAM, disque, réseau, logs, services ou SLA, par exemple.
Pour ces raisons, des propositions comme celle de Datadog insistent sur la connexion du GPU avec le reste de l’AI workload.
Ou, pour le dire autrement afin que ce soit clair. nvidia-smi et DCGM peuvent être d’excellentes sources de données, mais flottant seules dans le vide.
C’est une plateforme comme Pandora FMS qui les transforme en connaissance opérationnelle exploitable, avec historique, alertes, dashboards, rapports, corrélation et décisions de capacité.
Le tricordeur fournit une lecture ; une passerelle de commandement de l’Enterprise comme Pandora FMS vous indique ce qu’elle signifie dans le contexte de tout le reste lorsqu’elle intègre cette lecture.
Et en situation de crise, vous voulez être sur la passerelle, pas en train de déchiffrer des données isolées dans l’obscurité.

Les risques liés à l’absence de monitoring des GPU

Laisser le moteur sans surveillance a des conséquences désastreuses, comme :

• Saturation invisible, celle que l’on découvre seulement lorsqu’elle fait déjà mal.
• Dégradation des services, affectant l’inférence et entraînant des entraînements plus lents ou échoués.
• Erreurs CUDA qui passent inaperçues.
• Surchauffe et factures d’électricité interminables.
• Achat inutile de matériel ou sous-utilisation de celui déjà payé.
• Difficultés à relier les incidents applicatifs à la pression réelle exercée sur l’infrastructure.

C’est le scénario de tant de films catastrophe : les signaux étaient là, clignotant sur un panneau, mais personne ne les regardait.

Des métriques isolées à la corrélation opérationnelle

Le GPU monitoring isolé est un thermomètre qui, avec la corrélation opérationnelle issue de son intégration au monitoring global, devient diagnostic et connaissance opérationnelle.
Savoir qu’un GPU est à 95 % ne dit pas grand-chose, tout comme la fièvre seule n’en révèle pas la cause. Ce qui compte, c’est le contexte.
Pour reprendre l’exemple, un GPU à 95 % pendant dix minutes peut être normal, mais le même GPU à 95 % pendant quatre heures, avec une mémoire au-dessus de 85 %, des erreurs apparaissant dans les logs et une latence de service d’inférence en hausse, constitue un incident opérationnel.
Autre exemple : la température. Une valeur élevée associée à un ventilateur tournant à warp 9 et à des performances au ras du sol peut anticiper une défaillance physique, une brèche dans la muraille qui fera s’effondrer le château si elle est ignorée.
Connecter ces signaux, c’est ce qui distingue un outil qui regarde d’une plateforme qui comprend.
C’est la matière de l’analyse de cause racine, du travail quotidien de tout Network Operations Center ou de toute équipe SRE qui prend au sérieux le monitoring des systèmes IT.

Comment Pandora FMS aide au GPU monitoring

En technologie, soit vous êtes à la pointe, soit vous n’y êtes pas vraiment.
C’est la philosophie de Pandora FMS, et c’est pourquoi l’application permet d’intégrer les métriques GPU dans la même console où sont déjà monitorés les serveurs, les services, le réseau, le stockage, les logs, les événements et la disponibilité.
Cela fait de la surveillance des GPU non pas une note de bas de page, mais une pièce fondamentale d’une mécanique optimisée pour le monitoring et l’observabilité dont une infrastructure IT professionnelle a besoin.
Pour cela, Pandora FMS utilise un plugin spécialisé en GPU monitoring.
Celui-ci s’appuie sur nvidia-smi et fonctionne comme un plugin d’agent local sur l’hôte équipé d’un GPU NVIDIA, en émettant des modules que Pandora FMS intègre au contexte de l’agent.
Ainsi, ces métriques peuvent :

• Être visualisées, évidemment.
• Composer un historique pour les tendances, les analyses ou tout autre besoin.
• Déclencher des alertes intelligentes.
• Être incluses dans des rapports comme n’importe quelle autre métrique.

En outre, les informations émises sont critiques et nécessaires à la gestion optimale d’un actif plus coûteux que l’adamantium.
Pour chaque GPU détecté, il émet notamment : GPU_<i>_Status (1 = sain, 0 = dégradé), GPU_<i>_Utilization, GPU_<i>_Memory_Used, GPU_<i>_Memory_Free, GPU_<i>_Memory_Total (en MiB, mébioctets, pas en octets), GPU_<i>_Memory_Used_Percent, GPU_<i>_Temperature (°C), GPU_<i>_Power_Draw et GPU_<i>_Power_Limit (W), GPU_<i>_Fan_Speed (optionnel), GPU_<i>_Critical_Errors et GPU_<i>_Name.
À l’échelle de l’hôte, il ajoute trois modules globaux : GPU_Count, GPU_Driver_Version et GPU_CUDA_Version.
Le total découle d’une formule simple : 12N + 3 modules avec la vitesse du ventilateur, ou 11N + 3 sans elle, où N est le nombre de GPU de l’hôte.
Et un détail en dit long sur la conception. Si nvidia-smi n’est pas disponible, pas d’inquiétude, le plugin ne casse pas et ne produit pas de XML invalide ; il émet à la place GPU_Count = 0 en état critique.
Le défi reste visible sous forme d’alerte propre, et non comme ce silence suspect qui pourrait préparer la ruine.
Notre objectif, parce que nous avons vécu nous-mêmes le chaos coûteux de la fragmentation, est que Pandora FMS permette d’analyser tous ces signaux sur une même plateforme, avec des alertes intégrées ou notre métaconsole, par exemple, afin de disposer d’un point unique de visibilité et de contrôle, au lieu de jongler entre commandes, logs et dashboards dispersés.

Seuils, alertes et états critiques

Pandora FMS est là pour éviter le désastre. Pour cela, elle soulève jusqu’au dernier tapis et relie les points afin de vous offrir ce qui se rapproche le plus de la prescience des Atréides dans Dune. D’où son système de seuils et d’alertes.
Et pour que nous puissions commencer immédiatement sans tout créer de zéro, une situation qui nous conduit souvent à procrastiner sur ce qui compte, le plugin inclut des seuils prédéfinis, disjoints, qui ne se chevauchent pas, et bornés, avec un plancher et un plafond clairs, pour les métriques les plus sensibles :

• GPU_<i>_Memory_Used_Percent — Normal : 0-69 %. Warning : 70-84 %. Critical : 85-100 %.
• GPU_<i>_Temperature — Normal : 0-69 °C. Warning : 70-89 °C. Critical : 90-110 °C.
• GPU_<i>_Critical_Errors — Normal : 0. Critical : toute valeur supérieure à 0.

Rappelons que cette erreur critique a du sens sur les cartes de datacenter avec ECC, où toute erreur non corrigée doit être traitée comme prioritaire, sans demi-mesure. Sur les GPU grand public, cela ne s’applique pas.
Avec ces seuils, nous détecterons la pression mémoire, le risque thermique et les erreurs critiques sans tomber dans l’excès d’alertes, ce bruit qui finit par faire que plus personne ne prête attention à rien.
Et si une organisation a besoin d’autres valeurs, parfait. Nous pensons que chaque organisation est un monde à part, ils peuvent donc être ajustés à notre réalité concrète depuis la console elle-même.

Compatibilité et prérequis du plugin Pandora FMS

« Des promesses qui ne valent rien… », comme le dit la chanson. Chez Pandora FMS, nous ne les aimons pas du tout. Ainsi, pour éviter celles qui ne tiennent pas ensuite, il convient d’être clair sur ce que le plugin fait et ne fait pas :

• Il est orienté vers les GPU NVIDIA et utilise nvidia-smi comme source de données.
• Il fonctionne comme un plugin d’agent local et nécessite que le driver NVIDIA soit installé et que nvidia-smi soit disponible.
• Il est compatible avec Linux et Windows.
• Dans le cloud, il fonctionne avec des instances GPU d’AWS, Azure ou Google Cloud à condition que le GPU NVIDIA soit exposé au système d’exploitation et que le driver soit correctement installé. Les fournisseurs documentent ce point, comme dans les guides de Google Cloud ou d’AWS.
• Pour le moment, il ne prend pas en charge AMD ni Intel.
• Il ne monitore pas non plus les modèles d’IA, les prompts, le drift ni les métriques MLOps.
• L’intervalle recommandé de l’agent est d’au moins 30 secondes, bien que la valeur par défaut de 300 secondes soit adaptée à la plupart des environnements.

Et une nuance opérationnelle. Le plugin est pensé pour des hôtes individuels ou des environnements de taille moyenne.
Si votre cas concerne des clusters avec de nombreux GPU par nœud ou des architectures Kubernetes à grande échelle, il peut être nécessaire de le compléter avec des approches comme DCGM, Prometheus ou d’autres solutions d’agrégation.
Aucun outil ne fait tout, et le reconnaître nous semble honnête.

GPU monitoring et planification de capacité (capacity planning)

Compte tenu du nombre de premiers-nés que nous devons sacrifier au Dieu Machine pour pouvoir nous offrir un GPU, tout ce qui précède est largement justifié. Soit nous monitorons, soit le point le plus critique devient un angle mort.
Mais c’est dans le capacity planning que le monitoring se traduit en euros sonnants et trébuchants.
Grâce à l’historique d’utilisation, de mémoire, de température et de consommation, il est possible de détecter les GPU saturés de façon récurrente, d’identifier ceux qui sont sous-utilisés, de redistribuer les charges et de justifier les acquisitions auprès du service achats avec des données, plutôt qu’avec des intuitions et des supplications, car nous pourrons mesurer la croissance réelle de la demande.
Au final, c’est de la science des données appliquée à l’IT et une manière de transformer le passé en décisions.

Le monitoring des GPU comme partie d’un monitoring d’infrastructure IA (AI infrastructure monitoring)

On parle généralement des GPU parce qu’à notre époque ils se sont hissés au sommet de nombreuses infrastructures IT, mais ils ne jouent pas seuls le match.
Une infrastructure IA dépend aussi du CPU, de la RAM, du disque, du stockage, du réseau, des API, des services, des logs, des processus, des conteneurs, des bases de données et de la disponibilité de l’ensemble.
C’est pourquoi le GPU monitoring doit faire partie d’une stratégie plus large d’AI infrastructure monitoring.
Surveiller uniquement le GPU, c’est comme piloter l’Enterprise en ne prêtant attention qu’à ce qui se passe dans le moteur à antimatière, tout en ignorant les boucliers, le support vital ou même le cap.
C’est là que Pandora FMS devient ce légendaire ordinateur de bord qui savait tout.
Pandora intègre cette visibilité dans une exploitation IT complète, où l’IA appliquée à la gestion, l’IA générative et le deep learning apportent l’analyse que, reconnaissons-le en tant qu’espèce, aucun humain ne pourrait maintenir manuellement, ni n’aurait envie de le faire, car il n’y en a pas besoin.
C’est particulièrement pertinent dans les centres de données, où la disponibilité est considérée comme acquise jusqu’à ce qu’elle cesse de l’être, comme le sait bien toute bonne stratégie d’uptime monitoring.

Conclusion

Nous avons beaucoup parlé, mais concentrons-nous sur trois idées à retenir.

• Que les GPU sont des ressources critiques dans les infrastructures d’IA et HPC, et non un simple détail technique.
• Que les monitorer de manière isolée ne suffit pas, car une valeur sans contexte n’est que du bruit.
• Que la valeur réside dans leur intégration au monitoring global de l’infrastructure, où une métrique GPU dialogue avec les serveurs, les services, le réseau, les logs et les alertes.

Les outils NVIDIA fournissent la lecture, mais il faut une passerelle de commandement pour l’interpréter.
Pandora FMS aspire à être cette passerelle pour amener le GPU monitoring aux environnements on-premise, hybrides et enterprise. Car dans les interstices de l’IT vivent les gremlins de la machine, ceux qui vous causent des ennuis précisément là où vous ne surveillez pas.

Questions fréquentes

Rassemblons les questions les plus importantes sur le monitoring des GPU et leurs réponses.

Qu’est-ce que le GPU monitoring ?

Le GPU monitoring est la supervision continue de l’état, de l’utilisation, de la mémoire, de la température, de la consommation et des erreurs des unités de traitement graphique dans des environnements professionnels.
Il est utilisé pour contrôler les GPU employés dans l’IA, le HPC, l’inférence, l’entraînement de modèles ou le traitement intensif.
Comme je l’ai indiqué au début, il ne doit pas être confondu avec les outils de gaming, d’overclocking ou de tuning graphique.

Pourquoi est-il important de monitorer les GPU dans les infrastructures d’IA ?

Parce que les GPU font battre le cœur et sont, en plus, des ressources très coûteuses et critiques pour les charges d’inférence, d’entraînement et de machine learning.
Sans monitoring, nous sommes aveugles sur notre actif le plus critique, le laissant sans défense face à la saturation, la surchauffe, les erreurs ou la sous-utilisation, qui ont la fâcheuse habitude d’attaquer cachées dans les ombres et les zones que nous laissons sans surveillance.
Cela augmente le risque opérationnel et complique l’approbation de nouveaux investissements matériels par le département financier.

Quelles métriques faut-il monitorer sur un GPU ?

Les principales sont l’utilisation, la mémoire utilisée, libre et totale, le pourcentage de mémoire utilisée, la température, la consommation instantanée, la limite de consommation, la vitesse du ventilateur, l’état, les erreurs ECC critiques, le modèle de GPU, la version du driver et la version CUDA.
Presque rien, mais isolées, elles nous donnent un puzzle non assemblé. Ainsi, dans les environnements professionnels, ces métriques doivent être analysées avec le reste de l’infrastructure.

Quelle est la différence entre nvidia-smi, DCGM et une plateforme de monitoring ?

nvidia-smi est un utilitaire en ligne de commande permettant de consulter des métriques ponctuelles des GPU NVIDIA.
DCGM est orienté vers la gestion et le monitoring des GPU dans les datacenters et les clusters.
Une plateforme comme Pandora FMS centralise ces métriques avec le reste de l’infrastructure, avec historique, alertes, dashboards et rapports.

À partir de quelle température un GPU serveur est-il considéré comme critique ?

D’après notre expérience intégrée au plugin de GPU monitoring de Pandora FMS, une température à partir de 70 °C est considérée comme warning et, à partir de 90 °C, comme critical.
Ces seuils servent de référence opérationnelle, même s’ils peuvent varier selon le modèle de GPU, le fabricant et les conditions thermiques de l’environnement.

Que sont les erreurs ECC dans un GPU et pourquoi sont-elles importantes ?

Les erreurs ECC (Error-Correcting Code) sont des erreurs de mémoire détectées dans les GPU avec prise en charge ECC.
Les erreurs non corrigées peuvent indiquer des défaillances matérielles et doivent être traitées comme des incidents critiques.
Elles sont particulièrement pertinentes sur les GPU de datacenter comme A100, H100, Tesla ou RTX PRO. Sur les GPU grand public, le module est tout de même émis, mais avec une valeur 0 dans le plugin Pandora FMS, car il n’y a pas d’erreurs ECC à compter.

Peut-on monitorer des GPU dans des environnements on-premise avec Pandora FMS ?

Oui. Pandora FMS dispose d’un plugin d’agent local basé sur nvidia-smi, qui permet de monitorer des GPU NVIDIA sur des serveurs on-premise.
Il peut également être utilisé dans des environnements hybrides ou des instances cloud si le GPU NVIDIA est exposé au système d’exploitation et si le driver est correctement installé.

Comment le GPU monitoring aide-t-il au capacity planning ?

L’historique d’utilisation, de mémoire, de température et de consommation permet d’identifier les GPU saturés de façon récurrente, de détecter la sous-utilisation et de redistribuer les charges.
Il aide aussi à justifier les achats de matériel ou à reporter des extensions inutiles avec des données objectives d’utilisation et de capacité en main.

Que se passe-t-il si nvidia-smi n’est pas installé sur le serveur ?

Si nvidia-smi n’est pas disponible, le plugin Pandora FMS émet le module GPU_Count avec la valeur 0 en état critical.
Cela permet de générer une alerte sans interrompre l’exécution de l’agent ni produire de XML invalide.
Le défi reste visible comme absence de GPU ou comme défaillance de disponibilité de la source de données.

Le GPU monitoring suffit-il pour gérer une infrastructure d’IA ?

Non. Il fait partie d’un ensemble plus vaste.
Le GPU est un composant critique, mais une infrastructure d’IA dépend aussi du CPU, de la RAM, du stockage, du réseau, des services…
C’est pourquoi le GPU monitoring doit être intégré dans une stratégie plus large d’AI infrastructure monitoring. Sans cela, il sera impossible d’obtenir une vision opérationnelle complète.