Générateur d’images IA auto-hébergé : matériel réel

Ce qu’il faut réellement pour un générateur d’images IA auto-hébergé

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. Le modèle détermine le matériel nécessaire. Un checkpoint de classe SDXL est un fichier unique de 6.94 GB, et il doit être chargé dans la mémoire du GPU. Ce seul élément détermine tout le budget. Consultez donc l’échelle matérielle ci-dessous avant de louer quoi que ce soit.

En résumé : un VPS uniquement équipé d’un CPU peut installer et servir le logiciel. Il peut aussi générer des images en 512x512 avec un ancien modèle Stable Diffusion 1.5, à raison d’une à 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 question 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. Un rendu en 30 étapes repasse le modèle complet sur l’image 30 fois, et chaque passe lit tous les poids. SDXL en précision réduite occupe environ 6.9 GB de poids. Un rendu en 30 étapes transfère donc environ 200 GB en mémoire avant l’affichage de l’image.

Un GPU avec 24 GB de mémoire vidéo (VRAM, la mémoire soudée à côté de la puce graphique) lit à plusieurs centaines de gigaoctets par seconde et conserve les 6.9 GB en mémoire en une seule fois. Un VPS avec CPU lit la RAM système à plusieurs dizaines de gigaoctets par seconde. Il ne dispose d’aucun matériel matriciel pour les convolutions. La même boucle s’exécute donc 10 à 100 fois plus lentement. C’est le même problème de bande passante mémoire que pour les modèles de texte. Il est utile de lire ce sujet 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 de chat diffuse les tokens progressivement. Même une machine lente reste donc utilisable, car les mots apparaissent pendant que vous les lisez. Une image n’apparaît qu’une fois la dernière étape terminée. Une machine lente signifie que vous restez devant une barre de progression.

La progression matérielle, avec des chiffres réels

Le bloc ci-dessous présente des chiffres typiques pour une image SDXL en 1024x1024, avec 30 étapes et le sampler Euler, en juillet 2026. Considérez-les comme des ordres de grandeur. Votre sampler, le nombre d’étapes 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 indique 9 secondes. C’est l’écart que vous achetez.

Interprétez la progression ainsi. Avec moins de 8 GB de VRAM, SDXL fonctionne toujours, car ComfyUI déporte automatiquement des layers vers la RAM système et peut utiliser une carte avec seulement 1 GB. Le offloading ajoute du temps à chaque étape. Une carte de 6 GB produit donc une image en près d’une minute plutôt qu’en trente secondes. Avec 8 GB, le modèle de base tient en mémoire et le rendu se déroule normalement. Avec 12 GB, vous pouvez conserver un ou deux ControlNet avec le checkpoint sans offloading. Avec 24 GB, vous pouvez exécuter SDXL, le refiner et l’upscaling dans un seul workflow. Vous pouvez aussi commencer à entraîner des adaptateurs LoRA, ce qui nécessite beaucoup plus de mémoire que la génération.

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

Il peut faire plus que ce que l’on pense, et moins que ce que le marketing laisse entendre. Soyez précis sur cette limite.

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

Un VPS CPU ne permet pas un travail interactif. Itérer sur les prompts signifie produire vingt rendus en une heure. À raison de treize minutes par rendu, vous en obtenez 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 du GPU. Les poids sont chargés dans la RAM système. Vous avez donc besoin de la taille du modèle et d’un espace de travail supplémentaire : environ 16 GB de RAM pour SDXL et environ 8 GB pour SD 1.5. Une machine de 4 GB démarre ComfyUI, puis est arrêtée par l’out-of-memory killer 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 du projet en amont. Partez d’une installation Ubuntu 24.04 vierge avec le pilote NVIDIA déjà installé. Vérifiez d’abord le pilote, car sans cette vérification, 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 risquez d’attribuer le problème au logiciel.

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 facultatif. PyTorch installe un grand arbre de dépendances. Installer PyTorch à l’échelle du système sur une machine qui exécute déjà d’autres services risque de les rendre défaillants. Vérifiez que PyTorch détecte la carte avant de continuer.

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

True accompagné du nom de votre carte signifie que la pile fonctionne. False signifie que le wheel installé ne correspond pas au pilote. La cause habituelle est qu’un wheel torch réservé au CPU était déjà présent dans le cache. Réinstallez avec l’index URL indiqué ci-dessus.

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

ComfyUI ne fournit aucun poids. Placez les checkpoints 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

