Proxmox GPU Passthrough 2026 : NVIDIA + AMD pour LLM/IA

\\\\\\\\\\\\\\\\n

Le GPU passthrough sur Proxmox VE permet d'attribuer un GPU physique directement à une machine virtuelle, contournant l'hyperviseur pour offrir des performances quasi natives à la VM. Cette technique est devenue incontournable avec l'explosion des workloads d'intelligence artificielle et de machine learning qui nécessitent un accès direct aux capacités de calcul parallèle des GPU NVIDIA (CUDA) et AMD (ROCm). La configuration n'est pas triviale : elle implique la manipulation des groupes IOMMU, le binding du driver vfio-pci, la gestion des ROM GPU et la résolution de problèmes spécifiques à chaque famille de cartes. Ce guide couvre la configuration complète du passthrough pour les GPU NVIDIA (séries RTX, A100, H100, L40S) et AMD (Instinct MI250, MI300, Radeon Pro), incluant le SR-IOV pour le partage de GPU entre VMs, l'accès GPU dans les conteneurs LXC pour les déploiements légers, et les benchmarks de performance comparés au bare metal. Les configurations présentées sont testées et validées sur Proxmox VE 8.2 et 9.0.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Prérequis : IOMMU et VT-d/AMD-Vi

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Le passthrough PCI repose sur l'IOMMU (Input-Output Memory Management Unit), une fonctionnalité matérielle du processeur qui isole les accès DMA des périphériques PCI. Sans IOMMU, un périphérique passé à une VM pourrait accéder à la mémoire de l'hôte ou d'autres VMs, créant un risque de sécurité majeur et des corruptions de données. Pour les aspects sécurité de la virtualisation, consultez notre guide de migration VMware vers Proxmox.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Activation dans le BIOS/UEFI

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Plateforme	Paramètre BIOS	Emplacement typique
Intel	VT-d (Intel Virtualization for Directed I/O)	Advanced > CPU Configuration ou Chipset
AMD	AMD-Vi / IOMMU / SVM Mode	Advanced > NBC Configuration ou IOMMU
Serveur Dell	SR-IOV Global Enable + VT-d	System BIOS > Integrated Devices
Serveur HPE	Intel VT-d + SR-IOV	System Configuration > BIOS Settings

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Configuration du kernel Proxmox

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Éditer les paramètres GRUB\\\\\\\\\\\\\\\\nnano /etc/default/grub\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Pour CPU Intel :\\\\\\\\\\\\\\\\nGRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Pour CPU AMD :\\\\\\\\\\\\\\\\nGRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Mettre à jour GRUB\\\\\\\\\\\\\\\\nupdate-grub\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Charger les modules VFIO au boot\\\\\\\\\\\\\\\\ncat >> /etc/modules << 'EOF'\\\\\\\\\\\\\\\\nvfio\\\\\\\\\\\\\\\\nvfio_iommu_type1\\\\\\\\\\\\\\\\nvfio_pci\\\\\\\\\\\\\\\\nvfio_virqfd\\\\\\\\\\\\\\\\nEOF\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Redémarrer\\\\\\\\\\\\\\\\nreboot\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Vérifier que l'IOMMU est actif\\\\\\\\\\\\\\\\ndmesg | grep -i iommu\\\\\\\\\\\\\\\\n# Doit afficher : "DMAR: IOMMU enabled" ou "AMD-Vi: IOMMU enabled"

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Isolation du GPU : binding vfio-pci

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Pour passer un GPU à une VM, il faut d'abord empêcher le pilote graphique de l'hôte (nouveau, nvidia, amdgpu) de s'accaparer le GPU. Le driver vfio-pci prend le contrôle du périphérique au boot et le réserve exclusivement pour le passthrough.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Identifier le GPU et son groupe IOMMU\\\\\\\\\\\\\\\\nlspci -nn | grep -i "vga\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|3d\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|display"\\\\\\\\\\\\\\\\n# Exemple : 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD102 [GeForce RTX 4090] [10de:2684]\\\\\\\\\\\\\\\\n# Exemple : 01:00.1 Audio device [0403]: NVIDIA Corporation [10de:22ba]\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Vérifier le groupe IOMMU (TOUS les devices du groupe doivent être passés)\\\\\\\\\\\\\\\\nfind /sys/kernel/iommu_groups/ -type l | sort -t/ -k5 -n | grep "01:00"\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Créer la configuration vfio-pci\\\\\\\\\\\\\\\\necho "options vfio-pci ids=10de:2684,10de:22ba" > /etc/modprobe.d/vfio.conf\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Blacklister les drivers natifs\\\\\\\\\\\\\\\\necho "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf\\\\\\\\\\\\\\\\necho "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf\\\\\\\\\\\\\\\\n# Pour AMD : blacklist amdgpu et radeon\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Régénérer l'initramfs\\\\\\\\\\\\\\\\nupdate-initramfs -u -k all\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Redémarrer et vérifier\\\\\\\\\\\\\\\\nreboot\\\\\\\\\\\\\\\\nlspci -nnk -s 01:00.0\\\\\\\\\\\\\\\\n# Kernel driver in use: vfio-pci ← c'est bon

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\n

