Otimizar o ComfyUI com pouca VRAM: SDXL, FLUX e vídeo em GPUs de 6–8 GB

O terminal mostra torch.cuda.OutOfMemoryError: CUDA out of memory. O console do ComfyUI informa regular VAE encoding, retrying with tiled VAE encoding, mas a imagem de 1024×1024 ainda falha. Uma RTX 3060 com 8 GB gera uma imagem SDXL; ao adicionar Hires Fix, FaceDetailer e ControlNet, o consumo ultrapassa 12 GB. Reduzir para 768×768 e desligar ControlNet faz o workflow passar por pouco, mas a qualidade já não é a esperada.

Em uma GPU comum de 6–8 GB, Apple Silicon ou hardware AMD, o objetivo é executar SDXL, FLUX e workflows leves de vídeo com a maior estabilidade possível e entender quais ajustes sacrificam velocidade, qualidade ou compatibilidade.

---

Identifique primeiro a faixa de VRAM da GPU

O orçamento de VRAM não é um palpite. A faixa da GPU determina quais workflows são realistas e qual estratégia testar primeiro.

Faixas de VRAM, workflows possíveis e ponto de partida

VRAM	Workflows possíveis	Limites e riscos	Início recomendado
6GB	SDXL em baixa resolução (512–768) FLUX muito comprimido (Q2_K/Q3_K_S + GGUF + —lowvram/—novram) Vídeo: 8 frames em 480p como limite	Resolução limitada Nodes extras causam OOM facilmente Lento por offload para RAM	Quantização agressiva como Q3_K_S Resolução de 512–768 Desativar ControlNet e pós-processamento No máximo 8 frames
8GB	Uma imagem SDXL 1024×1024 FLUX fp8/GGUF Q4_K_S sem garantia 8 frames 480p confortáveis, 24 frames 720p no limite	ControlNet com Hires Fix pode causar OOM T5 precisa de fp8/GGUF Não passar de 1024×1024 FLUX.1 GGUF Q5_K_S fica no limite	Priorizar FLUX.2 Klein 4B GGUF T5 fp8/GGUF Tiled VAE batch size=1
12GB	SDXL + ControlNet + upscale simples FLUX Q5_K_S/Q6_K com margem 24 frames 720p confortáveis, 60 frames 1080p no limite	Vários ControlNet ainda exigem cuidado Calcular frames × resolução Pós-processamento continua limitado	FLUX Q5_K_S/Q6_K T5 fp8 opcional Tiled VAE opcional Testar batch size 2–3
16GB+	FLUX full fp16 ou Q8_0 quase sem perda Mais margem para ControlNet/LoRA 60 frames 1080p	FLUX full ocupa cerca de 23 GB Frames × resolução segue importante Pós-processamento ainda cria picos	FLUX Q8_0 ou fp16 T5 fp16 Tiled VAE opcional Testar batch size 4–8

Fontes de pico, da maior para a menor

1. Pesos do modelo: checkpoint SDXL de cerca de 6,5 GB; FLUX fp16 de cerca de 23 GB
2. Codificador T5: fp16 usa cerca de 9 GB e passa de uma GPU de 8 GB; fp8 usa 4–5 GB; GGUF oferece Q3/Q4/Q5
3. Resolução latente: um latent 2048×2048 pode se aproximar de 8 GB
4. VAE encode/decode: 2048×2048 pode chegar a picos de cerca de 8 GB
5. Batch size: inferência simultânea cria o maior pico
6. ControlNet/Detailer: cada um pode adicionar cerca de 2–3 GB
7. Frames de vídeo: frames × resolução × VideoVAE
8. Cache/preview: cerca de 0,5–1 GB

O uso real depende de resolução, precisão, versão do modelo, batch, nodes de pós-processamento, frames, PyTorch, driver e custom nodes. Pode variar 1–2 GB. Use a tabela como orçamento inicial e meça o workflow real.

---

Argumentos de inicialização do ComfyUI para pouca VRAM

