Requisitos de hardware para rodar Stable Diffusion local

O que um gerador de imagens de IA auto-hospedado realmente precisa

Um gerador de imagens de IA auto-hospedado é uma aplicação web e um ficheiro de modelo. A aplicação é o ComfyUI e funciona em qualquer servidor Linux. O modelo determina o hardware necessário. Um checkpoint da classe SDXL é um único ficheiro de 6.94 GB e precisa de ficar na memória da GPU. Esse facto define todo o orçamento, por isso consulte a tabela de hardware abaixo antes de contratar qualquer serviço.

O resumo honesto é este: uma VPS apenas com CPU pode instalar e disponibilizar o software, além de gerar imagens a 512x512 com um modelo Stable Diffusion 1.5 mais antigo em um ou dois minutos por imagem. O mesmo servidor a executar SDXL em 1024x1024 demora dez a vinte minutos por imagem. Isso não significa que a configuração esteja avariada. É uma questão de capacidade de processamento, e este guia explica-a.

Como o tamanho do modelo determina a máquina

A geração de imagens executa um ciclo de remoção de ruído. Uma renderização com 30 passos executa o denoiser, o UNet do SDXL, 30 vezes sobre a imagem, e cada passagem lê todos os pesos do UNet. Os dois codificadores de texto executam uma vez antes do ciclo, e o VAE descodifica uma vez depois dele. Por isso, não fazem parte do custo de cada passo. O UNet do SDXL em precisão reduzida ocupa 5.14 GB de pesos. Nesta visão simplificada, uma renderização com 30 passos move aproximadamente 154 GB de pesos pela memória antes de apresentar uma imagem. Os tensores intermédios acrescentam ainda mais dados.

Uma GPU com 24 GB de memória de vídeo (VRAM, a memória soldada junto do chip gráfico) lê a centenas de gigabytes por segundo e mantém todos os 6.9 GB na memória ao mesmo tempo. Uma VPS com CPU lê a RAM do sistema a dezenas de gigabytes por segundo e não tem hardware matricial para as convoluções. Por isso, o mesmo ciclo é executado uma ou duas ordens de grandeza mais lentamente. Este é o mesmo argumento baseado na largura de banda da memória que governa os modelos de texto. Vale a pena ler esta explicação juntamente com quando uma VPS com GPU vale realmente o custo.

A geração de imagens difere da geração de texto num aspeto importante. Um modelo de chat transmite tokens. Por isso, uma máquina lenta continua a ser utilizável, porque as palavras aparecem enquanto lê. Uma imagem só aparece quando o último passo termina. Se for lento, fica a olhar para uma barra de progresso.

A escala de hardware, com números reais

O bloco abaixo apresenta valores típicos para uma imagem SDXL a 1024x1024, com 30 passos e o sampler Euler, em julho de 2026. Considere-os como ordens de grandeza. O sampler, o número de passos e a resolução alteram esses valores.

[
  {
    "label": "8 vCPU VPS, no GPU",
    "seconds_per_image": 780
  },
  {
    "label": "8GB VRAM GPU",
    "seconds_per_image": 32
  },
  {
    "label": "12GB VRAM GPU",
    "seconds_per_image": 18
  },
  {
    "label": "24GB VRAM GPU",
    "seconds_per_image": 9
  }
]

A linha da CPU indica 780 segundos, ou cerca de treze minutos. A placa de 24 GB demora 9 segundos. Essa é a diferença que está a comprar.

Leia a escala desta forma. Com menos de 8 GB de VRAM, o SDXL continua a funcionar, porque o ComfyUI gere a VRAM e a RAM do sistema em conjunto e descarrega automaticamente os pesos do modelo. Em outubro de 2026, o README do projeto indica como requisito mínimo 4 GB de VRAM e 8 GB de RAM do sistema, usando o seu streaming assíncrono de pesos. O descarregamento acrescenta tempo a cada passo, por isso uma placa de 6 GB aproxima-se mais de um minuto por imagem do que de trinta segundos. Com 8 GB, o modelo base cabe e a renderização decorre sem limitações relevantes. Com 12 GB, pode manter um ou dois ControlNet juntamente com o checkpoint sem descarregar dados. Com 24 GB, pode executar o SDXL, o refiner e o upscaling no mesmo workflow, além de treinar adaptadores LoRA com memória disponível. O treino requer menos do que isso: o guia de treino do SDXL para o trainer kohya-ss sd-scripts indica que o treino de LoRA pode ser feito com 8 GB de memória GPU, recomendando 10 GB. Para isso, o guia manda treinar apenas o U-Net, ativar o gradient checkpointing, colocar em cache as saídas do text encoder e os latents, usar um otimizador de 8 bits ou Adafactor e reduzir o LoRA dim para 4 a 8 numa placa de 8 GB. O guia de LoRA da GUI kohya_ss, que encapsula esses scripts, é mais cauteloso: recomenda uma GPU com pelo menos 12 GB de memória para o treino de LoRA.

