Rédigé par Rédaction CyberSDF / 19 September 2026

Stable Diffusion CUDA out of memory en 6 Go : lire le message avant d’ajouter une option

« RuntimeError: CUDA out of memory. Tried to allocate 648.00 MiB (GPU 0; 6.00 GiB total capacity; 4.66 GiB already allocated; 0 bytes free; 4.70 GiB reserved in total by PyTorch) » : cette ligne, relevée dans un rapport de bug du webui AUTOMATIC1111 sur une carte à 6 Go, ne dit pas que la carte est trop petite. Elle dit que 4,66 Go sont occupés par des tenseurs, que l’allocateur de PyTorch en réserve 4,70 Go, et qu’aucun bloc de 648 Mo ne reste libre.

« 0 bytes free » avec 4,70 GiB réservés : ce que PyTorch garde pour lui

Les nombres qui suivent already allocated et reserved in total mesurent deux choses : les tenseurs vivants, et la mémoire que le cache de l’allocateur a demandée au pilote, blocs libérés compris. La documentation de PyTorch 2.14 le précise : la mémoire inutilisée gérée par l’allocateur continue d’apparaître comme occupée dans nvidia-smi.

Dans l’exemple, 4,70 Go sur 6,00 Go sont dans le pool de PyTorch ; le reste est pris par le contexte CUDA et la session graphique. C’est cette marge qui décide du succès d’une génération.

Un premier levier réduit la fragmentation du cache :

export PYTORCH_ALLOC_CONF=expandable_segments:True

expandable_segments est une option expérimentale de PyTorch 2.14, désactivée par défaut. L’ancien nom, PYTORCH_CUDA_ALLOC_CONF, fonctionne encore : la documentation de PyTorch le présente comme un alias conservé pour la compatibilité. Un second levier rend au pilote les blocs mis en cache :

python3 -c "import torch; torch.cuda.empty_cache()"

empty_cache() ne libère que les blocs en réserve, pas les tenseurs en cours d’utilisation. Pour lire l’état réel de la carte :

nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv

Sur une carte 6 Go, nvidia-smi donne memory.total à 6144 MiB et memory.used entre quelques centaines de Mo et la totalité de la carte pendant une génération.

Cinq réglages pour 6 Go, avec leur mémoire et leur vitesse mesurées

Les valeurs viennent du tableau de mesures du wiki du webui AUTOMATIC1111 (RTX 3060, CUDA 11.7, lots de 1 à 16). La résolution employée n’y est pas indiquée et n’a pas pu être vérifiée ; les chiffres comparent les options entre elles. Les libellés sont ceux du fichier modules/cmd_args.py du dépôt, branche master.

Sans optimisation d’attention, le lot de 2 demande 6,2 Go et échoue déjà sur une carte 6 Go : ce réglage vient en premier. xformers plafonne la consommation quand le lot grossit, contrairement à l’optimisation activée par défaut sur torch.cuda. Les options de découpe se cumulent avec elle : le wiki SDXL du webui AUTOMATIC1111 associe –medvram-sdxl et –xformers sur 8 Go, –lowvram et –xformers sur 4 Go.

La mise en route d’une interface de génération locale est décrite dans générer une image avec une IA ; les autres briques sont dans la rubrique IA.

Écrire –medvram dans webui-user.sh et vérifier qu’il est lu

1. Ouvrir webui-user.sh, à la racine du dossier du webui AUTOMATIC1111, et décommenter la ligne des arguments. Le fichier livré contient cette ligne inactive, sous la forme #export COMMANDLINE_ARGS=””.

   export COMMANDLINE_ARGS="--medvram --xformers"

   Ce qu’on doit voir : la ligne commence par export, sans # devant. Laissée telle quelle, elle ne change rien, même après redémarrage.

2. Relancer le lanceur depuis le même dossier.

   ./webui.sh

   Ce qu’on doit voir : la console reprend les arguments de lancement. Une faute de frappe arrête le démarrage sur un message de la forme error: unrecognized arguments: –medvramm.

3. Contrôler le réglage dans l’interface : Settings, catégorie Optimizations, ligne Cross attention optimization. Ce qu’on doit voir : xformers dans la liste déroulante. Ce choix n’existe dans l’interface du webui AUTOMATIC1111 que depuis la version 1.3.0 ; il reste sans effet si le paquet xformers n’est pas installé.
4. Lancer une génération en 512×512 et surveiller la carte depuis un second terminal.

   nvidia-smi -l 1

   Ce qu’on doit voir : la colonne memory.used reste sous 6144 MiB, avec un pic au moment où le VAE décode l’image finale.

Le lanceur webui.sh du webui AUTOMATIC1111 privilégie python3.10 quand il est présent (changelog de la version 1.10.0) et son wiki mentionne un test sur Python 3.10.6. Depuis la version 1.9.1, le projet annonce une compatibilité Debian 11 et suivantes. Pour l’édition d’un fichier de configuration sans quitter le terminal, le guide de la ligne de commande couvre les manipulations de base.

–medvram et –lowvram ne découpent pas le même objet

–medvram coupe le modèle en trois parties, cond pour le texte, first_stage pour l’image et unet pour le bruitage, et n’en garde qu’une en VRAM à la fois, les autres attendant en mémoire système. –lowvram pousse la découpe plus loin : l’UNet est fractionné en de nombreux modules, un seul restant sur la carte. Le premier se paie en vitesse, le second en grande partie de la vitesse, écart résumé par les libellés d’aide du webui AUTOMATIC1111 : « a little speed » contre « a lot of speed ».

