SDXL local em um laptop de 8 GB: o que quebrou ao atualizar o Stable Diffusion WebUI

Atualizei meu Stable Diffusion WebUI (AUTOMATIC1111, v1.10.1) para trabalhar com modelos SDXL abertos — realistas e sem censura, rodando 100% local — e a instalação das extensões derrubou o startup com um erro de ABI do numpy. Este é o diagnóstico, a correção e o que eu faria diferente.

Ambiente: laptop com RTX 5050 de 8 GB, CUDA 12.8, Python 3.10.6 (pyenv) em um venv próprio, torch 2.11.0.

Rodar modelos abertos em hardware modesto é comum — o relato Making PyTorch & Local ML Work on Modest Hardware: Lessons from a 4GB/8GB Laptop GPU 👤 @theclairvoyantbeing resume bem: a maioria dos tutoriais assume 40 GB de VRAM, mas dá para trabalhar com 8 GB se você respeitar as flags de memória.

As trocas de configuração

1. xformers morto → SDP attention. Meu xformers era compilado para Python 3.10.13 / torch 2.1.2, mas o venv é 3.10.6 / torch 2.11. Em vez de reinstalá-lo, troquei as flags:

# webui-user.sh
export COMMANDLINE_ARGS="--opt-sdp-attention --medvram-sdxl"

O aviso WARNING[XFORMERS]: xFormers can't load C++/CUDA extensions no startup é inofensivo — o WebUI segue com No module 'xformers'. Proceeding without it. e usa o SDP.

2. Modelos SDXL instalados (models/Stable-diffusion/):

Modelo	Papel
RealVisXL V5.0 fp16	Realismo (padrão no config.json)
LUSTIFY v2.0	Estilo sem censura
LUSTIFY v2.0 inpainting	Reparo localizado

O A1111 não tem safety checker — a saída depende apenas do checkpoint carregado, não há filtro escondido do lado do WebUI.

3. Extensões: FaceSwap Lab (com inswapper_128.onnx verificado por SHA1 contra o EXPECTED_INSWAPPER_SHA1 do código) e ControlNet, com modelos Canny e OpenPose em versão fp16/rank256 por causa de disco e VRAM.

O crash: numpy.dtype size changed

Na primeira inicialização, depois de instalar as dependências das extensões:

File ".../modules/processing.py", line 15, in <module>
    from skimage import exposure
ValueError: numpy.dtype size changed, may indicate binary incompatibility.
Expected 96 from C header, got 88 from PyObject

A tentação foi culpar o venv ("não ativei o ambiente?"). Mas o log já mostrava Python 3.10.6 e caminhos dentro de venv/lib/python3.10/site-packages. O venv estava certo.

A causa: durante a instalação de reqs das extensões (mediapipe, ml_dtypes, opencv 5.0, controlnet_aux), o pip subiu o numpy para 2.2.6 — enquanto o webui é fixado em numpy==1.26.2 e o scikit-image==0.21.0 é compilado contra a ABI do numpy 1.x. Checkpoints de descritor do numpy 2 têm outro tamanho; daí o erro de "binary incompatibility" no import.

Correção:

./venv/bin/pip install --force-reinstall --no-deps numpy==1.26.2

Como o requirements_versions.txt já obriga numpy==1.26.2 a cada launch, o pip não sobe o numpy de novo sozinho.

A segunda mina: protobuf

O pip check imediatamente acusou outra coisa: o webui fixa protobuf==3.20.0, mas o onnx 1.22 (via insightface do FaceSwap Lab) exige protobuf>=4.25.1, e a própria extensão pedia protobuf>=3.20.2. Sem intervir, cada launch faria ping-pong: webui baixava para 3.20.0, extensão subia de novo.

Solução: editar o pin no próprio repositório:

- protobuf==3.20.0
+ protobuf==4.25.3  # onnx>=4.25 (insightface/faceswaplab); compatível com open-clip

Ruído do pip check ≠ quebra real

Depois das correções restaram três avisos, e todos foram testados antes de aceitar:

• open-clip-torch declara protobuf<4 → testei import open_clip com protobuf 4.25.3: funciona (é um piso/ teto conservador).
• opencv 5.0 declara numpy>=2 → rodei operações reais (cvtColor, imencode) com numpy 1.26.2: funciona.
• xformers declara torch==2.1.2 → já contornado pelas flags.

A lição: nem restrição declarada é quebra real — confirme com imports e operações de verdade, não só com pip check.

Verificação final

./venv/bin/python - <<'EOF'
import numpy; print("numpy", numpy.__version__)
from skimage import exposure; print("skimage OK")
import cv2, google.protobuf, mediapipe, onnx, onnxruntime, insightface
import open_clip, torch
print("torch", torch.__version__, "| cuda:", torch.cuda.is_available())
EOF

Tudo verde: numpy 1.26.2, protobuf 4.25.3, torch 2.11.0+cu128, CUDA disponível.

O que eu faria diferente

1. Instalar as extensões ANTES de validar o ambiente, ou rodar pip check + imports logo após a primeira inicialização — o crash veio de uma dependência nova, não do core.
2. Ler o requirements_versions.txt do webui primeiro: ele é a autoridade que reafirma os pins a cada launch; brigar contra ele é o que gera o ping-pong de versões.
3. Não confiar no pip check cegamente nos dois sentidos: ele acusa conflitos que funcionam e silencia problemas de runtime.

Leituras que ajudaram

• 50. Virtual Environments: Why Your Projects Keep Breaking Each Other 👤 @yakhilesh — o ciclo "atualiza o numpy p/ projeto B e quebra o projeto A" é o mesmo que acontece dentro de um único venv; a saída é fixar a versão autoritativa.
• pip Version Specifiers — What ==, >=, and ~= Actually Commit You To 👤 @susumun — == compra reprodutibilidade e >= compra atualizações automáticas; nosso numpy==1.26.2 e o bump deliberado do protobuf escolheram lados diferentes cada um.

---

Post rascunhado com ajuda de um agente de IA (divulgação "some_ai" no DEV).