logo
RunComfy
AI Toolkit LoRA Training Guides

Fix: Bus error del DataLoader (/dev/shm) — LoRA LTX-2 in AI Toolkit

Guida di troubleshooting su /dev/shm: perché i worker del DataLoader crashano e come stabilizzare il training con meno workers/prefetch, più shm-size e meno memoria per sample.

Train Diffusion Models with Ostris AI Toolkit

Fix: “DataLoader worker is killed by signal: Bus error” (memoria condivisa /dev/shm) — LoRA LTX-2 in AI Toolkit

Se il tuo training LoRA LTX-2 va in crash con un Bus error, quasi sempre è pressione sulla memoria condivisa (/dev/shm): i worker del DataLoader di PyTorch + il prefetching tengono in memoria grandi batch video (molti frame) contemporaneamente.

Checklist di fix rapidi (parti da qui)

  • ✅ Applica Fix A: abbassa num_workers e prefetch_factor nella configurazione del dataset
  • ✅ Se fai self-hosting in Docker: applica Fix B e aumenta /dev/shm con --shm-size
  • ✅ Rilancia il training e verifica che il log non mostri più “out of shared memory” / “Bus error”
  • ✅ Se stai addestrando 121 frame, preparati a gestire anche GPU OOM (vedi note sotto)

1) Conferma che sia lo stesso problema

Sei nel posto giusto se i log includono qualcosa del genere:

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

Parole chiave comuni:

  • Bus error
  • out of shared memory
  • menzioni di DataLoader worker, shared memory limit, /dev/shm

2) Cosa sta succedendo

  • Il training LTX-2 usa batch video (molti frame per sample).
  • Con più worker del DataLoader + prefetching, AI Toolkit può accodare più batch grandi in /dev/shm.
  • Quando /dev/shm è troppo piccolo, un processo worker crasha → Bus error → il training si ferma.

RunComfy offre già una shared memory aumentata, ma alcuni dataset/impostazioni (soprattutto num_frames alto come 121) possono comunque superarla.

3) Fix

Tip: cambia una variabile alla volta. Parti da Fix A — risolve questo problema nella maggior parte dei casi.

Fix A (consigliato): riduci worker + prefetch del DataLoader

Questo riduce la pressione sulla memoria condivisa senza cambiare i dati di training.

Dove modificarlo (UI RunComfy):

  1. Apri Your Training Job Panel
  2. Clicca Show Advanced (in alto a destra)
  3. Nel config YAML, trova l’item del dataset sotto datasets: (il blocco che contiene il tuo folder_path)
  4. Aggiungi/regola queste chiavi dentro quell’item del dataset

Prova prima questo (di solito basta):

num_workers: 1

prefetch_factor: 1

Se crasha ancora (più stabile, ma più lento):

num_workers: 0

prefetch_factor: null

⚠️ Importante:

  • Se imposti num_workers: 0, imposta prefetch_factor: null (esattamente null).
  • Ridurre worker/prefetch impatta il throughput, non la qualità. Cambia solo come vengono caricati i dati.

Fix B (self-hosted / Docker): aumenta /dev/shm

Se esegui AI Toolkit in Docker in autonomia, aumenta la memoria condivisa del container:

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

or safer:

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

Puoi comunque applicare anche Fix A per maggiore stabilità.

Fix C (se colpisci ancora i limiti): riduci la memoria per sample

Se il dataset è estremamente pesante, riduci anche una o più di queste cose:

  • num_frames
  • resolution
  • batch_size

4) Verifica il fix

Un fix riuscito si riconosce così:

  • Il training supera la fase del DataLoader e continua ad avanzare con gli step.
  • Il log di crash non ripete più “out of shared memory” / “Bus error”.

Se fai self-hosting, assicurati anche che /dev/shm sia davvero grande dentro il container.

Note (problema comune successivo: GPU OOM)

  • 121 frame sono pesanti. Dopo aver sistemato /dev/shm, potresti comunque incontrare GPU OOM.
    • Consigliato: H200 per training a 121 frame.
    • Altrimenti riduci batch_size / resolution / num_frames.

Esempio copia-incolla (blocco 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

Vuol dire che il mio dataset è rotto?

Di solito no. È un limite di memoria condivisa del DataLoader, non un dataset “cattivo”.

Perché prefetch_factor: null è richiesto quando num_workers: 0?

Senza worker, il prefetching non viene usato. Impostarlo a null evita un comportamento di prefetch invalido/inutilizzato nel config.

Dovrei fare solo Fix B (aumentare /dev/shm)?

Se sei su RunComfy, parti da Fix A. Se fai self-hosting in Docker, Fix B è spesso necessario — e Fix A aiuta comunque.

Ho risolto il Bus error, ma ora ho GPU OOM. E adesso?

Abbassa batch_size, resolution o num_frames, oppure usa una GPU più grande (H200 consigliata per 121 frame).

Ready to start training?