O ComfyUI oferece argumentos para VRAM e memória do sistema. Eles mudam entre versões. A tabela se baseia no ComfyUI v0.18.0+ por volta de março de 2026; python main.py --help e a documentação oficial atual têm prioridade.

Argumentos, função, GPU e impacto na velocidade

Argumento	Função	GPU	Impacto na velocidade	Uso
--lowvram	Divide o modelo e transfere partes da RAM	4–8GB	20–40% mais lento	Sem efeito com Dynamic VRAM ativo Testar após —normalvram
--novram	Mantém pesos em CPU/RAM e leva apenas o cálculo ativo à GPU	Menos de 4GB	50–70% mais lento	Último recurso Muito lento, mas pode funcionar
--normalvram	Força modo padrão e desativa Dynamic VRAM	12GB+	Sem impacto esperado	Teste manual de —lowvram Ou OOM por fragmentação
--reserve-vram N	Reserva N GB de VRAM para o sistema	Todas	Sem impacto esperado	Evita instabilidade Reservar geralmente 2–4 GB
--async-offload	Faz offload assíncrono dos pesos	Todas	Exemplo: 5–10% mais rápido	Reduz espera CPU–GPU com RAM suficiente, normalmente 32 GB+
--fp8_e4m3fn-unet	Força UNet em fp8	8–12GB	Aproximadamente neutro	FLUX pode ignorar Verificar compute dtype
--fp8_e4m3fn-text-enc	Usa fp8 no codificador de texto	8GB	Aproximadamente neutro	Reduz T5 de cerca de 9 para 4–5 GB Útil para FLUX com pouca VRAM
--fp8_e5m2fn-text-enc	Outra variante fp8 para texto	8GB	Aproximadamente neutro	Alternativa a fp8_e4m3fn
--preview-method none	Desativa previews	Todas	Um pouco mais rápido	Economiza cerca de 0,5–1 GB Primeiro teste de OOM
--cache-none	Desativa cache	Pouca RAM	Mais lento	Economiza RAM, mas recalcula
--cache-lru 10	Guarda 10 resultados no cache LRU	RAM suficiente	Mais rápido	Bom equilíbrio Testar 10–20
--cache-classic	Cache clássico agressivo	RAM suficiente	Mais rápido	Pode usar mais RAM
--force-fp16	Força fp16 globalmente	Todas	Aproximadamente neutro	Pode economizar 2–3 GB
--use-pytorch-cross-attention	Força PyTorch SDP attention	Todas	Exemplo: 5–20% mais rápido	ComfyUI costuma escolher xformers/SDP Forçar apenas em teste
--use-flash-attention	Força Flash Attention	Todas	Exemplo: 5–20% mais rápido	Requer flash-attention Algumas versões CUDA são incompatíveis
--fast	Modo rápido experimental	Todas	Incerto	Experimento avançado Pode afetar qualidade/estabilidade Não é padrão para 8 GB

Exemplos de comandos

# Configuração básica para 8 GB de VRAM
python main.py --lowvram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none

# Configuração limite para 6 GB de VRAM
python main.py --novram --force-fp16 --fp8_e4m3fn-text-enc --preview-method none --reserve-vram 2

# Configuração de velocidade com RAM suficiente
python main.py --async-offload --cache-lru 10 --use-pytorch-cross-attention

Dados variáveis: os argumentos podem mudar. Consulte python main.py --help e a documentação atual. FLUX pode ignorar --fp8_e4m3fn-unet por seu compute dtype interno; ajuste weight_dtype no node quando necessário.

---

Por que —lowvram não evita o OOM

O ComfyUI v0.18.0+ por volta de março de 2026 ativa Dynamic VRAM por padrão. Quando ele está ativo, --lowvram é ignorado porque uma estratégia adaptativa de offload já funciona.

Quando usar --lowvram manualmente

• Depois de desativar Dynamic VRAM com --normalvram
• Se um workflow sofrer OOM por fragmentação, testar --disable-dynamic-vram

Alternativas

• Usar o comportamento padrão de Dynamic VRAM
• Reservar --novram para o último recurso e aceitar perda de velocidade de 50–70%
• Deixar espaço para o sistema com --reserve-vram 2-4

