logo
RunComfy
Guias de treinamento LoRA com AI Toolkit

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

Guia de troubleshooting sobre /dev/shm: por que os workers do DataLoader caem e como estabilizar o treino com menos workers/prefetch, mais shm-size e menos memória por amostra.

Treine modelos de difusão com Ostris AI Toolkit

Fix: “DataLoader worker is killed by signal: Bus error” (memória compartilhada /dev/shm) — LoRA LTX-2 no AI Toolkit

Se o seu treinamento de LoRA LTX-2 está caindo com Bus error, quase sempre é por pressão na memória compartilhada (/dev/shm): os workers do DataLoader do PyTorch + o prefetching acabam mantendo batches de vídeo grandes (muitos frames) na memória ao mesmo tempo.

Checklist de correção rápida (comece aqui)

  • ✅ Aplique o Fix A: reduza num_workers e prefetch_factor na config do dataset
  • ✅ Se você faz self-host em Docker: aplique o Fix B e aumente o /dev/shm com --shm-size
  • ✅ Rode o treinamento novamente e confirme que o log não mostra mais “out of shared memory” / “Bus error”
  • ✅ Se você está treinando com 121 frames, esteja pronto para lidar também com GPU OOM (veja as notas abaixo)

1) Confirme se é o mesmo problema

Você está no lugar certo se seus logs incluem algo como:

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

Palavras-chave comuns:

  • Bus error
  • out of shared memory
  • menções a DataLoader worker, shared memory limit, /dev/shm

2) O que está acontecendo

  • O treinamento do LTX-2 usa batches de vídeo (muitos frames por amostra).
  • Com múltiplos workers do DataLoader + prefetching, o AI Toolkit pode enfileirar vários batches grandes em /dev/shm.
  • Quando o /dev/shm é pequeno demais, um processo worker cai → Bus error → o treinamento para.

O RunComfy já fornece mais memória compartilhada, mas alguns datasets/configurações (especialmente num_frames alto como 121) ainda podem exceder.

3) Correções

Dica: mude uma variável por vez. Comece com o Fix A — ele resolve isso na maioria das execuções.

Fix A (recomendado): reduza workers + prefetch do DataLoader

Isso reduz a pressão na memória compartilhada sem alterar seus dados de treino.

Onde mudar (RunComfy UI):

  1. Abra Your Training Job Panel
  2. Clique em Show Advanced (canto superior direito)
  3. No YAML, encontre o item do dataset em datasets: (o bloco que contém seu folder_path)
  4. Adicione/ajuste estas chaves dentro desse item do dataset

Tente isso primeiro (geralmente é suficiente):

num_workers: 1

prefetch_factor: 1

Se ainda estiver crashando (mais estável, porém mais lento):

num_workers: 0

prefetch_factor: null

⚠️ Importante:

  • Se você definir num_workers: 0, defina prefetch_factor: null (exatamente null).
  • Reduzir workers/prefetch afeta throughput, não qualidade. Só muda como os dados são carregados.

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

Se você roda o AI Toolkit em Docker por conta própria, aumente a memória compartilhada do container:

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

or safer:

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

Você ainda pode aplicar o Fix A para mais estabilidade.

Fix C (se você ainda atingir limites): reduza a memória por amostra

Se o dataset for muito pesado, reduza também um ou mais de:

  • num_frames
  • resolution
  • batch_size

4) Verifique a correção

Um fix bem-sucedido parece assim:

  • O treinamento passa da fase do DataLoader e continua avançando steps.
  • O log não repete mais “out of shared memory” / “Bus error”.

Se você faz self-host, garanta também que o /dev/shm esteja realmente grande dentro do container.

Notas (follow-up comum: GPU OOM)

  • 121 frames é pesado. Depois de corrigir o /dev/shm, você ainda pode bater em GPU OOM.
    • Recomendado: H200 para treinamento com 121 frames.
    • Caso contrário, reduza batch_size / resolution / num_frames.

Exemplo para copiar e colar (bloco de 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

Isso significa que meu dataset está quebrado?

Normalmente não. Isso é um limite de memória compartilhada do DataLoader, não um dataset ruim.

Por que prefetch_factor: null é obrigatório quando num_workers: 0?

Sem workers, o prefetching não é usado. Definir como null evita um comportamento de prefetch inválido/não usado na config.

Eu devo fazer só o Fix B (aumentar /dev/shm)?

Se você está no RunComfy, comece com o Fix A. Se você faz self-host em Docker, o Fix B costuma ser necessário — e o Fix A ainda ajuda.

Eu corrigi o Bus error, mas agora tenho GPU OOM. E agora?

Reduza batch_size, resolution ou num_frames, ou use uma GPU maior (H200 recomendado para 121 frames).

Pronto para começar o treinamento?