k8bit/wan2gp repository overview

⁠Wan2GP Docker Deployment

Wan2GP (WanGP) is an open-source AI video generation platform supporting multiple model families including Wan 2.1/2.2, Hunyuan Video, LTX Video, and Flux. It exposes a Gradio web UI on port 7860 and auto-downloads model weights on first use.

GitHub: https://github.com/deepbeepmeep/Wan2GP⁠
Docker Hub: https://hub.docker.com/r/k8bit/wan2gp-cuda⁠

⁠Variants

Two builds are maintained, targeting different GPU architectures:

CUDA (NVIDIA) — k8bit/wan2gp-cuda:latest
Targets RTX-class GPUs. Built on nvidia/cuda:12.4.1-cudnn-runtime-ubuntu22.04 with PyTorch stable CUDA 12.4 wheels. Tested on dual RTX 3090 (24 GB VRAM each). Triton JIT cache is stable and can be persisted across container restarts.

ROCm (AMD) — local build, wan2gp-rocm:latest
Targets RDNA4 and other supported AMD architectures. Built on rocm/dev-ubuntu-22.04:6.4.3 with PyTorch nightly ROCm 6.4 wheels and PYTORCH_ROCM_ARCH=gfx1201. Tested on AMD Radeon AI PRO R9700 (32 GB VRAM). Triton cache must be pointed to a non-persistent path (/tmp/triton-cache) due to ROCm/Triton 3.7.0 .so stale cache issues on restart.

⁠Requirements

⁠NVIDIA (CUDA)

• NVIDIA Container Toolkit installed on the host
• Driver compatible with CUDA 12.4 (driver ≥ 550 recommended)
• Pass --gpus all at runtime
• Set NVIDIA_DRIVER_CAPABILITIES=compute,video,utility

⁠AMD (ROCm)

• ROCm 6.x installed on the host
• Devices /dev/kfd and /dev/dri passed through to the container
• Container must run with GID 18 (the video group): --group-add=18
• --ipc=host, --shm-size=8g, --security-opt seccomp=unconfined are required for ROCm shared memory
• If the host has multiple AMD GPUs (e.g. an integrated 780M alongside a discrete card), set HIP_VISIBLE_DEVICES=0 to restrict PyTorch to the discrete GPU only
• Do not set HSA_OVERRIDE_GFX_VERSION to an empty string — either set it to a valid version or omit it entirely; an empty value breaks GPU initialisation

⁠Volume Mounts

WanGP separates model weights from application source code. The correct mount targets are:

The cache directory (/app/cache) must be created on the host before the container starts. If it doesn't exist, Docker mounts an empty directory over it and HuggingFace's file locking will fail with OS error 17 (EEXIST) when attempting to download models.

⁠Environment Variables

⁠Quantization and VRAM

WanGP offers three quantization modes selectable in the web UI:

• Scaled Int8 (recommended) — best speed/quality trade-off; uses Triton for kernel dispatch
• Scaled Fp8 — lower VRAM than Int8
• 16-bit (no quantization) — highest quality, highest VRAM usage; bypasses Triton entirely

On ROCm with Triton 3.7.0 and ROCm 6.4.3, Scaled Int8 currently falls back to a Quanto software path because hipDrvLaunchKernelEx is not found in libamdhip64.so. Generation still works but is slower. Using 16-bit mode or the Distilled 1.1 model avoids this fallback. This is a Triton/ROCm compatibility issue expected to be resolved in a future ROCm release.

On CUDA with PyTorch stable, all three modes work correctly. RTX 3090 (24 GB VRAM) comfortably runs profile 1 (fastest) with Scaled Int8.

⁠Build

⁠CUDA

# Clone or copy the deployment files alongside the Dockerfiles
chmod +x build-and-deploy-cuda.sh
bash build-and-deploy-cuda.sh

The script:

1. Checks for Docker and nvidia-smi
2. Creates host directories
3. Builds wan2gp-cuda:latest locally
4. Tags and pushes to k8bit/wan2gp-cuda:latest on Docker Hub
5. Runs a GPU smoke-test inside the freshly built container

⁠ROCm

chmod +x build-and-deploy.sh
bash build-and-deploy.sh

Same flow without the Docker Hub push step (ROCm builds are architecture-specific and not published to a public registry).

⁠Running with Docker Compose

# CUDA
docker compose -f docker-compose.cuda.yml up -d
docker compose -f docker-compose.cuda.yml logs -f

# ROCm
docker compose -f docker-compose.rocm.yml up -d
docker compose -f docker-compose.rocm.yml logs -f

The web UI will be available at http://<host-ip>:7860 once WanGP prints Running on local URL.

On first launch WanGP downloads shared model files (~2 GB). The main generation model (Wan 2.1 T2V, ~14 GB) downloads when you first trigger a generation.

⁠Troubleshooting

Container exits immediately on AMD
Check that /dev/kfd and /dev/dri are passed through and that GID 18 is added. Verify with docker logs <container> — look for the torch.cuda (HIP) check output.

ModuleNotFoundError: No module named 'models.wan'
A host directory has been mounted over /app/models. Remove that mount; model weights belong at /app/ckpts.

OS error 17 (EEXIST) during model download
The cache host directory does not exist. Create it before starting the container: mkdir -p <host-cache-path>.

Triton errors on ROCm restart
Stale compiled .so files in a persistent Triton cache. Delete the cache directory contents and ensure TRITON_CACHE_DIR points to /tmp/triton-cache (ephemeral) rather than a persistent volume.

HSA_OVERRIDE_GFX_VERSION set to empty string
Remove the variable entirely. An empty string is parsed as a malformed GFX version override and prevents ROCm GPU detection.

Both AMD GPUs visible, PyTorch fails
Set HIP_VISIBLE_DEVICES=0 to hide the integrated GPU and expose only the discrete card to the container.