Vantagem de Dynamic VRAM: estima o espaço e descarrega para RAM automaticamente.

Risco de Dynamic VRAM: alguns workflows ainda sofrem OOM por fragmentação. Nesse caso, teste --disable-dynamic-vram.

---

Três rotas de FLUX em 8 GB: fp8, GGUF e Klein 4B

FLUX é um modelo de 12 bilhões de parâmetros cujo arquivo original tem cerca de 23 GB. Em 8 GB existem três rotas, cada uma com um custo.

Rotas de quantização FLUX

Rota	Tamanho	VRAM	Qualidade vs fp16	GPU	Velocidade	Compatibilidade	Uso
FLUX full (fp16)	~23GB	~20GB+	100%	24GB+	Mais rápida	Oficial	Uso profissional VRAM suficiente
FLUX fp8 checkpoint	~12GB	~11GB	~95–98%	12GB confortável/16GB+	Rápida	Quantização oficial	12GB+ Um arquivo
FLUX GGUF Q8_0	~12,7GB	~11GB	~99%	12GB+/16GB+	Mais lenta com offload	node city96, WIP	12GB+ Quase sem perda
FLUX GGUF Q5_K_S	~8,5GB	~7,5GB	~94–96%	8GB limite/12GB confortável	Lenta com offload	node city96, WIP	8GB Equilíbrio de qualidade
FLUX GGUF Q4_K_S	~6,8GB	~6,5GB	~88–90%	8GB/6GB limite	Mais lenta	node city96, WIP	6–8GB Priorizar execução
FLUX.2 Klein 4B GGUF Q4_K_M	~2,6GB	~2,6GB	Qualidade própria do modelo 4B	8GB confortável	Quatro steps, rápida	Apache 2.0, node city96	Para 8GB Quatro steps Rápida

Codificador T5

Versão T5	Tamanho	VRAM	GPU
T5 fp16	~9GB	~9GB	24GB+, passa de 8GB
T5 fp8_e4m3fn	~4–5GB	~4–5GB	Viável em 8GB
T5 GGUF Q3/Q4/Q5	~2–4GB	~2–4GB	Casos limite 6–8GB

Instalação

Para fp8, baixe o arquivo safetensors, carregue com Load Diffusion Model e defina weight_dtype como fp8_e4m3fn.

Para GGUF, instale o custom node ComfyUI-GGUF do city96, carregue o modelo com Unet Loader (GGUF) e coloque o arquivo em models/unet/.

Risco do node externo: GGUF está marcado como WIP e o suporte a LoRA é experimental. Ele muda com frequência e não é uma rota oficial integrada.

Observação de qualidade da Apatero: Q5_K_S fica próximo de fp16, com diferenças mais visíveis em texto e padrões finos. Q4_K_S perde mais detalhes.

Observação de velocidade do Local AI Master

• FLUX.1-dev Q4_K_S + —lowvram, 1024×1024, 20 steps, RTX 3060 Ti 8GB: cerca de 90–150 segundos
• FLUX.2 Klein 4B Q4_K_M, 1024×1024, quatro steps, 8GB: cerca de 15–30 segundos

Benchmark variável: hardware, versões e workflow alteram muito esses valores. Use-os como faixas de referência.

---

Reduzir OOM de VAE Encode/Decode com Tiled VAE

Em 2048×2048 ou vídeo, VAE Encode/Decode pode esgotar a VRAM. Tiled VAE processa a imagem em áreas menores para reduzir o pico.

Nodes

VAEDecodeTiled decodifica um latent em imagem tile por tile. VAEEncodeTiled codifica uma imagem em latent da mesma forma.

Parâmetros

Parâmetro	Função	Valor inicial	Uso
tile_size	Tamanho de cada tile	512 com pouca VRAM 1024 com margem	Menor usa menos, mas fica mais lento Começar em 512 para 8GB
overlap	Sobreposição entre tiles	64	Evita emendas Testar 32–128
fast mode	Modo rápido	true	Geralmente ativar
temporal_size	Chunk temporal apenas para Video VAE	8 com pouca VRAM 16 com margem	Processa frames em grupos Só é útil para Video VAE
temporal_overlap	Sobreposição entre chunks temporais	2–4	Continuidade entre grupos

