Do Docker ao bare-metal: a odisseia para rodar modelos de difusão na NVIDIA RTX série 50 (Blackwell) no Arch Linux
Voltar para blog

Do Docker ao bare-metal: a odisseia para rodar modelos de difusão na NVIDIA RTX série 50 (Blackwell) no Arch Linux

Atualizado em 20/09/2026 · Publicado em 18/09/2026 · 4 min · Inteligência Artificial

Quem gosta de rodar inteligência artificial generativa localmente sabe que a teoria raramente sobrevive ao primeiro contato com hardware recém-lançado. Recentemente, comecei a usar um notebook equipado com a NVIDIA GeForce RTX 5050 (8GB VRAM) rodando CachyOS (distribuição baseada em Arch Linux com foco em performance).

O plano inicial era direto: subir uma stack do ComfyUI em contêiner via Docker Compose, conectar ao meu fluxo e carregar modelos baseados em SDXL (como Juggernaut XL e Pony Diffusion). No entanto, o que parecia uma configuração de 15 minutos se transformou em uma jornada profunda de compatibilidade de volumes no Docker, arquiteturas de GPU recém-lançadas e bibliotecas dinâmicas do Linux.

Compartilho abaixo o passo a passo desse troubleshooting, os erros nos logs e o caminho definitivo para fazer tudo funcionar.


1. O problema inicial: o vazio em /opt/storage e o mapeamento no Docker#

Ao subir o contêiner do ComfyUI usando a imagem base do AI-Dock (ghcr.io/ai-dock/comfyui:latest-cuda), percebi que, embora eu tivesse colocado meus arquivos .safetensors na pasta mapeada do host (/workspace), a interface WebUI não listava checkpoint nenhum, travando o nó Load Checkpoint em undefined.

Fui inspecionar o contêiner pelo terminal:

docker exec -it comfyui ls -la /opt/storage/stable_diffusion/models/ckpt/
total 0
drwxrwsr-x 1 root ai-dock   0 Sep 26 2024 .
drwxrwsr-x 1 root ai-dock 182 Sep 26 2024 ..
-rw-rw-r-- 1 root ai-dock   0 Sep 26 2024 .gitkeep

O diagnóstico#

O diretório /opt/storage era um caminho isolado do filesystem interno do contêiner e não estava herdando os volumes de /workspace. Ao tentar remover o diretório para criar um link simbólico, o comando falhou devido à presença do arquivo oculto .gitkeep:

docker exec -it comfyui rmdir /opt/storage/stable_diffusion/models/ckpt
rmdir: failed to remove '/opt/storage/stable_diffusion/models/ckpt': Directory not empty

Limpei o diretório forçadamente e recriei o link apontando para os dados montados:

docker exec -it comfyui rm -rf /opt/storage/stable_diffusion/models/ckpt
docker exec -it comfyui ln -s /workspace/stable_diffusion/models/ckpt /opt/storage/stable_diffusion/models/ckpt

Mesmo com os arquivos acessíveis, a interface do ComfyUI continuava sem listar os modelos ao recarregar, revelando que a aplicação buscava os checkpoints diretamente em /opt/ComfyUI/models/checkpoints. No AI-Dock, é importante antes inspecionar se /opt/ComfyUI/models/checkpoints é na verdade um symlink para /opt/storage/... via docker exec comfyui ls -la /opt/ComfyUI/models/.

Para tornar essa montagem persistente a recriações do contêiner (docker compose down), apliquei um bind mount direto no docker-compose.yml:

services:
  comfyui:
    image: ghcr.io/ai-dock/comfyui:latest-cuda
    container_name: comfyui
    ports:
      - "8188:8188"
    volumes:
      - ./comfyui:/workspace
      - ./comfyui/stable_diffusion/models/ckpt:/opt/ComfyUI/models/checkpoints
    environment:
      - WEB_ENABLE_AUTH=false
      - NVIDIA_VISIBLE_DEVICES=all
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:true
      - TORCH_CUDA_ARCH_LIST=12.0+PTX
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: always

2. A barreira de hardware: CUDA error: no kernel image is available for execution#

Com os arquivos finalmente indexados e selecionados no nó Load Checkpoint, executei o fluxo clicando em Queue Prompt. Imediatamente, o nó CLIPTextEncode falhou em vermelho:

CUDA error: no kernel image is available for execution on the device
CUDA kernel errors might be asynchronously reported at some other API call.

