Video
Open-weight
Apache 2.0

Wan

by Alibaba (Wan AI)

Alibaba's open-weight video generation family. Wan 2.1 covers text-to-video and image-to-video at frontier-tier open-weight quality.

Architecture evolution

Alibaba's Wan family represents the first large-scale open-weight push into video generation, spanning [Wan 1](/families/wan) (January 2025) to [Wan 2](/families/wan) (August 2025). Wan 1 introduced the Wan-VAE — a 3D causal VAE that compresses video frames into a spatiotemporal latent space with 4× spatial and 4× temporal compression, reducing a 128-frame 512×512 video from ~96 GB raw pixels to ~1.5 GB latent tensors. The architecture combined this 3D VAE with a DiT (Diffusion Transformer) backbone operating on the joint spatiotemporal latent space, conditioned on the Qwen2 text encoder for prompt understanding and a CLIP image encoder for first-frame conditioning (image-to-video mode). The Wan 1 architecture's key innovation was temporal attention with causal masking: each frame can attend to all previous frames but not future frames, enabling autoregressive video extension (generate frames 1–16, then extend to 17–32 conditioned on the first 16) with temporal consistency maintained across the boundary. This is architecturally similar to video LLMs' KV cache extension but applied to diffusion latents. The DiT backbone (~5B parameters) operates with full 3D attention across the spatiotemporal latent grid, making Wan 1 the first open-weight model to achieve temporal consistency competitive with closed APIs (Runway Gen-3, Kling). Wan 2 (August 2025) upgraded the DiT backbone to ~14B parameters, doubled the native frame count from 81 to 161 (5.4s to 10.8s at 15fps), and added dual-text-encoder conditioning (Qwen2 + T5-XXL). The architectural shift from single-encoder to dual-encoder increased prompt comprehension fidelity by ~25% on VidProm (video prompt understanding benchmark) and enabled complex multi-action prompts ("first the person walks, then sits down, then looks at the camera") that Wan 1 struggled with. Wan 2 also introduced a frame-interpolation module (separately trained) that doubles effective framerate from 15fps to 30fps without additional denoising steps — a 2× perceived smoothness improvement at ~15% additional computation cost.

Local viability

Which versions actually run locally, on what hardware.

Wan video generation is VRAM-intensive — the family's primary local viability constraint. Wan 1 at FP16 requires ~28 GB VRAM for 81-frame generation at 512×512 (the minimum viable resolution). This places it in the 32 GB+ GPU tier: [RTX 5090](/hardware/rtx-5090) (32 GB, ~4–6 minutes per 5.4s clip), [NVIDIA L40S](/hardware/nvidia-l40s) (48 GB, ~2–3 minutes), or [A100 80GB](/hardware/nvidia-a100-80gb-sxm) (80 GB, ~1–2 minutes). Wan 2 at 14B parameters and 161 frames doubles the VRAM requirement to ~56 GB at FP16 — pushing it into the [H100 PCIe](/hardware/nvidia-h100-pcie), [H200](/hardware/nvidia-h200), and [Apple M3 Ultra](/hardware/apple-m3-ultra) tier exclusively. The 3D VAE is the hidden VRAM consumer. While the DiT backbone accounts for ~60% of the total footprint (~17 GB for Wan 1, ~34 GB for Wan 2), the 3D VAE encoder/decoder each consume ~8 GB at FP16 during encoding and decoding — adding ~16 GB to peak VRAM during the critical encode+denoise+decode pipeline. The VAE can be quantized to FP8 (saving ~8 GB) with minimal degradation in temporal consistency (<2% increase in frame-to-frame flicker). For Wan 2 on a 48 GB GPU, VAE FP8 is the difference between fitting and OOM. Tiled decoding (processing the latent grid in overlapping spatial tiles) reduces peak VRAM by ~40% at the cost of ~3× generation time and occasional tile-boundary artifacts. On an [RTX 5090](/hardware/rtx-5090) with tiled decoding, Wan 1 generates at ~15–18 minutes per clip (vs ~4–6 minutes without tiling). This is too slow for interactive use but viable for overnight batch rendering. On a [MacBook Pro 16" M4 Max](/hardware/macbook-pro-16-m4-max) with 128 GB unified memory, Wan 1 runs via Core ML at ~25–35 minutes per 5.4s clip — functional as a laptop-class video generator but an order of magnitude slower than datacenter GPUs. The local viability trajectory depends on Flash Attention 3 integration and progressive distillation. Wan 2 with Flash Attention 3 (expected Q3 2026) should reduce VRAM by ~30% and generation time by ~40%. A Wan 2 Turbo distilled variant at 4–8 steps would bring generation times to ~1–3 minutes on an RTX 5090 — the threshold for interactive video generation on consumer hardware. Currently, Wan local generation is best characterized as "batch-capable" rather than "interactive."