Comparação de picos da SynpixCloud

Resolução	VAE padrão	Tiled 512	Tiled 1024
1024×1024	~2GB	~0,5GB	~1GB
2048×2048	~8GB	~1GB	~2,5GB

Use Tiled VAE quando

• A resolução passar de 1024×1024
• A GPU tiver 8–12GB
• O workflow usar Video VAE
• Hires Fix, Upscale ou FaceDetailer falhar no pós-processamento

Aviso de documentação: a documentação do node está marcada como AI-generated. Verifique interface e parâmetros na versão atual.

---

Diagnosticar OOM pela fonte do pico

Diante de CUDA out of memory, revise primeiro os maiores picos e aplique uma redução concreta em cada etapa.

Tabela de OOM

Fonte do pico	Exemplo de VRAM	Redução	Prioridade
Pesos do modelo	SDXL ~6,5GB FLUX fp16 ~23GB	Mudar para fp8/GGUF —lowvram/—novram	P0
Codificador T5	fp16 ~9GB	T5 fp8/GGUF com loader compatível	P0 para FLUX
Resolução latente	2048×2048 ~8GB	Reduzir para 1024×1024 ou 512×512	P1
VAE encode/decode	Até cerca de 8GB em 2048×2048	Tiled VAE, tile_size=512, overlap=64	P1
Batch size	batch size=4 em 1024×1024, cerca de 8–12GB	batch size=1 batch count em queue	P2
ControlNet/Detailer	Cerca de 2–3GB cada	Desativar branch ControlNet Usar rota de pouca VRAM	P2
Frames de vídeo	Frames × resolução × VideoVAE	Temporal chunking Reduzir frames Tiled Video VAE	P2 vídeo
Cache/preview	~0,5–1GB	—preview-method none —cache-none	P3

Ordem das mudanças

1. Reduzir resolução: 2048 → 1024 → 512
2. Desativar preview: --preview-method none
3. Mudar para modelo fp8/GGUF: FLUX Q4_K_S, Q5_K_S ou Klein 4B
4. Mudar T5 para fp8/GGUF: importante para FLUX com pouca VRAM
5. Usar Tiled VAE: começar com tile_size=512 e overlap=64
6. Reduzir batch size: batch size=1, batch count em queue
7. Desativar ControlNet e pós-processamento: FaceDetailer, Hires Fix, Upscale
8. Em vídeo: reduzir frames e usar temporal chunking

---

Separar dois tipos de lentidão

Primeiro diferencie se o workflow está lento porque o offload é necessário ou se uma configuração o deixa mais lento do que deveria.

Tabela de velocidade

Gargalo	Sinal	Diagnóstico	Ajuste
Lentidão normal com pouca VRAM
—lowvram/—novram	20–70% mais lento	Revisar argumentos	Aceitar a lentidão Ou usar mais VRAM
Offload GGUF para RAM	Baixa utilização da GPU	Revisar uso da GPU	Banda da RAM limita Usar fp8/fp16 se couber
Vídeo com muitos frames	VAE Decode lento	Calcular frames × resolução	Reduzir frames Temporal Tiling
Modo CPU —cpu	Extremamente lento	Revisar argumentos	Apenas último recurso Usar GPU
Lentidão anormal
Sampler steps demais	FLUX dev passa de 20 steps	Revisar KSampler	Cerca de 20 pode bastar para FLUX dev schnell/Klein 4B usa quatro
Backend attention inadequado	Uso alto de memória	Revisar argumentos	xformers compatível Ou PyTorch SDP
VAE Decode lento	tile_size pequeno demais	Revisar VAEDecodeTiled	Passar de 512 para 1024 ~1GB a mais, possível ganho de 10–30%
Espera de CPU offload	Espera CPU–GPU	Revisar argumentos	—async-offload RAM suficiente, geralmente 32GB+
Cache de disco/RAM inadequado	Modelo recarrega	Revisar argumentos	—cache-lru 10 Guardar 10 resultados
Outro processo usa GPU	Pouco uso útil	Revisar sistema	Fechar navegador, jogo, editor de vídeo

