Gestion des épingles Ubuntu et des pilotes NVIDIA pour les serveurs d'IA

Si vous êtes responsable d'un serveur d'IA dont dépendent d'autres personnes, la cause la plus probable de votre prochaine panne n'est ni une défaillance matérielle, ni un bug du modèle, ni une coupure de courant. Il s'agit d'une apt-get upgrade que vous ou votre distribution avez exécuté en arrière-plan, lequel a installé un nouveau noyau, avec lequel le module DKMS de NVIDIA n'a pas pu reconstruire correctement, et qui a laissé nvidia-smi retour Failed to initialize NVML: Driver/library version mismatch au prochain redémarrage. C'est l'appel au support Kentino le plus fréquent après deux ou trois mois de fonctionnement d'un serveur.

Cet article explique comment éviter ce genre de problème. Il aborde la version LTS d'Ubuntu à choisir mi-2026, la procédure d'installation du pilote NVIDIA, le verrouillage du pilote et du noyau pour empêcher une mise à jour non supervisée d'endommager votre système, et la procédure de récupération en cas de problème.

Le public est constitué de tous ceux qui vont saisir du texte. sudo sur un boîtier à 4 ou 8 GPU censé fonctionner pendant des années.

Pourquoi Ubuntu LTS ?

Il existe des distributions Linux performantes autres qu'Ubuntu : Debian stable, RHEL, Rocky, AlmaLinux et openSUSE Leap. Aucune n'est mauvaise en soi, et certaines sont même sans doute mieux conçues. Nous recommandons néanmoins Ubuntu LTS pour les serveurs d'IA, pour quatre raisons sans rapport avec l'élégance.

NVIDIA effectue d'abord ses tests sur Ubuntu LTS. apt dépôts cuda-keyring paquets explicitement pour ubuntu2204, ubuntu2404, et (depuis le printemps 2026) ubuntu2604Le guide d'installation des pilotes mentionne Ubuntu LTS par son numéro de version ; les autres distributions sont mentionnées à la fin du document.

L'écosystème de conteneurs suppose Ubuntu. Chaque image NGC (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserverTensorRT-LLM est basé sur Ubuntu LTS. La distribution hôte n'a pas besoin d'être identique à celle du conteneur, mais lorsqu'elle l'est, les dépendances au niveau du noyau et de l'espace utilisateur sont parfaitement compatibles.

La plupart des outils d'IA tiers supposent l'utilisation d'Ubuntu dans leur fichier README. vLLM, llama.cpp, SGLang, les instructions de compilation de FlashAttention, les exemples Hugging Face Accelerate : tous ces outils ont été conçus et testés en priorité sous Ubuntu. RHEL fonctionne ; en cas de problème, c'est à vous de le signaler.

Le plus grand nombre de personnes ayant déjà rencontré votre problème se trouve sur Ubuntu. nvidia-smi Si la fonction renvoie des données erronées à 2 h du matin, les trois premiers résultats sur Stack Overflow concerneront Ubuntu. Cela a une importance démesurée.

Debian et RHEL sont des choix acceptables pour un serveur d'IA. Leur environnement de test est plus restreint, les cycles de validation NVIDIA sont plus longs et la communauté est plus petite en cas de problème. Si vous avez une raison organisationnelle solide de privilégier l'une d'entre elles (environnement isolé FedRAMP, licence de site RHEL existante, équipe d'administrateurs système utilisant Debian), optez pour cette solution. Sinon, choisissez Ubuntu LTS par défaut.

22.04 contre 24.04 contre 26.04 en mai 2026

Trois versions LTS sont actuellement prises en charge. Voici la matrice :

Quelques éléments intéressants à retenir de ce tableau.

Ubuntu 22.04 reste la version la plus installée au monde et celle pour laquelle le processus de validation de NVIDIA dispose du plus long historique. Si vous utilisez Ubuntu 22.04, inutile de vous précipiter pour la mettre à niveau. Elle bénéficie d'un support complet jusqu'en avril 2027 avec les mises à jour standard, et Ubuntu Pro étend la maintenance de sécurité jusqu'en 2032 si nécessaire. En revanche, si vous installez un nouveau serveur mi-2026, vous choisissez votre système d'exploitation pour les quatre à cinq années suivantes. Ubuntu 22.04 ne bénéficie plus que d'un an de support standard. Évitez cette version.

La version 24.04 est idéale pour les applications d'IA en production en 2026. Elle a bénéficié de deux années de corrections de bugs et de révisions du noyau HWE, et chaque branche de pilote NVIDIA à partir de la version R535 a inclus des packages de qualité professionnelle dans le système NVIDIA. ubuntu2404 Dans le dépôt, chaque image NGC indique la version 24.04 comme système d'exploitation de base pris en charge, et le support standard prend fin en avril 2029. C'est cette version que nous utilisons actuellement sur les nouvelles configurations Kentino.

