Optimiser ComfyUI avec peu de VRAM : SDXL, FLUX et vidéo sur un GPU de 6 à 8 Go

Le terminal affiche torch.cuda.OutOfMemoryError: CUDA out of memory. La console ComfyUI indique regular VAE encoding, retrying with tiled VAE encoding, mais l’image 1024×1024 échoue toujours. Une RTX 3060 de 8 Go peut produire une image SDXL ; dès que Hires Fix, FaceDetailer et ControlNet sont activés ensemble, le besoin dépasse 12 Go. À 768×768, sans ControlNet, le workflow finit par passer, mais le résultat ne correspond plus à l’objectif.

Sur un GPU grand public de 6 à 8 Go, Apple Silicon ou du matériel AMD, il faut donc rendre les workflows SDXL, FLUX et vidéo légère aussi stables que possible, tout en sachant quelles modifications sacrifient vitesse, qualité ou compatibilité.

---

Commencer par la catégorie de VRAM du GPU

Un budget VRAM ne se devine pas. La catégorie du GPU détermine les workflows réalistes et la première stratégie à tester.

Catégories de VRAM, workflows possibles et point de départ

VRAM	Workflows possibles	Limites et risques	Point de départ conseillé
6GB	SDXL en basse résolution (512–768) FLUX très compressé (Q2_K/Q3_K_S + GGUF + —lowvram/—novram) Vidéo : 8 images en 480p comme cas limite	Résolution limitée Les nodes supplémentaires déclenchent facilement un OOM Lent à cause de l’offload RAM	Quantification agressive comme Q3_K_S Résolution 512–768 Désactiver ControlNet et post-traitement 8 images vidéo au maximum
8GB	Une image SDXL 1024×1024 FLUX fp8/GGUF Q4_K_S sans garantie de stabilité 8 images 480p confortables, 24 images 720p en limite	ControlNet avec Hires Fix peut provoquer un OOM T5 doit être fp8/GGUF Ne pas dépasser 1024×1024 FLUX.1 GGUF Q5_K_S est limite	FLUX.2 Klein 4B GGUF en priorité T5 fp8/GGUF Tiled VAE batch size=1
12GB	SDXL + ControlNet + upscale simple FLUX Q5_K_S/Q6_K plus confortable 24 images 720p confortables, 60 images 1080p en limite	Plusieurs ControlNet restent coûteux Calculer images × résolution Le post-traitement garde un plafond	FLUX Q5_K_S/Q6_K T5 fp8 facultatif Tiled VAE facultatif Tester batch size 2–3
16GB+	FLUX full fp16 ou Q8_0 presque sans perte Plus de marge pour ControlNet/LoRA 60 images en 1080p	FLUX full fait environ 23 Go Images × résolution reste important Le post-traitement crée encore des pics	FLUX Q8_0 ou fp16 T5 fp16 Tiled VAE facultatif Tester batch size 4–8

Sources de pic, de la plus importante à la plus faible

1. Poids du modèle : checkpoint SDXL d’environ 6,5 Go, FLUX fp16 d’environ 23 Go
2. Encodeur T5 : fp16 d’environ 9 Go, trop grand pour 8 Go ; fp8 autour de 4–5 Go ; GGUF en Q3/Q4/Q5
3. Résolution latente : un latent 2048×2048 peut approcher 8 Go
4. VAE encode/decode : un pic proche de 8 Go est possible à 2048×2048
5. Batch size : l’inférence simultanée produit le pic le plus élevé
6. ControlNet/Detailer : environ 2–3 Go chacun dans les exemples
7. Images vidéo : nombre d’images × résolution × VideoVAE
8. Cache/preview : environ 0,5–1 Go

La consommation réelle dépend de la résolution, de la précision, de la version du modèle, du batch, des nodes de post-traitement, du nombre d’images, de PyTorch, du pilote et des custom nodes. Un écart de 1 à 2 Go est possible. Utilisez ce tableau comme budget initial, puis mesurez le workflow réel.

---

Arguments de démarrage ComfyUI pour faible VRAM