La page de dépannage du wiki porte encore des conseils périmés : elle recommande –lowvram –always-batch-cond-uncond lorsque –medvram échoue, or cette dernière option n’a plus aucun effet, décrite par « does not do anything » dans modules/cmd_args.py, avec un texte d’aide vide. –max-batch-count, –unload-gfpgan et –deepdanbooru appartiennent à la même famille, conservée pour ne pas casser les scripts existants.

SDXL en 1024×1024 : 6 Go tombent entre les deux configurations conseillées

Le wiki du webui AUTOMATIC1111 donne deux repères pour SDXL : sur une carte Nvidia de 8 Go, –medvram-sdxl –xformers ; sur une carte de 4 Go, –lowvram –xformers. Une carte 6 Go se situe entre les deux et commence par la combinaison des 8 Go, puis descend vers lowvram si la génération échoue.

Deux limites passent inaperçues. Le VAE livré avec SDXL réclame un calcul en fp32, que le wiki contourne en remplaçant le fichier par sdxl-vae-fp16-fix, ou par TAESD pour une mémoire bien plus faible et une qualité légèrement inférieure. Et –medvram-sdxl ne s’applique qu’aux modèles SDXL : sur Stable Diffusion 1.5, l’option ne change rien, ce que son libellé d’aide rappelle autrement, « enable –medvram optimization just for SDXL models ».

ComfyUI 0.36.0 : –lowvram ne fait rien tant que le VRAM dynamique est actif

Le fichier comfy/cli_args.py de ComfyUI 0.36.0, version publiée le 15 septembre 2026, le dit : –lowvram ne fait rien si le VRAM dynamique est actif, et sans VRAM dynamique elle fait tourner les encodeurs de texte sur le processeur. Recopier l’argument d’un tutoriel ancien ne produit donc aucun gain.

Les options qui portent encore sur la mémoire sont –novram, résumée par « When lowvram isn’t enough », –reserve-vram, qui fixe en Go la quantité laissée au système, –vram-headroom, –cpu-vae et –disable-smart-memory. –fp16-vae porte un avertissement explicite : des images noires sont possibles. Le port par défaut de ComfyUI est 8188 :

python3 main.py --reserve-vram 1

Sans interface, diffusers décharge vers le processeur et découpe le VAE en tuiles

diffusers propose deux niveaux de déchargement : enable_model_cpu_offload() garde un modèle à la fois sur la carte, enable_sequential_cpu_offload() déplace des sous-modules, à des performances que la documentation qualifie d’extrêmement lentes. Piège documenté : appeler enable_sequential_cpu_offload() après avoir déplacé la pipeline sur le GPU réduit fortement le gain.

Avec diffusers, enable_tiling() découpe le décodage du VAE en tuiles recouvrantes et reste inactif sous 512×512. Le script suivant ajoute la mesure qui compte sur une carte à faible mémoire :

from diffusers import StableDiffusionXLPipeline
import torch

pipe = StableDiffusionXLPipeline.from_pretrained(
    "stabilityai/stable-diffusion-xl-base-1.0",
    dtype=torch.float16,
)
pipe.enable_model_cpu_offload()
pipe.vae.enable_tiling()
resultat = pipe("un phare sur une falaise, lumière du soir").images
print(torch.cuda.max_memory_allocated() / 1024**3)

Ce qu’on doit voir à l’écran : une valeur en Go, à comparer aux 6 Go de la carte ; si elle s’en approche, enable_sequential_cpu_offload() est le recours suivant, au prix de l’attente. Le choix de l’interface avant tout réglage de mémoire est détaillé dans le choix d’une IA locale.

Questions fréquentes sur les cartes 6 Go

Est-ce que 6 Go suffisent pour Stable Diffusion ?

Oui pour Stable Diffusion 1.5 : les mesures du wiki tiennent entre 0,9 et 3,1 Go de pointe selon l’option retenue. Pour SDXL en 1024×1024, la carte travaille encore, au prix de la lenteur de –lowvram.

Pourquoi nvidia-smi affiche une carte presque pleine alors qu’aucune génération ne tourne ?

La mémoire du cache de l’allocateur de PyTorch reste comptée comme utilisée par nvidia-smi, ce qu’indique la documentation de PyTorch 2.14. torch.cuda.empty_cache() la rend au pilote.

Faut-il cumuler –xformers et –medvram ?

Oui, ils n’agissent pas au même endroit : xformers allège les couches d’attention, medvram déplace des parties du modèle. Le wiki du webui AUTOMATIC1111 associe les deux pour SDXL.

Quand la VRAM manque, la carte se sert-elle dans le disque dur ?

Non, CUDA ne déborde pas sur le disque. medvram et lowvram déplacent des morceaux du modèle vers la mémoire système, et le wiki du webui AUTOMATIC1111 demande 16 Go de RAM.

Pourquoi une image en 1024×1024 échoue-t-elle alors que le 512×512 passe ?

La mémoire suit la surface de l’image, quatre fois plus de pixels en 1024×1024, et le décodage du VAE ajoute un pic en fin de génération. Générer en 512 puis agrandir, ou activer un VAE en tuiles, évite l’arrêt.

Sur une GeForce à 6 Go, la valeur à surveiller pendant une génération reste la colonne memory.used de nvidia-smi -l 1, comparée aux 6144 MiB de la carte.