Ubuntu 26.04 vient d'être publié. Il intègre R595 comme pilote par défaut dans le dépôt officiel d'Ubuntu, inclut CUDA dans les dépôts principaux pour la première fois et propose des améliorations significatives pour Wayland et NVIDIA, importantes pour les ordinateurs de bureau mais pas pour les serveurs d'inférence sans interface graphique. Le risque pour un serveur d'IA réside dans le timing : les trois à quatre premiers mois suivant sa mise en service… .0 Version LTS, ubuntu-drivers Les recommandations et le comportement du module DKMS évoluent, et le dépôt NVIDIA lui-même nécessite plusieurs cycles pour valider entièrement chaque branche de pilote par rapport au nouveau noyau. D'après les versions LTS précédentes (20.04, 22.04, 24.04), la première mise à jour corrective… 26.04.1 En août 2026, les déploiements en production deviendront pertinents. Si vous pouvez patienter, patientez. Sinon, effectuez un test de charge pendant deux semaines avant d'y déployer des éléments critiques.

Les chemins d'installation des pilotes

Il existe trois façons d'installer le pilote NVIDIA sur un système Ubuntu. Elles ne se valent pas toutes.

ubuntu-drivers install C'est la solution de facilité. Canonical propose un outil qui analyse votre matériel, sélectionne une branche de pilote recommandée et installe le paquet correspondant depuis les archives Ubuntu. Il gère la signature du démarrage sécurisé (avec la clé de Canonical), prend en charge les noyaux HWE et fonctionne parfaitement sur un ordinateur de bureau équipé d'une seule carte graphique grand public. Sur un serveur d'IA, c'est la solution fragile : la branche recommandée peut changer d'une version à l'autre. ubuntu-drivers-common paquet, la version que vous obtenez sur apt update Cela dépend des paquets Ubuntu de cette semaine, et vous avez moins de contrôle sur la version mineure exacte du pilote installée sur le disque. Utilisez-le pour l'ordinateur portable. Ne l'utilisez pas pour le serveur.

apt du dépôt CUDA de NVIDIA c'est la voie manuelle mais contrôlable. Vous ajoutez NVIDIA cuda-keyring package, qui configure le bon apt Choisissez la source correspondant à votre version d'Ubuntu, puis installez précisément les paquets que vous souhaitez. cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580Sans surprise, NVIDIA gère le packaging, vous gérez la version. C'est le comportement par défaut de Kentino.

Le .run installateur à partir de developer.nvidia.com écrit des fichiers dans /usr/local, gère ses propres reconstructions de modules noyau et ne s'intègre pas à apt Absolument pas. C'est la bonne réponse dans deux cas précis : le matériel tout neuf pour lequel la branche de pilote dont vous avez besoin n'a pas encore été intégrée. apt Vous n'avez pas encore accès au dépôt, ni à un poste de travail où vous développez ou déboguez activement le pilote. Sinon, ce n'est pas la bonne réponse. Cela créera un conflit avec DKMS et ne sera pas pris en charge par apt-mark holdet cela dysfonctionnera discrètement lors de la prochaine mise à jour du noyau, car le chemin de reconstruction est désormais manuel.

Concrètement, sur un serveur 24.04 avec une installation propre, la séquence par défaut de Kentino est la suivante :

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

# Install the driver branch you actually want, by number.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Après le redémarrage, nvidia-smi Il devrait indiquer le pilote 580.x et la version CUDA maximale prise en charge par ce pilote (CUDA 13 pour R580). Voilà pour l'installation complète. Remarquez ce qui n'y figure pas : aucun cuda méta-paquet, non cuda-toolkit-13-0 (uniquement nécessaire si vous compilez du code CUDA sur l'hôte — voir L02), non ubuntu-driversVous avez choisi la version, vous l'avez installée, vous savez ce qui se trouve sur le disque.

Les branches principales qui comptent en 2026

NVIDIA distribue ses pilotes Linux par branches, chacune avec sa propre fenêtre de support. À partir de mi-2026 :