ComfyUI fournit plusieurs arguments pour la VRAM et la mémoire système. Ils changent avec les versions. La liste ci-dessous correspond à ComfyUI v0.18.0+ autour de mars 2026 ; python main.py --help et la documentation officielle actuelle restent prioritaires.

Arguments, rôle, GPU et effet sur la vitesse

Argument	Rôle	GPU	Effet sur la vitesse	Usage
--lowvram	Découpe le modèle et transfère depuis la RAM	4–8GB	20–40 % plus lent	Sans effet avec Dynamic VRAM actif À tester après —normalvram
--novram	Garde les poids sur CPU/RAM et ne place sur GPU que le calcul actif	Moins de 4GB	50–70 % plus lent	Dernier recours Très lent, mais peut fonctionner
--normalvram	Force le mode standard et désactive Dynamic VRAM	12GB+	Pas d’effet attendu	Test manuel de —lowvram Ou OOM par fragmentation
--reserve-vram N	Réserve N Go de VRAM au système	Tous	Pas d’effet attendu	Évite l’instabilité du système Réserver souvent 2–4 Go
--async-offload	Décharge les poids de façon asynchrone	Tous	Exemple : 5–10 % plus rapide	Réduit l’attente CPU–GPU avec beaucoup de RAM, souvent 32 Go+
--fp8_e4m3fn-unet	Force UNet en fp8	8–12GB	Neutre environ	Souvent ignoré par FLUX Vérifier compute dtype
--fp8_e4m3fn-text-enc	Utilise fp8 pour l’encodeur texte	8GB	Neutre environ	Réduit T5 d’environ 9 à 4–5 Go Utile pour FLUX faible VRAM
--fp8_e5m2fn-text-enc	Autre format fp8 pour l’encodeur texte	8GB	Neutre environ	Alternative à fp8_e4m3fn
--preview-method none	Désactive les previews	Tous	Légèrement plus rapide	Économise environ 0,5–1 Go Premier test OOM
--cache-none	Désactive le cache	RAM limitée	Plus lent	Économise la RAM mais recalcule
--cache-lru 10	Garde 10 résultats en cache LRU	RAM suffisante	Plus rapide	Bon compromis Tester 10–20
--cache-classic	Ancien cache agressif	RAM suffisante	Plus rapide	Peut utiliser plus de RAM
--force-fp16	Force fp16 globalement	Tous	Neutre environ	Peut économiser 2–3 Go
--use-pytorch-cross-attention	Force PyTorch SDP attention	Tous	Exemple : 5–20 % plus rapide	ComfyUI choisit souvent xformers/SDP automatiquement Forcer pour un test ciblé
--use-flash-attention	Force Flash Attention	Tous	Exemple : 5–20 % plus rapide	Nécessite flash-attention Certaines versions CUDA sont incompatibles
--fast	Mode rapide expérimental	Tous	Incertain	Expérience avancée Peut modifier qualité/stabilité Pas un réglage 8 Go par défaut

Exemples de commandes

# Configuration de base pour 8 Go de VRAM
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# Configuration limite pour 6 Go de VRAM
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# Configuration accélérée avec suffisamment de RAM
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

Faits variables : les arguments peuvent changer. Référez-vous à python main.py --help et à la documentation actuelle. FLUX peut ignorer --fp8_e4m3fn-unet à cause de son compute dtype interne ; définissez weight_dtype dans la node concernée.

---

Pourquoi —lowvram ne suffit pas à éviter l’OOM

ComfyUI v0.18.0+ autour de mars 2026 active Dynamic VRAM par défaut. Lorsqu’il est actif, --lowvram est ignoré, car une stratégie adaptative d’offload fonctionne déjà.

Quand utiliser --lowvram manuellement

• Après avoir désactivé Dynamic VRAM avec --normalvram
• Pour un OOM de fragmentation propre à un workflow, tester --disable-dynamic-vram

Solutions de remplacement

• Utiliser le comportement par défaut de Dynamic VRAM
• Garder --novram comme dernier recours et accepter une baisse de vitesse de 50 à 70 %
• Laisser de la marge au système avec --reserve-vram 2-4

Avantage de Dynamic VRAM : il estime le besoin et décharge automatiquement vers la RAM.