O que uma VPS com CPU pode e não pode fazer

Ela pode fazer mais do que se espera e menos do que o marketing sugere. Seja específico sobre esse limite.

Uma VPS com CPU pode instalar o ComfyUI, disponibilizar a interface web, armazenar a sua biblioteca de modelos, executar a fila e gerar imagens sem qualquer GPU. Com o Stable Diffusion 1.5 a 512x512 e 20 passos, espere cerca de 60 a 150 segundos por imagem em 8 vCPUs modernas com 16 GB de RAM. Para uma tarefa em lote executada durante a noite ou para um endpoint de imagens de baixo volume atrás de uma fila, isso é perfeitamente aceitável.

Uma VPS com CPU não permite trabalho interativo. Iterar prompts significa fazer vinte renderizações numa hora; a treze minutos por imagem, conseguirá fazer quatro. Também não permite treinar modelos. O fine-tuning de LoRA em CPU demora dias, não horas, por isso deve ser considerado indisponível.

A regra de memória para execução apenas em CPU é diferente da regra para GPU. Os pesos são carregados na RAM do sistema, por isso precisa do tamanho do modelo mais espaço de trabalho: cerca de 16 GB de RAM para SDXL e cerca de 8 GB para SD 1.5. Uma máquina com 4 GB inicia o ComfyUI e depois é terminada pelo out-of-memory killer durante a primeira renderização. O processo desaparece com Killed em dmesg, sem traceback do Python.

Instalar o ComfyUI numa máquina com GPU

Estes são os comandos do projeto. Comece por uma instalação limpa do Ubuntu 24.04, com o driver NVIDIA já instalado. Confirme primeiro o driver, porque sem esta verificação todas as falhas seguintes parecem iguais.

nvidia-smi

O comando deve mostrar uma tabela com a sua placa e uma versão do CUDA. command not found ou NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver significa que o driver está em falta ou que o módulo do kernel não foi carregado depois de uma atualização. Corrija isso antes de continuar, porque o ComfyUI passará silenciosamente a usar a CPU e o problema será atribuído ao software.

sudo apt update
sudo apt install -y git python3-venv python3-pip wget
git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
python3 -m venv venv
. venv/bin/activate
pip install torch torchvision torchaudio --extra-index-url https://download.pytorch.org/whl/cu130
pip install -r requirements.txt

O ambiente virtual não é opcional. O PyTorch instala uma árvore extensa de dependências. Instalá-lo globalmente num servidor que executa outros serviços pode quebrar esses serviços. Confirme que o PyTorch consegue detetar a placa antes de avançar.

python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"

True seguido do nome da sua placa significa que a pilha está a funcionar. False significa que o wheel instalado não é compatível com o driver, normalmente porque já estava em cache um wheel do torch apenas para CPU. Reinstale usando o URL do índice acima.

Obtenha um modelo e planeie o espaço em disco

O ComfyUI não inclui pesos. Coloque os checkpoints em models/checkpoints, os ficheiros VAE em models/vae e os adaptadores LoRA em models/loras.

cd ~/ComfyUI/models/checkpoints
wget https://huggingface.co/stabilityai/stable-diffusion-xl-base-1.0/resolve/main/sd_xl_base_1.0.safetensors

Prefira sempre .safetensors a .ckpt. Um ficheiro .ckpt é um objeto Python serializado com pickle, e carregá-lo executa código de quem o criou. O formato safetensors contém apenas tensores, por isso um ficheiro malicioso não consegue executar nada.