Utilisez toujours .safetensors plutôt que .ckpt. Un fichier .ckpt est un objet Python sérialisé avec pickle. Son chargement exécute du code provenant de son créateur. Le format safetensors contient uniquement des tenseurs. Un fichier malveillant ne peut donc rien exécuter.

Le stockage est souvent sous-estimé. Un checkpoint SDXL de base occupe 6.94 GB. Le refiner ajoute 6 GB. Un modèle ControlNet occupe 1.4 à 2.5 GB, un upscaler 60 à 350 MB et un LoRA 20 à 400 MB. Les utilisateurs réguliers téléchargent un deuxième, puis un troisième modèle de base en moins d’une semaine. Prévoyez 100 GB d’espace disque pour une installation fonctionnelle. Surveillez aussi le répertoire de sortie : les fichiers PNG de 1024x1024 occupent 1 à 2 MB chacun, et un traitement par lots laissé sans surveillance peut remplir 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 de nouveau. Les workflows que vous avez configurés ne le peuvent pas.

Lancez-le et accédez-y 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 ne possède ni écran de connexion ni comptes utilisateur. Toute personne pouvant atteindre ce port peut mettre des tâches en file d’attente, lire toutes les images que vous avez générées et installer des custom nodes. Cela permet d’exécuter du code arbitraire sur votre serveur. Accédez-y plutôt au moyen d’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 multi-utilisateur réel, 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 également le modèle standard dans les déploiements Docker Compose sur un VPS.

Maintenez-le en fonctionnement avec systemd

Une file d’attente de rendu qui s’arrête lorsque votre session SSH se ferme n’est pas un service. Écrivez /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 qu’il fonctionne. Notez que ExecStart désigne directement l’interpréteur de 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, choisissez un VPS avec CPU et 16 GB de RAM, exécutez SD 1.5 en 512x512 et acceptez un délai d’une à deux minutes par image. C’est le point d’entrée réaliste. Son coût représente une fraction de celui d’une solution avec GPU. C’est aussi 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 économique et montez-le.

Si vous fournissez ce service à d’autres personnes ou si vous entraînez des adaptateurs LoRA, vous avez besoin de 24 GB de VRAM et d’une machine que vous laissez en fonctionnement. À ce stade, la même machine est généralement aussi rentabilisée par l’exécution d’un modèle de langage local. C’est la configuration décrite dans héberger vous-même un LLM avec Ollama.

Quelle que soit l’option choisie, mesurez les performances de votre propre machine avant de vous fier à une valeur publiée. Placez cinq fois le même prompt dans la file d’attente et relevez le nombre de secondes par itération affiché par ComfyUI dans sa console. Cette valeur indique votre position réelle dans cette échelle.

FAQ

Puis-je exécuter Stable Diffusion sans GPU ?

Oui. ComfyUI fonctionne 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 10 à 20 minutes pour SDXL en 1024x1024, avec 8 vCPU modernes. Cette configuration convient aux traitements par lots nocturnes et aux endpoints à faible volume. Elle ne convient pas à l'itération sur les prompts, et l'entraînement est totalement hors de portée.

De combien de VRAM ai-je besoin pour SDXL ?

8 GB permettent d'exécuter SDXL confortablement en 1024x1024. En dessous de cette capacité, ComfyUI déporte automatiquement des layers vers la RAM système et continue de fonctionner, jusqu'à environ 1 GB de VRAM, mais chaque étape déportée augmente le temps d'exécution. 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. Cette capacité constitue aussi le minimum pratique pour entraîner des adaptateurs LoRA.

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 occupent 1.4 à 2.5 GB chacun, les adaptateurs LoRA 20 à 400 MB, et les upscalers jusqu'à 350 MB. Prévoyez 100 GB pour une installation fonctionnelle avec quelques modèles de base. Surveillez séparément le répertoire de sortie, car les fichiers PNG en 1024x1024 occupent 1 à 2 MB chacun.

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

Non. ComfyUI ne fournit aucune authentification, et son système de custom nodes installe et exécute du code Python depuis l'interface. Un port ouvert permet donc l'exécution de code à distance sur votre serveur. Liez-le à 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 lui si plusieurs personnes doivent y accéder.

Pourquoi mon rendu a-t-il été arrêté 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, en plus de l'espace de travail. Ajoutez de la RAM, ajoutez du swap, ou utilisez un modèle plus petit avec une résolution inférieure.