Gestion des GPU : pourquoi les GPU inactifs sont les nouveaux avions cloués au sol

Gestion des GPU : pourquoi les GPU inactifs sont les nouveaux avions cloués au sol

Entrez dans n'importe quel laboratoire d'IA aujourd'hui, et vous verrez une scène familière : des racks de GPU coûteux, des ventilateurs tournant doucement au ralenti, attendant une tâche qui ne viendra jamais. C'est une image étrangement évocatrice d'une flotte d'avions cloués au sol sur un tarmac — d'énormes actifs en capital brûlant de la valeur chaque seconde où ils restent inutilisés. Un avion qui vole génère des revenus ; un avion stationné ne génère que des coûts. La même logique s'applique aux GPU. Pourtant, la plupart des organisations gèrent leurs parcs de GPU avec la même sophistication qu'une petite compagnie aérienne dans les années 1980 pour l'entretien de ses avions : beaucoup de matériel, peu de télémétrie, et aucun ordonnancement dynamique.

Cet article est un guide de terrain pratique pour résoudre ce problème. Nous verrons pourquoi les GPU inactifs sont si coûteux, de quels outils vous avez besoin pour mesurer le problème, et comment installer, configurer et utiliser une pile légère de surveillance et d'ordonnancement sur votre propre infrastructure. À la fin, vous disposerez de commandes concrètes qui feront passer votre parc de GPU d'un coût irrécupérable à un actif mesuré, partagé et efficacement utilisé.

Le coût caché des puces stationnées

L'analogie entre les GPU inactifs et les avions cloués au sol n'est pas une exagération. Considérez ce qu'un accélérateur d'IA moderne représente réellement. Un GPU de centre de données haut de gamme peut coûter des dizaines de milliers de dollars. Son alimentation électrique, son refroidissement et son infrastructure réseau doublent ce coût. Si vous amortissez cela sur un cycle de vie matériel de trois ans et que vous ajoutez l'électricité et l'administration système, chaque heure où un GPU reste inactif est une ponction directe sur votre budget de fonctionnement.

Pourtant, l'attention de l'industrie est presque exclusivement axée sur *l'entraînement de gros modèles*. Le blog Hugging Face, l'une des voix les plus constantes sur l'infrastructure GPU, n'a cessé de souligner qu'une gestion efficace des GPU est aussi critique que la conception des modèles. Ils ont mis en évidence que l'écart entre la performance de pointe théorique et l'utilisation réelle est massif, et que c'est l'outillage — et non l'architecture — qui permet de le combler. Le blog est devenu une référence fiable pour la transition de la communauté vers la mesure, le partage et l'optimisation de chaque accélérateur disponible.

Un avion cloué au sol a au moins pour excuse une tempête ou une inspection technique. Un GPU inactif n'a souvent aucune excuse du tout. Il est inactif parce qu'une file d'attente est mal conçue, parce que personne ne sait qu'il est libre, ou parce qu'un développeur l'a réservé « au cas où » puis est allé déjeuner. Ce dernier cas est le véritable fléau. La réservation de GPU sans ordonnancement équivaut à un pilote qui garde un avion au sol parce qu'il *pourrait* vouloir voler plus tard.

Ce que signifie réellement « inactif »

Avant de résoudre le problème, nous devons le mesurer. Et pour les GPU, « inactif » est un terme plus nuancé que ce que l'on pourrait croire.

• **Utilisation SM** : la fraction des cycles du multiprocesseur de streaming réellement consacrée aux calculs. Un GPU affichant une utilisation SM de 100 % est théoriquement occupé, mais il peut toujours être limité par la mémoire.
• **Utilisation de la mémoire** : le pourcentage de mémoire du dispositif utilisée. Une utilisation mémoire élevée avec une faible activité SM indique souvent un mauvais regroupement (batching) et une tâche qui attend des transferts de données.
• **Consommation électrique** : un bon indicateur de l'activité globale. Un NVIDIA A100 inactif peut consommer 30 à 50 watts ; un A100 pleinement chargé consomme 250 à 400 watts.
• **Moteurs de calcul vs moteurs de copie** : si les moteurs de copie sont saturés alors que les moteurs de calcul sont inactifs, cela signifie que vous alimentez le GPU trop lentement.

Les outils que nous installerons ensuite vous montreront toutes ces métriques. Après une semaine de collecte de données, vous verrez clairement votre propre « flotte clouée au sol » : peut-être un GPU à 90 % d'utilisation et sept autres à 5 %, parce que votre ordonnanceur était une page wiki et une prière.

