
Stable Diffusion WebUI, généralement appelé AUTOMATIC1111 ou A1111, peut fonctionner sur un GPU cloud de la même manière que sur une station de travail Linux locale. Vous lancez une machine virtuelle GPU, installez l'interface Web et un point de contrôle Stable Diffusion, puis transférez son interface de navigateur en toute sécurité vers votre propre ordinateur.
Sur une RTX 5090, il y a un détail supplémentaire à connaître avant de commencer : utilisez la branche de développement d'AUTOMATIC1111 plutôt que de suivre aveuglément d'anciennes instructions d'installation. La branche de développement actuelle utilise une version de PyTorch compatible avec l'architecture Blackwell et CUDA 12.8, alors que de nombreux guides plus anciens supposent encore l'utilisation de GPU et de versions de CUDA antérieurs à la série RTX 50.
La configuration présentée dans ce guide utilise :
Vous n'avez pas besoin de deux GPU pour une utilisation interactive classique de Stable Diffusion. En réalité, l'ajout d'un second GPU ne permet pas simplement de combiner la VRAM des deux cartes au sein d'un même processus AUTOMATIC1111.
Si vous hésitez encore sur le matériel nécessaire à votre flux de travail d'imagerie, commencez par consulter notre guide sur le matériel et la VRAM pour Stable Diffusion.
Stable Diffusion WebUI est une interface de navigateur open source pour Stable Diffusion, créée par le projet AUTOMATIC1111.
Elle enveloppe les modèles de génération d'images sous-jacents dans une interface graphique, vous permettant ainsi d'utiliser le texte vers image, l'image vers image, l'inpainting, la mise à l'échelle, les LoRA, les extensions, les contrôles de prompt, les échantillonneurs et d'autres outils sans avoir à construire vous-même l'intégralité du pipeline.
L'interface du navigateur peut être trompeuse au début car elle ressemble à une application web hébergée. Ce n'est pas le cas.
L'interface WebUI s'exécute sur la machine qui effectue le calcul. Votre navigateur s'y connecte simplement.
Cette machine peut être :
L'utilisation d'un GPU cloud signifie que le modèle et l'interface WebUI s'exécutent sur le GPU distant tandis que vous les contrôlez depuis votre navigateur habituel.
L'exécution locale est judicieuse si vous possédez déjà un GPU performant et que vous utilisez Stable Diffusion fréquemment.
Les GPU cloud sont plus pertinents si votre utilisation est intermittente, si votre GPU local n'a pas assez de VRAM, si vous avez besoin d'une carte plus rapide pour un projet spécifique, ou si vous ne souhaitez pas acheter de matériel avant de savoir quelle sera votre utilisation réelle.
Le compromis est simple.
Le matériel local vous offre un accès permanent après l'achat initial. Le calcul dans le cloud remplace cet achat par un coût d'exploitation horaire et nécessite une certaine configuration de serveur.
Pour quelqu'un qui génère des images quelques heures par semaine, le calcul peut être bien plus simple que d'acheter un GPU haut de gamme qui reste inutilisé la plupart du temps.
Pour des charges de travail de production plus longues, vous devriez calculer le coût plutôt que de supposer que la location dans le cloud sera toujours moins chère.
AUTOMATIC1111 en lui-même n'est pas la cause principale de la consommation de VRAM. Ce sont les modèles et les flux de travail que vous exécutez à l'intérieur qui le sont.
Un flux de travail de base avec Stable Diffusion 1.5 peut fonctionner sur des GPU dotés d'une quantité modeste de VRAM. SDXL, la génération haute résolution, l'utilisation de plusieurs ControlNets, les grands lots, la mise à l'échelle et les pipelines plus complexes augmentent considérablement les besoins en mémoire.
Pour travailler confortablement avec les outils modernes de Stable Diffusion, disposer de 12 à 16 Go offre une marge de manœuvre bien plus importante qu'un GPU d'entrée de gamme.
La RTX 5090 dispose de 32 Go de VRAM, ce qui offre une marge de manœuvre considérable pour SDXL et les flux de travail d'image les plus exigeants.
Si vous souhaitez une explication plus approfondie de ce que 32 Go apportent réellement aux charges de travail liées à l'IA, consultez notre guide de la VRAM de la RTX 5090.
Plus de VRAM ne signifie pas que chaque génération devient proportionnellement plus rapide. Une fois que le modèle tient confortablement en mémoire, la puissance de calcul du GPU, la bande passante mémoire, la résolution, l'échantillonneur, le nombre d'étapes, la taille des lots et la conception du flux de travail influencent tous le temps de génération.
Pour cette configuration, utilisez un seul GPU cloud RTX 5090.
Il est important de le préciser, car louer deux GPU semble être un moyen évident de rendre AUTOMATIC1111 deux fois plus rapide.
Ce n'est pas ainsi qu'un processus A1111 standard fonctionne.
AUTOMATIC1111 vous permet de sélectionner le GPU CUDA utilisé par un processus, mais il ne mutualise généralement pas la VRAM de plusieurs GPU en un seul espace mémoire plus vaste pour la génération d'images. Si vous souhaitez utiliser plusieurs GPU pour augmenter le débit, l'approche habituelle consiste à exécuter des processus ou des travailleurs distincts assignés à des cartes différentes.
Pour une interface Web interactive utilisée par une seule personne, commencez avec un bon GPU.
Ne passez à l'échelle supérieure que lorsque vous avez une charge de travail qui bénéficie d'une génération en parallèle.
Connectez-vous à Compute avec Hivenet et créez une nouvelle instance.
Choisissez :
Utilisez une machine virtuelle pour ce guide plutôt qu'un conteneur.
AUTOMATIC1111 nécessite plusieurs paquets système, et l'installation est plus simple lorsque vous disposez d'une gestion de paquets Ubuntu standard et d'un accès sudo . Les conteneurs sont utiles pour les environnements d'application gérés, mais une VM nous offre le système Linux conventionnel attendu par l'interface Web.
S'il s'agit de votre première instance Compute, le guide de démarrage rapide Compute détaille la création d'instance et l'accès SSH.
Une fois la VM en cours d'exécution, connectez-vous en utilisant la commande SSH indiquée sous Options de connectivité.
Avant toute installation, vérifiez que le système d'exploitation détecte bien le GPU :
nvidia-smi
Vous devriez voir apparaître le GPU NVIDIA ainsi que les informations relatives à son pilote.
Effectuez cette vérification avant de déboguer Python, PyTorch ou Stable Diffusion. Si nvidia-smi ne détecte pas le GPU, l'installation d'un autre paquet Python ne résoudra pas le problème sous-jacent.
Mettez à jour la liste des paquets :
sudo apt update
Installez Git et les bibliothèques système utilisées par AUTOMATIC1111 :
sudo apt install -y \
wget \
git \
software-properties-common \
libgl1 \
libglib2.0-0
Le lanceur Linux d'AUTOMATIC1111 prend en charge Python 3.11, alors qu'une installation Ubuntu actuelle peut vous proposer une version plus récente de Python par défaut.
Ajoutez Python 3.11 :
sudo add-apt-repository -y ppa:deadsnakes/ppa
sudo apt update
sudo apt install -y python3.11 python3.11-venv
Vérifiez :
python3.11 --version
Clonez le projet :
git clone \
--branch dev \
https://github.com/AUTOMATIC1111/stable-diffusion-webui.git
Entrez ensuite dans le répertoire :
cd stable-diffusion-webui
Pourquoi la branche de développement ?
La branche de développement actuelle d'AUTOMATIC1111 installe PyTorch 2.7.0 avec CUDA 12.8 par défaut. PyTorch 2.7 a introduit la prise en charge des GPU Blackwell, incluant des wheels CUDA 12.8 pré-compilés.
La RTX 5090 est un GPU Blackwell.
C'est important car les anciennes installations d'AUTOMATIC1111 et de nombreux tutoriels utilisent des versions de PyTorch créées avant l'existence du support Blackwell. Ces installations peuvent détecter une RTX 5090 tout en échouant lors de l'exécution des noyaux CUDA.
La branche de développement d'AUTOMATIC1111 et Notes sur la prise en charge de Blackwell par PyTorch sont des sources utiles pour vérifier si ces versions changent après la publication de cet article.
Ouvrez son fichier de configuration Linux :
nano webui-user.sh
Recherchez :
#python_cmd="python3"
Modifiez-le comme suit :
python_cmd="python3.11"
Pour l'instant, gardez des arguments de ligne de commande simples :
export COMMANDLINE_ARGS="--port 7860"
Enregistrez le fichier.
Il y a une raison pour laquelle nous n'ajoutons pas une multitude d'options d'optimisation dès le premier lancement.
Assurez-vous d'abord que la configuration de base fonctionne.
Les options telles que --xformers, les optimisations de mémoire, les extensions, les moteurs d'attention personnalisés et autres réglages ajoutent trop de variables en cas de problème. Une fois que vous pouvez générer une image, vous disposez d'une base de référence fiable pour effectuer vos optimisations.
Exécutez :
bash webui.sh
Lors du premier lancement, AUTOMATIC1111 crée son environnement virtuel Python et installe ses dépendances.
Cela prend plus de temps que les démarrages suivants.
Une fois le chargement de l'application terminé, le terminal devrait indiquer que l'interface WebUI est à l'écoute sur le port 7860.
Ne fermez pas encore cette session SSH.
L'interface WebUI est un outil. Elle nécessite un point de contrôle (checkpoint) de modèle pour générer des images.
Pour une base propre, vous pouvez utiliser le modèle Stable Diffusion XL Base 1.0.
AUTOMATIC1111 recherche les points de contrôle Stable Diffusion dans :
stable-diffusion-webui/models/Stable-diffusion/
Depuis le répertoire WebUI, vous pouvez télécharger le point de contrôle officiel SDXL :
wget \
-O models/Stable-diffusion/sd_xl_base_1.0.safetensors \
"https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors"
Le point de contrôle pèse plusieurs gigaoctets, laissez-lui donc le temps de se télécharger.
Avant d'utiliser un modèle pour vos propres travaux, lisez sa licence et sa fiche descriptive. Le fait qu'un point de contrôle soit téléchargeable ne signifie pas que tous les modèles ont les mêmes conditions d'utilisation commerciale, de redistribution ou de création de dérivés.
Redémarrez AUTOMATIC1111 après avoir ajouté le point de contrôle s'il n'apparaît pas automatiquement.
Vous pourriez exposer le port 7860 publiquement.
Pour une interface Web personnelle, il n'y a généralement aucune raison de le faire.
Le transfert de port SSH permet de garder l'interface accessible depuis votre ordinateur sans en faire un service web public.
Sur votre ordinateur local, ouvrez un second terminal.
Prenez la commande SSH indiquée par Hivenet pour l'instance et ajoutez :
-L 7860:localhost:7860
Par exemple :
ssh \
-L 7860:localhost:7860 \
ubuntu@<instance-id>.ssh.hivecompute.ai
Votre commande SSH exacte peut varier ; utilisez donc celle affichée dans la console Compute plutôt que de copier le modèle tel quel.
Ouvrez ensuite :
http://localhost:7860
dans votre navigateur.
Votre navigateur communique désormais avec le port 7860 de votre propre machine, que SSH redirige de manière sécurisée vers l'interface Web Stable Diffusion exécutée sur le GPU cloud.
Hivenet propose un guide de transfert de port distinct si vous avez besoin de dépanner la connexion.
Dans l'interface AUTOMATIC1111 :
Gardez le premier test simple.
Vous vérifiez que :
Vous pouvez surveiller la mémoire et l'utilisation du GPU depuis un autre terminal SSH :
watch -n 1 nvidia-smi
Une fois que la génération de base fonctionne, commencez à modifier les échantillonneurs, les étapes, la taille de lot, la résolution, les LoRA, les upscalers, les extensions et les autres paramètres.
Modifier dix éléments avant d'obtenir une première image réussie rend le dépannage inutilement complexe.
Quelques répertoires deviennent rapidement importants.
Checkpoints de Stable Diffusion :
models/Stable-diffusion/
LoRAs :
models/Lora/
Embeddings :
embeddings/
Les images générées sont normalement stockées dans :
outputs/
Un espace de travail dédié à la génération d'images peut s'étendre plus vite que prévu. Les checkpoints de modèles occupent couramment plusieurs gigaoctets chacun, auxquels s'ajoutent les LoRAs, les modèles ControlNet, les images générées, les versions mises à l'échelle et les fichiers d'entraînement.
Ne considérez pas la gestion de l'espace disque comme une réflexion secondaire simplement parce que le GPU attire toute l'attention.
Oui.
AUTOMATIC1111 dispose d'un vaste système d'extensions, ce qui explique en partie pourquoi il est toujours autant utilisé.
Les extensions permettent d'ajouter des outils pour ControlNet, la navigation d'images, le prompting régional, le traitement des visages, la gestion des modèles et bien d'autres flux de travail.
Elles introduisent également du code tiers dans votre environnement.
Installez vos extensions de manière réfléchie plutôt que de les accumuler.
Une extension peut apporter ses propres dépendances Python, imposer des versions en conflit avec votre environnement actuel, consommer de la VRAM supplémentaire ou cesser de fonctionner après une mise à jour de l'interface Web.
Si votre installation cesse soudainement de fonctionner après l'ajout d'une extension, supprimez-la avant d'envisager une réinstallation complète de votre environnement GPU.
La branche de développement d'AUTOMATIC1111 prend actuellement en charge une version de xFormers conçue pour fonctionner avec sa configuration PyTorch 2.7.
Cela ne signifie pas pour autant que --xformers doit être votre priorité.
Commencez par faire fonctionner la configuration par défaut.
Ensuite, si vous souhaitez tester xFormers, ajoutez-le dans webui-user.sh:
export COMMANDLINE_ARGS="--port 7860 --xformers"
Redémarrez l'interface WebUI et comparez les performances sur vos charges de travail habituelles.
Mesurez le temps de génération et l'utilisation de la VRAM avec le même checkpoint, prompt, résolution, échantillonneur, nombre d'étapes et taille de lot.
Une option d'optimisation n'est utile que si elle améliore réellement votre flux de travail. Le nom d'une optimisation ne garantit pas que votre configuration sera plus rapide.
Un processus AUTOMATIC1111 standard utilise normalement un seul GPU sélectionné.
Si un serveur contient plusieurs GPU, vous pouvez choisir celui à utiliser via CUDA_VISIBLE_DEVICES ou les options de périphérique de l'interface WebUI.
Ne vous attendez pas à ce que deux RTX 5090 de 32 Go se comportent automatiquement comme un seul GPU de 64 Go au sein d'une même session A1111.
Si vous avez besoin de générer des images en parallèle, vous pouvez lancer plusieurs processus WebUI et assigner chaque processus à un GPU différent.
Cela peut améliorer le débit total pour une file d'attente de tâches indépendantes.
Pour une session interactive individuelle, louer plusieurs GPU avant d'avoir une charge de travail parallèle représente généralement un gaspillage de capacité.
Ils résolvent un problème similaire de manières différentes.
AUTOMATIC1111 est plus accessible si vous recherchez une interface conventionnelle avec des commandes pour le prompting, l'img2img, l'inpainting, les LoRA, les extensions et les opérations courantes de Stable Diffusion.
ComfyUI expose le pipeline d'image sous forme de graphe de nœuds.
Cela rend ComfyUI plus difficile à aborder au début, mais beaucoup plus facile à appréhender une fois que les flux de travail deviennent complexes, réutilisables ou fortement personnalisés.
Si vous souhaitez générer des images de manière interactive et ajuster des commandes familières, A1111 reste utile.
Si vous construisez des pipelines où le flux exact entre les chargeurs de modèles, le conditionnement, les échantillonneurs, ControlNet, les upscalers et les sorties est important, je choisirais ComfyUI.
Nous aborderons cette configuration séparément dans notre guide GPU cloud pour ComfyUI.
Pour les modèles plus récents comme FLUX, ComfyUI est également souvent l'environnement de travail le plus naturel. Notre futur guide GPU cloud pour FLUX.1 [dev] empruntera cette voie plutôt que de forcer chaque modèle d'image à passer par la même interface.
Le calcul repose principalement sur le temps d'utilisation du GPU.
Au tarif actuel de Hivenet pour une RTX 5090 de 0,75 € par heure de GPU, une instance à un seul GPU coûte :
Le calcul est facturé à la seconde tant que l'instance est en cours d'exécution.
C'est un point important pour ce type de charge de travail, car la génération d'images est souvent irrégulière. Vous pouvez travailler pendant une heure, faire une pause déjeuner, puis reprendre plus tard.
Lorsque vous arrêtez l'instance, la facturation du calcul s'arrête et l'environnement est temporairement conservé. Hivenet conserve actuellement les instances arrêtées pendant une durée maximale de cinq jours avant leur suppression automatique ; n'utilisez donc pas une machine virtuelle arrêtée comme stockage permanent.
Lorsque vous supprimez une instance, ses données sont effacées.
Sauvegardez vos points de contrôle, modèles personnalisés, résultats, flux de travail et tout ce dont vous avez besoin avant de la supprimer.
La tarification actuelle du calcul est disponible sur la page de tarification Hivenet.
La question est souvent posée de savoir s'il est plus économique d'exécuter Stable Diffusion localement ou dans le cloud.
Cela occulte la question pertinente : de quelle capacité avez-vous réellement besoin, et à quelle fréquence ?
Si vous générez des images quotidiennement sur la même machine pendant des années, l'achat de matériel peut être économiquement justifié.
Si vous avez occasionnellement besoin d'un GPU puissant, si vous passez d'un modèle à l'autre avec des exigences différentes, si vous travaillez par intermittence ou si vous souhaitez tester un flux de travail avant d'investir dans du matériel, la location de capacité est plus facile à justifier.
L'essentiel est d'arrêter l'instance lorsque vous ne l'utilisez plus.
La rentabilité du cloud diminue rapidement lorsqu'un GPU inutilisé reste allumé toute la nuit.
Pour des charges de travail plus importantes en matière de génération d'images et de rendu, consultez le rendu et les charges de travail intensives avec Hivenet.
Stable Diffusion WebUI est une interface par navigateur permettant d'exécuter les modèles d'image Stable Diffusion. L'implémentation la plus connue est le projet open source AUTOMATIC1111.
Non. Stable Diffusion désigne les modèles de génération d'images. AUTOMATIC1111 est un logiciel qui fournit une interface pour charger et utiliser ces modèles.
Le logiciel AUTOMATIC1111 est open source et ne nécessite aucun abonnement. Vous avez toutefois besoin de matériel pour l'exécuter, et les licences des modèles individuels peuvent comporter leurs propres conditions.
Oui. Installez-le sur un serveur GPU ou une machine virtuelle et connectez-vous à son interface par navigateur à distance. Le transfert de port SSH est un moyen simple d'accéder à l'interface sans l'exposer publiquement.
Oui, mais utilisez une version de PyTorch prenant en charge NVIDIA Blackwell. La branche de développement d'AUTOMATIC1111 utilise actuellement PyTorch 2.7 avec CUDA 12.8, qui a ajouté la prise en charge de Blackwell.
Cela dépend principalement du modèle et du flux de travail. Les anciens modèles Stable Diffusion peuvent fonctionner avec relativement peu de VRAM, tandis que SDXL, la génération haute résolution, ControlNet, les grands lots et d'autres ajouts en nécessitent davantage. Une RTX 5090 de 32 Go offre une marge confortable pour les flux de travail d'image modernes.
Oui. Ajoutez un point de contrôle SDXL compatible dans le répertoire models/Stable-diffusion et sélectionnez-le depuis l'interface WebUI.
Un processus A1111 normal utilise généralement un seul GPU plutôt que de mettre en commun la mémoire de plusieurs cartes. Plusieurs GPU sont plus utiles pour exécuter des tâches de génération distinctes en parallèle.
L'interface WebUI utilise normalement le port 7860 sauf si vous configurez un autre port.
Pour un usage personnel, le tunnel SSH est plus sûr et généralement plus simple. Si vous choisissez délibérément d'exposer l'interface WebUI au public, configurez soigneusement l'authentification et l'accès réseau plutôt que de laisser une interface de génération sans restriction sur Internet.
AUTOMATIC1111 est plus simple pour la génération d'images interactive classique. ComfyUI est mieux adapté aux flux de travail basés sur des nœuds explicites et aux pipelines complexes. Aucune interface n'est universellement meilleure ; le choix pertinent dépend de votre méthode de travail.
Pick one AI, compute, or storage workload and see the difference for yourself. Spin it up in minutes, or let our team map your fastest path to production.