ComfyUI sem memória no Windows: VRAM, RAM ou disco?
Quando o ComfyUI reporta CUDA out of memory no Windows, investigue primeiro a memória da GPU e o fluxo de trabalho que falhou. Excluir imagens geradas libera espaço em disco, mas não aumenta a VRAM dedicada. Uma mensagem genérica de falta de memória também pode envolver a RAM do sistema, então guarde o texto real do erro em vez de tratar toda falha como o mesmo problema.
Guarde o fluxo de trabalho que falhou e localize o estágio
Salve o fluxo de trabalho e anote o modelo, a resolução, o tamanho do lote e o nó em que a execução para. Use o relatório de erro e o log do terminal para distinguir entre carregar um modelo, amostrar, decodificar uma imagem e executar um nó personalizado. O estágio importa porque cada um pode precisar de uma quantidade diferente de memória.
O guia de solução de problemas do ComfyUI recomenda verificar o relatório, reduzir o tamanho da imagem ou o tamanho do lote e descartar problemas de nós personalizados. Trate essas ações como comparações controladas. Não atualize todos os nós, substitua o Python e troque o modelo ao mesmo tempo, porque uma nova execução bem-sucedida não revelaria mais qual mudança foi determinante.
Leia a memória da GPU e a memória do sistema separadamente
Abra Gerenciador de Tarefas › Desempenho e inspecione a memória dedicada da GPU junto com a página Memória enquanto reproduz a falha. Em um PC com várias GPUs, confirme que está olhando para a GPU realmente usada pelo fluxo de trabalho.
| Recurso | O que uma escassez altera |
|---|---|
| Memória dedicada da GPU | Se o modelo e os tensores intermediários cabem na GPU |
| RAM do sistema e commit | Se o Windows e o trabalho do lado da CPU têm espaço |
| Espaço em disco | Se modelos, saídas e arquivos de paginação podem crescer |
A memória compartilhada da GPU não é VRAM física extra na placa de vídeo. Um SSD livre grande não significa que um modelo grande caberá naquela placa. A explicação do Gerenciador de Tarefas sobre GPU da Microsoft descreve as diferentes leituras.
Relacione o primeiro experimento ao nó com falha
Um relatório de falta de memória geralmente contém mais informações úteis do que apenas o nó vermelho. Guarde o primeiro erro de alocação e o nó que o gerou; exceções posteriores podem ser consequências dessa primeira falha. Salve uma cópia do workflow antes de alterar o grafo.
| Etapa da falha | Primeira comparação controlada | O que o resultado pode estabelecer |
|---|---|---|
| Carregar um checkpoint ou text encoder | Um modelo menor compatível, com a mesma tarefa mínima | Se a exigência de carregamento é o obstáculo |
| Amostragem | Lote um e, depois, dimensões de imagem suportadas menores em uma execução separada | Se a carga intermediária cabe em um tamanho menor |
| Decodificação do VAE após a amostragem | Uma decodificação de VAE com tiles compatível | Se a decodificação foi o pico que falhou |
| Upscaling ou processamento de vídeo | Uma entrada menor ou menos quadros, se houver suporte | Se o tamanho da entrada dessa etapa é o que causa a falha |
| Um nó personalizado | O equivalente nativo suportado mais simples | Se a falha é específica desse caminho de nó |
Estes são experimentos, não garantias. Um checkpoint menor pode mudar a família do modelo, os nós necessários ou a qualidade da saída, então use um workflow que o suporte. Se o primeiro erro for sobre o carregamento de pesos, reduzir a qualidade final do JPEG não vai mudar a quantidade de memória de modelo necessária.
Mantenha um registro simples de modelo, seed, resolução, lote, nó alterado e resultado. Preserve a mesma seed quando o workflow suportar, para facilitar comparações visuais, reconhecendo que mudar a precisão ou os nós ainda pode alterar a imagem. Quando uma configuração pequena concluir, restaure um requisito por vez até que a etapa limitante fique clara.
Reduza uma demanda por vez
Comece com um tamanho de lote igual a um e uma resolução menor suportada. Se o fluxo de trabalho então concluir, aumente apenas uma dimensão e repita. Dobrar tanto a largura quanto a altura da imagem gera quatro vezes mais pixels, mas isso não implica exatamente quatro vezes a VRAM total, porque modelos e nós diferentes têm seus próprios custos.
Se a falha ocorrer na decodificação em vez da amostragem, tente um nó de decodificação VAE em blocos compatível quando o fluxo de trabalho oferecer suporte. Verifique a saída em busca de emendas ou outras diferenças. Se um único modelo não puder ser carregado, dimensões de saída menores sozinhas podem não resolver o problema. Teste um modelo ou precisão compatível com esse fluxo de trabalho e hardware.
Salve e feche outros trabalhos que usam muita GPU antes de outra execução. Se a memória continuar ocupada após um trabalho com falha, reinicie o ComfyUI normalmente depois de salvar o fluxo de trabalho. Um reinício pode liberar uma carga abandonada, mas não faz um fluxo de trabalho grande demais caber de forma confiável.
Altere a decodificação do VAE sem reconstruir o workflow inteiro
A documentação do VAE Decode Tiled do ComfyUI descreve a decodificação de amostras latentes em tiles menores. Em uma cópia salva de um workflow de imagem compatível, conecte as mesmas amostras latentes e o mesmo VAE ao nó de decodificação com tiles e, em seguida, conecte a saída de imagem ao nó de salvar ou pré-visualizar existente. Mantenha o workflow original para que a mudança seja reversível.
Comece pelos padrões disponíveis do nó em vez de copiar vários valores de tile e sobreposição de outro modelo. Se for necessário um tile menor, altere apenas esse valor e verifique tanto o uso de memória quanto a imagem resultante. Peças menores podem reduzir o conjunto de trabalho, mas adicionam sobrecarga de processamento; inspecione gradientes suaves, bordas e detalhes finos antes de aceitar o resultado.
O uso de tiles na decodificação não reduz a memória necessária antes, para carregar o modelo ou executar o sampler. Se a execução nunca chega à decodificação, volte a investigação para a etapa que falhou. Um VAE de vídeo ou um modelo especializado pode precisar do próprio nó compatível, então não substitua um decodificador de imagem só porque o nome inclui “tiled”.
Use o caminho de otimização da sua instalação
O guia oficial documenta --lowvram para instalações manuais. Para uma instalação manual iniciada a partir do próprio ambiente, a forma é:
python main.py --lowvram
Este não é um comando universal para colar no ComfyUI Desktop, em um pacote portátil ou em um inicializador de terceiros. Use as configurações de inicialização suportadas por essa instalação e mantenha os argumentos existentes. Mover o trabalho para fora da memória da GPU pode trocar velocidade e RAM do sistema por um requisito menor de VRAM.
Para falhas envolvendo nós personalizados, compare com um fluxo de trabalho integrado e siga a solução de problemas de nós personalizados do ComfyUI. Preserve o fluxo de trabalho original e registre quais nós foram desativados. Um nó personalizado ausente altera o fluxo de trabalho, então compare a menor tarefa equivalente que você consegue reproduzir.
Restaure as configurações de inicialização após a comparação
Guarde uma cópia do launcher ou uma anotação de seus argumentos antes de testar uma opção de memória. Um ambiente Python manual, o pacote portátil para Windows e o aplicativo Desktop não necessariamente iniciam da mesma forma. Adicione uma opção apenas pelo mecanismo que realmente inicia esta instalação; criar um segundo ambiente Python pode introduzir um problema diferente.
A referência de flags de inicialização do ComfyUI descreve vários controles independentes de memória e cache. Eles não são uma coleção de chaves para ativar em conjunto. Por exemplo, reduzir o cache de resultados pode diminuir a memória retida, mas fazer mais nós serem executados novamente. O offloading para CPU pode exigir RAM de sistema adicional e deixar o workflow mais lento.
Após uma execução bem-sucedida, verifique se a saída está completa e utilizável e, em seguida, repita a tarefa normal. Se a mudança permitir apenas um teste mínimo mas o workflow necessário ainda falhar, registre esse limite. Remova um argumento de teste inútil do launcher original e volte à última configuração funcional antes de outro experimento.
Se o comprometimento de memória do sistema for o gargalo, inspecione a Memória do Windows junto com a memória da GPU e mantenha uma configuração de arquivo de paginação funcional. Aumentar a capacidade do disco, aumentar o limite do arquivo de paginação e reduzir a demanda de VRAM dedicada são intervenções diferentes; nenhuma delas deve ser apresentada como cura universal para as outras.
Mantenha a limpeza das saídas como uma tarefa separada
Imagens e vídeos gerados podem consumir bastante espaço em disco. Revise-os por projeto e mantenha o fluxo de trabalho e os recursos necessários para reproduzir resultados valiosos. Faça backup de tudo que pretende manter antes de excluir sua única cópia.
Se o erro for uma falta de commit do Windows, o guia de memória do Windows explica como isso difere da VRAM. Não exclua o arquivo de paginação para deixar a unidade parecendo mais limpa. Ao relatar uma falha persistente, inclua o erro exato, a GPU e o driver, o tipo de instalação e o menor fluxo de trabalho que falha, com prompts e caminhos privados removidos.