logo
RunComfy
AI Toolkit LoRA Training Guides

Résoudre les erreurs CUDA Out of Memory dans AI Toolkit

Guide rapide de dépannage des erreurs OOM dans AI Toolkit : identifiez si le crash survient au chargement du modèle, pendant l'entraînement ou l'échantillonnage, puis ajustez batch size, gradient checkpointing, résolutions, frames ou réglages de prévisualisation.

Train Diffusion Models with Ostris AI Toolkit

AI Toolkit CUDA Out of Memory : résoudre les OOM au chargement, entraînement et échantillonnage

Si votre job AI Toolkit échoue avec CUDA out of memory, OOM during training step 3 times in a row ou 0 bytes is free, ne relancez pas le même job sans modification.

En pratique, la plupart des erreurs OOM dans AI Toolkit proviennent de l'un de ces quatre endroits :

  1. chargement du modèle (avant le début réel de l'entraînement)
  2. les premiers pas d'entraînement
  3. échantillonnage de prévisualisation / génération du sample de référence
  4. pics spécifiques à la vidéo dus à trop de frames, des buckets trop grands, ou les deux

Ce guide est le chemin rapide de récupération : identifiez quel OOM vous avez, changez les bons réglages dans RunComfy AI Toolkit et arrivez plus vite à un retry réussi.

Checklist rapide (commencez ici)

  • ✅ Dans Training, réduisez le Batch Size
  • ✅ Dans Datasets, désactivez le bucket de résolution le plus élevé en premier
  • ✅ Dans Sample, réduisez Width / Height / Sample Steps ou activez temporairement Disable Sampling
  • ✅ Cliquez sur Show Advanced et vérifiez que gradient_checkpointing: true
  • ✅ Pour les modèles vidéo, réduisez Num Frames avant de toucher au learning rate
  • ✅ Si l'erreur survient même avec une config très conservative, traitez-la comme un possible problème d'état du worker / GPU, pas uniquement de config

1) Confirmer qu'il s'agit du même problème

Vous êtes au bon endroit si vos logs contiennent des messages comme :

CUDA out of memory
torch.OutOfMemoryError
OOM during training step 3 times in a row
Tried to allocate ...
0 bytes is free
CUBLAS_STATUS_ALLOC_FAILED

Situations courantes :

  • le job échoue avant le step 1
  • le job atteint le step 2–10 puis OOM en boucle
  • l'entraînement semble correct, mais le crash survient lors de la génération des samples
  • la même config fonctionne parfois, parfois non

2) D'abord : quel type d'OOM ?

A. OOM au chargement du modèle ou avant l'entraînement

Cela signifie généralement :

  • le modèle est trop lourd pour le setup actuel d'économie de mémoire
  • la génération du sample de référence / prévisualisation est déjà trop coûteuse
  • le worker / GPU est dans un mauvais état et ne démarre pas avec une mémoire propre

Signes typiques :

  • échec avant des pas d'entraînement significatifs
  • l'erreur survient juste après le chargement du modèle ou pendant le premier sample
  • les logs montrent presque pas de VRAM libre ou une erreur d'allocation CUBLAS

B. OOM dans les premiers pas d'entraînement

C'est le cas le plus courant lié à la configuration.

Causes typiques :

  • gradient_checkpointing est désactivé
  • Batch Size trop élevé
  • le plus grand bucket du dataset est trop ambitieux
  • pour la vidéo, Num Frames est le vrai pic mémoire

C. OOM pendant l'échantillonnage / la génération de prévisualisation

C'est un piège très courant.

Votre config d'entraînement est peut-être presque correcte, mais la prévisualisation est trop coûteuse :

  • Sample Width / Height trop grand
  • Sample Steps trop élevé
  • Sample Every trop fréquent
  • la vidéo de prévisualisation utilise trop de frames

D. OOM seulement parfois

C'est généralement une config limite, pas un mystère.

Exemples :

  • le run survit aux petits buckets mais crashe au plus grand bucket
  • les runs vidéo échouent uniquement sur les clips les plus lourds
  • le cœur de l'entraînement tient, mais la génération de samples le fait déborder

3) Corrections les plus rapides dans RunComfy AI Toolkit

Fix A — Réactiver gradient checkpointing

C'est la première chose à vérifier pour les OOM de modèles d'images.

Où le changer

  1. Ouvrez le job échoué
  2. Cliquez sur Show Advanced
  3. Sous train:, vérifiez : 
gradient_checkpointing: true

En cas de doute, laissez-le activé.

Fix B — Baisser le Batch Size, utiliser Gradient Accumulation pour la stabilité

Où le changer

  • Ouvrez l'éditeur de job
  • Dans le panneau Training :
    • réduisez le Batch Size
    • maintenez ou augmentez Gradient Accumulation si vous voulez un batch effectif légèrement plus grand sans augmenter le pic VRAM

Règle de retry sûr

  • Modèles d'images : en cas d'OOM, passez à Batch Size = 1 d'abord
  • Modèles vidéo : considérez Batch Size = 1 comme votre défaut sauf si la config est déjà prouvée stable