Le R580 est le choix par défaut idéal en 2026. Il prend en charge tous les GPU de la gamme Kentino (5090, 4090, RTX Pro 6000 Blackwell les deux éditions, L40, L4), y compris ceux de l'architecture Blackwell. sm_120 Il offre une capacité de calcul élevée et intègre la prise en charge native de CUDA 13, cible de toutes les versions récentes de vLLM, PyTorch 2.10/2.11 et TensorRT-LLM. La version R570 est le choix LTSB prudent si vous disposez d'un parc de serveurs Ada (4090 / L40 / L4) ne nécessitant pas les dernières fonctionnalités et si vous souhaitez reporter la migration des pilotes d'un an. La version R595 est celle fournie par défaut avec Ubuntu 26.04 et est recommandée pour le matériel le plus récent. Sur un serveur exécutant uniquement des composants Kentino actuels, la version R580 est plus prudente et offre des fonctionnalités équivalentes.

La danse des trois versions du pilote / CUDA / PyTorch

Trois versions indépendantes doivent s'aligner. Elles se superposent comme ceci :

PyTorch wheel (e.g. torch==2.11.0+cu130)
        │  ships its own CUDA runtime, cuDNN, NCCL inside the wheel
        ▼
CUDA runtime version (here: 13.0)
        │  the driver must support this CUDA version or newer
        ▼
NVIDIA driver branch (here: R580 → supports CUDA 13.x)

La règle est la suivante : le pilote prend en charge une version maximale de l’environnement d’exécution CUDA. Toute version antérieure à cette limite, appartenant à la même version majeure, fonctionnera. Ainsi, la R580 (CUDA 13.x maximum) exécute les roues PyTorch compilées avec les versions 13.0, 13.1 et 13.2 ; elle n’exécute pas les roues compilées avec la version (hypothétique) CUDA 14.0 tant que la branche du pilote n’est pas mise à jour. Les pilotes plus anciens ne peuvent pas exécuter les versions plus récentes de CUDA ; certaines cartes graphiques pour centres de données offrent une compatibilité ascendante, mais celle-ci est fragile et n’est pas recommandée.

Carte pratique des serveurs Kentino actuels :

Votre tâche consiste à corriger le pilote et à assurer la compatibilité avec tous les services situés au-dessus. Vous n'avez pas besoin d'installer CUDA sur l'hôte si vous utilisez des conteneurs pour tout servir (et vous devriez le faire – voir L02L'hôte a besoin du pilote et du kit d'outils de conteneurisation. C'est tout.

Épingler — la commande la plus précieuse de cet article

Une fois que le conducteur est à bord et nvidia-smi Si c'est content, épinglez-le. Épingler signifie dire apt Ne pas mettre à niveau, rétrograder ou supprimer des paquets spécifiques, même si une dépendance ou une mise à jour de sécurité les concerne. La commande est : apt-mark hold.

# Pin the driver branch.
sudo apt-mark hold \
  cuda-drivers \
  cuda-drivers-580 \
  nvidia-driver-580 \
  nvidia-driver-580-server \
  nvidia-dkms-580 \
  libnvidia-compute-580 \
  libnvidia-compute-580-server

# Pin the running kernel and its headers — DKMS needs both to rebuild,
# and a kernel jump that DKMS does not handle is exactly how you lose the GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# If you are on the Ubuntu HWE kernel meta-package, hold that too:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Verify.
apt-mark showhold

Cela représente environ la moitié des appels « mon serveur d'IA a cessé de fonctionner » résolus. apt update && apt upgrade Lors d'une mise à niveau (manuellement, via un outil de gestion de configuration ou en mode sans assistance), les paquets mis en attente ne seront pas déplacés. Ils apparaîtront dans la liste « mis en attente » du rapport de mise à niveau, et vous pourrez les examiner et les débloquer lors d'une fenêtre de maintenance, au moment opportun.

Quelques pièges. Les gens tiennent nvidia-driver-580 et oublier cuda-drivers-580, qui est le méta-paquet proprement dit sur le dépôt CUDA. Si cuda-drivers-580 Les mises à jour sont effectuées car une dépendance transitive requiert une version mineure plus récente ; elle téléchargera donc une nouvelle version. nvidia-dkms-580 Vous avez perdu le code PIN. Indiquez les deux. Certains possèdent l'image du noyau mais pas les en-têtes ; le noyau se met à jour malgré tout grâce à un méta-paquet, et DKMS ne parvient pas à trouver les en-têtes lors de la reconstruction. nvidia-smi Fonctionne jusqu'au redémarrage, puis ne fonctionne plus. Conservez toujours l'image et les en-têtes ensemble.

Les pièges du noyau et de DKMS

DKMS (Dynamic Kernel Module Support) est le système qui reconstruit les modules du noyau hors du noyau principal à chaque modification de celui-ci. nvidia-dkms-XXX Le paquet enregistre le pilote en tant que module DKMS afin que, en théorie, une mise à niveau du noyau gérée par apt déclenche une reconstruction propre du module et que vous redémarriez sur un système fonctionnel.

