#Pourquoi héberger Ollama sur Proxmox

Dans un homelab, on veut rarement un serveur dédié uniquement à l'IA. Proxmox permet de coller Ollama à côté de vos autres services (NAS, domotique, reverse proxy) sur la même machine, tout en isolant chaque charge. Le daemon Ollama tourne alors dans un conteneur ou une VM, écoute sur son port habituel, et devient accessible depuis toute votre infrastructure locale — Open WebUI sur un autre conteneur, un pipeline n8n, ou votre poste de travail.

L'enjeu central, c'est le GPU. L'inférence LLM sans accélération matérielle est utilisable mais lente ; dès qu'on veut du 14B ou du 32B à une vitesse correcte, il faut donner à Ollama l'accès à une carte NVIDIA. Or virtualiser un GPU n'est pas trivial : Proxmox propose deux approches radicalement différentes, avec des compromis opposés en termes de simplicité et de propreté.

Ce que ce guide suppose

Proxmox VE 8.x installé et fonctionnel, un GPU NVIDIA (RTX 3060 12GB ou mieux), et un accès root au nœud via SSH ou la console web. Les commandes sont données pour un hôte Debian 12 (base de Proxmox 8) et un invité Debian/Ubuntu.

#LXC vs VM : quel choix pour Ollama

C'est la première décision, et elle conditionne tout le reste. Un conteneur LXC partage le noyau de l'hôte : léger, démarrage instantané, et surtout il peut accéder au GPU de l'hôte sans le lui retirer. Une VM, elle, est une machine complète et isolée ; pour lui donner un GPU il faut le lui dédier entièrement via passthrough VFIO — l'hôte perd alors totalement cette carte.

LXC + GPU partagé: La voie simple. Le driver NVIDIA est installé sur l'hôte et sur le conteneur (mêmes versions), les périphériques /dev/nvidia* sont montés dans le conteneur. Le GPU reste utilisable par l'hôte et par d'autres conteneurs simultanément. Idéal si vous voulez mutualiser une seule carte.
VM + passthrough complet: La voie propre. Le GPU est arraché à l'hôte et attribué à la VM via VFIO/IOMMU. Isolation totale, drivers gérés dans la VM comme sur du bare-metal, aucune interférence. Mais le GPU est monopolisé par cette VM tant qu'elle tourne.
Le critère décisif: Une seule carte à partager entre plusieurs services → LXC. Une carte dédiée à l'IA (ou plusieurs GPU) et besoin d'isolation stricte → VM. Le passthrough est aussi obligatoire si vous voulez faire tourner un OS différent (Windows, un OS avec drivers spécifiques).

→

Le conseil par défaut

Pour un premier montage avec un seul GPU dans un homelab, commencez par le LXC. C'est plus rapide à mettre en place, moins de pièges, et vous gardez la carte disponible pour d'autres usages. Passez à la VM quand vous avez un besoin réel d'isolation ou un GPU dédié.

#Prérequis matériels et VRAM

Dimensionnez le GPU selon les modèles visés. En quantification Q4_K_M (le meilleur compromis qualité/mémoire), voici la VRAM nécessaire par taille de modèle. Prévoyez toujours une marge pour le contexte.

3B (≈2 Go): RTX 3060 12GB largement suffisante. Confortable même en CPU-only pour du test.
7B (≈5 Go): RTX 3060 12GB ou RTX 4070 12GB. Le point d'entrée idéal pour un homelab.
14B (≈9 Go): RTX 4070 12GB serré, RTX 4080 16GB confortable.
32B (≈19 Go): RTX 4090 24GB nécessaire, ou deux cartes en tensor-split.
70B (≈40 Go): Multi-GPU (2× RTX 4090) ou Mac M4 Pro/Max à mémoire unifiée 48 Go+.

