Générateur d’images IA auto-hébergé : quel matériel ?

Ce dont un générateur d’images IA auto-hébergé a réellement besoin

Un générateur d’images IA auto-hébergé se compose d’une application web et d’un fichier de modèle. L’application est ComfyUI et elle fonctionne sur n’importe quelle machine Linux. C’est le modèle qui détermine le matériel nécessaire. Un checkpoint de classe SDXL est un fichier unique de 6.94 GB et doit être chargé dans la mémoire du GPU. Ce seul élément détermine l’essentiel du budget. Consultez donc la configuration matérielle ci-dessous avant de louer quoi que ce soit.

En résumé : un VPS sans GPU peut installer et servir le logiciel. Il peut générer des images en 512x512 avec un ancien modèle Stable Diffusion 1.5 en une ou deux minutes par image. Sur la même machine, une génération SDXL en 1024x1024 prend de dix à vingt minutes par image. Ce n’est pas un problème de configuration. C’est une contrainte de calcul, et ce guide l’explique.

Pourquoi la taille du modèle détermine la machine

La génération d’images exécute une boucle de débruitage. Avec 30 étapes, le débruiteur, c’est-à-dire le UNet de SDXL, traite l’image 30 fois. Chaque passe lit tous les poids du UNet. Les deux encodeurs de texte s’exécutent une fois avant la boucle et le VAE décode l’image une fois après. Ils ne font donc pas partie du coût de chaque étape. En précision réduite de moitié, le UNet de SDXL contient 5.14 GB de poids. Dans cette simplification, un rendu en 30 étapes transfère donc environ 154 GB de poids en mémoire avant l’apparition de l’image. Les tenseurs intermédiaires s’ajoutent à ce volume.

Un GPU doté de 24 GB de mémoire vidéo (VRAM, la mémoire soudée à côté de la puce graphique) lit les données à plusieurs centaines de gigaoctets par seconde. Il peut conserver les 6.9 GB en mémoire simultanément. Un VPS équipé d’un CPU lit la RAM système à quelques dizaines de gigaoctets par seconde. Il ne dispose pas de matériel spécialisé pour les opérations matricielles des convolutions. La même boucle s’exécute donc une à deux puissances de 10 plus lentement. C’est le même argument fondé sur la bande passante mémoire que pour les modèles de texte. Il est utile de le lire avec dans quels cas un VPS avec GPU vaut réellement son prix.

La génération d’images se distingue de la génération de texte sur un point important. Un modèle conversationnel diffuse les tokens au fur et à mesure. Même une machine lente reste donc utilisable, car les mots apparaissent pendant la lecture. Une image n’apparaît que lorsque la dernière étape est terminée. Une exécution lente signifie qu’il faut regarder une barre de progression.

La progression matérielle, avec des chiffres concrets

Le bloc ci-dessous donne des valeurs typiques pour une image SDXL en 1024x1024, avec 30 steps et le sampler Euler, en juillet 2026. Considérez-les comme des ordres de grandeur. Le sampler, le nombre de steps et la résolution les font varier.

[
  {
    "label": "8 vCPU VPS, no GPU",
    "seconds_per_image": 780
  },
  {
    "label": "8GB VRAM GPU",
    "seconds_per_image": 32
  },
  {
    "label": "12GB VRAM GPU",
    "seconds_per_image": 18
  },
  {
    "label": "24GB VRAM GPU",
    "seconds_per_image": 9
  }
]

La ligne CPU indique 780 secondes, soit environ treize minutes. La carte de 24 GB met 9 secondes. C’est l’écart que vous achetez.

Lisez cette progression ainsi. Avec moins de 8 GB de VRAM, SDXL fonctionne toujours, car ComfyUI gère conjointement la VRAM et la RAM système et déporte automatiquement les poids du modèle. En octobre 2026, le README du projet fixe le minimum à 4 GB de VRAM et 8 GB de RAM système, avec son streaming asynchrone des poids. Le déport ajoute du temps à chaque step. Une carte de 6 GB produit donc plutôt une image en une minute qu’en trente secondes. Avec 8 GB, le modèle de base tient en mémoire et le rendu reste confortable. Avec 12 GB, vous pouvez garder un ControlNet ou deux en plus du checkpoint sans déport. Avec 24 GB, vous pouvez exécuter SDXL, le refiner et l’upscaling dans un même workflow, et entraîner des adaptateurs LoRA avec une marge confortable. L’entraînement nécessite moins de mémoire : le guide d’entraînement SDXL du trainer kohya-ss sd-scripts indique que l’entraînement LoRA est possible avec 8 GB de mémoire GPU, et recommande 10 GB. Pour y parvenir, il vous demande d’entraîner uniquement l’U-Net, d’activer le gradient checkpointing, de mettre en cache les sorties de l’encodeur de texte et les latents, d’utiliser un optimizer 8-bit ou Adafactor, et de réduire la dimension LoRA à 4 à 8 sur une carte de 8 GB. Le guide LoRA de l’interface kohya_ss GUI, qui encapsule ces scripts, est plus prudent : il recommande un GPU avec au moins 12 GB de mémoire pour l’entraînement LoRA.