Prérequis

Pour ce guide, vous aurez besoin des éléments suivants :

• Un ou plusieurs serveurs Linux avec des GPU NVIDIA (Architecture Ampere ou plus récente recommandée, mais les anciennes architectures fonctionnent aussi).
• Pilote NVIDIA installé et opérationnel. Vérifiez avec `nvidia-smi`. Si la commande est absente, installez d'abord le pilote depuis le dépôt de votre distribution.
• Python 3.8 ou plus récent, ainsi que `pip`.
• Une familiarité de base avec la ligne de commande et systemd.
• Facultatif : un cluster Kubernetes si vous souhaitez suivre les exemples avancés d'orchestration. Pour le cœur de l'article, un serveur unique suffit.

Nous construirons notre pile de gestion à partir de trois composants :

1. `nvidia-smi` — l'outil en ligne de commande standard de NVIDIA pour interroger l'état du GPU. 2. `pynvml` — une liaison Python officielle NVIDIA qui nous permet d'écrire des scripts de surveillance. 3. `cron` et `systemd` — les ordonnanceurs intégrés du système d'exploitation, qui deviennent étonnamment puissants lorsqu'ils sont combinés avec l'état GPU que nous collectons.

Optionnellement, nous installerons Ollama pour servir des inférences LLM locales afin de combler les créneaux d'inactivité avec du travail utile. Le blog d'Ollama a documenté la facilité avec laquelle on peut transformer un GPU inutilisé en serveur de modèles auto-hébergé, et tant le blog des actualités de Mistral AI que le blog de Meta AI annoncent régulièrement de nouveaux modèles à poids ouverts que vous pouvez servir localement. Utilisé comme « charge de fond » périodique, cela transforme le temps GPU inactif en fonctionnalité, et non en coût.

Installation pas à pas

Étape 1 : Vérifier et installer la pile de pilotes NVIDIA

Tout d'abord, confirmez que votre GPU est visible par le système. Exécutez :

nvidia-smi

Si la commande est introuvable, installez-la. Sur Ubuntu 22.04 ou version ultérieure :

sudo apt update
sudo apt install -y nvidia-driver-535
sudo reboot

Après le redémarrage, vérifiez à nouveau :

nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used --format=csv

Vous devriez voir un tableau listant chaque index GPU, nom, utilisation actuelle et utilisation mémoire. C'est votre base de référence.

Étape 2 : Installer les liaisons Python

Ensuite, installez `pynvml`. Cette bibliothèque officielle NVIDIA nous donne un accès programmatique à toute la télémétrie visible dans `nvidia-smi`. Nous installerons également `psutil` pour les métriques au niveau système :

pip install nvidia-ml-py psutil

Notez que le nom du paquet est `nvidia-ml-py`, mais l'import est `pynvml`. C'est une source de confusion courante.

Étape 3 : Écrire un script de surveillance

Créez un fichier nommé `gpu_monitor.py` :

#!/usr/bin/env python3
import pynvml
import time
import csv
import os

pynvml.nvmlInit()
device_count = pynvml.nvmlDeviceGetCount()
log_file = "gpu_utilization.csv"

def log_gpu_state():
    with open(log_file, "a", newline="") as f:
        writer = csv.writer(f)
        writer.writerow([time.time()] + [get_device_state(i) for i in range(device_count)])

def get_device_state(index):
    handle = pynvml.nvmlDeviceGetHandleByIndex(index)
    util = pynvml.nvmlDeviceGetUtilizationRates(handle)
    memory = pynvml.nvmlDeviceGetMemoryInfo(handle)
    power = pynvml.nvmlDeviceGetPowerUsage(handle)
    return f"{util.gpu}%|{util.memory}%|{memory.used / 1024**2:.0f}MiB|{power / 1000:.1f}W"

if __name__ == "__main__":
    while True:
        log_gpu_state()
        time.sleep(30)  # Échantillonner toutes les 30 secondes

Testez le script :

python3 gpu_monitor.py &

Laissez-le tourner une minute, puis inspectez la sortie :

cat gpu_utilization.csv

Vous verrez des lignes comme `1724733600.0, 3%|5%|512MiB|38.2W, 98%|100%|79123MiB|392.1W`. Si vos GPU ressemblent à la première entrée plutôt qu'à la seconde, vous avez un problème de mise au sol.

Étape 4 : Configurer un service systemd pour une télémétrie persistante