O diagnóstico da arquitetura Blackwell#

A RTX 5050 é baseada na arquitetura NVIDIA Blackwell (Compute Capability 12.0).

As imagens Docker pré-construídas vêm empacotadas com versões do PyTorch compiladas para CUDA 12.1 ou 12.4 antes do lançamento da série 50. Como essas compilações antigas não continham as instruções de kernel binárias para Blackwell, o PyTorch falhava no exato momento de descarregar os tensores na GPU.

Atualizar o PyTorch dentro do contêiner esbarrava em múltiplos ambientes Python virtuais mascarados por scripts de inicialização internos. A solução mais limpa foi pivotar: abandonar a camada de abstração do Docker e rodar nativamente (bare-metal) aproveitando os pacotes atualizados do CachyOS / Arch Linux.


3. A tentativa bare-metal e a armadilha do Python 3.14#

Clonei o repositório do SD-WebUI-Forge para rodar localmente via webui.sh:

git clone https://github.com/lllyasviel/stable-diffusion-webui-forge.git ~/ai-tools/stable-diffusion-webui-forge
cd ~/ai-tools/stable-diffusion-webui-forge
./webui.sh

O script falhou imediatamente durante a preparação do ambiente virtual:

This program is tested with 3.10.6 Python, but you have 3.14.6.
ERROR: Could not find a version that satisfies the requirement torch==2.3.1
ERROR: No matching distribution found for torch==2.3.1

O CachyOS mantém seus repositórios no estado da arte, já rodando o Python 3.14. Os scripts legados de Stable Diffusion exigem versões antigas e rígidas do PyTorch (como a 2.3.1), que não possuem pacotes pré-compilados (wheels) para versões tão recentes do Python.


4. O caminho com stabilitymatrix: resolvendo libcrypt.so.1 e uv#

Para isolar os runtimes de IA sem quebrar o Python do sistema, recorri ao StabilityMatrix, um orquestrador que gerencia ambientes portáteis de IA.

Durante a inicialização inicial, o runtime quebrou com erro de biblioteca compartilhada ausente:

System.DllNotFoundException: Could not load libpython3.10.so: libcrypt.so.1: cannot open shared object file: No such file or directory

Além disso, o utilitário portátil de resolução de pacotes Python (uv) também não conseguia ser executado de forma isolada.

Resolução de dependências no Arch / CachyOS#

O ecossistema Arch moderno substituiu a biblioteca legada libcrypt pela libxcrypt. Softwares que dependem de runtimes do Python 3.10 precisam do pacote de retrocompatibilidade:

# 1. Instalar a biblioteca de compatibilidade para binários antigos
sudo pacman -S libxcrypt-compat

# 2. Instalar o gerenciador 'uv' nativamente no sistema
sudo pacman -S uv

Com esses dois pacotes instalados no host, o StabilityMatrix inicializou perfeitamente, baixou o Python isolado necessário e permitiu compilar e rodar o PyTorch com aceleração completa na GPU Blackwell.


Lições práticas para rodar IA em hardware novo#

  1. Atenção aos caminhos em imagens Docker: Imagens pré-montadas de IA frequentemente utilizam árvores de pastas internas não óbvias. Bind mounts explícitos no Docker Compose apontando diretamente para o caminho final da aplicação evitam links simbólicos quebrados.
  2. Placas de vídeo recém-lançadas exigem CUDA moderno: GPUs de arquitetura nova (como a RTX série 50) precisam de PyTorch 2.7 ou superior com wheels CUDA 12.8 (primeiro toolkit com kernels nativos sm_120 para a série RTX 50); CUDA 12.4 ou 12.6 não bastam e falham na execução dos tensores.
  3. Distribuições rolling release precisam de retrocompatibilidade: Em sistemas como Arch Linux e CachyOS, instalar pacotes como libxcrypt-compat e gerenciar ambientes com ferramentas dedicadas como o uv e StabilityMatrix resolve incompatibilidades de versões do Python sem sujar o sistema operacional.

Conclusão#

Neste artigo compartilhei a jornada completa — do bind mount no Docker ao runtime isolado no StabilityMatrix. A combinação que destravou a RTX 5050 foi simples no fim: pacotes do sistema (libxcrypt-compat, uv) somados a um runtime Python isolado gerenciado pelo StabilityMatrix, sem container defasado nem conflitos com o Python do sistema.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.

0 comentários