Agent IA auto-hébergé sur Proxmox : le guide LXC 2026

Pourquoi les homelabbers Proxmox font tourner leurs agents IA dans des LXC

Si vous avez déjà une machine Proxmox qui ronronne sous le bureau avec Pi-hole, Home Assistant et Nextcloud, ajouter un agent IA auto-hébergé à cette pile est la suite logique. La communauté homelab a largement convergé vers la même réponse : mettez l'agent dans un conteneur LXC, pas dans une VM, pas sur le host nu. Un tutoriel récent d'Uptown4 et un article très partagé sur dev.to au sujet de sept agents autonomes sur un cluster Proxmox 3 nœuds arrivent au LXC pour la même raison : un conteneur d'agent au repos consomme 200-400 Mo de RAM et quasiment zéro CPU, donc vous pouvez en faire tourner cinq à huit sur une machine 16 Go sans le sentir.

Cet article détaille à quoi ressemble concrètement un agent IA auto-hébergé sur Proxmox en 2026 : comment dimensionner le LXC, s'il faut faire tourner Docker à l'intérieur ou passer en natif, comment le sauvegarder pour qu'une mauvaise mise à jour ne coûte pas la mémoire de l'agent, et où le passthrough GPU en vaut la peine. Il s'adresse à quelqu'un qui connaît déjà Proxmox et veut une recette concrète, pas une introduction à Proxmox.

LXC vs VM pour un agent IA : les chiffres comptent vraiment

La question la plus courante est de choisir entre un conteneur LXC et une VM QEMU complète. Pour un agent IA en texte qui parle à une API LLM cloud, LXC gagne sur tous les axes qui comptent pour un homelabber.

L'écart de surcharge est réel. Un LXC Debian brut consomme 30-60 Mo de RAM avant tout service, alors qu'une VM Debian avec la même empreinte utilise 200-400 Mo, principalement parce que le conteneur n'a pas besoin de kernel invité, de QEMU ni d'état des périphériques virtio (source). La surcharge CPU tourne autour de 1-3 % pour LXC contre 5-15 % pour les VM, et les conteneurs démarrent en 1-3 secondes au lieu de 30-90. Un cluster de production rapporte 180 conteneurs LXC sur du matériel qui accueillait auparavant 35 VM, une densité 5x meilleure.

Pour un agent IA, cela compte concrètement. Le runtime de l'agent lui-même est petit : un processus Python ou Node, un Postgres pour l'état, un listener de webhook. Le gros du travail se fait sur le GPU de quelqu'un d'autre, chez OpenAI, Anthropic ou une VM Ollama locale sur le même host. Le conteneur est un coordinateur léger, pas une charge. Payer la surcharge d'une VM pour héberger un coordinateur, c'est de l'argent que vous pourriez mettre dans plus d'agents.

Le seul point où les VM gagnent, c'est l'isolement. Si vous ne faites pas confiance au code de l'agent ou à ses extensions, une VM est une frontière plus forte. Pour un agent personnel que vous avez écrit ou un runtime open source que vous avez audité, le modèle à kernel partagé de LXC suffit largement.

La recette de référence : LXC Ubuntu 22.04, 2 cœurs, 2 Go, disque 8 Go

Le dimensionnement par défaut d'un premier agent IA auto-hébergé sur Proxmox est petit à dessein. Vous pouvez toujours agrandir le conteneur, et il n'y a aucune raison de réserver de la RAM que vous n'utilisez pas.

Réglage	Valeur	Pourquoi
Template	`ubuntu-22.04-standard`	La meilleure base supportée pour Docker, Node, Python
CPU	2 cœurs	La charge au repos est triviale, mais les rappels LLM sont des pics IO
RAM	2 Go	Marge suffisante pour Postgres plus le processus de l'agent
Swap	512 Mo	Assurance bon marché contre un pic mémoire à la Chrome
Disque	8 Go local-lvm	À agrandir plus tard si vous ajoutez un vector store sur disque
Réseau	vmbr0, DHCP	Derrière votre routeur, pas directement sur le WAN
Non privilégié	Oui	Par défaut ; à garder sauf si vous avez besoin de Docker
Features	`nesting=1, keyctl=1`	Seulement si vous comptez lancer Docker à l'intérieur