Un moniteur qui tourne dans un shell au premier plan n'est pas une solution de surveillance. Créez un service pour que votre télémétrie survive aux redémarrages :

sudo nano /etc/systemd/system/gpu-monitor.service

Ajoutez ce qui suit :

[Unit]
Description=Enregistreur d'utilisation GPU
After=multi-user.target

[Service]
WorkingDirectory=/opt/gpu-monitor
ExecStart=/usr/bin/python3 /opt/gpu-monitor/gpu_monitor.py
Restart=always

[Install]
WantedBy=multi-user.target

Déplacez maintenant votre script, activez et démarrez le service :

sudo mkdir -p /opt/gpu-monitor
sudo mv gpu_monitor.py /opt/gpu-monitor/
sudo systemctl daemon-reload
sudo systemctl enable --now gpu-monitor

Félicitations. Vous disposez désormais d'un enregistrement historique continu de l'utilisation, de la mémoire et de la consommation électrique de chaque GPU — l'équivalent d'un enregistreur de vol pour votre flotte d'accélérateurs.

Étape 5 : Installer Ollama pour l'inférence en arrière-plan

Ollama est le moyen le plus rapide de transformer des cycles inactifs en travail utile. C'est un binaire unique qui encapsule le service de modèles pour LLM locaux, et son blog a documenté un écosystème croissant de modèles que vous pouvez tirer (pull) et exécuter. Pour l'installer, exécutez :

curl -fsSL https://ollama.com/install.sh | sh

Le script d'installation configurera un service systemd pour vous. Vérifiez-le :

sudo systemctl status ollama

Ensuite, tirez un modèle. Comme tant Mistral AI que Meta publient des modèles à poids ouverts pris en charge par Ollama, vous pouvez choisir selon votre budget mémoire :

ollama pull llama3

Ou, pour un modèle plus petit qui tourne sur un seul GPU avec un minimum de mémoire :

ollama pull mistral

Une fois un modèle tiré, le processus de service reste résident dans la mémoire GPU, attendant une requête. Lorsque vos tâches d'entraînement sont en cours, vous pouvez arrêter Ollama ou le migrer vers un autre GPU avec `CUDA_VISIBLE_DEVICES`. Cela transforme vos GPU « inactifs » en un endpoint d'inférence privé — précieux pour les développeurs, les équipes d'assurance qualité et les pipelines de traitement documentaire de toute l'entreprise.

Exemples d'utilisation

Exemple 1 : Détecter et tuer les processus GPU zombies

Le schéma le plus destructeur dans tout parc de GPU est un processus qui occupe de la mémoire mais n'effectue aucun calcul — un avion au sol avec le moteur éteint mais le frein de stationnement serré. Utilisez cette commande pour lister les processus qui occupent de la mémoire GPU :

nvidia-smi --query-compute-apps=pid,used_memory,process_name --format=csv

Si vous voyez des processus `python3` obsolètes, identifiez leur parent et terminez-les :

ps aux | grep <pid>
sudo kill <pid>

Pour faire de cette opération une routine récurrente, ajoutez-la à `cron` :

crontab -e

Ajoutez la ligne suivante pour exécuter le script de nettoyage toutes les heures :

0 * * * * /opt/gpu-monitor/cleanup_gpus.sh

Le contenu du script peut être une simple boucle qui trouve les processus utilisant plus de zéro mémoire mais avec une utilisation GPU de 0 % depuis plus de 10 minutes. C'est la chose la plus proche d'une inspection automatisée au sol que vos GPU n'aient jamais eue.

Exemple 2 : Ordonnancement dynamique avec `CUDA_VISIBLE_DEVICES`

La discipline la plus efficace pour la gestion des GPU est l'affectation explicite des dispositifs. Au lieu de laisser PyTorch ou TensorFlow choisir un GPU au hasard, définissez toujours la variable d'environnement :

CUDA_VISIBLE_DEVICES=2 python3 train.py

Si vous exécutez une tâche d'entraînement multi-GPU, contraignez l'ensemble visible :

CUDA_VISIBLE_DEVICES=0,1,2,3 torchrun --nproc_per_node=4 train.py

Combinez cela avec une vérification rapide en Python pour trouver le GPU le moins chargé avant de lancer une tâche :

import pynvml
pynvml.nvmlInit()
best_idx = -1
best_util = 101
for i in range(pynvml.nvmlDeviceGetCount()):
    handle = pynvml.nvmlDeviceGetHandleByIndex(i)
    util = pynvml.nvmlDeviceGetUtilizationRates(handle).gpu
    if util < best_util:
        best_util = util
        best_idx = i