Ações em ordem

1. xformers ou SDP attention: pip install xformers para detecção automática, ou testar --use-pytorch-cross-attention; referências de 20–30% menos VRAM e 5–20% mais velocidade
2. FLUX de quatro steps: schnell ou Klein 4B no lugar de dev com 20 steps
3. Aumentar tile_size: 512 → 1024, cerca de 1GB a mais de pico para possível ganho de 10–30%
4. Ativar async offload: --async-offload com RAM suficiente
5. Fechar outros processos de GPU: navegador, jogos e editor de vídeo

Observação da SynpixCloud: xformers/SDP attention reduziu VRAM em 20–30% e aumentou velocidade em 5–20% no ambiente citado.

Observação do Local AI Master: FLUX.2 Klein 4B Q4_K_M, quatro steps, 1024×1024 e 8GB levou cerca de 15–30 segundos.

Benchmark variável: todos os valores são referências dependentes do ambiente.

---

Por que um arquivo GGUF menor pode ser mais lento

Um GGUF Q4_K_S de cerca de 6,8GB pode ser mais lento que FLUX fp16 de cerca de 23GB:

• GGUF pode descarregar os pesos na RAM do sistema em vez de mantê-los na VRAM, reduzindo o uso da GPU
• A inferência transfere pesos repetidamente da RAM para a VRAM
• A banda da RAM é menor: DDR4/DDR5 em torno de 25–50GB/s contra GDDR6X em torno de 500–1000GB/s

Use GGUF quando

• fp8 não couber em uma GPU de 6–8GB e GGUF for a rota restante para executar FLUX
• Você aceitar menor velocidade para fazer o modelo caber

Evite GGUF quando

• Uma GPU de 12GB+ puder executar fp8 ou fp16 com mais eficiência
• Velocidade for mais importante do que executar o modelo a qualquer custo

Observação da Apatero: Q8_0 with CPU offloading may take 5-10 minutes per generation.

---

Orçamento de VRAM para vídeo: frames × resolução × VideoVAE

Em vídeo, frames × resolução × VideoVAE pode dominar a VRAM. Aqui entram orçamento e redução de pico, não um workflow completo de Wan ou AnimateDiff.

Princípio de orçamento

Pico de VRAM ≈ pesos do modelo + T5 + frames × latent por frame + pico do VideoVAE.

Exemplos dos recursos citados ComfyUI-Wan2.2 e Local AI Master

Configuração de vídeo	Orçamento VRAM	GPU	Nota
8 frames em 480p (640×360)	~6–8GB	6GB pode funcionar	O exemplo citado de RTX 3050 6GB produziu cerca de um segundo de vídeo em menos de cinco minutos
24 frames em 720p (1280×720)	~12–16GB	8GB limite/12GB confortável	Requer Temporal Tiling
60 frames em 1080p (1920×1080)	~20–24GB+	16GB+	Rota de alta VRAM

Reduzir o pico

Temporal Tiling divide frames em grupos pequenos, por exemplo oito por vez. Os parâmetros são temporal_size e temporal_overlap.

Tiled VAE processa VAE Decode de cada frame em tiles espaciais.

Reduza frames de 60 para 24 e depois para 8, validando primeiro a execução mínima.

Reduza resolução de 1080p para 720p e depois 480p.

Os recursos fonte sugerem Wan 2.2 5B para alvo de 8GB ou Wan 2.2 14B GGUF como exemplo a partir de 6GB.

Benchmark variável: esses números são referências dependentes do ambiente.

---

Evitar OOM em série: batch size e batch count

batch size e batch count produzem picos muito diferentes. Aumentar batch size sem controle causa OOM com facilidade.

batch size e batch count

batch size executa várias imagens ao mesmo tempo; latents, VAE e tensores ativos aumentam. batch count coloca vários batches pequenos na queue e mantém o batch ativo reduzido.