Créez-le depuis l'interface Proxmox ou avec pct create en SSH sur le host. Si vous prévoyez de faire tourner Docker dans le conteneur (voir la section suivante), activez nesting et keyctl à la création, pas après ; les changer plus tard implique d'éditer la config et de redémarrer le conteneur.

Une fois le conteneur en place, durcissez-le comme n'importe quelle machine de la famille Debian. Un utilisateur non-root avec sudo, des clés SSH plutôt que des mots de passe, unattended-upgrades activé et le client Tailscale installé si vous voulez y accéder depuis votre téléphone sans ouvrir de port sur votre routeur.

Docker dans le LXC, ou systemd natif ?

Il y a deux philosophies pour faire tourner le processus de l'agent, et les deux fonctionnent.

Docker dans le LXC. Vous installez Docker dans un conteneur Ubuntu 22.04 non privilégié avec nesting activé, puis vous lancez l'agent depuis un docker-compose.yml. C'est ce que livrent la plupart des runtimes d'agent IA auto-hébergés, donc vous suivez les instructions exactes du fournisseur. Le coût, c'est un peu de complexité : le conteneur doit être créé avec features: nesting=1,keyctl=1, et debugger revient parfois à se demander si le souci vient du conteneur, de Docker ou de l'agent. Le guide CoSci sur Docker dans un LXC Proxmox couvre les flags nécessaires en détail.

