AI Toolkit CUDA Out of Memory: corrigir OOM durante carregamento de modelo, treino e amostragem

Se o seu job do AI Toolkit falha com CUDA out of memory, OOM during training step 3 times in a row ou 0 bytes is free, não continue relançando o mesmo job sem alterações.

Na prática, a maioria dos erros OOM no AI Toolkit vem de um destes quatro pontos:

1. carregamento do modelo (antes do treino real começar)
2. os primeiros passos de treino
3. amostragem de preview / geração de sample de referência
4. picos específicos de vídeo por frames demais, buckets grandes demais, ou ambos

Este guia é o caminho rápido de recuperação: identifique qual OOM você tem, mude as configurações corretas no RunComfy AI Toolkit e chegue mais rápido a uma nova tentativa bem-sucedida.

---

Checklist rápido (comece aqui)

• ✅ Em Training, reduza o Batch Size
• ✅ Em Datasets, desative o bucket de resolução mais alto primeiro
• ✅ Em Sample, reduza Width / Height / Sample Steps ou ative temporariamente Disable Sampling
• ✅ Clique em Show Advanced e confirme que gradient_checkpointing: true
• ✅ Para modelos de vídeo, reduza Num Frames antes de mexer no learning rate
• ✅ Se o erro ocorre mesmo com config muito conservadora, trate como possível problema de estado do worker / GPU, não apenas de configuração

---

1) Confirmar que é o mesmo problema

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

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

Situações comuns:

• o job falha antes do passo 1
• o job chega ao passo 2–10 e depois entra em OOM repetidamente
• o treino parece ok, mas o crash acontece ao gerar samples
• a mesma config às vezes funciona, às vezes não

---

2) Primeiro: qual tipo de OOM é?

A. OOM durante carregamento do modelo ou antes do treino

Normalmente significa uma destas coisas:

• o modelo é pesado demais para o setup atual de economia de memória
• a geração do sample de referência / preview já é muito cara
• o worker / GPU está em mau estado e não parte de memória limpa

Sinais típicos:

• falha antes de passos de treino significativos
• erro ocorre logo após carregar o modelo ou durante o primeiro sample
• logs mostram quase nenhuma VRAM livre ou erro de alocação CUBLAS

B. OOM nos primeiros passos de treino

É o caso mais comum causado por configuração.

Causas típicas:

• gradient_checkpointing está desativado
• Batch Size muito alto
• o maior bucket do dataset é ambicioso demais
• para vídeo, Num Frames é o verdadeiro pico de memória

C. OOM durante amostragem / geração de preview

É uma armadilha muito comum.

Sua config de treino pode estar quase ok, mas o preview é caro demais:

• Sample Width / Height muito grande
• Sample Steps muito alto
• Sample Every muito frequente
• vídeo de preview usa frames demais

D. OOM só às vezes

Normalmente é uma config no limite, não um mistério.

Exemplos:

• o treino sobrevive com buckets menores, mas crasha com o maior bucket
• treinos de vídeo falham só com os clips mais pesados
• o core do treino cabe, mas a geração de samples estoura

---

3) Correções mais rápidas no RunComfy AI Toolkit

Fix A — Reativar gradient checkpointing

É a primeira coisa a verificar em OOMs de modelos de imagem.

Onde mudar

1. Abra o job que falhou
2. Clique em Show Advanced
3. Sob train:, confirme:

gradient_checkpointing: true

Na dúvida, deixe ativado.

---

Fix B — Reduzir Batch Size, usar Gradient Accumulation para estabilidade

Onde mudar

• Abra o editor do job
• No painel Training:
• reduza o Batch Size
• mantenha ou aumente Gradient Accumulation se quiser batch efetivo ligeiramente maior sem aumentar o pico de VRAM

Regra de nova tentativa segura

• Modelos de imagem: se OOM, desça para Batch Size = 1 primeiro
• Modelos de vídeo: assuma Batch Size = 1 como padrão a menos que a config já tenha sido comprovada estável

Não trate o learning rate como sua primeira alavanca de memória. Normalmente não é.

---

Fix C — Remover primeiro o bucket de dataset mais alto