Côté virtualisation, le passthrough VM exige des prérequis stricts absents du LXC : un CPU et une carte mère supportant VT-d (Intel) ou AMD-Vi (AMD), l'IOMMU activé dans le BIOS, et idéalement un groupe IOMMU propre pour le GPU. Le LXC n'a besoin de rien de tout ça — juste que le driver NVIDIA s'installe sur l'hôte.

#LXC avec GPU partagé, la voie simple

Le principe : installer le driver NVIDIA sur l'hôte Proxmox, créer un conteneur LXC non privilégié, y monter les périphériques du GPU, puis installer le même driver (sans le module noyau) et Ollama dans le conteneur. La version du driver doit être identique entre hôte et conteneur, sinon le userspace du conteneur refuse de parler au module noyau de l'hôte.

01
Installer le driver NVIDIA sur l'hôte
Ajoutez les en-têtes noyau puis installez le driver depuis le dépôt NVIDIA (ou le .run officiel). Vérifiez avec nvidia-smi que la carte est bien détectée sur l'hôte avant d'aller plus loin.
02
Créer un conteneur LXC non privilégié
Un template Debian 12 ou Ubuntu 24.04 suffit. Activez l'imbrication (nesting=1) pour permettre l'exécution des runtimes GPU. Notez l'ID du conteneur (ex. 200).
03
Repérer les périphériques GPU
Sur l'hôte, listez les nœuds /dev/nvidia* et relevez leurs numéros majeur/mineur. Ce sont ces device nodes qu'on va exposer au conteneur.
04
Monter les devices dans la config LXC
Éditez /etc/pve/lxc/200.conf pour autoriser les cgroups des devices NVIDIA et les monter en bind. Redémarrez le conteneur.
05
Installer le même driver dans le conteneur
Dans le conteneur, installez le driver NVIDIA avec l'option --no-kernel-module (le module vient de l'hôte). nvidia-smi doit maintenant fonctionner à l'intérieur.
06
Installer Ollama
Le script officiel détecte le GPU automatiquement. Ollama démarre son daemon et charge les modèles sur la carte partagée.

Hôte Proxmox

# 1. En-têtes noyau + driver NVIDIA sur l'hôte
apt update && apt install -y pve-headers-$(uname -r)
apt install -y nvidia-driver nvidia-smi

# Vérifier la détection
nvidia-smi

# 2. Repérer les device nodes (relever major:minor)
ls -l /dev/nvidia*

/etc/pve/lxc/200.conf

# Conteneur non privilégié + nesting
features: nesting=1

# Autoriser les cgroups des périphériques NVIDIA (major 195, 234, 508 selon setup)
lxc.cgroup2.devices.allow: c 195:* rwm
lxc.cgroup2.devices.allow: c 234:* rwm
lxc.cgroup2.devices.allow: c 509:* rwm

# Monter les device nodes dans le conteneur
lxc.mount.entry: /dev/nvidia0 dev/nvidia0 none bind,optional,create=file
lxc.mount.entry: /dev/nvidiactl dev/nvidiactl none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm dev/nvidia-uvm none bind,optional,create=file
lxc.mount.entry: /dev/nvidia-uvm-tools dev/nvidia-uvm-tools none bind,optional,create=file

Dans le conteneur LXC

# Même version de driver, SANS le module noyau (fourni par l'hôte)
./NVIDIA-Linux-x86_64-<version>.run --no-kernel-module

# nvidia-smi doit répondre à l'intérieur du conteneur
nvidia-smi

# Installer Ollama (détecte le GPU tout seul)
curl -fsSL https://ollama.com/install.sh | sh

# Test : le modèle doit se charger sur le GPU
ollama run llama3.1:8b

Le piège des versions de driver

Si nvidia-smi affiche « Failed to initialize NVML: Driver/library version mismatch » dans le conteneur, c'est que le driver du conteneur ne correspond pas exactement à celui de l'hôte. Réinstallez la version identique, ou après une mise à jour de l'hôte, redémarrez le conteneur pour resynchroniser.

#VM avec passthrough complet, la voie propre