Comparação de VRAM

Configuração	Resolução	Pico de VRAM	Risco de OOM
batch size=4	1024×1024	~8–12GB	Alto por simultaneidade
batch count=4, batch size=1	1024×1024	~2–3GB	Menor por execução sequencial

Recomendação

• Com 6–8GB: batch size=1 e batch count=N
• Para batches via API: usar queue e controle de concorrência do workflow de automação do ComfyUI em vez de iniciar várias requisições pesadas juntas

---

OOM repentino após atualizar: verifique as versões

Se o mesmo workflow fica lento ou falha após atualizar PyTorch, driver ou ComfyUI, o ambiente pode ter mudado mesmo com prompt e graph iguais.

Mudanças de versão que afetam VRAM

O comportamento CUDA do PyTorch muda, incluindo defaults de TF32/FP16 e allocator. TF32 e FP16 não são sempre melhores: exemplos do PyTorch mostram multiplicação TF32 mais rápida com maior erro numérico. Driver, ROCm e CUDA também alteram o comportamento da GPU.

Processo recomendado

1. Salvar o ambiente antes de atualizar com conda ou pip freeze
2. Testar a versão nova em ambiente separado
3. Registrar versões estáveis de PyTorch, CUDA e driver
4. Voltar a uma versão fixa se houver regressão

---

Separar acelerações experimentais de inícios estáveis

Diferencie experimentos avançados de configurações adequadas para um primeiro teste estável.

Experimentos avançados, não requisitos para 8GB

Item	Estado	Risco	Nota
--fast	Experimental	Pode alterar qualidade/estabilidade	Marcado como experimental pelo ComfyUI
FlashAttention	Requer flash-attention	Algumas versões CUDA incompatíveis	Instalação complexa
Sage Attention	Otimização externa	Experimental, pode afetar precisão	Requer CUDA/PyTorch compatíveis
TensorRT	Requer TensorRT SDK e configuração	Conversão complexa	Pouco indicado para iniciantes

Pontos de partida estáveis

Item	Estado	Efeito	Nota
xformers	Estável se compatível	Referência: 20–30% menos VRAM, 5–20% mais rápido	pip install xformers ComfyUI detecta
SDP attention com —use-pytorch-cross-attention	Estável	Referência: 20–30% menos VRAM, 5–20% mais rápido	ComfyUI pode escolher o melhor backend automaticamente

---

Conclusão

Faixa da GPU: identifique primeiro 6GB, 8GB, 12GB ou 16GB+ e comece por um workflow base adequado.

Argumentos: no comportamento citado da v0.18.0+, Dynamic VRAM está ativo por padrão, então --lowvram pode não ter efeito. Confirme com python main.py --help.

Quantização: as medições citadas apresentam FLUX.2 Klein 4B GGUF como rota rápida para 8GB e FLUX.1 GGUF Q4_K_S quando fazer o modelo caber importa mais que velocidade. O offload GGUF depende muito da banda da RAM.

Ordem de diagnóstico: pesos do modelo → T5 → resolução latente → VAE → batch size → ControlNet → frames de vídeo → cache. Para velocidade, separe a lentidão normal do offload de um gargalo ajustável.

Próximos passos

1. Identificar a faixa 6GB, 8GB, 12GB ou 16GB+
2. Para os casos citados de 8GB, escolher FLUX.2 Klein 4B ou FLUX.1 GGUF Q4_K_S
3. Aplicar a checklist de memória diante de OOM
4. Aplicar a checklist de velocidade diante de lentidão anormal
5. Usar Temporal Tiling em workflows de vídeo

Se o ambiente básico ainda não funciona, comece pelo guia de ComfyUI para iniciantes. Para nodes vermelhos, modelos ausentes ou workflows que não podem ser reproduzidos, consulte a checklist para reutilizar workflows do ComfyUI. Se ainda houver dúvida entre SDXL, SD 3.5 e FLUX, leia primeiro o guia para escolher modelos do Stable Diffusion.