freedzhost.cloud

Votre conteneur GPU tourne sur le processeur : trois pièges après une mise à jour ou un redémarrage

Niveau IntermédiaireTemps estimé 30 minÀ lire avant Docker avec accès à votre carte graphiqueUn mot inconnu ? Lexique

Ça marchait hier. Aujourd'hui, après une mise à jour du pilote ou un simple redémarrage, vos conteneurs de modèles refusent de démarrer ou, pire, démarrent et tournent sur le processeur sans rien dire. Les deux venaient du même fichier, et les deux se règlent pour de bon avec un petit service.

Ce que vous y gagnez. Une vérification de deux minutes qui dit si votre carte sert vraiment, le correctif des deux pannes que nous avons eues, et un service de démarrage qui les empêche de revenir. Le nôtre tourne à chaque démarrage depuis.

1. La carte sert-elle vraiment ?

Un modèle qui passe en bonne santé en sept secondes et répond à quelques jetons par seconde tourne sur le processeur. Vérifiez trois choses :

docker exec modele nvidia-smi -L        # la carte est visible...
docker logs modele 2>&1 | grep -i -E "cuda|offloaded"   # ...mais CUDA est-il vivant ?

Si la deuxième ligne dit failed to initialize CUDA: unknown error, ou offloaded 0/.. couches, la carte est vue mais pas utilisée. Voir la carte ne prouve rien : nvidia-smi n'a besoin que des fichiers du pilote, CUDA a aussi besoin des nœuds de périphériques.

2. Premier piège : la description est plus vieille que le pilote

Avec CDI, Docker lit /etc/cdi/nvidia.yaml, une liste des fichiers et périphériques du pilote écrite au moment de sa génération. Mettez le pilote à jour sans la régénérer, et la liste nomme des fichiers qui n'existent plus :

failed to fulfil mount request: open /usr/lib/libnvidia-egl-wayland.so.1.1.21: no such file or directory

Recréer le conteneur ne change rien : la description est la source, pas le conteneur. Régénérez-la :

sudo nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

3. Deuxième piège : un numéro de périphérique qui change à chaque démarrage

Le plus coriace. Après un redémarrage, CUDA échouait avec « unknown error » alors que l'hôte, lui, marchait. Nous avons coupé en deux les options du conteneur, une à une :

La cause : le périphérique nvidia-uvm reçoit son numéro au démarrage, dynamiquement. Il valait 234 quand la description a été écrite, 235 après le redémarrage. Le périphérique était monté avec le nouveau numéro, mais le conteneur n'avait droit qu'à l'ancien.

grep nvidia-uvm /proc/devices     # le numéro du jour

4. Le correctif définitif : régénérer à chaque démarrage

Un petit service, lancé avant Docker, règle les deux pièges d'un coup :

# /etc/systemd/system/nvidia-cdi-generate.service
[Unit]
Description=Regenerate the NVIDIA CDI spec (nvidia-uvm major changes each boot)
After=systemd-modules-load.service
Before=docker.service

[Service]
Type=oneshot
ExecStartPre=/usr/bin/nvidia-modprobe -u -c=0
ExecStart=/usr/bin/nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

[Install]
WantedBy=multi-user.target
sudo systemctl enable nvidia-cdi-generate.service

nvidia-modprobe -u charge d'abord le module nvidia-uvm, pour que la description soit écrite avec le numéro de ce démarrage.

Pièges

Une mise à jour du pilote sans redémarrage cache le premier piège : les conteneurs en cours gardent leurs anciens fichiers ouverts. Il surgit des jours plus tard, au premier vrai démarrage. Régénérez juste après la mise à jour.

Quand plus rien n'a de sens, coupez en deux : retirez une option à la fois et gardez celle qui change le résultat.

Sources

Utile ? Dites-nous ce qu'il faut mesurer ensuite.