- La quantification GGUF réduit considérablement la taille des grands modèles de diffusion comme FLUX.1 (environ 24 Go en fp16) à 5–12 Go, permettant ainsi leur exécution sur des GPU grand public dotés de 6 à 16 Go de VRAM.
- Installez le nœud personnalisé ComfyUI-GGUF développé par city96, placez les
.gguffichiers dans le dossierComfyUI/models/unet/et utilisez le nœudUnetLoaderGGUFà la place du chargeur UNET standard. - Les niveaux Q4_K_S ou Q5_K_S offrent généralement le meilleur rapport qualité/VRAM pour la plupart des cartes graphiques. Q8_0 est quasi sans perte mais permet une économie moindre de mémoire. Q2_K cible les GPU disposant de 4 à 6 Go de VRAM, avec des compromis visibles sur la qualité.
- L’encodeur textuel T5-XXL de FLUX (~9 Go en fp16) peut également être chargé au format GGUF via le nœud
DualCLIPLoaderGGUFce qui libère une quantité significative de VRAM supplémentaire.
GGUF est un format binaire développé par le projet llama.cpp pour stocker des poids de réseaux neuronaux quantifiés. Initialement conçu pour les LLM, il a été adapté aux UNets des modèles de diffusion, et le nœud personnalisé ComfyUI-GGUF nœud personnalisé de city96 intègre cette fonctionnalité dans ComfyUI. Le résultat pratique : FLUX.1-dev, qui nécessite environ 24 Go de VRAM en précision BF16 complète, devient exécutable sur un GPU de 6 à 8 Go avec une quantification Q4 — tout en conservant une qualité d’image souvent indiscernable, à l’œil nu, de celle du modèle en pleine précision.
Pourquoi GGUF est essentiel pour la génération d’images
Les points de contrôle standard de diffusion sont fournis sous la forme de .safetensors fichiers en FP16 ou BF16. Pour les modèles plus anciens (SD1.5, environ 2 Go ; SDXL, environ 7 Go), cela reste gérable sur du matériel milieu de gamme. En revanche, pour FLUX.1 et SD3, les fichiers en précision complète pèsent respectivement 24 Go et 16 Go — dépassant largement la capacité de VRAM de toute carte graphique grand public.
La quantification GGUF mappe chaque poids vers une représentation entière plus compacte. Un poids Q8_0 utilise 8 bits au lieu de 16, réduisant ainsi d’environ moitié la taille du modèle sans perte de qualité notable. Les variantes Q4 utilisent 4 bits par poids, ramenant la taille à environ un quart de celle du format fp16. Ces gains s’accumulent de façon spectaculaire sur les modèles comptant des milliards de paramètres. Utilisez le Calculateur de VRAM pour estimer la quantité de mémoire GPU nécessaire à un niveau de quantification donné, avant même de télécharger quoi que ce soit.
FLUX.1 intègre également un grand encodeur textuel T5-XXL (environ 9,3 Go en fp16). Associer un UNet GGUF à un encodeur T5-XXL également au format GGUF permet de faire tenir l’ensemble du pipeline FLUX.1 sur des cartes graphiques qui, autrement, seraient totalement incapables de l’exécuter. Ces deux composants peuvent être chargés indépendamment au format GGUF.
Installation du nœud personnalisé ComfyUI-GGUF
Via ComfyUI Manager (recommandé)
- Ouvrez ComfyUI, puis cliquez sur Manager dans la barre latérale.
- Aller à Installer des nœuds personnalisés.
- Recherchez
nœud personnalisé ComfyUI-GGUF. - Cliquez Installer à côté de l’entrée publiée par city96, puis redémarrez ComfyUI.
Installation manuelle
Clonez le dépôt dans votre dossier custom_nodes puis installez sa dépendance Python :
cd ComfyUI/custom_nodes
git clone https://github.com/city96/ComfyUI-GGUF
Linux / macOS (environnement virtuel) :
source ComfyUI/venv/bin/activate
pip install -r ComfyUI/custom_nodes/ComfyUI-GGUF/requirements.txt
Windows (version portable de ComfyUI) :
ComfyUIpython_embedspython.exe -m pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt
Windows (environnement virtuel) :
ComfyUIvenvScriptsactivate.bat
pip install -r ComfyUIcustom_nodesComfyUI-GGUFrequirements.txt
La dépendance principale est le paquet Python gguf . Redémarrez ComfyUI après l’installation.
Obtention des fichiers modèles GGUF
city96 publie sur Hugging Face des versions GGUF de FLUX.1-dev et FLUX.1-schnell sous le nom d’utilisateur city96. Recherchez city96 FLUX.1-dev-gguf sur Hugging Face pour localiser le dépôt correspondant. Chaque dépôt contient plusieurs fichiers, chacun correspondant à un niveau de quantification différent. Téléchargez uniquement le fichier correspondant au niveau de quantification souhaité — il n’est pas nécessaire de télécharger l’ensemble des fichiers. .gguf des fichiers
Des versions GGUF de l’encodeur textuel T5-XXL sont également disponibles sur Hugging Face (recherchez t5-v1_1-xxl-encoder-gguf). L’encodeur CLIP-L étant suffisamment léger (~240 Mo), sa quantification est rarement justifiée.
Des membres de la communauté publient également sur CivitAI des variantes GGUF de modèles FLUX affinés. La même structure de nœuds et de dossiers s’applique, quelle que soit l’origine du fichier téléchargé.
Emplacement des fichiers modèles
| Type de fichier | Répertoire |
|---|---|
UNet de diffusion GGUF (ex. : flux1-dev-Q4_K_S.gguf) | ComfyUI/models/unet/ |
Encodeur textuel GGUF (ex. : T5-XXL .gguf) | ComfyUI/models/clip/ |
VAE (.safetensors, inchangé) | ComfyUI/models/vae/ |
Le VAE utilisé par FLUX n’est pas quantifié et reste à son emplacement habituel. Seuls l’UNet et l’encodeur textuel bénéficient du chargement GGUF.
Utilisation des nœuds chargeurs GGUF
Une fois ComfyUI-GGUF installé et ComfyUI redémarré, de nouveaux nœuds apparaissent dans le navigateur de nœuds. Ils remplacent leurs équivalents standard dans vos workflows — vous ne pouvez pas charger un fichier .gguf avec le nœud standard UNETLoader.
| Nœud | Remplace | Accepte |
|---|---|---|
UnetLoaderGGUF | UNETLoader | .gguf modèles de diffusion |
UnetLoaderGGUFAdvanced | UNETLoader | .gguf avec options supplémentaires |
DualCLIPLoaderGGUF | DualCLIPLoader | GGUF ou .safetensors CLIP/T5 |
CLIPLoaderGGUF | CLIPLoader | Encodeur CLIP unique au format GGUF |
Pour un flux de travail FLUX standard : remplacez UNETLoader pour UnetLoaderGGUF, et remplacez DualCLIPLoader pour DualCLIPLoaderGGUF si vous utilisez également un T5-XXL au format GGUF. Connectez les sorties aux mêmes nœuds aval qu’auparavant — les formes des tenseurs sont compatibles.
Choix du niveau de quantification
Le tableau ci-dessous indique des valeurs approximatives relatives aux poids du réseau UNet de FLUX.1 uniquement. Votre budget total de VRAM doit également couvrir le VAE (~350 Mo), les encodeurs de texte (240 Mo pour CLIP-L, plus la mémoire allouée au T5-XXL) ainsi que les tenseurs intermédiaires utilisés pendant la génération. Utilisez le Référence des besoins en VRAM en complément de ce tableau, et consultez le guide GPU si vous hésitez sur le choix de votre carte graphique.
| Quantification | Taille approximative du fichier (UNet de FLUX.1) | VRAM typique requise | Qualité par rapport à BF16 |
|---|---|---|---|
| BF16 (référence) | ~24 Go | 24+ Go | Référence |
| Q8_0 | ~12 Go | ~13 Go | Quasiment identique |
| Q5_K_S | ~8 Go | ~8–9 Go | Dégradation minimale |
| Q4_K_S | ~7 Go | ~7–8 Go | Légère, souvent imperceptible |
| Q4_0 | ~6,5 Go | ~7 Go | Légère |
| Q3_K_S | ~5,5 Go | ~6 Go | Modéré |
| Q2_K | ~4,5 Go | ~5 Go | Remarquable |
Points de départ pratiques : Q5_K_S ou Q4_K_S pour les cartes disposant de 8 à 12 Go de VRAM (meilleur rapport qualité/VRAM). Q3_K_S ou Q2_K pour les cartes de 6 Go, si vous utilisez également un T5-XXL quantifié. Q8_0 pour les cartes de 16 Go lorsque vous souhaitez une fidélité maximale tout en conservant l’intégralité du modèle en VRAM.
Les checkpoints standards de diffusion sont fournis au format
À niveau Q8_0, les différences par rapport à BF16 sont pratiquement indétectables lors de comparaisons côte à côte. À niveau Q4_K_S, des dégradations très subtiles peuvent apparaître sur les textures fines et le rendu du texte lors d’un examen minutieux, mais les résultats restent de qualité professionnelle pour la plupart des cas d’usage. Q2_K introduit une perte de netteté visible et occasionnellement des artefacts, notamment sur les visages et les détails fins — il ne doit être utilisé qu’en dernier recours, sur du matériel extrêmement contraint en mémoire.
La vitesse de génération avec GGUF peut être comparable, voire supérieure, à celle obtenue en chargeant un modèle BF16 avec déchargement CPU, car les poids quantifiés réduisent la pression sur la bande passante mémoire. Toutefois, si votre GPU peut charger intégralement le modèle BF16 en VRAM sans déchargement, cette méthode sera généralement plus rapide que l’inférence GGUF. L’avantage en vitesse de GGUF est surtout marqué lorsque l’alternative implique un transfert continu de couches entre VRAM et mémoire système.
Sur Puces Apple Silicon (macOS), le backend MPS prend en charge l’inférence GGUF via ComfyUI-GGUF, mais ses caractéristiques de performance diffèrent de celles de CUDA NVIDIA. Les résultats sont fonctionnels, mais la vitesse de génération peut être inférieure à celle obtenue sur une GPU NVIDIA équivalente. L’architecture mémoire unifiée d’Apple Silicon signifie que le plafond pratique de VRAM est supérieur à celui des GPU discrets de même capacité nominale ; vous pourrez donc potentiellement exécuter des niveaux de quantification plus élevés que ceux suggérés dans le tableau ci-dessus.
Sur GPU AMD (Linux, ROCm), l’inférence GGUF fonctionne via le backend ROCm de PyTorch. Installez d’abord la version de PyTorch compatible ROCm destinée à ComfyUI, avant d’installer ComfyUI-GGUF. Les performances et la compatibilité varient selon la génération du GPU ; les cartes RDNA 3 (série RX 7000) bénéficient du support le plus fiable.
Questions fréquemment posées
Puis-je charger un fichier .gguf avec le nœud standard UNETLoader ?
Non. Le nœud standard UNETLoader n’accepte que des fichiers .safetensors . Vous devez installer le nœud personnalisé ComfyUI-GGUF et utiliser UnetLoaderGGUF pour charger les modèles .gguf de diffusion.
Dois-je quantifier moi-même mes modèles, ou puis-je télécharger des fichiers déjà quantifiés ?
Pour FLUX.1-dev et FLUX.1-schnell, city96 fournit sur Hugging Face des fichiers GGUF pré-quantifiés couvrant tous les principaux niveaux de quantification. Téléchargez le fichier .gguf spécifique correspondant au niveau souhaité — aucune utilisation d’outils de quantification n’est nécessaire.
GGUF fonctionne-t-il avec les modèles SD1.5 et SDXL ?
Techniquement oui, mais l’avantage est marginal. SD1.5 occupe environ 2 Go et SDXL environ 7 Go en fp16 — deux tailles qui tiennent aisément sur des GPU grand public milieu de gamme. La quantification GGUF est surtout utile pour les modèles très volumineux (FLUX.1, SD3), dont les poids en précision pleine dépassent la capacité de VRAM de la plupart des cartes.
Un T5-XXL au format GGUF est-il nettement moins performant que sa version fp16 complète ?
Aux niveaux Q8_0 ou Q5_K_S, la fidélité à la consigne et la qualité de l’encodage textuel sont effectivement identiques à celles de la version fp16. Des niveaux de quantification inférieurs (Q2_K, Q3_K_S) peuvent occasionnellement entraîner une légère dégradation de la conformité à la consigne sur des prompts complexes, mais cet effet reste subtil comparé à l’impact sur la qualité du UNet au même niveau de quantification.
Mon flux de travail a été conçu pour un modèle FLUX en précision pleine. Dois-je le reconstruire entièrement ?
Non. Remplacez UNETLoader avec UnetLoaderGGUF et (facultativement) DualCLIPLoader avec DualCLIPLoaderGGUF. Toutes les connexions aval — KSampler, décodage VAE, conditionnement — restent inchangées. Les sorties de ces nœuds sont compatibles sous forme de tenseurs avec le reste d’un flux de travail FLUX standard.
Pourquoi ComfyUI épuise-t-il encore la VRAM même avec un modèle quantifié ?
Le UNet GGUF ne représente qu’une partie de la consommation totale de VRAM. Un pipeline FLUX complet charge également CLIP-L (~240 Mo), T5-XXL (jusqu’à ~9,3 Go en fp16) et le VAE (~350 Mo), ainsi que des tampons intermédiaires pendant la génération. Si vous continuez à manquer de VRAM, chargez également T5-XXL au format GGUF via DualCLIPLoaderGGUFet envisagez d’activer la découpe (tiling) intégrée du VAE dans ComfyUI pour l’étape de décodage.