O armazenamento é um custo que muitas pessoas esquecem. Um checkpoint base SDXL ocupa 6.94 GB. O refiner ocupa mais 6 GB. Um modelo SDXL ControlNet ocupa entre 320 MB para o modelo Canny pequeno e 2.5 GB para o modelo completo com precisão half. Um upscaler é pequeno: o modelo padrão Real-ESRGAN x4plus ocupa 67 MB, o modelo para anime ocupa 17.9 MB e o modelo para vídeo de anime ocupa 2.5 MB. Uma LoRA varia entre dezenas de megabytes e 787 MB no caso dos adaptadores Hyper-SDXL da ByteDance. Quem gosta deste tipo de trabalho descarrega um segundo e um terceiro modelo base na primeira semana. Reserve 100 GB de disco para uma instalação funcional e monitorize também o diretório de saída: ficheiros PNG com 1024x1024 ocupam 1 a 2 MB cada, e um lote não supervisionado pode encher silenciosamente um disco pequeno. Coloque models/ e output/ num volume que possa aumentar e faça cópias de segurança dos ficheiros JSON dos workflows com algo como cópias de segurança incrementais e encriptadas para armazenamento de objetos. Os pesos podem ser descarregados novamente. Os workflows que afinou não podem.

Execute e aceda com segurança

cd ~/ComfyUI
. venv/bin/activate
python main.py --listen 127.0.0.1 --port 8188

O ComfyUI disponibiliza o serviço na porta 8188. Num sistema apenas com CPU, adicione --cpu. Esta opção força o processamento pela CPU em vez de falhar por não encontrar um dispositivo CUDA.

Associe o serviço a 127.0.0.1, e não a 0.0.0.0. O ComfyUI tem agora contas de utilizador, mas nenhuma delas protege o seu servidor. O início de sessão em Settings, na secção User, autentica-o numa conta Comfy e funciona numa instalação local: a documentação do Comfy indica o início de sessão por email, Google, GitHub e chave de API. A documentação descreve essa conta como o acesso a nós de parceiros e subscrições Comfy Cloud. Nada nela indica que seja uma forma de proteger o seu próprio servidor com palavra-passe. A opção --multi-user ativa apenas o armazenamento por utilizador: em outubro de 2026, o servidor obtém o nome do utilizador de um cabeçalho de pedido comfy-user e não verifica nenhuma palavra-passe. Qualquer origem que alcance a porta pode colocar tarefas na fila, ler todas as imagens que gerou e, se iniciou o serviço com --enable-manager, instalar nós personalizados. Isso permite executar código arbitrário no seu servidor. Aceda ao serviço através de um túnel SSH a partir do seu portátil.

ssh -N -L 8188:127.0.0.1:8188 you@your-server

Depois, abra http://127.0.0.1:8188 localmente. Se precisar de acesso real para vários utilizadores, coloque um reverse proxy com autenticação à frente do serviço e mantenha a aplicação associada a localhost. O mesmo princípio aplica-se a qualquer serviço self-hosted sem autenticação. Este é o padrão habitual em implementações do Docker Compose num VPS.

Mantenha-o em execução com systemd

Uma fila de renderização que termina quando a sessão SSH é fechada não é um serviço. Execute-a como um utilizador comfy sem login, e não como o seu próprio utilizador: os nós personalizados são código, e esse código não deve ter acesso ao seu diretório pessoal. Crie o utilizador e mova a instalação para o respetivo diretório pessoal:

sudo useradd --system --create-home --home-dir /home/comfy --shell /usr/sbin/nologin comfy
sudo mv ~/ComfyUI /home/comfy/
sudo chown -R comfy:comfy /home/comfy/ComfyUI

O ambiente virtual continua a funcionar depois da mudança, porque a unidade chama diretamente o seu python. Em seguida, escreva /etc/systemd/system/comfyui.service.

[Unit]
Description=ComfyUI
After=network-online.target

[Service]
User=comfy
WorkingDirectory=/home/comfy/ComfyUI
ExecStart=/home/comfy/ComfyUI/venv/bin/python main.py --listen 127.0.0.1 --port 8188
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now comfyui
systemctl status comfyui

active (running) e uma linha de log com To see the GUI go to: http://127.0.0.1:8188 significam que o serviço está ativo. Tenha em atenção que ExecStart especifica diretamente o interpretador dentro do ambiente virtual, porque o systemd não executa o seu perfil de shell e activate nunca acontece.

A recomendação prática por orçamento

Se quer experimentar a geração de imagens e o custo é mais importante do que a velocidade, escolha um VPS com CPU e 16 GB de RAM, execute SD 1.5 a 512x512 e aceite esperar um ou dois minutos por imagem. Este é o ponto de entrada realista e custa uma fração de qualquer opção com GPU dedicada. Também é o local adequado para alojar a biblioteca de modelos e os workflows enquanto decide.

Se itera diariamente nos prompts, alugue por hora uma GPU com pelo menos 12 GB de VRAM numa cloud de GPU e desligue-a quando parar. A geração de imagens é uma carga de trabalho intermitente, e manter uma GPU ociosa com faturação mensal é a forma mais comum de gastar demasiado neste contexto. Mantenha os checkpoints num armazenamento de blocos económico e monte-o.