Ne traitez pas le learning rate comme votre premier levier mémoire. Ce n'en est généralement pas un.

Fix C — Supprimer d'abord le bucket de dataset le plus élevé

Où le changer

  • Allez au panneau Datasets
  • Sous Resolutions, désactivez le bucket le plus élevé en premier

Ordre de rollback sûr

  • 1024 / 1536 → supprimer d'abord
  • garder 512 / 768 pendant la vérification de stabilité
  • une fois stable, rajouter les buckets plus grands un par un

C'est l'un des moyens les plus rapides de transformer un run limite en un run reproductible.

Fix D — Rendre l'échantillonnage de prévisualisation peu coûteux ou le désactiver temporairement

Si le crash survient avant que l'entraînement ne démarre vraiment, ou à chaque échantillonnage, corrigez d'abord la prévisualisation.

Où le changer

  • Ouvrez le panneau Sample

Puis faites une ou plusieurs de ces actions :

  • réduisez Width
  • réduisez Height
  • réduisez Sample Steps
  • augmentez Sample Every
  • activez Disable Sampling pour un run de validation

Bon premier retry

Si votre objectif est « prouver que le job peut entraîner », un run temporaire sans échantillonnage convient.

Une fois stable, réactivez les prévisualisations avec des réglages plus petits.

Fix E — Modèles vidéo : réduire Num Frames avant tout

Pour les modèles vidéo, les frames sont généralement le plus gros levier mémoire.

Où le changer

  • Panneau Datasets → Num Frames
  • Panneau Sample → Num Frames

Si vous entraînez de la vidéo et voyez un OOM, réduisez les frames d'abord, puis le batch size, puis la résolution.

Ne commencez pas par changer l'optimizer ou le LR.

Fix F — Utiliser le chemin basse mémoire du modèle

Certaines architectures sont conçues pour être entraînées avec des réglages d'économie de mémoire quand la VRAM est serrée.

Où le changer

  • Cliquez sur Show Advanced
  • Sous model:, cherchez : 
low_vram: true

Pour certains modèles, le bon chemin basse mémoire inclut aussi une quantification ou un traitement du text-encoder spécifique. Suivez le guide du modèle concerné plutôt que de deviner.

4) Diagnostic rapide par moment du crash

Quand ça crashe Cause la plus probable Premier changement
Avant le step 1 / pendant le sample initial prévisualisation trop lourde, pression au chargement ou worker sale désactiver l'échantillonnage ou réduire la prévisualisation
Step 1–10 GC désactivé, batch trop élevé, bucket trop grand activer GC, batch à 1, supprimer le plus grand bucket
Uniquement à l'échantillonnage réglages de prévisualisation trop coûteux baisser Width/Height/Sample Steps ou désactiver l'échantillonnage
Parfois oui, parfois non config limite réduire le plus grand bucket / frames et stabiliser
Config conservative échoue instantanément possible problème d'état GPU / worker recréer sur un worker frais ou contacter le support

5) Distinguer OOM de config et problèmes d'environnement / état GPU

Considérez que ce n'est pas qu'un problème de config quand tout ceci est vrai :

  • Batch Size = 1
  • gradient_checkpointing: true
  • résolution / frames conservateurs
  • le job échoue quand même avant que l'entraînement ne commence vraiment
  • les logs montrent 0 bytes is free ou échec d'allocation CUBLAS

Dans cette situation :

  1. arrêtez de répéter le même retry
  2. créez un nouveau job sur un worker frais si possible
  3. si la même config conservative fonctionnait avant et échoue maintenant instantanément, escaladez au support

C'est important car les retries répétés peuvent gaspiller du temps et du budget GPU.

6) L'ordre de rollback le plus sûr

Pour les modèles d'images

  1. gradient_checkpointing: true
  2. Batch Size → 1
  3. supprimer le plus grand bucket de résolution
  4. réduire ou désactiver Sample
  5. activer low_vram ou le chemin basse mémoire du modèle

Pour les modèles vidéo

  1. réduire Num Frames
  2. Batch Size → 1
  3. supprimer le plus grand bucket de résolution
  4. réduire ou désactiver Sample
  5. activer low_vram ou offloading / quantification spécifique au modèle

7) Après votre premier retry réussi

Une fois un run stable obtenu :

  • ne rajoutez qu'un seul réglage plus lourd à la fois
  • notez ce qui a changé
  • ne réintroduisez pas plusieurs réglages à haut risque ensemble

Bon ordre pour monter en charge :

  1. garder les mêmes réglages mémoire stables
  2. augmenter les Steps
  3. réactiver un bucket plus grand
  4. réactiver un échantillonnage plus riche
  5. seulement ensuite tester un batch plus grand ou une vidéo plus longue

Résumé en une ligne

Si AI Toolkit renvoie un OOM, arrêtez les essais au hasard.

Activez gradient_checkpointing, baissez le Batch Size, supprimez le plus grand bucket de résolution et rendez l'échantillonnage de prévisualisation moins cher avant de réessayer.

Guides associés

Ready to start training?