Ce qu’un VPS CPU peut faire et ne peut pas faire

Il peut faire plus que ce que l’on imagine, mais moins que ce que le marketing laisse entendre. Il faut bien définir cette limite.

Un VPS CPU peut installer ComfyUI, servir l’interface web, héberger votre bibliothèque de modèles, exécuter la queue et générer des images sans aucun GPU. Avec Stable Diffusion 1.5 en 512x512 et 20 étapes, prévoyez environ 60 à 150 secondes par image sur 8 vCPU modernes avec 16 GB de RAM. Pour un traitement lancé pendant la nuit ou un endpoint d’images à faible volume placé derrière une queue, c’est tout à fait acceptable.

Un VPS CPU ne permet pas de travailler de manière interactive. Itérer sur un prompt signifie générer vingt images en une heure ; à raison de treize minutes par image, vous n’en obtenez que quatre. Il ne permet pas non plus d’entraîner un modèle. Le fine-tuning LoRA sur CPU se mesure en jours, et non en heures. Considérez donc cette fonction comme indisponible.

La règle de mémoire pour un fonctionnement uniquement sur CPU diffère de celle d’un GPU. Les poids sont chargés dans la RAM système. Il faut donc prévoir la taille du modèle ainsi que l’espace de travail : environ 16 GB de RAM pour SDXL et environ 8 GB pour SD 1.5. Une machine de 4 GB démarre ComfyUI, puis le out-of-memory killer termine le processus pendant le premier rendu. Le processus disparaît alors avec Killed dans dmesg, sans traceback Python.

Installer ComfyUI sur une machine équipée d’un GPU

Voici les commandes fournies par le projet. Partez d’une installation propre d’Ubuntu 24.04, avec le pilote NVIDIA déjà installé. Vérifiez d’abord le pilote, car sans ce contrôle, toutes les erreurs suivantes se ressemblent.

nvidia-smi

Cette commande doit afficher un tableau contenant votre carte et une version de CUDA. command not found ou NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver signifie que le pilote est absent ou que le module du noyau ne s’est pas chargé après une mise à niveau. Corrigez ce problème avant de continuer, car ComfyUI basculera silencieusement sur le CPU et vous accuserez le logiciel à tort.

sudo apt update
sudo apt install -y git python3-venv python3-pip wget
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
python3 -m venv venv
. venv/bin/activate
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt

L’environnement virtuel n’est pas une simple recommandation. PyTorch installe un arbre important de dépendances. L’installer au niveau du système sur une machine qui exécute déjà d’autres services risque de les rendre inutilisables. Vérifiez que PyTorch détecte la carte avant d’aller plus loin.

python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

True suivi du nom de votre carte signifie que la pile fonctionne. False signifie que le wheel installé ne correspond pas au pilote, généralement parce qu’un wheel torch limité au CPU était déjà présent dans le cache. Réinstallez-le avec l’URL d’index ci-dessus.

Récupérer un modèle et prévoir l’espace disque

ComfyUI ne fournit aucun poids. Les checkpoints vont dans models/checkpoints, les fichiers VAE dans models/vae et les adaptateurs LoRA dans models/loras.

cd ~/ComfyUI/models/checkpoints
wget https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors

Privilégiez toujours .safetensors à .ckpt. Un fichier .ckpt est un objet Python sérialisé avec pickle. Son chargement exécute le code de la personne qui l’a créé. Le format safetensors contient uniquement des tenseurs. Un fichier hostile ne peut donc rien exécuter.

Le stockage est souvent oublié. Un checkpoint SDXL de base occupe 6.94 GB. Le refiner ajoute 6 GB. Un modèle SDXL ControlNet occupe de 320 MB pour le petit modèle Canny à 2.5 GB pour le modèle complet en précision réduite. Un upscaler est peu volumineux : le modèle standard Real-ESRGAN x4plus occupe 67 MB, son modèle anime 17.9 MB et son modèle anime vidéo 2.5 MB. Un LoRA occupe de quelques dizaines de mégaoctets à 787 MB pour les adaptateurs Hyper-SDXL de ByteDance. Les utilisateurs qui adoptent cet outil téléchargent généralement un deuxième, puis un troisième modèle de base en moins d’une semaine. Prévoyez 100 GB sur le disque pour une installation opérationnelle. Surveillez aussi le répertoire de sortie : les fichiers PNG en 1024x1024 occupent 1 à 2 MB chacun et un batch laissé sans surveillance remplit discrètement un petit disque. Placez models/ et output/ sur un volume extensible. Sauvegardez vos fichiers JSON de workflow avec, par exemple, des sauvegardes incrémentielles chiffrées vers un stockage objet. Les poids peuvent être téléchargés à nouveau. Les workflows que vous avez réglés ne le peuvent pas.