Se serve outras pessoas ou treina regularmente adaptadores LoRA, planeie 24 GB de VRAM e uma máquina que mantenha ligada. O guia de SDXL do sd-scripts indica que o treino de LoRA pode ser feito com 8 GB, recomendando 10 GB, quando são usadas as definições de poupança de memória. O guia de LoRA da GUI kohya_ss exige pelo menos 12 GB. O valor de 24 GB no guia do sd-scripts refere-se ao fine-tuning completo de SDXL com batch size 1. Assim, uma placa com 24 GB suporta o trabalho com LoRA e mantém o fine-tuning ao alcance. Nesse ponto, a mesma máquina normalmente também compensa ao executar um modelo de linguagem local, que é a configuração descrita em alojar um LLM próprio com Ollama.

Seja qual for o nível escolhido, meça a sua própria máquina antes de confiar em qualquer valor publicado. Coloque o mesmo prompt na fila cinco vezes e leia os segundos por iteração que o ComfyUI apresenta na consola. Esse valor indica a sua posição real na escala.

FAQ

Posso executar Stable Diffusion sem uma GPU?

Sim. O ComfyUI é executado com python main.py --cpu e gera imagens reais sem uma placa gráfica. Conte com cerca de 60 a 150 segundos por imagem para Stable Diffusion 1.5 a 512x512 e com dez a vinte minutos para SDXL a 1024x1024, usando 8 vCPUs modernas. Isto funciona para lotes executados durante a noite e endpoints de baixo volume. Não funciona para iterar prompts, e o treino fica completamente fora de alcance.

De quanta VRAM preciso para SDXL?

8 GB executam o SDXL confortavelmente a 1024x1024. Abaixo disso, o ComfyUI transfere automaticamente os pesos do modelo para a RAM do sistema e continua a funcionar. Em outubro de 2026, o README indica um mínimo de 4 GB de VRAM e 8 GB de RAM do sistema, e cada etapa transferida acrescenta tempo de execução. 12 GB permitem manter um ControlNet juntamente com o checkpoint, e 24 GB cobrem o modelo base, o refiner e o upscaling num único workflow. O guia dos sd-scripts do kohya-ss indica que o treino de LoRA para SDXL pode ser feito com 8 GB, recomendando 10 GB, se utilizar as definições de poupança de memória. O guia de LoRA da GUI do kohya_ss pede pelo menos 12 GB. O fine-tuning completo do SDXL precisa de 24 GB com batch size 1.

De quanto espaço em disco precisam os modelos?

O checkpoint base do SDXL ocupa sozinho 6.94 GB, e o refiner acrescenta cerca de 6 GB. Os modelos ControlNet do SDXL ocupam entre 320 MB e 2.5 GB cada com half precision, os adaptadores LoRA ocupam entre algumas dezenas de megabytes e 787 MB, e os upscalers Real-ESRGAN ocupam entre 2.5 MB e 67 MB. Reserve 100 GB para uma instalação funcional com alguns modelos base e monitorize o diretório de saída separadamente, porque os ficheiros PNG 1024x1024 ocupam entre 1 e 2 MB cada.

É seguro expor o ComfyUI na Internet pública?

Não. O início de sessão da conta Comfy nas definições do ComfyUI funciona numa instalação local, mas dá acesso aos partner nodes e às subscrições cloud da Comfy. Nenhuma documentação da Comfy o apresenta como proteção para o servidor. O sinalizador --multi-user apenas separa o armazenamento por utilizador, sem validar qualquer palavra-passe. Com o ComfyUI-Manager ativado, a interface instala custom nodes. Estes são código Python executado no servidor, portanto uma porta aberta permite execução remota de código. Faça o bind em 127.0.0.1, aceda através de um túnel SSH com ssh -N -L 8188:127.0.0.1:8188 you@your-server e coloque um reverse proxy com autenticação à frente se mais do que uma pessoa precisar de acesso.

Porque é que o meu render foi terminado sem mensagem de erro?

O desaparecimento do processo com Killed em dmesg, sem traceback do Python, indica o out-of-memory killer do Linux, não um erro do ComfyUI. Num servidor apenas com CPU, os pesos ficam na RAM do sistema. Por isso, o SDXL precisa de cerca de 16 GB e o SD 1.5 de cerca de 8 GB, além do espaço de trabalho. Adicione RAM, adicione swap ou utilize um modelo menor e uma resolução mais baixa.