En pratique, les reconstructions DKMS échouent de trois manières récurrentes :

Les en-têtes du noyau ne sont pas installés pour le nouveau noyau — ce qui est fréquent lorsque le paquet noyau a été installé mais que le paquet d'en-têtes a été exclu par une préférence apt ou une sélection personnalisée. Le nouveau noyau démarre, mais le module NVIDIA est manquant. nvidia-smi Renvoie « NVIDIA-SMI a échoué car il n'a pas pu communiquer avec le pilote NVIDIA. »

Le nouveau noyau est trop récent pour la branche de développement des pilotes. La version R570 ne se compile pas correctement avec le noyau 6.14 le plus récent ; la version R580, si. Si une mise à jour HWE vous force à utiliser un noyau avec lequel la branche de développement des pilotes n'a jamais été testée, DKMS génère une erreur de compilation. /var/lib/dkms/nvidia/.../make.log et vous redémarrez sur un système fonctionnel mais sans carte graphique.

Le démarrage sécurisé est activé et le module reconstruit n'est pas signé. ubuntu-driversLes paquets installés incluent la signature Canonical. Ce n'est pas le cas des paquets du dépôt CUDA de NVIDIA ; ils nécessitent l'enregistrement d'une clé de propriétaire de machine (MOK) et la signature des modules recompilés à chaque modification du noyau. DKMS peut effectuer la signature automatiquement avec une configuration appropriée par module, mais cette configuration doit être effectuée avant la première recompilation, et non après un échec de démarrage du système. Si le démarrage sécurisé n'est pas nécessaire (et sur un serveur d'inférence sans interface graphique dans une baie verrouillée, il ne l'est généralement pas), désactivez-le dans le firmware avant d'installer le pilote pour éviter ce type de problème.

Le verrouillage du noyau permet de contourner ces trois problèmes. Le noyau ne change pas sans votre intervention, les en-têtes restent compatibles et le module recompilé continue de se charger. Lorsque vous souhaitez utiliser un nouveau noyau (pour corriger une vulnérabilité ou ajouter une fonctionnalité), vous le faites délibérément, en créant un instantané, prêt à revenir en arrière.

CUDA bare-metal — quand (rarement) c'est encore le cas

L02 Cet article démontre que l'utilisation de CUDA directement sur le matériel est aujourd'hui généralement un mauvais choix : les conteneurs masquent la complexité des versions de CUDA, découplent l'hôte de la charge de travail et n'entraînent qu'un impact négligeable sur les performances. Cela se vérifie dans environ 95 % des cas.

Les exceptions sont rares. Profilage GPU au niveau du noyau avec Nsight Systems / Nsight Compute, où la couche conteneur masque les appels système importants. Développement de pilotes : exécution de pilotes préliminaires NVIDIA, débogage de plantages impliquant le module noyau lui-même. Environnements très isolés où la récupération et la fiabilité des images OCI sont plus complexes que la maintenance d'un miroir apt figé. Quelques rares centres de calcul haute performance entièrement construits autour de cette architecture. module load et MPI bare metal et ne souhaitent pas changer.

Pour tous les autres : installez le pilote directement sur le système, ne mettez pas CUDA sur l’hôte et exécutez CUDA dans des conteneurs. nvidia-container-toolkit (recouvert de L02) relie les deux de manière nette.

Mises à jour automatiques : ce qu’il faut autoriser et ce qu’il faut bloquer

Ubuntu unattended-upgrades Ce paquet est correct et vous devriez le laisser activé. Ignorer complètement les mises à jour de sécurité sur un serveur connecté au réseau est pire que le risque d'une mise à niveau automatique défaillante. La bonne pratique consiste à activer les mises à jour de sécurité, mais pas celles du noyau ni celles des paquets NVIDIA.

Modifier /etc/apt/apt.conf.d/50unattended-upgrades et ajouter au bloc de la liste noire :

Unattended-Upgrade::Package-Blacklist {
    "linux-image-";
    "linux-headers-";
    "linux-generic";
    "linux-modules-";
    "nvidia-";
    "libnvidia-";
    "cuda";
    "cuda-";
    "libcudnn";
};

apt-mark hold empêche déjà la mise à jour de ces paquets. La liste noire est une mesure de sécurité supplémentaire : elle explicite l’intention et bloque… unattended-upgrades rien qu'en enregistrant une tentative, et cela survit à une négligence apt-mark unhold De la part d'un administrateur junior. Exécutez les deux.