Lancer le service et y accéder en toute sécurité

cd ~/ComfyUI
. venv/bin/activate
python main.py --listen 127.0.0.1 --port 8188

ComfyUI écoute sur le port 8188. Sur une machine équipée uniquement d’un CPU, ajoutez --cpu. Cette option force l’utilisation du CPU au lieu d’échouer parce qu’aucun périphérique CUDA n’est disponible.

Liez le service à 127.0.0.1, et non à 0.0.0.0. ComfyUI prend désormais en charge les comptes, mais aucun de ces comptes ne protège votre serveur. La connexion disponible dans Settings, à la section User, vous connecte à un compte Comfy. Elle fonctionne avec une installation locale : la documentation de Comfy indique une connexion par e-mail, Google, GitHub ou clé API. Cette documentation présente ce compte comme un moyen d’accéder aux nœuds partenaires et aux abonnements Comfy Cloud. Elle ne le présente pas comme un moyen de protéger votre propre serveur par mot de passe. L’option --multi-user active uniquement le stockage par utilisateur. En octobre 2026, le serveur récupère le nom de l’utilisateur depuis un en-tête de requête comfy-user et ne vérifie aucun mot de passe. Toute personne pouvant atteindre le port peut mettre des tâches en file d’attente, lire toutes les images que vous avez générées et, si vous avez lancé le service avec --enable-manager, installer des custom nodes. Cela permet d’exécuter du code arbitraire sur votre serveur. Accédez plutôt au service par un tunnel SSH depuis votre ordinateur portable.

ssh -N -L 8188:127.0.0.1:8188 you@your-server

Ouvrez ensuite http://127.0.0.1:8188 en local. Si vous avez besoin d’un accès réellement multi-utilisateur, placez un reverse proxy avec authentification devant le service et laissez l’application liée à localhost. Le même raisonnement s’applique à tout service auto-hébergé sans authentification. C’est le schéma standard pour les déploiements Docker Compose sur un VPS.

Exécuter le service avec systemd

Une file de rendu qui s’arrête à la fermeture de votre session SSH n’est pas un service. Exécutez-la avec un utilisateur comfy sans accès interactif, et non avec votre propre compte : les nœuds personnalisés sont du code, qui ne doit pas pouvoir accéder à votre répertoire personnel. Créez l’utilisateur et déplacez l’installation dans son répertoire personnel :

sudo useradd --system --create-home --home-dir /home/comfy --shell /usr/sbin/nologin comfy
sudo mv ~/ComfyUI /home/comfy/
sudo chown -R comfy:comfy /home/comfy/ComfyUI

L’environnement virtuel continue de fonctionner après le déplacement, car l’unité appelle directement son python. Écrivez ensuite /etc/systemd/system/comfyui.service.

[Unit]
Description=ComfyUI
After=network-online.target

[Service]
User=comfy
WorkingDirectory=/home/comfy/ComfyUI
ExecStart=/home/comfy/ComfyUI/venv/bin/python main.py --listen 127.0.0.1 --port 8188
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now comfyui
systemctl status comfyui

active (running) et une ligne de journal contenant To see the GUI go to: http://127.0.0.1:8188 indiquent que le service fonctionne. Notez que ExecStart désigne directement l’interpréteur situé dans l’environnement virtuel, car systemd n’exécute pas votre profil shell et activate ne se produit jamais.

La recommandation pragmatique selon le budget

Si vous voulez essayer la génération d’images et que le coût compte davantage que la vitesse, prenez un VPS avec CPU et 16 GB de RAM, exécutez SD 1.5 en 512x512 et acceptez d’attendre une ou deux minutes par image. C’est le point d’entrée réaliste. Il coûte une fraction du prix de toute solution équipée d’un GPU. C’est également l’endroit adapté pour héberger la bibliothèque de modèles et les workflows pendant votre phase d’évaluation.

Si vous itérez chaque jour sur les prompts, louez à l’heure un GPU avec au moins 12 GB de VRAM auprès d’un GPU cloud, puis arrêtez-le lorsque vous avez terminé. La génération d’images est une charge ponctuelle. Un GPU inactif facturé au mois est le moyen le plus courant de dépenser trop dans ce contexte. Conservez les checkpoints sur un block storage peu coûteux et montez-le.