Ici, le GPU est retiré à l'hôte et attribué à une VM via VFIO. La VM voit une vraie carte NVIDIA et se comporte comme du bare-metal : on y installe le driver normalement, sans bidouille de version. En contrepartie, il faut préparer l'hôte pour qu'il relâche la carte au démarrage (binding VFIO) et que le noyau ne charge pas le driver nvidia côté hôte.

01
Activer IOMMU au boot
Ajoutez intel_iommu=on (ou amd_iommu=on) et iommu=pt aux paramètres du noyau, dans GRUB ou systemd-boot selon votre installation Proxmox.
02
Isoler le GPU pour VFIO
Identifiez les IDs PCI de la carte (GPU + son audio HDMI), déclarez-les dans vfio-pci et blacklistez les drivers nouveau/nvidia côté hôte pour qu'il ne s'en empare pas.
03
Régénérer l'initramfs et redémarrer
Mettez à jour l'initramfs pour prendre en compte les modules VFIO, puis redémarrez l'hôte. Vérifiez que le GPU est bien pris en charge par vfio-pci.
04
Créer la VM et lui attribuer le GPU
Créez une VM (machine type q35, BIOS OVMF/UEFI), ajoutez le périphérique PCI du GPU en passthrough, cochez PCI-Express. Installez l'OS invité (Ubuntu Server recommandé).
05
Installer driver + Ollama dans la VM
Dans la VM, installez le driver NVIDIA classique (le module noyau est autorisé ici, c'est une vraie machine), vérifiez avec nvidia-smi, puis installez Ollama.

Hôte — activer IOMMU (GRUB)

# Éditer /etc/default/grub, ligne GRUB_CMDLINE_LINUX_DEFAULT
# Intel :
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
# AMD :
# GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

update-grub
reboot

# Après reboot : vérifier que l'IOMMU est actif
dmesg | grep -e DMAR -e IOMMU

Hôte — binding VFIO

# Trouver les IDs PCI et les vendor:device IDs du GPU
lspci -nn | grep -i nvidia
# ex. 01:00.0 ... [10de:2504]  (GPU)
#     01:00.1 ... [10de:228e]  (audio HDMI de la carte)

# Déclarer les IDs pour vfio-pci
echo "options vfio-pci ids=10de:2504,10de:228e" > /etc/modprobe.d/vfio.conf

# Blacklister les drivers côté hôte
echo -e "blacklist nouveau\nblacklist nvidia\nblacklist nvidiafb" > /etc/modprobe.d/blacklist-nvidia.conf

# Charger vfio au boot puis régénérer l'initramfs
echo -e "vfio\nvfio_iommu_type1\nvfio_pci" >> /etc/modules
update-initramfs -u -k all
reboot

# Après reboot : le GPU doit utiliser vfio-pci
lspci -nnk -d 10de:2504

→

Ajout du PCI dans l'interface Proxmox

Dans la VM → Hardware → Add → PCI Device, choisissez le GPU. Cochez « All Functions » pour inclure l'audio HDMI, et « PCI-Express » (nécessite une VM en machine type q35 avec BIOS OVMF). Sur les drivers NVIDIA récents, le contournement du fameux « Code 43 » n'est plus nécessaire sous Linux invité.

#IOMMU, drivers et pièges classiques

Le passthrough échoue rarement au hasard : presque toujours à cause de l'IOMMU ou d'un groupe PCI mal isolé. Voici les blocages qui reviennent le plus souvent et comment les diagnostiquer.

Groupes IOMMU non isolés: Si le GPU partage son groupe IOMMU avec d'autres périphériques (contrôleur USB, autre carte), Proxmox refuse le passthrough. Vérifiez les groupes ; en dernier recours le patch ACS override sépare les groupes, au prix d'une isolation moins stricte.
L'hôte s'accapare le GPU: Si après reboot lspci montre le GPU sous « nvidia » ou « nouveau » et non « vfio-pci », le blacklist n'a pas pris. Vérifiez /etc/modprobe.d et régénérez l'initramfs.
IOMMU non activé au BIOS: dmesg ne montre aucune ligne DMAR/IOMMU : VT-d ou AMD-Vi est désactivé dans le firmware. Activez-le dans le BIOS avant tout.
Version de driver LXC désynchronisée: Côté LXC uniquement : NVML mismatch après une mise à jour de l'hôte. Réalignez les versions hôte/conteneur.
GPU utilisé par la console de l'hôte: Un GPU unique servant aussi de sortie vidéo à Proxmox est difficile à passthrough proprement. Idéalement, gardez un iGPU ou une seconde carte pour l'affichage de l'hôte.

Hôte — vérifier les groupes IOMMU

# Lister les groupes IOMMU et leurs périphériques
for g in /sys/kernel/iommu_groups/*; do
  echo "Groupe ${g##*/}:"
  for d in $g/devices/*; do
    echo -n "  "; lspci -nns "${d##*/}"
  done
