Infraestrutura Docker multi-container para rodar LTX-2, Wan 2.1, MAGI-1 e Waver no DGX Spark, cada um com sua API REST, carregamento sob demanda e auto-unload.
# build da base, build dos containers e sobe docker build -t videosdgx-base:latest -f common/base.Dockerfile . docker-compose build docker-compose up -d ./scripts/health_check.py
Arquitetura Docker multi-container para o DGX Spark 2026 (128 GB de memória unificada, Blackwell). Cada modelo roda no seu próprio container, com a mesma API REST e quantização otimizada (FP4 / FP8).
LTX-2 (:8001, vídeo+áudio), Wan 2.1 (:8002, 14B versátil), MAGI-1 (:8003, autoregressive para vídeos longos) e Waver 1.0 (:8004, leve para batch).
Todos expõem /health, /ready, /info, /generate, /jobs/{id}, /jobs/{id}/download, /queue/status e /metrics.
Lazy loading (modelo só carrega na 1ª requisição), auto-unload após inatividade e volumes persistentes para modelos e outputs.
Você submete um prompt via POST, recebe um job_id, acompanha o progresso e baixa o vídeo quando o status fica completed. O modelo carrega na primeira chamada e fica em memória para as próximas.
Cada container gerencia sua própria fila; /queue/status mostra a posição e o tempo estimado.
AUTO_UNLOAD_MINUTES descarrega o modelo após X minutos ociosos (0 = nunca). Também dá para forçar com POST /unload.
ComfyUI (recomendado pela NVIDIA) com custom nodes de LTX-2, e a API Python direta da Lightricks via ltx_pipelines.
Docker recente com runtime NVIDIA, GPU com CUDA 12.3+ e bastante disco — os modelos são grandes (LTX-2 sozinho ocupa centenas de GB no volume).
Docker Engine 24.0+, Compose 2.20+ e o runtime NVIDIA configurado.
# testa GPU no Docker docker run --rm --gpus all \ nvidia/cuda:12.3.0-base-ubuntu22.04 nvidia-smi
~100 GB+ só para os modelos. O volume videosdgx_models guarda os pesos baixados.
# cria o volume de modelos docker volume create videosdgx_models
Ajuste o auto-unload e o nível de log antes de subir.
AUTO_UNLOAD_MINUTES=30 LOG_LEVEL=INFO
Build da base, download dos modelos, build dos containers e o primeiro generate.
Imagem compartilhada com CUDA + PyTorch, reusada por todos os containers.
docker build -t videosdgx-base:latest -f common/base.Dockerfile .
Script interativo, ou download manual via HuggingFace CLI para o volume.
./scripts/download_models.sh # ou manual, ex. LTX-2: huggingface-cli download Lightricks/LTX-Video \ --local-dir /var/lib/docker/volumes/videosdgx_models/_data/ltx2
Builda e sobe os 4 containers em background.
docker-compose build docker-compose up -d
Confere que cada modelo está online nas portas 8001-8004.
./scripts/health_check.py # ● LTX-2 Status: Online Endpoint: http://localhost:8001
POST com o prompt e parâmetros; a resposta traz o job_id.
curl -X POST http://localhost:8001/generate \ -H "Content-Type: application/json" \ -d '{"prompt":"A cat walking on a beach at sunset","duration":5,"resolution":"1024x576","fps":24,"seed":42}'
Consulte o status do job e baixe quando ficar completed.
curl http://localhost:8001/jobs/ltx2-abc12345 curl -O http://localhost:8001/jobs/ltx2-abc12345/download
Scripts de teste e benchmark acompanham o projeto, além de duas abordagens alternativas à arquitetura Docker.
generate_all_videos.py dispara o mesmo prompt para os 4 modelos; check_jobs_status.py monitora os jobs em loop.
./scripts/benchmark.py mede performance de todos os modelos, de um só (--model ltx2) ou em modo rápido (--quick).
Caminho recomendado pela NVIDIA: ative o venv e rode python main.py --port 8188 com os custom nodes de LTX-2 e MAGI-1 já configurados.
A pipeline oficial da Lightricks via python -m ltx_pipelines.distilled gera o MP4 direto da linha de comando, sem container.
A infra Docker e as APIs estão de pé; o carregamento de modelos esbarra em issues conhecidos de ambiente ARM64 + CUDA e pressão de VRAM.
/health saudável e jobs de geração aceitos por todos os modelos.torch.xpu (ARM64+CUDA); MAGI-1 sem model_type no config; VRAM do host saturada.