Démonter le nœud GPU, de Proxmox à une Debian nue

Le nœud GPU de mon homelab est une station de travail Xeon mono-socket qui, pendant un an, a fait tourner Proxmox comme le reste du cluster. En juin, je l’ai effacé et j’ai réinstallé une Debian 13 (Trixie) nue, parce que la seule chose que j’attends vraiment de cette machine, faire tourner des charges CUDA sur son GPU, est justement celle qu’un hyperviseur rend plus difficile. La réinstallation a pris vingt minutes. Faire charger le pilote a pris le reste de la soirée, presque entièrement sur une seule étape : le Secure Boot refusant en silence un module signé par une clé inconnue.

L’ordre des opérations qui marche réellement sur Trixie tient en quelques étapes, dont une facile à manquer.

Mise à jour, septembre 2026 : le nœud a depuis rejoint le cluster Proxmox, où il fait tourner les services multimédias, la VM Kubernetes et l’inférence LLM locale. Le pilote NVIDIA est désormais installé sur l’hôte Proxmox lui-même : toujours pas de passthrough VFIO. Proxmox VE 9 repose sur Debian 13 : les étapes ci-dessous valent aussi sur l’hôte, à un détail près, installer les en-têtes du noyau Proxmox (proxmox-default-headers) au lieu de linux-headers-amd64.

Pourquoi un hyperviseur était la mauvaise couche ici

Proxmox mérite sa place quand on consolide de nombreux invités sur une seule machine. Le calcul GPU, c’est le cas inverse. Pour donner un vrai GPU à une machine virtuelle, on passe par le passthrough VFIO, le mécanisme qui détache un périphérique de l’hôte pour le confier à un invité. Il faut alors démêler les groupes IOMMU, ces blocs de périphériques que le matériel refuse de séparer, tenir les pilotes de l’hôte à l’écart de la carte, puis remettre le périphérique entier à exactement un invité. On finit par parler à son GPU à travers une machine virtuelle, la carte ne peut de toute façon appartenir qu’à une VM à la fois, et on traîne toute cette mécanique pour un nœud qui fait précisément une seule chose.

Une machine qui n’existe que pour faire tourner un GPU n’a pas besoin d’un hyperviseur posé entre moi et nvidia-smi. Une fois la couche supprimée, la carte revient sur le métal nu, et la taxe du passthrough disparaît avec elle.

Le même matériel, deux piles. Le passthrough offre une flexibilité dont un nœud GPU à usage unique ne se sert jamais.

Écarter nouveau de la carte

Debian fournit nouveau, le pilote open source, et le charge au démarrage. Le module propriétaire ne s’attachera pas tant que nouveau tient la carte. Le paquet nvidia-driver installe déjà sa propre liste noire, donc le fichier ci-dessous n’est qu’une précaution ; l’étape qui compte, c’est de reconstruire l’initramfs, pour que la liste noire s’applique dès le début du démarrage, avant que nouveau ne soit chargé depuis l’initramfs et ne prenne la carte.

# /etc/modprobe.d/blacklist-nouveau.conf
blacklist nouveau
options nouveau modeset=0

# puis régénérer l'initramfs pour que ça tienne au démarrage
sudo update-initramfs -u

Le pilote lui-même : laissez DKMS faire la compilation

Trixie garde le pilote NVIDIA dans le composant non-free et son firmware dans non-free-firmware : il faut donc élargir les sources avant de pouvoir installer quoi que ce soit. Ensuite on installe les en-têtes du noyau et le paquet du pilote, et DKMS compile le module pour le noyau en cours d’exécution. C’est la raison de préférer le pilote empaqueté à l’installeur .run : DKMS recompile le module à chaque mise à jour du noyau, si bien qu’un apt upgrade ne vous laisse pas discrètement avec un écran noir.

# ajoutez  contrib non-free non-free-firmware  à vos sources apt, puis :
sudo apt update
sudo apt install linux-headers-amd64 nvidia-driver

Le Secure Boot : pourquoi nvidia-smi ne trouvait pas le pilote

Après le redémarrage, j’ai lancé nvidia-smi et j’ai obtenu ceci :

$ nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the
NVIDIA driver. Make sure that the latest NVIDIA driver is installed
and running.

La carte allait bien et le module s’était compilé sans broncher. Le noyau refusait simplement de le charger, parce que le Secure Boot était actif et que DKMS avait signé le module avec une clé locale que le firmware ne reconnaissait pas encore. Il y a deux issues. On peut désactiver le Secure Boot dans le firmware, ou enrôler cette clé comme clé du propriétaire de la machine (Machine Owner Key) et garder la chaîne de confiance intacte. J’ai gardé le Secure Boot et enrôlé la clé, une manipulation à faire une seule fois dans le gestionnaire MOK, au démarrage suivant. Rien dans l’installation elle-même n’échoue bruyamment : on ne s’en aperçoit qu’au moment de lancer nvidia-smi.

# enrôler la clé de signature DKMS, définir un mot de passe à usage unique, puis redémarrer
sudo mokutil --import /var/lib/dkms/mok.pub
# au gestionnaire MOK bleu au redémarrage : Enroll MOK, saisir le mot de passe, redémarrer

Après ça, nvidia-smi a répondu normalement, avec la carte et la version du pilote.

Toute la séquence. Toutes les cases sauf la case ambrée sont mécaniques ; la case ambrée est celle où une compilation propre vous donne quand même un nvidia-smi mort.

Ce que j’ai récupéré

Un nvidia-smi sur métal nu, la carte entière sans machine virtuelle au milieu, et un nœud qui fait tourner mes builds CUDA et Kokkos directement sur le matériel plutôt qu’à travers un invité. Le reste du cluster est toujours sous Proxmox : ces nœuds font le travail de consolidation où Proxmox excelle. Ce nœud ne faisait pas ce travail.

Garder un nœud sur métal nu à côté d’un cluster Proxmox restait bancal côté supervision : il fallait le surveiller à part, hors des outils qui couvrent tous les autres nœuds. Le nœud est depuis revenu sous Proxmox (voir la mise à jour en tête d’article).