Sécurité et isolation des workloads GPU dans Proxmox

\\\\\\\\n

Le passthrough GPU dans Proxmox soulève des considérations de sécurité spécifiques qui dépassent les bonnes pratiques de virtualisation standard. La nature du passthrough direct (le GPU est directement attribué à une VM, bypassing l'hyperviseur pour les opérations GPU) crée des vecteurs d'attaque potentiels entre VMs et hôte qui méritent d'être traités.

\\\\\\\\n\\\\\\\\n

L'isolation IOMMU est la protection fondamentale : elle empêche une VM avec accès GPU d'accéder à la mémoire d'autres VMs ou de l'hôte via DMA (Direct Memory Access). Vérifiez que l'IOMMU est correctement configuré avec des groupes IOMMU séparés pour chaque GPU passthrough : for d in /sys/kernel/iommu_groups/*/devices/*; do echo IOMMU Group ${d##*/group}; ls $d; done. Si plusieurs périphériques partagent le même groupe IOMMU (ACS problem), tous doivent être assignés à la même VM, ce qui peut créer des contraintes d'allocation. Les correctifs ACS (Access Control Services) appliqués au noyau Proxmox résolvent ce problème sur certaines plateformes matérielles.

\\\\\\\\n\\\\\\\\n

La politique d'accès GPU pour les workloads IA sensibles doit être définie explicitement : les modèles LLM chargés en VRAM peuvent potentiellement exposer des données si la VRAM n'est pas effacée entre les sessions. Pour les environnements multi-tenant, l'effacement sécurisé de la VRAM avant réaffectation du GPU à une autre VM est une bonne pratique. Les implémentations GPU confidentielles (NVIDIA Hopper H100 avec Confidential Computing, AMD SEV-SNP) offrent des garanties matérielles supplémentaires pour les workloads IA nécessitant le plus haut niveau de confidentialité.

\\\\\\\\n\\\\\\\\n

Le monitoring des workloads GPU est essentiel pour détecter les usages anormaux : pic de consommation GPU inhabituel (potentielle exécution de code malveillant ou de cryptominage), température anormalement élevée (signe de surcharge), ou activité GPU en dehors des plages horaires autorisées. Les outils de monitoring GPU (nvidia-smi, DCGM - Data Center GPU Manager pour NVIDIA, ROCm SMI pour AMD) peuvent être intégrés dans Prometheus/Grafana pour une surveillance continue avec alertes.

\\\\\\\\n\\\\\\\\n

Optimisation des workloads IA sur Proxmox : cas d'usage avancés

\\\\\\\\n

Proxmox avec passthrough GPU est devenu une plateforme de choix pour les organisations qui souhaitent déployer des workloads d'IA en interne, sans dépendance aux clouds publics et avec un contrôle total sur la confidentialité des données. Plusieurs architectures ont émergé comme références selon les besoins.

\\\\\\\\n\\\\\\\\n

L'architecture LLM on-premise avec Ollama est la plus accessible pour les équipes techniques : Ollama est déployé dans une VM Proxmox avec GPU passthrough, les modèles (Llama 3, Mistral, Qwen) sont téléchargés localement, et les équipes accèdent au service via l'API compatible OpenAI. Cette architecture garantit que les prompts et les données sensibles ne quittent jamais l'infrastructure de l'organisation. Le réseau Proxmox gère l'isolation entre la VM Ollama et les autres VMs, et un reverse proxy Nginx avec authentification contrôle l'accès au service LLM.

\\\\\\\\n\\\\\\\\n

Pour les workloads d'entraînement de modèles, Proxmox permet de créer des environnements éphémères avec GPU passthrough : une VM avec PyTorch/TensorFlow et accès GPU est créée pour la durée de l'entraînement, puis détruite avec nettoyage des données temporaires. Cette approche immutable garantit la reproductibilité des expériences et évite l'accumulation de configurations divergentes. Les snapshots Proxmox avant et après l'entraînement permettent le rollback en cas de problème et la comparaison des résultats entre runs.

\\\\\\\\n\\\\\\\\n

L'intégration avec les orchestrateurs de conteneurs (Kubernetes via K3s ou RKE2 déployé sur des VMs Proxmox) permet de bénéficier des capacités de scheduling GPU de Kubernetes (NVIDIA GPU Operator, AMD GPU Device Plugin) tout en conservant l'isolation forte de la virtualisation Proxmox. Cette architecture hybride (Kubernetes dans des VMs Proxmox avec GPU passthrough) est plus complexe à gérer mais offre la meilleure combinaison de flexibilité opérationnelle, d'isolation sécurité et de performance pour les plateformes IA d'entreprise.

\\\\\\\\n\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Passthrough NVIDIA : CUDA et workloads ML

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Configuration de la VM

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Créer la VM avec les options nécessaires\\\\\\\\\\\\\\\\nqm create 200 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --name gpu-ml-worker \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --memory 32768 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --cores 16 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --cpu host \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --bios ovmf \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --efidisk0 local-zfs:1, efitype=4m \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --machine q35 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --net0 virtio, bridge=vmbr0\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Ajouter le GPU en passthrough\\\\\\\\\\\\\\\\nqm set 200 -hostpci0 01:00, pcie=1, x-vga=0\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Pour les GPU NVIDIA avec CUDA (pas besoin de x-vga pour le calcul)\\\\\\\\\\\\\\\\n# x-vga=1 uniquement si vous voulez l'affichage graphique dans la VM\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Configuration mémoire pour gros modèles ML\\\\\\\\\\\\\\\\nqm set 200 --balloon 0 # Désactiver le ballooning pour les workloads ML\\\\\\\\\\\\\\\\nqm set 200 --hugepages 1048576 # Hugepages 1GB pour meilleures performances

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Installation des drivers NVIDIA dans la VM

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Dans la VM Ubuntu/Debian\\\\\\\\\\\\\\\\napt install build-essential linux-headers-$(uname -r) -y\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Installer le driver NVIDIA (méthode recommandée)\\\\\\\\\\\\\\\\napt install nvidia-driver-560 nvidia-cuda-toolkit -y\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# OU via le .run officiel (pour contrôle précis de la version)\\\\\\\\\\\\\\\\nwget https://developer.download.nvidia.com/compute/cuda/12.6.0/local_installers/cuda_12.6.0_560.28.03_linux.run\\\\\\\\\\\\\\\\nchmod +x cuda_12.6.0_560.28.03_linux.run\\\\\\\\\\\\\\\\n./cuda_12.6.0_560.28.03_linux.run\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Vérifier le fonctionnement\\\\\\\\\\\\\\\\nnvidia-smi\\\\\\\\\\\\\\\\n# Doit afficher le GPU avec la mémoire disponible

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Contourner le "Code 43" NVIDIA

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Historiquement, NVIDIA bloquait le passthrough sur les GPU grand public (GeForce) avec une erreur "Code 43" quand le driver détectait un environnement virtuel. Depuis les drivers 465+ (2021) et la série RTX 30xx+, cette restriction a été officiellement levée. Pour les anciennes cartes, les workarounds suivants restent nécessaires :

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Dans /etc/pve/qemu-server/200.conf — uniquement pour GPU pre-RTX 30xx\\\\\\\\\\\\\\\\nargs: -cpu host, kvm=off, hv_vendor_id=proxmox\\\\\\\\\\\\\\\\n# kvm=off masque l'hyperviseur au driver NVIDIA

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Passthrough AMD : spécificités

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Les GPU AMD (Radeon Pro, Instinct) sont généralement plus simples à passer en passthrough car AMD n'impose pas de restrictions artificielles sur la virtualisation. Le driver ROCm pour le calcul ML est open source, ce qui facilite le débogage. Cependant, les GPU AMD souffrent d'un problème connu de "reset bug" : certaines cartes ne se réinitialisent pas correctement lors du redémarrage de la VM, nécessitant un reboot complet de l'hôte.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Passthrough AMD Instinct MI250\\\\\\\\\\\\\\\\nqm set 200 -hostpci0 41:00, pcie=1\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Pour contourner le reset bug AMD (si présent)\\\\\\\\\\\\\\\\necho "options vfio-pci enable_sriov=0" >> /etc/modprobe.d/vfio.conf\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Vendor-reset module (solution communautaire pour le reset bug)\\\\\\\\\\\\\\\\napt install pve-headers-$(uname -r) git dkms -y\\\\\\\\\\\\\\\\ngit clone https://github.com/gnif/vendor-reset.git\\\\\\\\\\\\\\\\ncd vendor-reset && dkms install .\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\necho "vendor-reset" >> /etc/modules\\\\\\\\\\\\\\\\nupdate-initramfs -u

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

SR-IOV et vGPU pour le partage de GPU

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Le SR-IOV (Single Root I/O Virtualization) permet de partitionner un GPU physique en plusieurs fonctions virtuelles (VF), chacune assignable à une VM différente. NVIDIA propose cette fonctionnalité via ses GPU datacenter (A100, H100, L40S) avec le profile MIG (Multi-Instance GPU). Pour les déploiements d'IA nécessitant une allocation dynamique des ressources GPU, consultez notre guide d'optimisation des coûts d'inférence LLM.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# NVIDIA MIG sur A100 (80GB)\\\\\\\\\\\\\\\\n# Activer MIG mode\\\\\\\\\\\\\\\\nnvidia-smi -i 0 -mig 1\\\\\\\\\\\\\\\\n# Redémarrer le driver\\\\\\\\\\\\\\\\nnvidia-smi -r\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Créer des instances GPU (exemple : 3x 20GB)\\\\\\\\\\\\\\\\nnvidia-smi mig -i 0 -cgi 9,9,9 -C\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Lister les instances\\\\\\\\\\\\\\\\nnvidia-smi mig -i 0 -lgi\\\\\\\\\\\\\\\\nnvidia-smi mig -i 0 -lci\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Chaque instance apparaît comme un device séparé utilisable par un conteneur ou une VM

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Accès GPU dans les conteneurs LXC

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Pour les workloads ne nécessitant pas une isolation VM complète, le passthrough GPU dans un conteneur LXC offre des performances identiques au bare metal avec une empreinte mémoire minimale. C'est la méthode privilégiée pour les serveurs d'inférence Ollama ou vLLM en production.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Configuration du conteneur LXC (dans /etc/pve/lxc/300.conf)\\\\\\\\\\\\\\\\nlxc.cgroup2.devices.allow: c 195:* rwm\\\\\\\\\\\\\\\\nlxc.cgroup2.devices.allow: c 236:* rwm\\\\\\\\\\\\\\\\nlxc.cgroup2.devices.allow: c 509:* rwm\\\\\\\\\\\\\\\\nlxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind, optional, create=file\\\\\\\\\\\\\\\\nlxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind, optional, create=file\\\\\\\\\\\\\\\\nlxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind, optional, create=file\\\\\\\\\\\\\\\\nlxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind, optional, create=file\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Le driver NVIDIA doit être installé sur l'hôte ET dans le conteneur (même version)\\\\\\\\\\\\\\\\n# Sur l'hôte :\\\\\\\\\\\\\\\\napt install nvidia-driver-560 -y\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Dans le conteneur (installer uniquement les libs, pas le driver kernel)\\\\\\\\\\\\\\\\napt install nvidia-utils-560 libnvidia-compute-560 -y\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Vérifier\\\\\\\\\\\\\\\\nlxc-attach -n 300 -- nvidia-smi

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Ollama et vLLM sur Proxmox avec GPU

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Déployer un serveur d'inférence LLM sur Proxmox avec GPU passthrough est une alternative crédible aux solutions cloud pour les organisations souhaitant garder le contrôle de leurs données. Les performances sont à 95-98% du bare metal pour l'inférence, ce qui est négligeable en pratique. Pour approfondir les architectures de déploiement LLM, consultez notre guide RAG en production.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# Déploiement Ollama dans un LXC avec GPU\\\\\\\\\\\\\\\\n# Dans le conteneur :\\\\\\\\\\\\\\\\ncurl -fsSL https://ollama.ai/install.sh | sh\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Vérifier la détection GPU\\\\\\\\\\\\\\\\nollama serve &\\\\\\\\\\\\\\\\ncurl http://localhost:11434/api/tags\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Charger un modèle\\\\\\\\\\\\\\\\nollama pull llama3.1:70b-instruct-q4_K_M\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# Déploiement vLLM dans une VM avec GPU passthrough\\\\\\\\\\\\\\\\npip install vllm\\\\\\\\\\\\\\\\nvllm serve meta-llama/Llama-3.1-70B-Instruct \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --tensor-parallel-size 2 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --gpu-memory-utilization 0.90 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\n --max-model-len 32768

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Benchmarks : passthrough vs bare metal

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Test	Bare Metal	VM Passthrough	LXC Passthrough	Overhead
nvidia-smi power draw (idle)	25W	25W	25W	0%
CUDA bandwidthTest H2D	12.8 GB/s	12.6 GB/s	12.8 GB/s	VM: 1.5%, LXC: 0%
Llama 3.1 8B inference (tok/s)	142	138	141	VM: 2.8%, LXC: 0.7%
Llama 3.1 70B inference (tok/s)	24	23.5	23.8	VM: 2.1%, LXC: 0.8%
PyTorch MNIST training (s)	8.2	8.4	8.2	VM: 2.4%, LXC: 0%
Stable Diffusion XL (img/min)	18.5	18.1	18.4	VM: 2.2%, LXC: 0.5%

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Troubleshooting

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Problèmes courants et solutions

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

# 1. "IOMMU group is not viable" — Le GPU partage un groupe avec d'autres devices\\\\\\\\\\\\\\\\n# Solution : ACS override (dernier recours)\\\\\\\\\\\\\\\\nGRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream, multifunction"\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# 2. "BAR 3: cannot reserve [mem]" — Conflit d'espace mémoire PCI\\\\\\\\\\\\\\\\n# Solution : augmenter l'espace MMIO\\\\\\\\\\\\\\\\necho "options kvm ignore_msrs=1" >> /etc/modprobe.d/kvm.conf\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# 3. VM freeze au démarrage avec GPU — ROM GPU manquante\\\\\\\\\\\\\\\\n# Solution : extraire et fournir la ROM\\\\\\\\\\\\\\\\ncd /sys/bus/pci/devices/0000:01:00.0/\\\\\\\\\\\\\\\\necho 1 > rom\\\\\\\\\\\\\\\\ncat rom > /usr/share/kvm/gpu-rtx4090.rom\\\\\\\\\\\\\\\\necho 0 > rom\\\\\\\\\\\\\\\\n# Dans la conf VM : hostpci0: 01:00, pcie=1, romfile=gpu-rtx4090.rom\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# 4. Le GPU ne se réinitialise pas après arrêt VM (AMD reset bug)\\\\\\\\\\\\\\\\n# Solution : vendor-reset module (voir section AMD ci-dessus)\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n# 5. dmesg errors "vfio-pci: cannot reset device"\\\\\\\\\\\\\\\\necho 1 > /sys/bus/pci/devices/0000:01:00.0/reset

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

FAQ — Questions fréquentes

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Peut-on passer le même GPU à plusieurs VMs simultanément ?

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Non, pas avec le passthrough classique. Un GPU physique ne peut être attribué qu'à une seule VM à la fois. Pour partager un GPU entre plusieurs VMs, il faut utiliser SR-IOV/MIG (GPU datacenter NVIDIA) ou une solution vGPU. Les GPU grand public (GeForce, Radeon) ne supportent pas le partage matériel. L'alternative pour les petits budgets est de passer le GPU à un conteneur LXC qui expose un service d'inférence via API (Ollama, vLLM), accessible par toutes les VMs du réseau.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Le passthrough GPU fonctionne-t-il avec les conteneurs LXC non privilégiés ?

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Oui, mais cela nécessite une configuration supplémentaire des cgroups et des permissions sur les device nodes. Les conteneurs non privilégiés (par défaut dans Proxmox) remappent les UID/GID, ce qui complique l'accès aux fichiers de device /dev/nvidia*. La solution recommandée est d'utiliser un conteneur privilégié pour les workloads GPU, en acceptant le compromis de sécurité, ou de configurer des règles cgroup2 spécifiques avec les bons mappings UID.

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Quel est l'impact du passthrough GPU sur la live migration ?

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n

Une VM avec un GPU en passthrough ne peut pas être migrée à chaud (live migration). Le GPU est un périphérique physique attaché à un slot PCI spécifique du serveur hôte — il ne peut pas "suivre" la VM vers un autre nœud. La migration nécessite un arrêt de la VM, la migration, puis le rattachement à un GPU disponible sur le nœud de destination. Pour les workloads ML, cela implique de concevoir l'application pour gérer les interruptions (checkpointing des modèles en cours d'entraînement).