Risque de Dynamic VRAM : certains workflows conservent un OOM de fragmentation. Dans ce cas, testez --disable-dynamic-vram.

---

Trois voies FLUX sur 8 Go : fp8, GGUF et Klein 4B

FLUX est un modèle de 12 milliards de paramètres dont le fichier d’origine fait environ 23 Go. Sur 8 Go, trois voies existent, avec des compromis différents.

Voies de quantification FLUX

Voie	Taille	VRAM	Qualité vs fp16	GPU	Vitesse	Compatibilité	Usage
FLUX full (fp16)	~23GB	~20GB+	100 %	24GB+	La plus rapide	Officielle	Usage professionnel VRAM suffisante
FLUX fp8 checkpoint	~12GB	~11GB	~95–98 %	12GB confort/16GB+	Assez rapide	Quantification officielle	12GB+ Un seul fichier
FLUX GGUF Q8_0	~12,7GB	~11GB	~99 %	12GB+/16GB+	Plus lent avec offload	node city96, WIP	12GB+ Presque sans perte
FLUX GGUF Q5_K_S	~8,5GB	~7,5GB	~94–96 %	8GB limite/12GB confort	Lent avec offload	node city96, WIP	8GB Compromis qualité
FLUX GGUF Q4_K_S	~6,8GB	~6,5GB	~88–90 %	8GB/6GB limite	Le plus lent	node city96, WIP	6–8GB Priorité à l’exécution
FLUX.2 Klein 4B GGUF Q4_K_M	~2,6GB	~2,6GB	Qualité propre au modèle 4B	8GB confort	Quatre steps, rapide	Apache 2.0, node city96	Pour 8GB Quatre steps Rapide

Encodeur T5

Version T5	Taille	VRAM	GPU
T5 fp16	~9GB	~9GB	24GB+, dépasse 8GB
T5 fp8_e4m3fn	~4–5GB	~4–5GB	Pratique sur 8GB
T5 GGUF Q3/Q4/Q5	~2–4GB	~2–4GB	Configurations limites 6–8GB

Installation

Pour fp8, téléchargez le fichier safetensors, chargez-le avec Load Diffusion Model, puis définissez weight_dtype sur fp8_e4m3fn.

Pour GGUF, installez la custom node ComfyUI-GGUF de city96, chargez le modèle avec Unet Loader (GGUF) et placez le fichier dans models/unet/.

Risque de la node tierce : GGUF est marqué WIP et le support LoRA reste expérimental. La node évolue souvent et n’est pas une voie intégrée officielle.

Observation qualité d’Apatero : Q5_K_S reste proche de fp16, avec des écarts surtout sur le texte rendu et les motifs fins. Q4_K_S perd davantage de détails.

Observation vitesse de Local AI Master

• FLUX.1-dev Q4_K_S + —lowvram, 1024×1024, 20 steps, RTX 3060 Ti 8GB : environ 90 à 150 secondes
• FLUX.2 Klein 4B Q4_K_M, 1024×1024, quatre steps, 8GB : environ 15 à 30 secondes

Benchmark variable : matériel, versions et workflow modifient fortement ces valeurs. Utilisez-les comme plages de référence.

---

Réduire l’OOM de VAE Encode/Decode avec Tiled VAE

À 2048×2048 ou en vidéo, VAE Encode/Decode peut épuiser la VRAM. Tiled VAE traite l’image par zones plus petites pour réduire le pic.

Nodes

VAEDecodeTiled décode un latent en image tile par tile. VAEEncodeTiled encode une image en latent de la même façon.

Paramètres

Paramètre	Rôle	Valeur de départ	Usage
tile_size	Taille d’une tile	512 avec peu de VRAM 1024 avec de la marge	Plus petit consomme moins mais ralentit Commencer à 512 sur 8GB
overlap	Chevauchement entre tiles	64	Limite les coutures Tester 32–128
fast mode	Mode rapide	true	Généralement à activer
temporal_size	Chunk temporel pour Video VAE uniquement	8 avec peu de VRAM 16 avec marge	Traite les images par groupes Utile seulement pour Video VAE
temporal_overlap	Chevauchement entre chunks temporels	2–4	Continuité entre groupes d’images

