Présentation du canvas

Workflow1111 est un espace Gradio qui réassemble la plupart des fonctionnalités du WebUI d’AUTOMATIC1111 sous la forme d’un graphe de onze pipelines média composés de soixante‑trois nœuds. Chaque pipeline exploite un modèle d’état de l’art : génération texte‑image, amélioration haute résolution, conversion image‑image, matrice de prompts, interrogation VLM, masquage à partir de détection, annotateurs de type ControlNet, suppression d’arrière‑plan, stockage d’informations PNG et conversion image‑vidéo. Les utilisateurs accèdent aux modèles via leur compte Hugging Face ou un jeton d’accès, ce qui fait que les appels de modèle utilisent le quota personnel de l’utilisateur.

Le canvas repose sur quatre types d’opérateurs définis par Gradio : fn (fonction Python), model (modèle invoqué via InferenceClient), space (appel d’un autre Space) et dataset (ligne d’un dataset Hub). Cette uniformité permet de connecter les entrées et sorties de chaque nœud comme des ports, créant ainsi un flux de données explicite.

Architecture des opérateurs

Le pipeline texte‑image central reproduit les contrôles classiques d’AUTOMATIC1111 (prompt, négatif, steps, CFG, seed, dimensions, model_id). Le texte passe d’abord par un nœud fn qui concatène le style choisi et nettoie la chaîne, puis par un nœud model qui invoque le checkpoint via les fournisseurs d’inférence. Un nœud fn post‑process ajoute les métadonnées de génération dans le chunk texte du PNG, ce qui alimente le pipeline PNG Info.

Le module de haute résolution utilise un nœud model FLUX.1‑Kontext avec l’instruction de raffinement « enhance fine detail and micro‑texture, keep the composition identical ». Le même nœud sert de pipeline image‑image : l’image d’entrée est modifiée selon la description fournie.

Le générateur de tags repose sur un modèle Qwen3‑4B suivi d’un nœud fn qui tronque la liste à quarante éléments. Aucun nœud personnalisé n’est requis ; le LLM et le modèle de diffusion sont tous deux des opérateurs model standards.

L’interrogation VLM utilise Qwen2.5‑VL, tandis qu’un classifieur ViT fournit des probabilités d’étiquetage. Les deux nœuds partagent l’entrée image et s’exécutent en parallèle, réduisant le temps total au coût d’un seul appel modèle.

Analyse des performances et limites

Sur les trente‑deux nœuds fn, vingt‑deux s’exécutent entièrement en processus local, sans appel réseau. Les opérations de pré‑traitement (Canny, line‑art, etc.) sont implémentées en NumPy et s’exécutent en environ 0,5 s sur CPU. Cette proportion de calcul local signifie que deux‑tiers du canvas restent fonctionnels même en perte de connexion.

Les nœuds model et space délèguent le calcul à l’infrastructure d’Hugging Face : chaque appel consomme le quota GPU de l’utilisateur mais ne nécessite pas de matériel local. Cette architecture élimine la dépendance à un GPU dédié, mais introduit une latence réseau proportionnelle à la taille du modèle (par ex. FLUX.1‑Kontext ou AuraSR ×4).

Gradio Workflow ne propose pas d’opérateur de boucle. Les variantes de la matrice de prompts sont donc implémentées par quatre nœuds texte‑image parallèles, ce qui augmente la consommation de ressources simultanées mais garantit une exécution simultanée.

Le code de liaison final montre comment un seul point d’entrée expose la génération :

@spaces.GPU(duration=get_duration, size=GPU_SIZE)
def _generate(prompt_embeds, text_token_tags, height, width, num_frames, seed):
    ...

gr.Workflow(bind={"generate": generate, "status": status}).launch()

Cette fonction reçoit un GPU uniquement pendant l’exécution, puis le libère, illustrant le modèle ZeroGPU de Gradio. La dépendance à des services externes limite la portabilité en environnement hors‑ligne, et l’absence de boucle empêche la mise en œuvre de pipelines itératifs (ex. diffusion progressive). Malgré ces contraintes, Workflow1111 démontre la faisabilité de reproduire un WebUI complet via un graphe de nœuds standardisés, tout en conservant la modularité et la transparence du code Python.