Exécuter ComfyUI dans le cloud est simple. Le rendre reproductible, privé et peu coûteux, voilà le vrai travail.
Une configuration utile de GPU cloud pour ComfyUI sépare quatre préoccupations : du calcul jetable, des fichiers persistants, un accès privé et une règle d’arrêt. Considérez l’instance GPU comme remplaçable ; placez les modèles, workflows, entrées et sorties sur un stockage qui lui survit. Vous obtenez ainsi une configuration que vous pouvez redémarrer sans retélécharger une pile de workflows ni vous demander où sont passées les images d’hier.
Ce guide est neutre vis-à-vis des fournisseurs. Il montre comment configurer un GPU cloud pour ComfyUI pour un travail interactif, comment planifier le stockage et comment calculer les coûts sans prétendre qu’un tarif GPU horaire unique raconte toute l’histoire.
En bref
Pour la plupart des développeurs indépendants et des petites équipes IA, commencez par ce modèle de déploiement :
- Choisissez une VM GPU interactive ou un pod disposant de suffisamment de VRAM pour un véritable workflow — pas pour un benchmark théorique.
- Attachez un stockage persistant avant de télécharger des modèles ou d’installer des nœuds personnalisés.
- Gardez le processus web de ComfyUI privé par défaut ; utilisez un bureau authentifié, un tunnel ou un proxy du fournisseur plutôt qu’un port public ouvert.
- Enregistrez chaque graphe fonctionnel, révision de modèle et sortie sur le point de montage persistant.
- Mesurez une génération représentative, puis arrêtez le GPU dès que la session de travail se termine.
Le principe essentiel est simple : un GPU cloud pour ComfyUI doit être facile à remplacer, contrairement à votre état de travail.
1. Choisissez le bon type d’environnement cloud avant d’installer quoi que ce soit
Pour une session ComfyUI pratique, choisissez une VM GPU, un pod ou un environnement de bureau à distance qui vous donne accès à un navigateur, un terminal et un point de montage persistant. C’est généralement plus facile à déboguer qu’un endpoint limité aux requêtes, car vous pouvez inspecter les journaux, tester un graphe, ajouter un modèle et itérer dans la même session.
N’utilisez un déploiement orienté requêtes qu’une fois le workflow stable et après avoir déterminé comment il recevra les entrées, renverra les sorties, authentifiera les appelants et se rétablira après des échecs. Un service GPU cloud pour ComfyUI interactif est le bon point de départ lorsque l’objectif est le développement de workflows plutôt qu’une API de produit finalisée.
Avant le déploiement, répondez à ces questions propres au fournisseur :
| Question | Pourquoi c’est important |
|---|---|
| Puis-je attacher un stockage qui survit à un redémarrage ou à un remplacement ? | Les modèles et les sorties sont coûteux à recréer ou à télécharger. |
| Puis-je restreindre l’accès réseau entrant ? | ComfyUI ne doit pas devenir un panneau de contrôle public non authentifié. |
| Puis-je utiliser un terminal et consulter les journaux ? | La plupart des problèmes d’installation et de nœuds personnalisés se diagnostiquent plus rapidement depuis le shell. |
| Qu’est-ce qui reste facturable après l’arrêt du GPU ? | Le calcul, le disque, les instantanés, les IP et le trafic sortant sont souvent des postes distincts. |
| Le volume est-il lié à une région ou à une zone de disponibilité ? | Cela peut limiter l’emplacement où le prochain GPU pourra démarrer. |
Ne choisissez pas le meilleur GPU cloud pour ComfyUI en vous fondant uniquement sur le nom d’un modèle. Partez de la demande mémoire maximale du workflow : checkpoint, encodeurs de texte, VAE, modèles de contrôle, LoRA, taille de lot, résolution, ainsi que toute étape vidéo ou d’upscaling se disputent la VRAM. Exécutez un graphe représentatif et consignez son comportement au pic avant de vous engager sur une machine plus grande ou exécutée plus longtemps.
Pour des comparaisons plus larges entre plateformes, consultez les guides de Flatkey sur les plateformes de location de GPU cloud, la sélection de GPU et la capacité GPU serverless par rapport à la capacité dédiée.
2. Attachez d’abord le stockage persistant
L’erreur la plus fréquente dans le cloud consiste à tout télécharger dans le système de fichiers temporaire de l’instance. Lorsque cette machine est arrêtée, reconstruite ou remplacée, le cache de modèles, les sorties, les workflows et les modifications locales peuvent disparaître avec elle.
Créez et attachez le volume persistant avant la première installation. Sur ce volume, conservez une arborescence simple et sans fioritures :
/workspace/comfy-data/
├── models/
│ ├── checkpoints/
│ ├── vae/
│ ├── loras/
│ ├── controlnet/
│ └── upscale_models/
├── input/
├── output/
├── workflows/
├── custom-node-notes/
└── run-notes/
Vous n’avez pas besoin de tous les dossiers dès le premier jour. L’objectif est de placer les ressources réutilisables et le travail final sur le point de montage durable, tout en laissant les fichiers temporaires et les environnements reconstructibles sur le disque de l’instance lorsque c’est plus pratique.
ComfyUI propose des contrôles de répertoires utiles via ses indicateurs de démarrage. --base-directory modifie l’emplacement de base pour les modèles, les nœuds personnalisés, les entrées, les sorties, les fichiers temporaires et les données utilisateur ; --input-directory, --output-directory et --extra-model-paths-config vous permettent d’être plus précis. Consultez la référence actuelle des indicateurs de démarrage de ComfyUI avant d’intégrer des chemins dans un modèle.
À titre d’exemple concret de stockage cloud, RunPod indique que son système de fichiers de conteneur est temporaire, tandis que les volumes persistent en dehors du cycle de vie du conteneur. D’autres fournisseurs utilisent des termes différents ; vérifiez donc le comportement exact lors de l’arrêt, du redémarrage et de la terminaison dans la documentation de stockage du fournisseur avant de vous y fier. Le guide de persistance de RunPod explique utilement cette distinction.
3. Installez ComfyUI avec une base reproductible
Utilisez le projet amont comme référence pour l’installation. Le guide actuel d’installation manuelle de ComfyUI couvre les plateformes prises en charge, les choix de PyTorch propres au GPU, l’installation des dépendances, les répertoires de modèles et l’option comfy-cli. Commencez par le README de ComfyUI officiel, puis consignez dans vos propres notes les ajouts spécifiques à votre équipe.
Pour une machine cloud Linux, la séquence générale ressemble à ceci :
git clone https://github.com/Comfy-Org/ComfyUI.git
cd ComfyUI
python -m venv .venv
source .venv/bin/activate
# Installez la version de PyTorch qui correspond à cet environnement GPU/pilote.
# Suivez les instructions actuelles de ComfyUI et PyTorch en amont plutôt que de
# copier une commande de wheel CUDA depuis une ancienne image.
pip install -r requirements.txt
python main.py \
--base-directory /workspace/comfy-data \
--input-directory /workspace/comfy-data/input \
--output-directory /workspace/comfy-data/output \
--disable-auto-launch
Il s’agit volontairement d’une base de départ, et non d’un programme d’installation universel à copier-coller. Les images cloud diffèrent en matière de pilotes, de versions de Python, de compatibilité CUDA, de points de montage et d’autorisations. Vérifiez python main.py --help sur la machine en cours d’exécution et consignez la commande de lancement validée dans run-notes/ une fois qu’elle fonctionne.
Si vous partagez une bibliothèque de modèles avec une autre interface utilisateur ou placez des modèles en dehors des répertoires par défaut de ComfyUI, utilisez le mécanisme amont extra_model_paths.yaml au lieu de créer des liens symboliques vers des dossiers au hasard. Cela rend la relation explicite et évite bien des surprises lors d’une reconstruction ultérieure.
4. Configurez un accès distant sécurisé avant d’utiliser --listen
Par défaut, ComfyUI écoute sur 127.0.0.1 et utilise le port 8188. Ses options de démarrage prennent également en charge une autre adresse de liaison, un autre port, des fichiers de certificat/clé TLS et un en-tête CORS configurable. Consultez les arguments CLI actuels pour connaître le comportement exact.
Cette flexibilité n’est pas une invitation à exposer sur l’Internet public une console de génération d’images non authentifiée. Pour le travail interactif, un modèle de bureau GPU cloud sécurisé pour ComfyUI est généralement plus sûr :
- Ouvrez un navigateur dans une session de bureau à distance authentifiée, en conservant ComfyUI sur l’interface de bouclage ; ou
- Utilisez un tunnel SSH authentifié ou un proxy géré par le fournisseur ; ou
- Placez un proxy inverse avec des contrôles d’identité et TLS devant un service ComfyUI délibérément exposé.
Ne liez l’écoute à 0.0.0.0 que lorsque le chemin réseau est intentionnellement protégé par un pare-feu, une couche d’identité et TLS lorsque cela est approprié. N’activez pas un CORS permissif simplement pour faire fonctionner une connexion de navigateur. Si un nœud personnalisé, une extension ou un proxy modifie la frontière de confiance, consignez-le dans run-notes/ et testez depuis un compte ou un appareil distinct.
C’est particulièrement important si vous téléversez des images de référence privées, utilisez des clés API dans des nœuds ou autorisez des collègues à installer des nœuds personnalisés. Traitez l’installation de nœuds personnalisés comme une modification de dépendance : examinez la source, consignez la version et testez-la dans un environnement jetable avant de l’ajouter à un volume de production partagé.
5. Rendez reproductible la première génération ComfyUI sur GPU cloud
Votre première session doit valider le modèle de déploiement, et non chercher à produire une image parfaite. Utilisez un petit workflow connu et suivez cette boucle :
- Téléversez une image de test non sensible ou une invite de test.
- Chargez un modèle depuis le répertoire de modèles persistant.
- Exécutez une seule génération à la résolution et avec la taille de lot cibles.
- Enregistrez le JSON du workflow dans
workflows/avec un nom descriptif et une date. - Conservez l’image finale et toute sortie de comparaison dans
output/. - Notez la révision du modèle, les nœuds personnalisés pertinents, le temps d’exécution et toute solution de contournement liée à la mémoire dans
run-notes/.
Cela transforme une génération ComfyUI sur GPU cloud ponctuelle en une expérience qu’une autre personne peut reproduire. Cela vous indique aussi si la machine est correctement dimensionnée avant de télécharger plusieurs modèles volumineux et de découvrir que le workflow ne peut pas s’exécuter avec les paramètres prévus.
6. Adoptez une règle axée d’abord sur la charge de travail pour choisir le GPU
Le meilleur GPU cloud pour ComfyUI est la plus petite option disponible qui exécute votre graphe réel de façon fiable, à la résolution, avec la taille de lot et la latence dont vous avez besoin. Le « meilleur » choix varie selon le graphe.
| Indicateur de charge de travail | Éléments à privilégier | Éléments à tester avant de s’engager |
|---|---|---|
| Un workflow à image unique | Assez de VRAM pour chaque composant actif, avec une marge | Une invite représentative à votre résolution habituelle |
| Plusieurs modèles de contrôle, de grands lots ou des étapes d’agrandissement | Davantage de VRAM avant de rechercher un débit de calcul brut | Le comportement de mémoire au pic et le temps d’exécution de bout en bout |
| Des graphes vidéo, à plusieurs étapes ou avec de nombreux modèles | Un stockage persistant, un chargement rapide et un plan de redémarrage | Le temps de chargement des modèles, l’utilisation du disque temporaire et la gestion des sorties |
| Des sessions d’équipe répétées | Une image/un modèle réutilisable et des contrôles d’accès clairs | Le temps de reconstruction depuis une instance propre en utilisant le même volume |
Ne vous fiez pas au chiffre de VRAM d’un autre créateur comme à une garantie. Son checkpoint, sa quantification, ses versions de nœuds, sa résolution et ses paramètres de lot peuvent différer des vôtres. Un test représentatif de 10 minutes est plus utile qu’une recommandation matérielle trop simplifiée.
7. Calculez le coût à partir du travail effectué, et non du tarif horaire du GPU
Un devis pour un GPU cloud n’est qu’une partie du total. Utilisez cette feuille de calcul pour chaque workflow ou projet :
Session cost
= (GPU runtime × current provider compute rate)
+ retained storage for the billing period
+ applicable transfer, snapshot, or platform charges
Cost per accepted output
= session cost / number of outputs you actually keep
Le second chiffre est souvent plus utile que le coût par image générée. Si vous effectuez 200 tests rapides et ne conservez que cinq résultats, le coût par résultat retenu vous en dit davantage sur le workflow que le chiffre nominal par image.
Utilisez ces mesures pratiques pour un GPU cloud ComfyUI :
- Adoptez une habitude d’arrêt. Décidez qui arrête le GPU et à quel moment. Ne le laissez pas fonctionner simplement parce qu’un onglet de navigateur est ouvert.
- Séparez les données persistantes des données jetables. Conservez les modèles, workflows, entrées et sorties sur un stockage durable ; évitez de payer accidentellement pour préserver des fichiers temporaires.
- Testez à petite échelle avant de monter en charge. Validez un graphe à une résolution et une taille de lot modestes avant de vous engager dans une longue exécution d’images ou de vidéos.
- Conservez un manifeste des modèles. Documentez ce qui est installé et pourquoi. Cela évite les téléchargements en double et rend le nettoyage plus sûr.
- Examinez la facture à l’arrêt. Le stockage, les instantanés, les IP publiques et les règles de transfert de données varient selon le fournisseur ; vérifiez-les dans l’interface de facturation et la documentation actuelles.
- Consignez les données d’exécution. Pour un workflow récurrent, notez la durée d’exécution, les nouvelles tentatives, les résultats retenus et les tailles des entrées/sorties. Vous obtiendrez ainsi une véritable base de référence budgétaire.
Pour un cadre de décision plus général, consultez Explication des prix de location de GPU. Cet article couvre la différence entre un tarif horaire attrayant et le coût du travail effectué.
8. Lorsqu’un GPU cloud n’est pas la bonne abstraction
ComfyUI est utile lorsque vous avez besoin d’un contrôle au niveau des nœuds, de fichiers de modèles locaux, d’un traitement personnalisé, d’une itération visuelle ou d’un graphe spécifique. Ce n’est pas automatiquement la manière la plus simple de déployer une fonctionnalité d’IA.
Si le besoin produit consiste en un appel à un modèle hébergé plutôt qu’en un contrôle au niveau du workflow, évaluez séparément une approche fondée sur un modèle géré ou une API. Flatkey fournit une interface unifiée pour les appels d’API de modèles et d’outils ; cela peut réduire la fragmentation de l’intégration et de la facturation, mais ne remplace pas ComfyUI lorsque votre besoin est un graphe de nœuds persistant avec des ressources locales personnalisées. Clarifiez cette limite avant d’optimiser la mauvaise pile technologique.
Liste de vérification avant démarrage
Avant de démarrer une session GPU cloud ComfyUI, vérifiez tous les points suivants :
- [ ] Le stockage persistant est attaché et monté à l’emplacement attendu.
- [ ] Les chemins des modèles, workflows, entrées et sorties pointent vers ce stockage.
- [ ] La combinaison GPU/PyTorch actuelle a été validée avec un graphe réel.
- [ ] L’accès distant est authentifié ; aucun port public non authentifié n’est exposé.
- [ ] Le JSON du workflow, la révision du modèle et les modifications des nœuds personnalisés seront documentés.
- [ ] Vous savez ce qui reste facturé après l’arrêt du GPU.
- [ ] Un responsable désigné arrêtera le calcul après la session.
Questions fréquemment posées
Comment exécuter ComfyUI sur un GPU cloud ?
Déployez une machine GPU interactive avec un volume persistant, installez ComfyUI conformément aux instructions actuelles en amont, dirigez les chemins des modèles/entrées/sorties de ComfyUI vers le stockage monté, gardez l’accès au navigateur privé et testez un workflow représentatif avant de passer à l’échelle.
Que dois-je stocker de manière persistante pour ComfyUI ?
Stockez les modèles réutilisables, les workflows, les ressources d’entrée dont vous aurez à nouveau besoin, les sorties finales, les notes sur les nœuds personnalisés et un petit journal d’exécution. Gérez séparément les caches temporaires et les environnements reconstructibles, sauf si leur conservation justifie le coût de stockage.
Un bureau GPU cloud sécurisé pour ComfyUI est-il nécessaire ?
C’est un choix pratique lorsque vous souhaitez disposer d’un navigateur et d’un terminal interactifs sans publier ComfyUI directement sur Internet. Utilisez un bureau à distance, un tunnel ou un proxy authentifié, et gardez l’application privée par défaut.
Quel GPU cloud est le mieux adapté à ComfyUI ?
Choisissez en fonction des besoins réels en VRAM de votre workflow, de l’objectif de durée d’exécution et de vos besoins en stockage et en accès. Testez d’abord le graphe prévu ; un GPU adapté au checkpoint et à la résolution de quelqu’un d’autre peut ne pas convenir aux vôtres.
Que doit inclure un service GPU cloud pour ComfyUI ?
Au minimum : un environnement GPU compatible, un stockage persistant, un accès réseau contrôlé, un moyen d’inspecter les journaux et des informations de facturation claires pour les ressources en cours d’exécution comme pour celles arrêtées.
Références officielles utilisées dans ce guide
- Installation manuelle de ComfyUI et conseils sur le répertoire des modèles
- Indicateurs de démarrage de ComfyUI
- Définitions des arguments CLI de ComfyUI
- Guide RunPod sur la persistance des données de conteneur — utilisé comme exemple concret de stockage, et non comme comparaison de plateformes
La configuration durable n’est pas compliquée : gardez le GPU remplaçable, conservez le travail de manière persistante, gardez l’accès privé et intégrez l’arrêt du calcul au flux de travail.
