Rodando FLUX em 8GB de VRAM

FLUX.1 lançou como um modelo texto-para-imagem de 12 bilhões de parâmetros com qualidade de prompt que rivalizava sistemas fechados. Esse desempenho veio com um custo: o modelo fp16 completo e seu codificador de texto podem exceder o orçamento de memória de uma GPU de 8GB. Se você quer rodar FLUX localmente em 8GB de VRAM, quantização fp8, offload GGUF e o orçamento de passos correto não são ajustes opcionais — são as condições que fazem o workflow completar.

Este artigo cobre as diferenças verificadas entre FLUX.1-schnell e FLUX.1-dev, os caminhos fp8 e GGUF, o que offlar, e a resolução e contagem de passos que usuários consistentemente relatam completar em 8GB de VRAM.

TL;DR

• Use FLUX.1-schnell com 4 passos e sampler Euler para o único caminho local rápido e confiável em 8GB de VRAM; FLUX.1-dev geralmente precisa de mais passos e mais folga de memória.
• Carregue o UNet fp8 ou um modelo quantizado GGUF através do custom node ComfyUI-GGUF, e coloque ae.safetensors mais os arquivos CLIP esperados nas suas pastas padrão.
• Orçamente memória do sistema e disco com cuidado: o carregamento pode consumir aproximadamente 32GB de RAM e precisa de cerca de 25GB de espaço livre em disco, ou o workflow pode falhar antes do primeiro passo.

FLUX.1-schnell versus FLUX.1-dev

Black Forest Labs posiciona os dois modelos open-weight de forma diferente. FLUX.1-schnell é destilado para velocidade e pode gerar imagens em 1 a 4 passos sem um sampler LCM. FLUX.1-dev também é destilado, mas é treinado para qualidade e uso não comercial, o que geralmente significa mais passos de inferência e maior pressão de memória durante a geração. O efeito prático para donos de 8GB de VRAM é que schnell é o candidato local realista; dev é melhor visto como um alvo de maior qualidade para hardware com mais folga.

A licença também difere. FLUX.1-schnell é lançado sob Apache 2.0, enquanto FLUX.1-dev usa uma licença não comercial. Se você está avaliando modelos para um projeto que inclui uso comercial, schnell é o ponto de partida mais seguro.

O ComfyUI espera checkpoints UNet, VAE e CLIP em pastas específicas; confirme o layout de pastas da sua instalação antes de copiar arquivos.

O FLUX roda em 8GB de VRAM sem quantização?

Não em fp16. O checkpoint padrão do FLUX e seu codificador de texto juntos podem exceder o orçamento de memória de uma placa de 8GB antes mesmo de a geração começar. A comunidade consistentemente usa dois desvios em torno desse teto: UNets quantizados em fp8 e loaders GGUF que podem derramar pesos inativos para a RAM do sistema ou disco. Sem um desses caminhos, o workflow geralmente para com uma falha de memória insuficiente ou trava durante a fase de carregamento.

Para o panorama mais amplo do que cada modelo precisa, veja Requisitos de VRAM por modelo.

Como a quantização fp8 reduz a pegada de memória

FP8 no contexto do FLUX geralmente significa float8_e4m3fn, um formato de armazenamento de 8 bits para os pesos do modelo. Como fp16 armazena cada peso em 16 bits e fp8 armazena em 8 bits, a pegada de memória dos pesos é aproximadamente reduzida pela metade. A documentação de quantização do diffusers (bitsandbytes) nota que a quantização de 8 bits "multiplica outliers em fp16 com não-outliers em int8, converte os valores não-outlier de volta para fp16, e então os soma para retornar os pesos em fp16", o que preserva o comportamento de saída enquanto reduz a memória dos pesos. Para FLUX, o mesmo princípio se aplica às variantes fp8.

Uma distribuição fp8 amplamente usada é o repositório Kijai flux-fp8, que oferece variantes fp8 para ambos FLUX.1-schnell e FLUX.1-dev. Ao usar fp8 no ComfyUI, usuários relatam colocar os arquivos em pastas específicas:

• flux1-schnell-fp8.safetensors em ComfyUI/models/unet
• ae.safetensors em ComfyUI/models/vae
• Arquivos CLIP como clip_l.safetensors e t5xxl_fp16.safetensors em ComfyUI/models/clip

Nota: o nome do arquivo VAE mudou para ae.safetensors nos workflows fp8, então tutoriais mais antigos que referenciam nomes antigos estilo sd3 podem confundir usuários durante a configuração.

O GGUF pode rodar FLUX em VRAM ainda menor?