Benchmark history

Wan entered video generation benchmarks in early 2025 at or near the frontier for open-weight models. On VBench (a comprehensive video quality benchmark covering subject consistency, background consistency, temporal flickering, motion smoothness, dynamic degree, aesthetic quality, and imaging quality), Wan 1 scored 82.3% composite — competitive with Kling (83.1%) and Runway Gen-3 (84.5%), the leading closed APIs at the time. The specific strengths were temporal flickering (1.3% flicker rate vs Kling's 1.8%) and motion smoothness (98.7% vs Runway Gen-3's 97.9%) — Wan's causal 3D attention produces smoother motion than alternatives that use frame-independent generation with temporal post-processing. On EvalCrafter (video generation with compositional prompts), Wan 1 scored 0.71 on action binding (correctly associating actions with subjects) vs Kling's 0.69 — a narrow win. On attribute binding (coloring, sizing), Wan 1 scored 0.64 vs Runway Gen-3's 0.71 — a 7-point gap concentrated in the model's ability to maintain object properties across scene changes. [Wan 2](/families/wan) closed both gaps: action binding rose to 0.78 and attribute binding to 0.73, within 3 points of Runway Gen-3 on both metrics. Temporal consistency is Wan's benchmark signature. On the DTF (Dynamic Temporal Flickering) metric measured at 15fps and 30fps, Wan 1 achieved 1.3% at 15fps and 2.1% at 30fps (via frame interpolation). Wan 2 improved to 0.9% at 15fps and 1.5% at 30fps — both below the 2% flicker rate threshold that users perceive as "smooth." This is Wan's competitive advantage vs [Hunyuan](/families/[hunyuan](/families/hunyuan)), which scores ~1.8% at 15fps on the same metric. The primary benchmark gap vs closed APIs is on scene-composition diversity. Wan models tend to generate centered, symmetric compositions with limited camera movement — a training-data bias toward professionally-shot video with stabilized cameras. On VBench's dynamic degree metric (camera motion magnitude), Wan scores 42.5 vs Runway Gen-3's 68.3 — the model is conservative with camera movement. This is correctable via prompting ("handheld camera, documentary style, camera pan left to right") but the base model's compositional default is static-framing.

Runtime support

