ComfyUI 0.36.0 s'exécute dans une image Docker construite localement sur VM210 : base Python figée par digest, sources figées par commit, dépendances verrouillées avec leurs empreintes (wheels téléchargées puis installées hors ligne). Environnement validé : Python 3.12.14, PyTorch 2.11.0, CUDA 13.0. Détails du conteneur et du correctif de cache sur la page Docker.
Alternative effectivement étudiée : un POC Windows antérieur (VM260) avait éprouvé ComfyUI via Docker Desktop avec des workflows SDXL / Flux. Ce déploiement Linux (VM210) en est distinct et n'a pas encore confirmé l'usage de Flux ; seul RealVisXL a été utilisé et mesuré ici. La RTX 5090 étant exclusive, VM210 et VM260 ne l'utilisent pas simultanément.
Choix de durcissement retenus : exécution sans privilèges, système de fichiers racine en lecture seule, modèles montés en lecture seule, nœuds personnalisés et API désactivés (sans bloquer le réseau sortant en général), interface publiée uniquement en boucle locale (accès par tunnel SSH, sans publication Internet).
Noms de comptes, hôtes et chemins remplacés par des exemples. Aucun secret n'est requis. Vérification du conteneur et de l'API (docker inspect/logs, ollama ps, curl) détaillée sur la page Docker ; télémétrie GPU et vérification SHA-256 du checkpoint sur la page IA & LLM.
$SshTarget = '<compte>@<hote-gpu>' ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:8188:127.0.0.1:8188 $SshTarget
Ouvrir ensuite http://127.0.0.1:8188/ sur ce poste. Le silence du terminal après authentification
est normal : -N ouvre le tunnel sans session distante. Ctrl+C ferme le tunnel, mais ne coupe pas
ComfyUI ; une interface inaccessible après fermeture du terminal n'est donc pas nécessairement une panne
serveur.
Symptôme : un graphe mélangeant le checkpoint RealVisXL avec des nœuds SD3/AuraFlow a été construit puis écarté (incompatibilité de graphe). Une annulation de génération est ensuite restée bloquée, sans qu'une cause exacte ait pu être établie ; un redémarrage ciblé du conteneur a été nécessaire pour revenir à un état sain. Solution adoptée : retour à un graphe SDXL adapté (cohérent avec RealVisXL), qui a ensuite fonctionné normalement.
Un second incident, décrit sur la page Docker, a
touché le démarrage du conteneur (getpass.getuser() en échec faute d'UID connu) ; il a été résolu
par variables d'environnement sans reconstruire l'image.
| Essai | Observation | Portée |
|---|---|---|
| Portrait 512×512, 8 étapes | 8,03 s (chargement initial compris) | Validation fonctionnelle, pas un test de qualité |
| Portrait 1 024×1 024, 30 étapes | Image obtenue (DPM++ SDE Karras) | Durée non attribuée avec certitude dans l'historique |
- Durcissement d'un conteneur ComfyUI (sans privilèges, FS racine en lecture seule)
- Vérification d'intégrité de checkpoint par empreinte SHA-256
- Partage d'un GPU exclusif entre inférence LLM et génération d'image
- Diagnostic d'incompatibilité de graphe ComfyUI et récupération après blocage
- Accès distant sécurisé par tunnel SSH, sans publication Internet
Limites et travaux ouverts
- Le partage automatique des requêtes entre ComfyUI et Ollama reste à construire (bascule manuelle pour l'instant)
- Le réalisme anatomique, les poses et la qualité à grande échelle restent à évaluer
- L'usage de Flux sur cette cible Linux n'est pas confirmé — seul RealVisXL a été mesuré ici
- Intégrations agentiques/n8n, admission commune des requêtes et politique de redémarrage après reboot restent des travaux ouverts
- RealVisXL V5.0 est diffusé sous licence Open RAIL++ : des poids disponibles ne signifient pas l'absence de restrictions de licence