Comparaison des pics SynpixCloud

Résolution	VAE standard	Tiled 512	Tiled 1024
1024×1024	~2GB	~0,5GB	~1GB
2048×2048	~8GB	~1GB	~2,5GB

Utiliser Tiled VAE pour

• Une résolution supérieure à 1024×1024
• Un GPU de 8 à 12GB
• Un workflow avec Video VAE
• Un OOM dans Hires Fix, Upscale ou FaceDetailer

Précaution documentaire : la documentation de la node est marquée AI-generated. Vérifiez l’interface et les paramètres de votre version ComfyUI.

---

Diagnostiquer l’OOM par source de pic

Face à CUDA out of memory, vérifiez d’abord les plus gros pics et appliquez une réduction concrète à chaque étape.

Tableau OOM

Source du pic	Exemple VRAM	Réduction	Priorité
Poids du modèle	SDXL ~6,5GB FLUX fp16 ~23GB	Passer à fp8/GGUF —lowvram/—novram	P0
Encodeur T5	fp16 ~9GB	Passer à T5 fp8/GGUF avec un loader compatible	P0 pour FLUX
Résolution latente	2048×2048 ~8GB	Réduire à 1024×1024 ou 512×512	P1
VAE encode/decode	Jusqu’à environ 8GB à 2048×2048	Tiled VAE, tile_size=512, overlap=64	P1
Batch size	batch size=4 à 1024×1024, environ 8–12GB	batch size=1 batch count en queue	P2
ControlNet/Detailer	Environ 2–3GB chacun	Désactiver la branche ControlNet Choisir une voie faible VRAM	P2
Images vidéo	Images × résolution × VideoVAE	Temporal chunking Réduire les images Tiled Video VAE	P2 vidéo
Cache/preview	~0,5–1GB	—preview-method none —cache-none	P3

Ordre des actions

1. Réduire la résolution : 2048 → 1024 → 512
2. Désactiver la preview : --preview-method none
3. Passer à un modèle fp8/GGUF : FLUX Q4_K_S, Q5_K_S ou Klein 4B
4. Passer T5 en fp8/GGUF : important pour FLUX faible VRAM
5. Utiliser Tiled VAE : commencer par tile_size=512 et overlap=64
6. Réduire batch size : batch size=1, batch count en queue
7. Désactiver ControlNet et le post-traitement : FaceDetailer, Hires Fix, Upscale
8. Pour la vidéo : réduire les images et utiliser temporal chunking

---

Distinguer deux causes de lenteur

Déterminez d’abord si le workflow est lent parce que l’offload faible VRAM l’impose, ou s’il est plus lent que nécessaire à cause d’un réglage.

Tableau de vitesse

Goulot	Signe	Diagnostic	Ajustement
Lenteur normale avec peu de VRAM
—lowvram/—novram	20–70 % plus lent	Vérifier les arguments	Accepter la lenteur Ou utiliser plus de VRAM
Offload GGUF vers RAM	Faible utilisation GPU	Vérifier l’utilisation GPU	La bande passante RAM limite Utiliser fp8/fp16 si possible
Vidéo avec beaucoup d’images	VAE Decode lent	Calculer images × résolution	Réduire les images Temporal Tiling
Mode CPU —cpu	Extrêmement lent	Vérifier les arguments	Dernier recours uniquement Passer au GPU
Lenteur anormale
Trop de sampler steps	FLUX dev dépasse 20 steps	Vérifier KSampler	Environ 20 peuvent suffire à FLUX dev schnell/Klein 4B en quatre
Backend attention inadapté	Mémoire élevée	Vérifier les arguments	xformers compatible Ou PyTorch SDP
VAE Decode lent	tile_size trop petit	Vérifier VAEDecodeTiled	Passer de 512 à 1024 Environ 1GB de pic en plus, gain possible de 10–30 %
Attente de CPU offload	Attente CPU–GPU	Vérifier les arguments	—async-offload RAM suffisante, souvent 32GB+
Mauvais cache disque/RAM	Modèle rechargé souvent	Vérifier les arguments	—cache-lru 10 Mettre 10 résultats en cache
Autre processus sur le GPU	Faible utilisation utile	Vérifier le système	Fermer navigateur, jeu, éditeur vidéo