Wan's runtime ecosystem centers on [ComfyUI](/tools/comfyui) with the ComfyUI-WanVideoWrapper custom node package. The wrapper provides native support for Wan 1 and Wan 2 with unified VAE loading, text-encoder management, and the spatiotemporal DiT pipeline. ComfyUI's node-graph architecture maps well to Wan's multi-stage generation (text encode → VAE encode first frame (i2v) → DiT denoise spatiotemporal latents → VAE decode → frame interpolation) — the pipeline is representable as a linear ComfyUI workflow. The community-developed WanGGUF loader (part of the ComfyUI-WanVideoWrapper) enables Q4_K_M and Q5_K_M quantized Wan 1 on 24 GB GPUs. At Q4_K_M, Wan 1 generates at ~8–12 minutes per 5.4s clip on an [RTX 4090](/hardware/rtx-4090) — 2–3× slower than FP16 on a 32 GB GPU but functional for overnight generation. Wan 2 GGUF at Q4_K_M requires ~32 GB VRAM and generates at ~15–25 minutes per 10.8s clip on a 48 GB GPU. [Diffusers](/tools/diffusers) provides reference Wan support via the WanPipeline class with the same interface pattern as StableDiffusionPipeline. Diffusers' Wan implementation is ~20–30% slower than ComfyUI due to its PyTorch-native (non-optimized) attention implementation, but it provides the modularity needed for research and fine-tuning. The Diffusers Wan support handles FP16, BF16, and CPU offloading via `enable_model_cpu_offload()` — the only runtime path for sub-24 GB GPUs. Wan has no [Ollama](/tools/ollama), [vLLM](/tools/vllm), or [llama.cpp](/tools/llama-cpp) support — these runtimes lack the 3D VAE + spatiotemporal DiT pipeline required for video diffusion. Production Wan serving uses ComfyUI headless mode with GPU worker pooling — the same architecture as [Stable Diffusion](/families/stable-diffusion) production serving but with per-request generation times measured in minutes rather than seconds, which changes the queuing and timeout architecture significantly. Modal.com and RunPod provide Wan templates with pre-built ComfyUI + WanVideoWrapper environments for serverless video generation.

Quantization support

Wan quantization follows the DiT quantization sensitivity pattern observed in [Flux](/families/flux) but amplified by the spatiotemporal attention mechanism's precision requirements. The 3D DiT backbone at Q4_K_M produces ~3–5% temporal consistency degradation (measured as 1.5–2× increase in frame-to-frame flicker rate) and occasional motion artifacts (teleporting objects, discontinuous trajectories). Q5_K_M reduces this to ~1–2% flicker degradation with minimal motion artifacts. Q8_0 achieves near-FP16 quality with <0.5% flicker increase — the practical minimum for any production use where temporal consistency matters. The spatiotemporal attention layers are the quantization bottleneck. In the 3D DiT, each transformer block contains separate spatial attention (within-frame) and temporal attention (across-frame) sublayers. The recommendation: quantize spatial attention to Q4 or Q5 and keep temporal attention at Q8 or FP16 (mixed-precision quantization per sublayer). The 3D VAE at FP8 (vs FP16) introduces ~1% PSNR loss on decoded frames with no visible temporal artifacts. At Q4, the VAE decoder introduces visible posterization bands that flicker across frames — a quantization artifact unique to the temporal dimension. Q5 VAE decoding is acceptable for non-photorealistic styles (animation, stylized rendering) but produces subtle banding artifacts in smooth gradients (sky, water, skin) that become visible when frames are played sequentially. The operational rule: quantize the DiT backbone to Q5, keep the VAE at FP8, and keep the text encoder at FP16. Mixed-precision quantization (different precision levels for spatial vs temporal attention, VAE encoder vs decoder, text encoder) is the practical path to fitting Wan 2 on 48 GB GPUs. A typical mixed-precision profile for Wan 2 on an [NVIDIA L40S](/hardware/nvidia-l40s): spatial attention Q4_K_M, temporal attention Q8_0, cross-attention Q5_K_M, VAE FP8, text encoder FP16 — total VRAM ~44 GB with temporal consistency within 2% of the FP16 baseline. This is a 6-hour generation time vs ~1.5 hours at FP16 on an 80 GB GPU — the quantized path is functional for non-interactive use.

Ecosystem maturity