Onde mudar

• Vá ao painel Datasets
• Em Resolutions, desative o bucket mais alto primeiro

Ordem de rollback segura

• 1024 / 1536 → remover primeiro
• manter 512 / 768 enquanto verifica estabilidade
• uma vez estável, adicionar buckets maiores um de cada vez

É uma das formas mais rápidas de transformar um treino no limite em um reproduzível.

---

Fix D — Tornar a amostragem de preview barata ou desativá-la temporariamente

Se o crash acontece antes do treino começar de fato, ou toda vez que a amostragem roda, corrija o preview primeiro.

Onde mudar

• Abra o painel Sample

Depois faça uma ou mais destas:

• reduza Width
• reduza Height
• reduza Sample Steps
• aumente Sample Every
• ative Disable Sampling para um run de validação

Boa primeira tentativa

Se o objetivo é "provar que o job consegue treinar", um run temporário sem amostragem está ok.

Uma vez estável, reative os previews com configurações menores.

---

Fix E — Modelos de vídeo: reduzir Num Frames antes de tudo

Para modelos de vídeo, frames são geralmente a maior alavanca de memória.

Onde mudar

• Painel Datasets → Num Frames
• Painel Sample → Num Frames

Se está treinando vídeo e vendo OOM, reduza frames primeiro, depois batch size, depois resolução.

Não comece mudando optimizer ou LR.

---

Fix F — Usar o caminho de baixa memória do modelo

Algumas arquiteturas são feitas para treinar com configurações de economia de memória quando a VRAM é limitada.

Onde mudar

• Clique em Show Advanced
• Sob model:, procure:

low_vram: true

Para alguns modelos, o caminho correto também inclui quantização ou tratamento de text-encoder específico. Siga o guia do modelo em vez de adivinhar.

---

4) Diagnóstico rápido por momento da falha

---

5) Como distinguir OOM de config de problemas de ambiente / estado da GPU

Trate como não apenas problema de config quando tudo isso for verdade:

• Batch Size = 1
• gradient_checkpointing: true
• resolução / frames conservadores
• o job ainda falha antes do treino começar de forma significativa
• logs mostram 0 bytes is free ou falha de alocação CUBLAS

Nessa situação:

1. pare de repetir a mesma tentativa
2. crie um novo job em worker limpo se possível
3. se a mesma config conservadora funcionava antes e agora falha instantaneamente, escale para o suporte

Isso importa porque tentativas repetidas podem desperdiçar tanto tempo quanto orçamento de GPU.

---

6) A ordem de rollback mais segura

Para modelos de imagem

1. gradient_checkpointing: true
2. Batch Size → 1
3. remover o maior bucket de resolução
4. reduzir ou desativar Sample
5. ativar low_vram ou o caminho de baixa memória do modelo

Para modelos de vídeo

1. reduzir Num Frames
2. Batch Size → 1
3. remover o maior bucket de resolução
4. reduzir ou desativar Sample
5. ativar low_vram ou offloading / quantização específica do modelo

---

7) Após sua primeira nova tentativa bem-sucedida

Uma vez com um treino estável:

• adicione de volta apenas uma configuração mais pesada por vez
• anote o que mudou
• não reintroduza múltiplas configurações de alto risco juntas

Boa ordem para escalar:

1. manter as mesmas configurações de memória estáveis
2. aumentar Steps
3. reativar um bucket maior
4. reativar amostragem mais rica
5. só então testar batch maior ou vídeo mais longo

---

Resumo em uma linha

Se o AI Toolkit dá OOM, pare de tentar aleatoriamente.

Ative gradient_checkpointing, reduza o Batch Size, remova o maior bucket de resolução e torne a amostragem de preview mais barata antes de tentar novamente.

---

Guias relacionados

• Como evitar OOM no AI Toolkit: configurações seguras para o primeiro treino bem-sucedido
• Por que desativar o Gradient Checkpointing causa OOM no AI Toolkit
• Wan 2.2 / LTX-2 Guia OOM: Frames, Batch Size e Resolução seguros
• Abrir RunComfy AI Toolkit