Confirmer en suivant /var/log/unattended-upgrades/unattended-upgrades.log Après la prochaine exécution, vous devriez voir les paquets de sécurité passer et ceux bloqués/sur liste noire être explicitement ignorés.

Le guide de récupération « J'ai mis à niveau mon système et maintenant plus rien ne fonctionne »

Quelqu'un a couru apt full-upgrade (ou votre outil CM l'a fait) et au redémarrage suivant, les GPU ont disparu. Ordre des opérations :

1. Démarrage. Si le système ne démarre pas, maintenez la touche Maj enfoncée et appuyez sur Échap à l'invite GRUB, puis sélectionnez le noyau précédent dans le menu de démarrage. Confirmez. nvidia-smi fonctionne avec l'ancien noyau. Si c'est le cas, le problème vient du nouveau noyau ; épinglez l'ancien (apt-mark hold linux-image-<old>) et continuez.
2. Si le système a démarré mais nvidia-smi Le message d'erreur indique une incompatibilité NVML : vous exécutez un nouvel espace utilisateur avec un ancien module chargé. Redémarrez l'ordinateur. Cela résout presque toujours le problème.
3. If nvidia-smi indique que le pilote n'est pas chargé, vérifiez /var/lib/dkms/nvidia/<version>/build/make.log et dmesg | grep -i nvidiaLes défaillances les plus courantes : en-têtes du noyau manquants (apt install linux-headers-$(uname -r) puis dkms autoinstall); un noyau trop récent pour le pilote (rétrogradez le noyau ou mettez à niveau la branche du pilote délibérément) ; le démarrage sécurisé rejette le module non signé (mokutil --sb-state, puis soit désactiver SB, soit inscrire un MOK).
4. Si les paquets de pilotes eux-mêmes ont été mis à niveau vers un état que vous ne souhaitiez pas (par exemple, si le méta-paquet a installé la version R585 par-dessus votre version R580 épinglée parce que quelqu'un a supprimé le blocage), purgez et réinstallez : sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, puis réinstallez le dépôt CUDA à la version que vous souhaitez réellement, puis réappliquez les blocages.
5. Si vous disposez d'un instantané (et vous devriez en avoir un, voir ci-dessous), restaurez-le. Cela vous permettra de revenir en vingt minutes à une situation stable au lieu de quatre heures de débogage.

Prenez un instantané avant de modifier le pilote ou le noyau.

Quelle que soit votre configuration de stockage, prenez un instantané avant toute opération sur un pilote ou le noyau. Utilisateurs de ZFS (/ (sur ZFS ou un ensemble de données séparé) obtenez ceci gratuitement avec zfs snapshot rpool@pre-driver-upgrade-2026-05-15Les utilisateurs LVM avec des pools fins peuvent lvcreate --snapshotLes utilisateurs d'ext4 sans LVM sont contraints d'effectuer des sauvegardes complètes ; c'est l'une des raisons pour lesquelles nous abordons l'organisation du système de fichiers dans [référence manquante]. L04.

La discipline qui porte ses fruits : ne jamais toucher au pilote, aux paquets CUDA ou au noyau sans avoir pris un instantané au cours des cinq dernières minutes. Un instantané ne coûte que quelques secondes. En l’absence d’un instantané lors d’une mise à jour qui tourne mal, on risque une demi-journée d’indisponibilité et une soirée gâchée.

voie de mise à niveau LTS

Les mises à niveau d'Ubuntu LTS vers LTS ont lieu tous les deux ans ; pour les serveurs d'IA, nous recommandons d'en sauter une sur deux. La procédure est la suivante :

22.04  ──(skip 23.x interim, skip 24.04 if production-stable)──▶  26.04
24.04  ──(skip 25.x interim, skip 26.04 if production-stable)──▶  28.04

Explication : le coût d’une mise à niveau LTS sur un serveur d’IA est élevé (revalidation des pilotes, nouveau test de l’image conteneur, souvent une nouvelle exécution des tests d’intégration), le gain à passer directement à une seule étape est minime, et les outils de mise à niveau LTS vers LTS d’Ubuntu prennent entièrement en charge cette option. Planifiez la mise à niveau, programmez une fenêtre de maintenance, créez un instantané, puis exécutez-la. do-release-upgradeEffectuez un test de stabilité pendant une semaine, puis rétablissez la version précédente. La migration directe de la version 22.04 vers la version 26.04 est prise en charge et c'est ce que la plupart des clients Kentino feront fin 2026 ou en 2027.

Ce qu'il faut éviter : les mises à niveau sur place pendant un sprint de développement, les mises à niveau sans instantané, et la mise à niveau suivie d'une mise à niveau de distribution immédiate de la pile NVIDIA. Procédez par étapes.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.