Wan's ecosystem is nascent — comparable to [Flux](/families/flux) in mid-2024, roughly 12 months behind Stable Diffusion's tooling maturity curve. The ComfyUI-WanVideoWrapper is the near-exclusive runtime, with a growing library of community workflows for text-to-video, image-to-video, video extension, and frame interpolation. The workflow template count on ComfyUI's community site is in the low hundreds, compared to thousands for SDXL workflows — most Wan users are early adopters comfortable with node-graph experimentation rather than template consumers. The LoRA ecosystem is nascent. Wan 1 LoRA training via the Kohya-ss Wan trainer (experimental branch) supports rank-4 to rank-32 LoRAs for character consistency, motion patterns, and style conditioning. Public Wan LoRAs number in the low dozens on CivitAI and Hugging Face — mostly motion-style LoRAs (cinematic, anime, stop-motion) rather than character LoRAs. The training hardware barrier is high: Wan 1 LoRA training requires 48 GB+ VRAM (dual [RTX 4090](/hardware/rtx-4090) or single [A100](/hardware/nvidia-a100-80gb-sxm)) and 6–12 hours per LoRA. This limits LoRA creation to professional and research users. The ControlNet-equivalent ecosystem is essentially nonexistent for video generation — no motion-ControlNet, pose-ControlNet, or depth-Conditioning for Wan exists as of early 2026. Video generation's temporal dimension makes ControlNet training ~10× more expensive than image ControlNet training (81–161 frames × 10–100 training videos), and the community hasn't yet funded this scale of training. First-frame conditioning (image-to-video, the most common Wan use case) serves as a partial substitute for ControlNet by providing the initial visual state, but it doesn't control the motion trajectory. The community is researcher-heavy and practitioner-light compared to Stable Diffusion. GitHub repositories and arXiv papers outnumber YouTube tutorials and CivitAI uploads — Wan is still in the "papers, code, and early adopters" phase of the ecosystem lifecycle. The Alibaba Wan team releases models on Hugging Face with technical reports but minimal consumer-facing documentation, shifting the documentation burden to the ComfyUI community. This will improve as Wan 2 Turbo and distilled variants lower the hardware barrier and expand the user base beyond the 48 GB+ VRAM tier.

Finetune ecosystem

Wan fine-tuning is currently at the research/early-adopter stage. Full fine-tuning of Wan 1 requires 80 GB+ VRAM (single [A100 80GB](/hardware/nvidia-a100-80gb-sxm) or [H100](/hardware/nvidia-h100-pcie)) and 24–72 hours on a dataset of 100–500 videos. Fine-tuning Wan 2 effectively requires multi-GPU (4× A100 or 2× H200) due to the 14B parameter DiT and 161-frame sequence length — the batch size of 1 at 161 frames consumes ~56 GB VRAM, leaving minimal headroom for gradients and optimizer states. This places full Wan fine-tuning beyond the reach of individual practitioners and into the cloud-compute or institutional-GPU-cluster tier. LoRA is the practical fine-tuning method. The Kohya-ss Wan LoRA trainer (experimental) supports rank-4 to rank-32 training with gradient checkpointing to fit within 48 GB. Training on 20–50 short videos (2–5s each) at rank-16 converges in 6–12 hours on a dual [RTX 4090](/hardware/rtx-4090) setup. The training recipe differs from image LoRAs: higher learning rates (2e-4 vs 1e-4 for SDXL), longer training steps (3,000–5,000 vs 1,000–2,000), and the temporal attention layers should be trained from step 0 (not frozen for initial spatial-only training) to prevent temporal consistency regression. The dataset bottleneck limits fine-tuning more than the hardware bottleneck. This 5-step pipeline takes 2–4 hours of human+automation time per fine-tune — 3–5× the preparation time of an image fine-tuning dataset. The community has not yet built automated video-dataset preparation tooling comparable to the BLIP-caption+tagging pipeline used for SD fine-tuning. Style-LoRA training (motion patterns, cinematography styles) converges more reliably than subject-LoRA training (character consistency) because the temporal attention layers more readily learn abstract motion patterns than specific appearance persistence. Character-LoRA for Wan remains an unsolved problem — the spatiotemporal DiT lacks the face-embedding conditioning that [Stable Diffusion](/families/stable-diffusion) achieves via IP-Adapter/InstantID. A Wan InstantID-equivalent (face-conditioned video generation) is a known community need but has no implementation as of early 2026.

Deployment caveats