GGUF armazena pesos do modelo em forma quantizada que pode ser carregada em pedaços, o que o torna atraente para GPUs com VRAM muito limitada. O custom node ComfyUI-GGUF fornece um loader de UNet GGUF e loaders de CLIP conscientes de GGUF que se encaixam em workflows regulares, com releases pré-quantizados de FLUX.1-schnell e FLUX.1-dev já disponíveis.

Seu README diz que modelos estilo transformer como o FLUX parecem menos afetados pela quantização do que arquiteturas convolucionais UNet mais antigas, então quants GGUF de bits mais baixos podem permanecer utilizáveis em placas com 8GB de VRAM ou menos. Na prática, um anexo de workflow da comunidade mostra geração bem-sucedida em uma GPU de notebook 3050 com apenas 4GB de VRAM, então GGUF é o caminho quando fp8 ainda é muito pesado.

Uma vez rodando, as configurações que importam são cobertas em Parâmetros de treinamento LoRA do FLUX para treinamento e em nosso guia de samplers e schedulers para geração.

Que resolução e orçamento de passos realmente completam em 8GB

Em 8GB de VRAM com os caminhos fp8 ou GGUF, o único orçamento local rápido consistentemente relatado é FLUX.1-schnell mais 4 passos usando sampler Euler. Relatos da comunidade descrevem saída 1024x768 completando em cerca de 2 minutos nessa configuração. Em troca, o carregamento do modelo é lento: os mesmos relatos da comunidade descrevem tempos totais de geração em torno de 20 minutos quando o carregamento do modelo é incluído.

Se você está comparando isso com hardware local de nuvem ou de ponta, o gargalo não é o sampler — é o movimento de pesos entre a RAM da CPU e a VRAM da GPU. O orçamento de passos acima é, portanto, realista em vez de aspiracional; qualidade estilo dev em 20–50 passos é geralmente impraticável dentro de um envelope de 8GB de VRAM.

O que você deve offlar para a CPU?

A rota prática de offload é enable_model_cpu_offload(), que move os pesos do modelo para a RAM do sistema enquanto não são ativamente necessários na GPU. Isso mantém a VRAM de pico mais baixa, mas adiciona latência à medida que os pesos se movem para frente e para trás durante a geração. O trade-off é inevitável em placas de 8GB: offload faz o workflow completar, mas também estende o tempo de carregamento.

Usuários relatam que a fase de carregamento em si é faminta por memória. Aproximadamente 32GB de RAM do sistema podem ser consumidos enquanto o modelo está sendo preparado, e uma vez que os arquivos de instalação estão presentes, cerca de 25GB de espaço livre em disco é necessário para evitar falhas de carregamento. Se seu SSD ou HDD está perto da capacidade, esse é o primeiro gargalo a limpar antes de debugar configurações da GPU.

Erros comuns e correções

FAQ

Quanto de VRAM o FLUX.1-schnell precisa para inferência de 4 passos? O modelo pode tecnicamente rodar em 8GB de VRAM quando pareado com quantização fp8 ou GGUF e offload para CPU, mas o desempenho depende fortemente se a RAM do sistema e o disco também são suficientes. O schnell fp16 completo geralmente excede uma placa de 8GB, então quantização é o caminho prático.

O FLUX roda em uma GPU de 8GB? Sim. Workflows da comunidade demonstram FLUX.1-schnell rodando em placas de 8GB usando quantização fp8 ou GGUF, com ComfyUI-GGUF também permitindo execuções em hardware com apenas 4GB de VRAM. O sucesso depende do posicionamento dos arquivos, comportamento de offload e RAM do sistema disponível.

Qual a diferença entre FLUX.1-schnell fp8 e GGUF? fp8 reduz a precisão dos pesos em um formato safetensors padrão, enquanto GGUF usa um container quantizado com suporte embutido para carregamento em baixa VRAM e offload parcial. fp8 se encaixa em loaders comuns do ComfyUI; GGUF requer o custom node ComfyUI-GGUF e oferece economias de VRAM mais agressivas.

Por que o FLUX demora tanto para carregar? Em sistemas de 8GB de VRAM, esse processo pode consumir aproximadamente 32GB de RAM do sistema e levar tempo suficiente para que o tempo total de geração seja dominado pela inicialização, não pela amostragem.

Que resolução o FLUX pode gerar em 8GB de VRAM? Relatos da comunidade citam 1024x768 com sampler Euler em 4 passos como um orçamento realista. Resoluções maiores aumentam a demanda de memória e computação, então são mais propensas a falhar ou exigir quantização ou offload ainda mais agressivos.