Actions dans l’ordre

1. xformers ou SDP attention : pip install xformers pour la détection automatique, ou tester --use-pytorch-cross-attention ; références de 20–30 % de VRAM en moins et 5–20 % plus rapide
2. FLUX en quatre steps : schnell ou Klein 4B au lieu de dev en 20 steps
3. Augmenter tile_size : 512 → 1024, environ 1GB de pic supplémentaire pour un gain possible de 10–30 %
4. Activer async offload : --async-offload avec assez de RAM
5. Fermer les autres processus GPU : navigateur, jeux, éditeur vidéo

Observation SynpixCloud : xformers/SDP attention a réduit la VRAM de 20–30 % et accéléré de 5–20 % dans l’environnement cité.

Observation Local AI Master : FLUX.2 Klein 4B Q4_K_M, quatre steps, 1024×1024 et 8GB a demandé environ 15 à 30 secondes.

Benchmark variable : toutes les valeurs sont des références dépendantes de l’environnement.

---

Pourquoi un fichier GGUF plus petit peut être plus lent

Un GGUF Q4_K_S d’environ 6,8GB peut être plus lent qu’un FLUX fp16 d’environ 23GB :

• GGUF peut décharger les poids en RAM système au lieu de les garder en VRAM, ce qui réduit l’utilisation du GPU
• L’inférence transfère plusieurs fois les poids de la RAM vers la VRAM
• La bande passante RAM est bien plus faible : DDR4/DDR5 autour de 25–50GB/s contre GDDR6X autour de 500–1000GB/s

Utiliser GGUF lorsque

• fp8 ne tient pas sur un GPU de 6 à 8GB et GGUF reste la voie possible pour FLUX
• Vous acceptez une génération plus lente afin de faire tenir le modèle

Éviter GGUF lorsque

• Un GPU de 12GB+ peut exécuter fp8 ou fp16 plus efficacement
• La vitesse compte davantage que le simple fait de pouvoir lancer le modèle

Observation Apatero : Q8_0 with CPU offloading may take 5-10 minutes per generation.

---

Budget VRAM vidéo : images × résolution × VideoVAE

En vidéo, images × résolution × VideoVAE peut rapidement dominer la VRAM. Cette section traite du budget et de la réduction du pic, pas d’un workflow Wan ou AnimateDiff complet.

Principe de budget

Pic VRAM ≈ poids du modèle + T5 + nombre d’images × latent par image + pic VideoVAE.

Exemples issus des ressources ComfyUI-Wan2.2 et Local AI Master citées

Réglage vidéo	Budget VRAM	GPU	Remarque
8 images en 480p (640×360)	~6–8GB	6GB possible	L’exemple RTX 3050 6GB cité produit environ une seconde de vidéo en moins de cinq minutes
24 images en 720p (1280×720)	~12–16GB	8GB limite/12GB confortable	Temporal Tiling nécessaire
60 images en 1080p (1920×1080)	~20–24GB+	16GB+	Voie haute VRAM

Réduire le pic

Temporal Tiling sépare les images en petits groupes, par exemple huit à la fois. Les paramètres sont temporal_size et temporal_overlap.

Tiled VAE traite VAE Decode de chaque image en tiles spatiales.

Réduisez le nombre d’images de 60 à 24 puis à 8 et validez d’abord la plus petite exécution.

Réduisez la résolution de 1080p à 720p puis à 480p.

Les ressources source proposent Wan 2.2 5B pour une cible 8GB ou Wan 2.2 14B GGUF comme exemple à partir de 6GB.

Benchmark variable : ces nombres restent des références dépendantes de l’environnement.

---

Éviter l’OOM en série : batch size et batch count

batch size et batch count produisent des pics très différents. Augmenter batch size sans contrôle provoque facilement un OOM.

batch size et batch count

batch size exécute plusieurs images en parallèle ; latents, VAE et tenseurs actifs augmentent. batch count met plusieurs petits batches en queue et garde le batch actif réduit.

Comparaison VRAM