done

# Le GPU (et son audio) doit idéalement être seul dans son groupe

#Exposer Ollama sur le réseau local

Par défaut, Ollama n'écoute que sur http://localhost:11434 — donc uniquement depuis l'intérieur du conteneur ou de la VM. Pour l'appeler depuis Open WebUI hébergé ailleurs, ou depuis votre poste, il faut lui dire d'écouter sur toutes les interfaces via la variable OLLAMA_HOST.

Dans le conteneur / la VM

# Écouter sur toutes les interfaces (override du service systemd)
mkdir -p /etc/systemd/system/ollama.service.d
cat > /etc/systemd/system/ollama.service.d/override.conf <<'EOF'
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF

systemctl daemon-reload
systemctl restart ollama

# Depuis un autre hôte du LAN, tester l'API
curl http://<ip-conteneur>:11434/api/tags

Ne pas exposer Ollama nu sur internet

L'API Ollama n'a aucune authentification. En écoutant sur 0.0.0.0, gardez-la strictement sur votre réseau local ou derrière un reverse proxy avec authentification (Traefik, Caddy). Ne redirigez jamais le port 11434 directement depuis votre box.

#Dépannage

nvidia-smi absent dans le conteneur: Devices non montés ou cgroups mal autorisés. Vérifiez les lignes lxc.mount.entry et lxc.cgroup2.devices.allow, puis les majeurs réels via ls -l /dev/nvidia*.
Ollama tourne en CPU malgré le GPU: Vérifiez ollama ps : si le modèle est « 100% CPU », le runtime CUDA ne voit pas la carte. Contrôlez nvidia-smi et relancez le daemon Ollama.
VM ne démarre pas après ajout du PCI: Souvent un problème OVMF/q35 ou un groupe IOMMU partagé. Consultez les logs de la VM, et vérifiez que la carte est bien sur vfio-pci côté hôte.
Performances dégradées après mise à jour Proxmox: Une mise à jour du noyau hôte peut casser le module NVIDIA (LXC) ou le binding VFIO. Réinstallez les headers et le driver, régénérez l'initramfs.

Vérifications rapides

# Le GPU est-il vu par Ollama ?
ollama ps          # doit montrer un % GPU, pas 100% CPU

# État de la carte et VRAM utilisée
nvidia-smi

# Le daemon répond-il ?
curl http://localhost:11434/api/tags

#Pour aller plus loin

Une fois Ollama en place sur Proxmox, ces guides du site aident à finaliser la stack et à choisir le bon matériel :

Installer Ollama sur Linux: Détaille l'installation propre du daemon, systemd et la config GPU NVIDIA/AMD — utile pour l'intérieur du conteneur ou de la VM.
Déployer un LLM en production avec Docker Compose: Pour coller Open WebUI, Qdrant et un reverse proxy à votre Ollama Proxmox dans une stack complète.
Choisir son GPU pour l'IA locale: Le guide d'achat 2026 pour dimensionner la carte à passer en LXC ou en passthrough selon les modèles visés.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Installation · 4 min