Si vous fournissez un service à d’autres personnes ou si vous entraînez régulièrement des adaptateurs LoRA, prévoyez 24 GB de VRAM et une machine que vous gardez en fonctionnement. Le guide SDXL de sd-scripts indique que l’entraînement de LoRA est possible avec 8 GB, avec 10 GB recommandés, en utilisant ses paramètres d’économie mémoire. Le guide LoRA de l’interface graphique kohya_ss demande au moins 12 GB. La valeur de 24 GB indiquée dans le guide sd-scripts concerne le fine-tuning complet de SDXL avec une batch size de 1. Une carte de 24 GB couvre donc les tâches LoRA et permet encore d’envisager le fine-tuning. À ce stade, cette même machine est généralement suffisamment utile pour exécuter aussi un modèle de langage local. C’est la configuration décrite dans auto-héberger un LLM avec Ollama.

Quel que soit le niveau choisi, mesurez votre propre machine avant de vous fier à une valeur publiée. Mettez le même prompt en file d’attente cinq fois et relevez le nombre de secondes par itération affiché par ComfyUI dans sa console. Cette valeur indique votre position réelle sur cette échelle.

FAQ

Puis-je exécuter Stable Diffusion sans GPU ?

Oui. ComfyUI s’exécute avec python main.py --cpu et génère de vraies images sans carte graphique. Comptez environ 60 à 150 secondes par image pour Stable Diffusion 1.5 en 512x512, et de dix à vingt minutes pour SDXL en 1024x1024, avec 8 vCPU modernes. Cette configuration convient aux traitements par lots pendant la nuit et aux endpoints peu sollicités. Elle ne convient pas à l’itération sur les prompts, et l’entraînement est totalement hors de portée.

De quelle quantité de VRAM ai-je besoin pour SDXL ?

8 GB permettent d’exécuter SDXL confortablement en 1024x1024. En dessous, ComfyUI déporte automatiquement les poids du modèle vers la RAM système et continue de fonctionner. En octobre 2026, son README indique un minimum de 4 GB de VRAM et 8 GB de RAM système, chaque étape déportée augmentant le temps de traitement. 12 GB permettent de conserver un ControlNet avec le checkpoint, et 24 GB couvrent le modèle de base, le refiner et l’upscaling dans un même workflow. Le guide des sd-scripts de kohya-ss indique que l’entraînement d’un LoRA SDXL est possible avec 8 GB, avec 10 GB recommandés, si vous utilisez ses paramètres d’économie mémoire. Le guide LoRA de l’interface graphique kohya_ss demande, lui, au moins 12 GB. Un fine-tuning complet de SDXL nécessite 24 GB avec une batch size de 1.

De combien d’espace disque les modèles ont-ils besoin ?

Le checkpoint de base SDXL occupe à lui seul 6.94 GB, et le refiner ajoute environ 6 GB. Les modèles ControlNet SDXL occupent de 320 MB à 2.5 GB chacun en half precision, les adaptateurs LoRA de quelques dizaines de mégaoctets à 787 MB, et les upscalers Real-ESRGAN de 2.5 MB à 67 MB. Prévoyez 100 GB pour une installation fonctionnelle avec quelques modèles de base, et surveillez séparément le répertoire de sortie, car les fichiers PNG en 1024x1024 occupent de 1 à 2 MB chacun.

Est-il sûr d’exposer ComfyUI sur Internet ?

Non. La connexion au compte Comfy dans les paramètres de ComfyUI fonctionne depuis une installation locale, mais elle vous donne accès aux nodes partenaires et aux abonnements cloud de Comfy. Rien dans la documentation de Comfy ne la présente comme une protection pour votre serveur. Le flag --multi-user sépare uniquement le stockage de chaque utilisateur, sans vérifier de mot de passe. Lorsque ComfyUI-Manager est activé, l’interface installe des nodes personnalisés. Il s’agit de code Python qui s’exécute sur votre serveur. Un port ouvert permet donc l’exécution de code à distance. Liez ComfyUI à 127.0.0.1, accédez-y via un tunnel SSH avec ssh -N -L 8188:127.0.0.1:8188 you@your-server, et placez un reverse proxy avec authentification devant si plusieurs personnes doivent y accéder.

Pourquoi mon rendu a-t-il été interrompu sans message d’erreur ?

La disparition du processus avec Killed dans dmesg, sans traceback Python, indique l’out-of-memory killer de Linux, et non un bug de ComfyUI. Sur une machine CPU-only, les poids résident dans la RAM système. SDXL nécessite donc environ 16 GB et SD 1.5 environ 8 GB, auxquels il faut ajouter l’espace de travail. Ajoutez de la RAM, ajoutez du swap, ou utilisez un modèle plus petit avec une résolution inférieure.