ComfyUI GGUF : comment et pourquoi utiliser ce format ?

Le format GGUF (Generalized Graphical Unified Format), popularisé notamment par llama.cpp, était initialement réservé aux modèles de texte (LLM). Cependant, avec l’évolution de ComfyUI et de ses extensions, les modèles GGUF sont désormais utilisables pour la génération d’images, offrant une alternative intéressante aux traditionnels .safetensors et .ckpt. À la différence de formats classiques, le GGUF s’appuie sur des techniques de quantisation (Q4, Q6, Q8) similaires à celles employées par Unsloth pour les LLM, ce qui permet de réduire considérablement la mémoire requise sans trop dégrader la qualité. En pratique, passer de .safetensors à GGUF, c’est comme gagner une génération de carte graphique sans rien changer à son PC.

Même avec ma RTX 5090, économiser de la VRAM s’avère très utile pour de nombreux Workflow. J’ai réalisé de nombreux tests en particulier sur HiDream i1 Full. Pour une image en 1280×720, le temps de génération tombe à 60 secondes, contre presque 120 secondes pour la version .safetensors. Il y a également des gains notables sur Flux 1 Dev.

Ces gains sont liés à la gestion de la VRAM : avec un modèle quantifié adapté à votre GPU, vous évitez saturer la VRAM. Une fois cette dernière saturée, PyTorch ou ComfyUI déchargent sur RAM/SSD, ce qui ralentie drastiquement le processus. À l’inverse, si votre workflow avec les .safetensors n’occupe pas toute votre VRAM, le passage en GGUF n’apporte pas forcément de bénéfice.

A noter, l’utilisation du format GGUF pour la génération de vidéo avec des modèles comme Wan 2.1 peut également améliorer le temps de calcul. Enfin si vous rencontrez fréquemment des freezes avec ComfyUI (plantage complet de l’ordinateur), il est fort probable que cela soit dû à une mémoire saturée. Là encore l’utilisation du format GGUF pourra vous aider au prix d’une légère perte en précision mais rend possible l’inférence sur des GPU de 6 à 8 Go de VRAM. La quantisation dynamique d’Unsloth (technique avancée) améliore nettement la précision, si le modèle que vous utilisez est disponible avec Unsloth, c’est un choix à privilégier.

Pourquoi choisir GGUF avec ComfyUI ? (mots-clés : ComfyUI, GGUF vs safetensors, optimisation VRAM)

1. Réduction de l’usage VRAM et optimisation de la taille : les fichiers GGUF sont souvent quantifiés (Q4, Q6, Q8), ce qui réduit drastiquement la taille du modèle et la mémoire utilisée. Cette approche permet de charger un modèle 13B sur seulement 6–8 Go de VRAM, là où FP16/BF16 nécessitent 24 Go ou plus.
2. Chargement plus rapide : grâce à la quantification, les modèles GGUF se chargent plus rapidement que leurs équivalents .safetensors, ce qui est un vrai plus en production ou en test rapide.
3. Compatibilité via extension : en installant l’extension ComfyUI-GGUF (via GitHub ou le Custom Nodes Manager), il devient possible de charger des modèles Unet, CLIP/T5, et VAE en .gguf (github.com).

Comment installer et utiliser GGUF avec ComfyUI

1. Installation de l’extension

• Clone le dépôt city96/ComfyUI-GGUF dans custom_nodes/ ou installe via le Custom Nodes Manager de ComfyUI, puis redémarre et recharge ComfyUI pour rafraîchir les nœuds.

2. Organisation des fichiers modèles

• Place les .gguf dans les bons dossiers :
  • models/unet pour UNet quantifié,
  • models/clip pour les encodeurs CLIP/T5,
  • models/vae reste souvent en .safetensors, même si certains projets testent déjà le VAE en GGUF (huggingface.co).

3. Utilisation des nœuds GGUF

• Les nodes “Unet Loader (GGUF)” et “DualCLIPLoader (GGUF)” apparaissent désormais dans le menu, sous la catégorie “bootleg” ou “gguf” (github.com).
• Remplace les loaders .safetensors par ces nœuds dans ton workflow pour profiter de la quantisation Q8 si possible, avec la quantification dynamique on obtient un compromis proche du comportement FP16/BF16 mais avec un usage mémoire bien plus faible.

Avantages pratiques de GGUF vs safetensors pour ComfyUI (optimisation VRAM, vitesse)

Critère	.safetensors classique	.gguf quantifié
Taille du modèle	Élevée (FP16/BF16)	Jusqu’à –80 % avec Q4–Q8
Usage de la VRAM	Important (24–48 Go pour un 13B)	Réduit (6–8 Go pour un 13B)
Temps de chargement	Modéré	2–5x plus rapide
Qualité d’image	Référence	Proche FP16, pertes minimes en Q8
Disponibilité	Large base	Nécessite extension GGUF
Compatibilité	Universelle	Limitée aux loaders GGUF

HiDream i1 GGUF dans ComfyUI : test et optimisation VRAM

Le modèle HiDream i1 GGUF illustre parfaitement l’intérêt du format GGUF avec ComfyUI pour la génération d’images avancée, même sur des GPU modestes. À l’image des LLM quantifiés par Unsloth, la version Q8 conserve une précision très proche du FP16 tout en divisant la consommation mémoire.

Présentation du modèle HiDream i1 GGUF