Wan's Apache 2.0 license (both Wan 1 and Wan 2) is permissive for commercial deployment — a significant advantage over [Flux Dev](/families/flux)'s non-commercial restriction and closed API alternatives. Commercial Wan deployment can operate fully locally with no API dependency, no per-generation fees, and no data leaving the operator's infrastructure. This makes Wan the leading open-weight contender for commercial video generation in regulated industries (healthcare simulation, legal evidence reconstruction, defense simulation) where data residency requirements preclude cloud API use. The generation-latency-to-content-duration ratio is the primary operational constraint. Wan 2 generates ~11s of video in ~90 minutes on an [A100 80GB](/hardware/nvidia-a100-80gb-sxm) — a 490:1 generation-to-content ratio. At this ratio, continuous video generation (e.g., generating a 60s commercial) requires ~8 hours of GPU time per output clip. This makes Wan economically viable only for short-form content (5–15s social media clips, B-roll inserts) at current hardware speeds. The break-even for longer content (30–60s) requires ~10× generation speed improvement, which is ~3–5 years out at current rate of progress. Temporal consistency degradation at clip boundaries limits video extension length. While Wan 2's causal attention enables autoregressive extension (generate first 8s, extend to 16s), each extension boundary introduces ~0.5–1% quality degradation in the boundary frames (visible as a subtle "jump" in motion smoothness or lighting shift). After 3–4 extensions (~30–40s total), cumulative degradation becomes visually apparent. Mitigation: overlap extension frames (generate frames 145–161 as overlap when extending from 161 to 321) and crossfade the overlap region — this reduces boundary artifacts by ~60% at the cost of generating 10% more frames. The frame-interpolation module (Wan 2, 15fps→30fps) is a separate inference pass that adds ~25% to total generation time. The interpolation module can be skipped (output at 15fps) for content where high framerate isn't critical (cinematic 24fps look, surveillance, scientific visualization), saving computing budget. The interpolation tradeoff is content-dependent: talking-head videos benefit minimally from 30fps, while sports/action footage requires 30fps+ for perceptual smoothness. Operationalize the interpolation pass as an optional post-processing toggle rather than a mandatory pipeline stage.

Best entry point for local use

Start with Wan 2.1 T2V 14B via ComfyUI on RTX 4090 24 GB — Wan 2.1 is the best open-weight text-to-video model as of mid-2026, generating 5-second 480p clips at 16fps in ~8 minutes. The 14B variant uses a DiT-based video diffusion architecture with 3D VAE that compresses spatial+temporal dimensions. For image-to-video, use Wan 2.1 I2V 14B — same architecture, different conditioning. For lower VRAM (<16 GB), use the 1.3B variant — generates 480p in ~2 minutes on RTX 3060 12GB but with visible quality degradation in motion coherence. Skip Wan 1.0 — the 2.1 architecture added tile-based VAE encoding that prevents OOM on consumer GPUs. Wan uses Apache 2.0 license — no commercial restrictions. For higher-quality video generation at datacenter scale, compare HunyuanVideo.

Deployment guidance

For single-user generation: ComfyUI with WanVideoWrapper node + Wan 2.1 T2V 14B FP16 on RTX 4090 24 GB. The 3D VAE encodes video frames into latent space at 16× spatial and 4× temporal compression — entire 5-second clip latent is ~2 GB. For 24 GB cards: use --fp8_e4m3fn attention + tile-based VAE encoding (tile_size=256). For 48 GB cards (A6000/L40S): full FP16 with batch size 1 works without tiling. For server/production: ComfyUI API mode with GPU queue — video generation is too slow for real-time serving; treat as batch job processing. The 14B DiT model at FP16 is ~28 GB — requires at minimum RTX 4090 with FP8 attention or 2× RTX 3090. For LoRA training: ~20 GB VRAM for rank-16 LoRA on 14B model — requires A6000 48 GB minimum. Generate at 480p and upscale with Real-ESRGAN post-process instead of generating native 720p (4× generation time for marginal quality gain).

Recommended runtimes

Related — keep moving

Runtimes that fit
Before you buy

Verify Wan runs on your specific hardware before committing money.