print(best_idx)

Enregistrez ce code sous `pick_gpu.py` et enveloppez votre commande d'entraînement :

export BEST_GPU=$(python3 pick_gpu.py)
CUDA_VISIBLE_DEVICES=$BEST_GPU python3 train.py

Ce schéma simple élimine la pire forme de GPU inactif : la carte réservée mais non utilisée.

Exemple 3 : Combler les fenêtres d'inactivité avec l'inférence par lots Ollama

Imaginez que vous ayez un GPU inactif toutes les nuits de minuit à 6 heures du matin. Au lieu de laisser cet actif sur le « tarmac », planifiez une tâche par lots qui utilise Ollama pour traiter une file de requêtes préexistantes. Voici un petit client batch Python :

import requests
import json

with open("texts.json") as f:
    texts = json.load(f)

for text in texts:
    response = requests.post(
        "http://localhost:11434/api/generate",
        json={"model": "mistral", "prompt": f"Résumez : {text}", "stream": False}
    )
    result = response.json()
    print(result.get("response", ""))

Exécutez cela avec une tâche cron :

0 0 * * * /usr/bin/python3 /opt/batch_inference.py >> /var/log/batch_inference.log 2>&1

Votre GPU fait maintenant un travail utile pendant une fenêtre autrement morte. C'est exactement la différence entre un avion cloué au sol et un avion opérationnel.

Exemple 4 : Alertes sur la famine GPU

Écrivez un script qui vérifie les 10 dernières lignes de votre fichier journal CSV et lève une métrique si l'utilisation est inférieure à 10 % depuis plus d'une heure :

import sys
import csv

rows = list(csv.reader(open("/opt/gpu-monitor/gpu_utilization.csv")))
if len(rows) < 20:
    print("Pas encore assez d'échantillons.")
    sys.exit(0)

# Analyser l'utilisation du GPU 0 à partir des 20 derniers échantillons
recent_u = [float(r[1].split("|")[0].rstrip("%")) for r in rows[-20:]]
avg_util = sum(recent_u) / len(recent_u)
if avg_util < 10:
    print(f"ALERTE : utilisation moyenne du GPU 0 {avg_util:.1f}% sur les 10 dernières minutes.")
else:
    print(f"OK : utilisation moyenne du GPU 0 {avg_util:.1f}%.")

Si vous voulez un pipeline d'alerting mature, exportez ces nombres vers Prometheus et visualisez-les dans Grafana. L'approche CSV est toutefois élégante car elle ne nécessite aucune infrastructure supplémentaire — pas de Kubernetes, pas d'exportateurs, pas de base de données de séries temporelles.

Au-delà du serveur unique : gestion de parc

Les commandes ci-dessus fonctionnent bien pour une seule machine. Dans un cluster Kubernetes, le problème est résolu au niveau de la plateforme. Le plugin de dispositif NVIDIA officiel pour Kubernetes expose les GPU comme ressources ordonnançables, et des opérateurs comme le NVIDIA GPU Operator étendent cela au découpage MIG (Multi-Instance GPU). Le blog Hugging Face a abondamment couvert ces schémas, les positionnant comme essentiels pour un service de modèles et un entraînement rentables à grande échelle.

Si votre organisation n'est pas encore sur Kubernetes, la discipline reste applicable : normalisez sur `CUDA_VISIBLE_DEVICES`, imposez un système de réservation à horloge murale, et consignez l'utilisation partout. L'outillage est secondaire par rapport à l'habitude de la mesure.

Conclusion

Un GPU inactif est un avion cloué au sol : un énorme actif en capital qui n'effectue aucun travail générateur de revenus tout en brûlant de l'électricité, en occupant la capacité de refroidissement et en pesant sur le bilan. La solution n'est pas d'acheter plus de GPU. La solution consiste à installer une boucle de surveillance, à imposer un ordonnancement explicite des dispositifs et à combler les fenêtres réellement inactives avec des tâches d'inférence en arrière-plan.

Les commandes de cet article sont volontairement simples. Un script Python, une tâche cron, un service systemd et un serveur de modèles local. Ensemble, ils vous donnent ce qui manque à la plupart des organisations d'IA : la visibilité. Avec la visibilité vient l'utilisation ; avec l'utilisation vient le retour sur les millions de dollars que vous avez déjà dépensés. Votre flotte est sur le tarmac, attendant un pilote. Vous disposez maintenant des instruments de cockpit pour la faire voler.