HiDream-i1 est disponible en version Full, Dev et Fast. Converti en GGUF (via Hugging Face), il propose des variantes quantifiées du Q2 au Q8. Cela permet d’adapter le modèle à la quantité de VRAM disponible, comme pour les LLM où FP16/BF16 restent réservés aux GPU haut de gamme (>24 Go), alors que la quantisation permet l’exécution sur des cartes 8–12 Go.

Intégration dans ComfyUI

L’intégration de HiDream i1 GGUF dans un workflow ComfyUI repose sur quelques étapes clés :

• Installer l’extension ComfyUI-GGUF pour activer les nœuds spécialisés (ex. “Unet Loader (GGUF)”).
• Placer les fichiers .gguf dans les dossiers appropriés (models/unet/, models/clip/, etc.).
• Utiliser les nodes GGUF dans votre workflow : il suffit de remplacer le node de chargement classique par le node dédié au format GGUF, comme décrit dans la documentation officielle et le wiki ComfyUI.
• Choisir la bonne variante selon la VRAM disponible :
  • Full : nécessite environ 16 à 20 Go de VRAM,
  • Dev : environ 12 Go,
  • Fast : environ 8 Go (Next Diffusion, 2024).

Avantages concrets

• Accessibilité sur des GPU modestes : Là où le modèle .safetensors serait inutilisable faute de mémoire, la version GGUF Q8 permet d’exécuter HiDream-i1 sur des cartes disposant de seulement 8 à 12 Go de VRAM, sans sacrifier la génération d’images de qualité.
• Chargement plus rapide et stabilité : Le modèle quantifié est plus léger, ce qui accélère l’initialisation et limite les risques d’erreur “Out of Memory”, même lors de l’utilisation de workflows complexes.
• Expérience utilisateur documentée : Des utilisateurs sur Reddit confirment la bonne compatibilité de HiDream-i1 GGUF avec ComfyUI, à condition de tenir le plugin ComfyUI-GGUF à jour.

Points à vérifier et limites à surveiller

• Compatibilité des poids et mise à jour du plugin : Certains retours signalent des erreurs de chargement (“dimensions mismatch” sur certains blocs) avec des versions obsolètes de ComfyUI-GGUF ou avec des fichiers GGUF non adaptés. Il est donc conseillé de vérifier la compatibilité entre la version du modèle et celle du plugin ; surveillez les mises à jour et les notes de version sur les dépôts GitHub (Hugging Face Discussions).
• Fonctionnalités avancées (ControlNet, LoRA, etc.) : Leur support sur les modèles quantifiés reste expérimental et pourra nécessiter des ajustements futurs.

HiDream-i1 et GGUF, en bref

HiDream-i1 GGUF est une solution de choix pour profiter de modèles diffusion de nouvelle génération sur des configurations matérielles accessibles, sans compromis majeur sur la qualité. L’écosystème ComfyUI, enrichi du support GGUF, ouvre ainsi la porte à de nombreux usages jusqu’alors réservés aux configurations haut de gamme.

---

Cas d’usage concret : Flux.1 Dev GGUF

Un guide indique que la version Flux.1 Dev GGUF permet une génération d’images fluide avec seulement 6 Gb de VRAM, en combinant UNet et CLIP quantifiés, plus un VAE standard (comfyui-wiki.com, nextdiffusion.ai). La démarche comprend :

• téléchargement des modèles (flux1-dev-gguf, encoder T5, clip, vae),
• placement aux bons emplacements,
• installation des nœuds GGUF,
• utilisation dans un workflow JSON « clé en main ».

---

Evolutions en cours et points d’attention

• Compatibilité VAE en .gguf : certains modules comme gguf-node supportent maintenant le VAE quantifié (huggingface.co, runcomfy.com).
• Support des LoRA et ControlNet : encore expérimentaux en quantifié, à tester en charge réelle (github.com).
• Qualité visuelle : la perte de qualité dépend de la quantification (Q2= pertes visibles, Q8 : pertes minimes voir négligeable) et également du modèle. L’idéal est de créer un Workflow avec une version quantifiée et un autre avec la version .safetensors, puis de comparer les résultats. Avec HiDream i1 et plusieurs tests, la version Q8 produit à mes yeux des résultats quasiment similaires à la version .safetensors. Avec Flux 1 Dev, le constat est à peu près similaire, mais j’ai moins de recul pour le moment.
• Stabilité des nœuds : certains utilisateurs signalent des bugs (loader absent ou nœud null) après changement de version, à surveiller (discuss.huggingface.co).

---

Conclusion

Si vous la VRAM de votre GPU est saturée et ComfyUI plante régulièrement, c’est probablement le moment de tester GGUF. Personnellement, avec le version Q8 d’Unsloth, je n’ai pas vu de différence notable de qualité par rapport au .safetensors, même en zoomant sur les détails.

ComfyUI GGUF permet une génération d’images efficace et économique, particulièrement pour les utilisateurs disposant de GPU modestes. Le format GGUF, lorsqu’il est utilisé via les nœuds appropriés (Unet Loader, DualCLIPLoader), offre une alternative légère aux formats traditionnels comme .safetensors. Comparé à .safetensors, GGUF réduit l’usage de VRAM, accélère le chargement, tout en conservant une qualité visuelle acceptable , bien que quelques améliorations soient à vérifier (VAE, LoRA, qualité). Comme nous l’avons vu, les techniques avancés de quantification dynamique (Unsloth) sont à privilégier, afin d’obtenir une meilleure qualité / precision.