SSD Nodes Learn Hosting plans →
Guides Matt ConnorPar Matt Connor · Mis à jour le 2026-08-07

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

Découvrez le matériel réellement nécessaire pour Stable Diffusion : VPS CPU, GPU pour SDXL, commandes d’installation de ComfyUI et 6,94 Go par checkpoint.

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. Un rendu en 30 étapes parcourt le modèle complet sur l’image 30 fois, et chaque étape lit tous les poids. SDXL en précision demi-mot est composé d’environ 6.9 GB de poids. Un rendu en 30 étapes fait donc transiter environ 200 GB par la mémoire avant l’affichage de l’image.

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 et conserve les 6.9 GB en mémoire simultanément. Un VPS avec CPU lit la RAM système à plusieurs dizaines de gigaoctets par seconde et ne dispose d’aucun matériel spécialisé pour les opérations matricielles des convolutions. La même boucle s’exécute donc dix à cent fois 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 en parallèle de dans quels cas un VPS avec GPU vaut réellement son prix.

La génération d’images diffère de la génération de texte sur un point important. Un modèle conversationnel diffuse les tokens au fur et à mesure. 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 exécution lente signifie que vous devez regarder une barre de progression.

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

Le bloc ci-dessous présente des valeurs typiques pour une image SDXL en 1024x1024, avec 30 étapes et l’échantillonneur Euler, en juillet 2026. Considérez-les comme des ordres de grandeur. L’échantillonneur, le nombre d’étapes et la résolution les font varier.

ChartOne SDXL image, 1024x1024, 30 steps (typical, July 2026)
The data behind this chart
[
  {
    "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 du CPU indique 780 secondes, soit environ treize minutes. La carte de 24 GB prend 9 secondes. C’est l’écart de performances que vous achetez.

Lisez la grille de cette manière. Avec moins de 8 GB de VRAM, SDXL fonctionne toujours, car ComfyUI décharge automatiquement des couches vers la RAM système et peut utiliser une carte dotée de seulement 1 GB. Le déchargement coûte 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 s’effectue dans de bonnes conditions. Avec 12 GB, vous pouvez conserver un ou deux ControlNet en mémoire avec le checkpoint, sans déchargement. Avec 24 GB, vous pouvez exécuter SDXL, le refiner et l’upscaling dans un même workflow, et 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 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.

Téléchargez un modèle et prévoyez 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

Préférez 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 malveillant ne peut donc rien exécuter.

Le stockage est un coût souvent oublié. Un checkpoint de base SDXL 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. Toute personne qui utilise régulièrement ComfyUI télécharge un deuxième, puis un troisième modèle de base dans la semaine. Prévoyez 100 GB d’espace disque pour une installation fonctionnelle. Surveillez également le répertoire de sortie : les fichiers PNG en 1024x1024 occupent 1 à 2 MB chacun, et un batch lancé 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 à 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 ne possède ni écran de connexion ni comptes utilisateur. 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 installer des custom nodes. Cela permet d’exécuter arbitrairement du code sur votre serveur. Accédez plutôt au service via 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 principe s’applique à tout service auto-hébergé sans authentification. C’est également le schéma standard pour les déploiements Docker Compose sur un VPS.

Le maintenir en fonctionnement avec systemd

Une file de rendu qui s’arrête lorsque votre session SSH se ferme n’est pas un service. Créez /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 tester 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 un délai d’une à deux minutes par image. C’est le point d’entrée réaliste, et son coût représente une fraction de celui d’une solution équipée d’un GPU. C’est aussi l’endroit idéal pour héberger la bibliothèque de modèles et les workflows pendant que vous prenez votre décision.

Si vous itérez chaque jour sur vos prompts, louez à l’heure un GPU avec au moins 12 GB de VRAM auprès d’un fournisseur de GPU cloud, puis arrêtez-le lorsque vous avez terminé. La génération d’images est une charge de travail ponctuelle. Un GPU inactif facturé au mois est le moyen le plus courant de dépasser son budget dans ce domaine. 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 des adaptateurs LoRA, vous avez besoin de 24 GB de VRAM et d’une machine que vous laissez en fonctionnement. À ce stade, cette même machine est généralement rentabilisée par l’exécution d’un modèle de langage local, comme dans la configuration décrite dans auto-héberger un LLM avec Ollama.

Quel que soit le niveau choisi, mesurez votre propre machine avant de faire confiance à des chiffres publiés. Placez cinq fois le même prompt dans la file d’attente et consultez le nombre de secondes par itération affiché par ComfyUI dans sa console. Ce nombre indique votre position réelle dans 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 10 à 20 minutes pour SDXL en 1024x1024, avec 8 vCPU modernes. Cette configuration convient aux traitements par lots pendant la nuit 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 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 des couches vers la RAM système et continue de fonctionner, jusqu’à environ 1 GB de VRAM, mais chaque étape déportée prend du temps. 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. C’est aussi le minimum pratique pour entraîner des adaptateurs LoRA.

De quel 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 aussi 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 ?

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 sans GPU, 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.