Configuration	Résolution	Pic VRAM	Risque OOM
batch size=4	1024×1024	~8–12GB	Élevé par parallélisme
batch count=4, batch size=1	1024×1024	~2–3GB	Plus faible en séquentiel

Recommandation

• Avec 6–8GB : batch size=1 et batch count=N
• Pour les batches API : utiliser la queue et le contrôle de concurrence du workflow d’automatisation ComfyUI au lieu de lancer plusieurs requêtes lourdes ensemble

---

OOM soudain après une mise à jour : vérifier les versions

Si le même workflow ralentit ou échoue après une mise à jour de PyTorch, du pilote ou de ComfyUI, l’environnement a peut-être changé alors que prompt et graph sont identiques.

Versions qui influencent la VRAM

Le comportement CUDA de PyTorch évolue, notamment les valeurs par défaut TF32/FP16 et l’allocator. TF32 et FP16 ne sont pas toujours meilleurs : des exemples PyTorch montrent une multiplication TF32 plus rapide mais avec davantage d’erreur numérique. Pilote, ROCm et CUDA modifient aussi le comportement du GPU.

Procédure

1. Sauvegarder l’environnement avant mise à jour avec conda ou pip freeze
2. Tester la nouvelle version dans un environnement séparé
3. Noter les versions stables de PyTorch, CUDA et du pilote
4. Revenir à une version fixée en cas de régression

---

Séparer accélérations expérimentales et réglages stables

Distinguez les expériences avancées des réglages adaptés à un premier test stable.

Expériences avancées, pas des exigences par défaut pour 8GB

Élément	État	Risque	Remarque
--fast	Expérimental	Peut modifier qualité/stabilité	Marqué experimental par ComfyUI
FlashAttention	Nécessite flash-attention	Certaines versions CUDA incompatibles	Installation complexe
Sage Attention	Optimisation tierce	Expérimental, peut affecter la précision	Version CUDA/PyTorch correspondante
TensorRT	Nécessite TensorRT SDK et configuration	Conversion complexe	Peu adapté aux débutants

Points de départ stables

Élément	État	Effet	Remarque
xformers	Stable si compatible	Référence : 20–30 % de VRAM en moins, 5–20 % plus rapide	pip install xformers Détecté par ComfyUI
SDP attention avec —use-pytorch-cross-attention	Stable	Référence : 20–30 % de VRAM en moins, 5–20 % plus rapide	ComfyUI peut déjà choisir automatiquement le meilleur backend

---

Conclusion

Catégorie GPU : identifiez d’abord 6GB, 8GB, 12GB ou 16GB+ et commencez par un workflow de base adapté.

Arguments : dans le comportement v0.18.0+ cité, Dynamic VRAM est actif par défaut ; --lowvram peut donc être sans effet. Vérifiez avec python main.py --help.

Quantification : les mesures citées présentent FLUX.2 Klein 4B GGUF comme voie rapide sur 8GB, ou FLUX.1 GGUF Q4_K_S lorsque faire tenir le modèle compte plus que la vitesse. L’offload GGUF dépend fortement de la bande passante RAM.

Ordre du diagnostic : poids du modèle → T5 → résolution latente → VAE → batch size → ControlNet → images vidéo → cache. Pour la vitesse, séparez la lenteur normale de l’offload d’un goulot réellement réglable.

Étapes suivantes

1. Identifier la catégorie 6GB, 8GB, 12GB ou 16GB+
2. Pour les cas 8GB cités, choisir FLUX.2 Klein 4B ou FLUX.1 GGUF Q4_K_S
3. Appliquer la checklist mémoire en cas d’OOM
4. Appliquer la checklist vitesse en cas de lenteur anormale
5. Utiliser Temporal Tiling pour les workflows vidéo

Si l’environnement de base ne fonctionne pas encore, commencez par le guide ComfyUI pour débutants. Pour des nodes rouges, des modèles absents ou un workflow non reproductible, consultez la checklist de réutilisation des workflows ComfyUI. Si vous hésitez encore entre SDXL, SD 3.5 et FLUX, lisez d’abord le guide de sélection des modèles Stable Diffusion.