Images en local : ComfyUI 0.40 et comfy_attention, pour tous les modèles

Générer des images en local n'est plus une nouveauté. En revanche, un aspect moins visible l'est encore : le moteur qui pilote les modèles. ComfyUI 0.40, publiée le 13 octobre, touche exactement à ça — et d'une manière qui concerne tous les modèles, pas seulement un.

Le point de départ est simple : la qualité des modèles open (SDXL, FLUX, Qwen-Image) n'est plus le goulot d'étranglement. L'est l'infrastructure qui les fait tourner : la gestion de la VRAM, le noyau d'attention utilisé, la sortie des résultats. ComfyUI 0.40 répond aux trois.

comfy_attention : un moteur d'attention pour tous les modèles

Jusqu'ici, le support par ComfyUI du nouveau conteneur d'attention (AttentionTensorContainer) était limité à une partie des modèles. La 0.40 l'étend à tous les modèles (release 0.40.0).

Concrètement, ce qui change :

• Configuration par modèle — les fichiers de modèle peuvent déclarer quel noyau d'attention utiliser : la nouvelle configuration comfy_attention peut sélectionner le noyau « kitchen sol attention », en plus de flash attention et de SDPA.
• Remplacement via LoRA — un LoRA peut remplacer la configuration d'attention par couche du modèle de base : on entraîne une personnalisation qui modifie aussi le comportement d'exécution, pas seulement le rendu esthétique.

Pourquoi ça compte : le noyau d'attention est l'un des rares points où la même GPU produit des vitesses très différentes selon l'implémentation des calculs. Avoir le choix — par modèle, et modifiable par un LoRA — signifie optimiser le même workflow sur un laptop AMD et sur une workstation NVIDIA sans toucher au reste de la pipeline.

Une note honnête : la release ne publie aucun benchmark officiel sur comfy_attention. Le bénéfice est dans l'unification et la configurabilité, pas dans un chiffre mesuré et publié par ComfyUI.

L'API d'assets, en local

La 0.40 implémente en local l'API d'export des assets (CORE-454) : les résultats du workflow sortent en tant qu'assets gérés par le système, actif par défaut dans cette version — désactivable avec --disable-assets.

Concrètement : si vous reliez ComfyUI à un outil externe (une interface, un script, un service qui consomme vos outputs), le format d'échange devient standard et local. Aucune image ne passe par un service externe pour être « enregistrée » ou servie. Pour qui monte une petite ligne de production graphique sur son propre matériel — catalogue, variantes, assets du site — c'est la pièce manquante pour automatiser le dernier kilomètre.

Sorties 3D standardisées

Tous les nœuds 3D exportent désormais le modèle comme élément de sortie 3D standard (PR 16200), et deux nouveaux nœuds de caméra arrivent : CreateCameraInfo et CameraAngle.

Le 3D en local reste une niche — les modèles 3D open restent loin de la qualité photo des DiT — mais la standardisation de la sortie signifie que les workflows 3D se composent avec les mêmes connecteurs que les 2D. Ceux qui expérimentent le rendu de produit ou le prototypage ont moins de friction pour relier un générateur 3D à une image.

VRAM réelle : le tableau qui compte

ComfyUI 0.40 inclut aussi des améliorations de performances basse VRAM pour les LLM Qwen 3.5 (PR 16820) et un chargeur natif de pile de LoRA (CORE-186). Mais la question reste la même : combien de GB faut-il vraiment ?

Voici le tableau de référence utilisé dans nos articles sur les modèles d'images, toujours valable aujourd'hui :

Modèle	Paramètres	Résolution native	VRAM conseillée	Architecture
SD 1.5	~0,9B	512px	6-8GB	U-Net
SDXL 1.0	2,6B	1024px	12GB	U-Net
FLUX.1 [schnell]	12B	1024px	16GB	DiT
FLUX.1 [dev]	12B	1024px	16-24GB	DiT
Qwen-Image 2.1	7B	2048px	16GB	DiT

Avec Qwen-Image 2.1, le détail compte : en bfloat16, le modèle occupe environ 14GB de VRAM. Avec 16GB (RTX 4060 Ti 16GB, RTX 5080), ça tourne, avec offload vers la CPU si la scène est en 2K ; avec 24GB (RTX 4090, 3090), c'est confortable sans offload ; en dessous de 16GB, on réduit la sortie à 1024×1024 ou on utilise l'offload CPU. Comme expliqué dans Qwen-Image 2.1 : générer et éditer des images en local, le raisonnement complet — et le choix selon le budget — est dans le guide Modèles d'images en local : de SDXL à Qwen-Image.

Et les limites ?

• Aucun chiffre officiel — ComfyUI n'a publié aucun speedup pour comfy_attention ; attendez-vous à des améliorations, pas à un multiplicateur garanti.
• L'API assets est jeune — active par défaut, mais l'écosystème d'outils externes qui la consomme est encore en train de naître.
• Le 3D est expérimental — sorties standardisées, oui ; qualité comparable à la photographie, non.

En écrivant ces lignes : la 0.43 est déjà là

La 0.40 date du 13 octobre ; à ce jour la 0.43.0 est déjà disponible, avec le support de MOSS-Image (rope scaling, LoRA de color-depth et d'édition), les nœuds FLUX 3 Max et FLUX 3 Video en 2K/4K, le support de Fibo 2.0 et la première partie des KV cache à VRAM dynamique (release 0.43.0). Le rythme de ComfyUI est une release majeure par mois : un workflow qui exploite aujourd'hui comfy_attention pourra, dans un mois, compter aussi sur les nouveaux nœuds sans refaire l'infrastructure.

Sources

• ComfyUI v0.40.0 — notes de release
• ComfyUI v0.43.0 — notes de release
• Modèles d'images en local : de SDXL à Qwen-Image

En résumé

ComfyUI 0.40 étend comfy_attention à tous les modèles, avec des noyaux sélectionnables par modèle et remplaçables via LoRA ; active par défaut le système d'assets avec API locale ; standardise la sortie 3D des nœuds. La VRAM reste la variable qui décide ce qui tourne : le tableau ci-dessus est la référence. Si votre setup a 16GB, FLUX quantisé et Qwen-Image 2.1 sont le point de départ ; avec 24GB, les DiT à pleine qualité sans offload. Pour tirer le meilleur de votre matériel, la quantisation reste le levier le plus direct.

Article généré par IA