logo
RunComfy
Guides d'entraînement LoRA AI Toolkit

Correctif : Bus error DataLoader (/dev/shm) — LoRA LTX-2 dans AI Toolkit

Guide de dépannage sur /dev/shm : cause (shared memory saturée) et fixes recommandés — moins de workers/prefetch, plus de shm-size, et réduction de la mémoire par échantillon si besoin.

Entraînez des modèles de diffusion avec Ostris AI Toolkit

Correctif : « DataLoader worker is killed by signal: Bus error » (mémoire partagée /dev/shm) — LoRA LTX-2 dans AI Toolkit

Si votre entraînement LoRA LTX-2 plante avec un Bus error, c’est presque toujours une pression sur la mémoire partagée (/dev/shm) : les workers du DataLoader PyTorch + le prefetching gardent en mémoire de gros batches vidéo (beaucoup de frames) en même temps.

Checklist de correction rapide (commencez ici)

  • ✅ Appliquez Fix A : baissez num_workers et prefetch_factor dans votre config de dataset
  • ✅ Si vous hébergez vous‑même via Docker : appliquez Fix B et augmentez /dev/shm avec --shm-size
  • ✅ Relancez l’entraînement et vérifiez que le log n’affiche plus “out of shared memory” / “Bus error”
  • ✅ Si vous entraînez 121 frames, attendez‑vous aussi à devoir gérer un GPU OOM (voir notes ci‑dessous)

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

Vous êtes au bon endroit si vos logs contiennent quelque chose comme :

DataLoader worker (pid XXX) is killed by signal: Bus error

It is possible that dataloader's workers are out of shared memory

Please try to raise your shared memory limit

Mots‑clés fréquents :

  • Bus error
  • out of shared memory
  • mentions de DataLoader worker, shared memory limit, /dev/shm

2) Ce qui se passe

  • L’entraînement LTX-2 utilise des batches vidéo (beaucoup de frames par échantillon).
  • Avec plusieurs workers DataLoader + le prefetching, AI Toolkit peut mettre en file plusieurs gros batches dans /dev/shm.
  • Quand /dev/shm est trop petit, un processus worker plante → Bus error → l’entraînement s’arrête.

RunComfy fournit déjà une mémoire partagée augmentée, mais certains datasets/réglages (en particulier un num_frames élevé comme 121) peuvent encore la dépasser.

3) Correctifs

Astuce : changez une seule variable à la fois. Commencez par Fix A — c’est ce qui règle le problème dans la plupart des cas.

Fix A (recommandé) : réduire les workers + le prefetch du DataLoader

Cela réduit la pression sur la mémoire partagée sans changer vos données d’entraînement.

Où modifier (RunComfy UI) :

  1. Ouvrez Your Training Job Panel
  2. Cliquez sur Show Advanced (en haut à droite)
  3. Dans la config YAML, trouvez l’élément de dataset sous datasets: (le bloc qui contient votre folder_path)
  4. Ajoutez/ajustez ces clés à l’intérieur de cet élément de dataset

Essayez d’abord ceci (souvent suffisant) :

num_workers: 1

prefetch_factor: 1

Si ça plante encore (le plus stable, mais plus lent) :

num_workers: 0

prefetch_factor: null

⚠️ Important :

  • Si vous mettez num_workers: 0, mettez prefetch_factor: null (exactement null).
  • Baisser workers/prefetch impacte le débit, pas la qualité. Ça ne change que la façon dont les données sont chargées.

Fix B (self‑hosted / Docker) : augmenter /dev/shm

Si vous exécutez AI Toolkit dans Docker vous‑même, augmentez la mémoire partagée du conteneur :

docker run --shm-size=32g ...

or safer:

docker run --shm-size=64g ...

Vous pouvez aussi appliquer Fix A pour plus de stabilité.

Fix C (si vous touchez encore les limites) : réduire la mémoire par échantillon

Si le dataset est extrêmement lourd, réduisez aussi une ou plusieurs de ces valeurs :

  • num_frames
  • resolution
  • batch_size

4) Vérifier le correctif

Un correctif réussi ressemble à ceci :

  • L’entraînement passe l’étape DataLoader et continue à avancer.
  • Le log de crash ne répète plus “out of shared memory” / “Bus error”.

Si vous êtes en self‑hosting, vérifiez aussi que /dev/shm est réellement grand à l’intérieur du conteneur.

Notes (problème fréquent ensuite : GPU OOM)

  • 121 frames, c’est lourd. Après avoir corrigé /dev/shm, vous pouvez quand même rencontrer un GPU OOM.
    • Recommandé : H200 pour l’entraînement à 121 frames.
    • Sinon, réduisez batch_size / resolution / num_frames.

Exemple prêt à copier‑coller (bloc dataset)

datasets:

  • folder_path: /app/ai-toolkit/datasets/your_dataset

    num_frames: 121

    resolution: [512, 768]

    caption_ext: "txt"

    # Fix shared memory Bus error (start here):

    num_workers: 1

    prefetch_factor: 1

    # If still crashing, use this instead (slowest but most stable):

    # num_workers: 0

    # prefetch_factor: null

FAQ

Est‑ce que cela veut dire que mon dataset est cassé ?

Généralement non. C’est une limite de mémoire partagée du DataLoader, pas un dataset corrompu.

Pourquoi prefetch_factor: null est requis quand num_workers: 0 ?

Sans workers, le prefetching n’est pas utilisé. Le mettre à null évite un comportement de prefetch invalide/inutile dans la config.

Est‑ce que je dois faire uniquement Fix B (augmenter /dev/shm) ?

Sur RunComfy, commencez par Fix A. En self‑hosting Docker, Fix B est souvent nécessaire — et Fix A aide aussi.

J’ai corrigé le Bus error, mais j’ai maintenant un GPU OOM. Que faire ?

Baissez batch_size, resolution ou num_frames, ou utilisez un GPU plus gros (H200 recommandé pour 121 frames).

Prêt à commencer l'entraînement ?