systemd natif. Vous zappez Docker complètement et installez l'agent, son runtime Python ou Node et Postgres directement dans le LXC comme services systemd. C'est plus léger, plus facile à raisonner, et bien plus compatible avec les snapshots LXC (vous photographiez un vrai système de fichiers, pas une pile d'overlays). Le coût, c'est que tous les agents open source ne publient pas des instructions systemd propres, donc vous risquez de traduire un Dockerfile en unit systemd à la main.

Pour une première installation, Docker dans le LXC est presque toujours le choix pragmatique, il vous laisse suivre le runtime choisi sans écart. Pour un agent homelab de longue durée que vous comptez faire évoluer pendant des années, systemd natif vaut l'effort. Consultez notre guide agent IA auto-hébergé en Docker pour la forme du compose-file à laquelle les deux chemins aboutissent.

Snapshots et sauvegardes : la seule chose que vous ne pouvez pas zapper

Un agent IA accumule de la mémoire : conversations, embeddings, tâches planifiées, préférences par utilisateur. Au bout d'un mois, cet état vaut plus que le conteneur lui-même. Proxmox vous donne deux outils liés mais distincts pour le protéger, et il faut être explicite sur la différence : un snapshot n'est pas une sauvegarde. Un snapshot vit sur le même disque que le conteneur, donc un SSD mort emporte les deux.

La recette à l'échelle homelab qui tient sur la durée :

Snapshot avant chaque mise à jour. Depuis l'onglet Snapshots du conteneur, prenez-en un juste avant apt upgrade, avant d'éditer docker-compose.yml, avant de basculer un feature flag. Un retour en arrière est un clic si la mise à jour casse la boucle d'outils de l'agent.
Sauvegardes nocturnes vers Proxmox Backup Server. PBS est le bon outil : il fait de la déduplication à longueur variable, donc sept sauvegardes nocturnes d'un LXC de 4 Go pèsent plus proche de 4 Go que de 28 Go. Faites tourner PBS sur une seconde petite machine ou un NAS, pas sur le host Proxmox lui-même.
Mode snapshot, pas mode stop. Pour un agent auquel des gens parlent sur Telegram, le mode snapshot est le bon défaut : le conteneur continue de tourner pendant la sauvegarde. Le mode stop est plus sûr pour des bases de données mais perd les messages entrants.
Conservez avec une politique. Une rétention courante qui marche pour les agents personnels : gardez les 3 dernières sauvegardes, quotidiennes pendant 7 jours, hebdomadaires pendant 4 semaines, mensuelles pendant 6 mois. Testez le chemin de restauration au moins une fois, avant d'en avoir vraiment besoin.

Si vous sautez PBS, envoyez au moins des archives vzdump sur un disque externe via un cron. Perdre la mémoire d'un agent homelab à cause d'un disque mort est une mauvaise façon de découvrir que les snapshots n'étaient pas des sauvegardes.

Passthrough GPU : presque jamais rentable

Le rêve homelab séduisant, c'est un GPU local qui fait tourner Ollama, apparié à un agent LXC sur Proxmox, pour que toute la pile reste chez soi. C'est techniquement possible et, dans le bon setup, gratifiant. Mais soyez honnête sur le trade-off.

La plupart des homelabs sont limités en bande passante pour de l'inférence locale sérieuse. Une seule RTX 3090 fera tourner un modèle 32B à peut-être 30-50 tokens par seconde, ce qui est correct pour du chat mais lent pour un agent qui enchaîne des appels d'outils. Plus gros que ça, il faut des GPU professionnels qui coûtent plus qu'une voiture d'occasion. Et la taxe opérationnelle est réelle : modules noyau, spécificités du passthrough PCIe, mises à jour de driver qui cassent le namespace du LXC, tout ce à quoi vous n'aviez pas souscrit en voulant un assistant IA sur Telegram.

Le pattern homelab pragmatique en 2026, c'est le setup petite machine, gros cerveau ailleurs. Faites tourner l'agent dans un LXC de 2 Go sur un Mini-PC d'occasion à 200 dollars qui consomme des centimes d'électricité, et laissez le modèle vivre sur OpenRouter, OpenAI ou Anthropic. Votre argumentaire vie privée devient « le code de l'agent tourne sur mon matériel, l'appel API est sans état, le fournisseur ne retient aucune donnée », ce qui est défendable et bon marché. Si plus tard vous voulez des modèles locaux pour certaines tâches, mettez Ollama sur une VM voisine avec passthrough GPU et laissez l'agent l'appeler comme un fournisseur parmi d'autres.

Quand Proxmox est la mauvaise réponse

Proxmox est fantastique si vous vous y êtes déjà engagé. Sinon, soyez honnête sur ce que vous voulez vraiment.

Vous voulez juste un agent IA sur Telegram. L'hébergement managé, c'est une minute et un café. Proxmox, c'est un week-end et un Mini-PC d'occasion. Voyez notre analyse tarifs Hermes Agent auto-hébergé vs managé.
Vous n'utilisez pas encore Proxmox. La courbe d'apprentissage de Proxmox vaut le coup pour un homelab à 10 services, pas pour un seul agent IA. Un VPS à 5 dollars et Docker Compose vous y amènent en une soirée.
Vous voulez une frontière de sécurité forte entre l'agent et tout le reste de la machine. Utilisez une VM, pas un LXC, ou carrément une machine séparée.

L'alternative Hermify : même possession, sans conteneur

Il y a une voie du milieu que beaucoup de homelabbers finissent par choisir après quelques cycles de mise à jour. Faites tourner le tout-venant sur Proxmox (Home Assistant, médias, réseau) et laissez un Hermes Agent managé gérer le côté IA. Vous conservez le même récit « vos données, votre clé de modèle, votre agent » sans un LXC à choyer ni une politique de rétention PBS à réfléchir. Hermify gère la flotte de conteneurs, vous apportez votre clé OpenRouter ou OpenAI, et l'agent vit sur Telegram en une minute environ. Commencez avec Hermify si ce trade vous parle plus qu'un nœud de plus dans votre cluster.