\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\\\\\\\\\n\\\\\\\\n\\\\n\\\\n

Planification de la capacité GPU et évolution du parc Proxmox

\\\\n

La planification de la capacité GPU dans un environnement Proxmox doit anticiper la croissance des besoins en calcul IA, la disponibilité et le coût des nouvelles générations de GPU, et les contraintes d'infrastructure (alimentation, refroidissement, espace rack). Une approche structurée évite les investissements précipités et les goulots d'étranglement.

\\\\n

L'inventaire et le monitoring de l'utilisation GPU sont les fondations de la planification de capacité : DCGM (Data Center GPU Manager) pour NVIDIA ou ROCm SMI pour AMD centralisent les métriques de tous les GPUs du cluster dans Prometheus. Les indicateurs clés incluent : utilisation GPU (%), utilisation VRAM (%), file d'attente des requêtes, et nombre de sessions actives par GPU. Ces métriques permettent d'identifier les GPUs saturés (utilisation >85% en moyenne sur la semaine) qui justifient l'ajout de capacité, et les GPUs sous-utilisés (<30%) qui peuvent être réaffectés ou consolidés.

\\\\n

Le partage de GPU via vGPU (NVIDIA GRID/vGPU) ou SR-IOV permet d'augmenter le nombre de VMs ayant accès GPU sans multiplier le nombre de cartes physiques. NVIDIA vGPU partage un GPU physique entre 2 à 32 instances virtuelles selon le profil choisi, avec garanties de mémoire et de bande passante par instance. Cette technologie est particulièrement adaptée aux workloads d'inférence LLM (qui nécessitent moins de mémoire que l'entraînement) et aux environnements multi-utilisateurs où chaque utilisateur a besoin d'un accès GPU dédié mais pas exclusif.

\\\\n

La stratégie d'évolution du parc GPU doit intégrer les cycles d'obsolescence des cartes (3 à 5 ans pour un usage intensif), les coûts de renouvellement, et les bénéfices des nouvelles générations. Les cartes NVIDIA H100/H200 et AMD MI300X offrent des performances 3 à 10x supérieures aux générations précédentes pour les LLMs, mais leur coût (15 000€ à 30 000€ par carte) justifie une analyse ROI rigoureuse. Pour les organisations avec des budgets contraints, le marché secondaire des cartes A100/A6000 offre un bon rapport performance/prix pour les workloads d'inférence modérés.

\\\\n\\n

Le passthrough GPU dans Proxmox est une technologie mature et fiable pour les déploiements de production, à condition de respecter les prérequis matériels (IOMMU, UEFI) et de maintenir les drivers et firmwares à jour. La combinaison de la flexibilité de la virtualisation Proxmox avec les performances quasi-bare-metal du passthrough GPU offre une plateforme optimale pour les workloads IA on-premise, en préservant la maîtrise des données et la liberté architecturale face aux contraintes et aux coûts des cloud publics.

\n

L'écosystème Proxmox GPU est soutenu par une communauté très active sur le forum officiel Proxmox, le subreddit r/Proxmox, et plusieurs canaux Discord dédiés. Les scripts de configuration automatisée (Proxmox VE Helper-Scripts de tteck, disponibles sur GitHub) simplifient le déploiement initial et maintiennent les meilleures pratiques à jour. Contribuer à cette communauté en partageant vos configurations testées et vos résolutions de problèmes est une façon de consolider vos propres connaissances tout en aidant les équipes qui démarrent leur parcours GPU passthrough sur Proxmox.

La configuration du passthrough GPU dans Proxmox, bien que parfois fastidieuse lors de la mise en place initiale, offre un niveau de performances et de flexibilité difficilement égalable par d'autres approches de virtualisation GPU. Les administrateurs systèmes qui maîtrisent ces configurations disposent d'une compétence de plus en plus demandée dans les organisations qui cherchent à déployer des capacités IA on-premise. L'investissement temps dans la compréhension de IOMMU, VFIO et des mécanismes d'isolation GPU est largement compensé par la valeur ajoutée d'une plateforme IA interne souveraine, performante et économiquement attractive comparée aux coûts récurrents du cloud GPU.