Deploy Wan 2.2
VideoWan 2.2 is Alibaba Tongyi Lab's video generation family. The dense 5B variant is the lighter option, while the 14B mixture-of-experts variants target higher-quality text-to-video and image-to-video generation on larger GPUs.
Deploy Wan 2.2 in minutes
Starting at $0.72/hr on dedicated GPU
Available Variants (4)
| Model | GPU | VRAM | Price | Action |
|---|---|---|---|---|
Wan 2.2 5B Text-to-Video 5B Text-to-Video | RTX A6000 | 48 GB | $0.72/hr | Deploy |
Wan 2.2 5B Image-to-Video 5B Image-to-Video | RTX A6000 | 48 GB | $0.72/hr | Deploy |
Wan 2.2 14B Text-to-Video 14B Text-to-Video | A100 80GB PCIe | 80 GB | $1.85/hr | Deploy |
Wan 2.2 14B Image-to-Video 14B Image-to-Video | A100 80GB PCIe | 80 GB | $1.85/hr | Deploy |
Prices include the service fee. Charges follow actual running time.
Requirements
ModelPilot assigns 48–80GB cloud GPUs across the listed variants. Actual local VRAM requirements vary with model variant, precision, quantization, resolution, and workflow settings.
On ModelPilot, deploy on a dedicated cloud GPU (up to 80GB VRAM) starting at $0.72/hr with no setup required.
Compare Wan 2.2
Source-backed GPU, VRAM, and cost comparisons for nearby deployment choices.
Use Cases
- ✓Text-to-video generation
- ✓Image-to-video animation
- ✓Social media content creation
- ✓Product demo videos
Related Models
Known Issues & Fixes
Real failures from running Wan 2.2 and similar pipelines, with the mechanism behind each one.
Over-processed / double-degraded output when a speed LoRA is stacked on an already-distilled checkpoint
Cause: A distill/acceleration LoRA and a pre-distilled checkpoint are alternative acceleration paths — the rule is to disable the distill LoRA whenever the checkpoint is already pre-distilled. Stacking two conflicting few-step schedules degrades output.
Fix: Apply AT MOST ONE acceleration path. Note: base Wan DOES need the lightx2v LoRA for few-step (the correct single path); the double-distill hazard only arises with a pre-merged/FusionX-style Wan checkpoint that already bakes lightx2v/CausVid in.
Over-caution that fp8 degrades quality, so users force bf16 and double VRAM/download for no gain
Cause: fp8_e4m3fn_scaled checkpoints carry per-block scale factors that preserve dynamic range, matching bf16 quality for many modern diffusion/video models at ~half VRAM. Plain (unscaled) fp8_e4m3fn CAN visibly degrade — that's why the scaled repacks exist.
Fix: Prefer the 'scaled' fp8 variant; don't reflexively pick bf16. Do NOT generalize the claim to unscaled fp8.
'Value not in list: gemma_path ... not in []', or the pod hard-exits on a missing tokenizer.model even though you supplied a CLIP/T5
Cause: Newer models replaced CLIP/T5 with a full LLM encoder. LTX-2 19B's LTXVGemmaCLIPModelLoader wants a DIRECTORY encoder: weights come from the non-gated Comfy-Org/ltx-2 repo, but config.json + tokenizer.model come from the GATED google/gemma-3-12b-it repo — without HF token + accepted license the sidecar 403s and the loader sees an empty list.
Fix: Supply HF token + accept the Gemma license so the gated config/tokenizer sidecar downloads into the encoder directory. Note LTX-2.3's default graph instead uses a single-file FP4 encoder (gemma_3_12B_it_fp4_mixed, non-gated, no tokenizer sidecar).
Encoder file is present on disk but the node still errors, or a workflow references a filename you 'basically' have
Cause: Loaders are picky three orthogonal ways: (1) PRECISION — Kijai LoadWanVideoT5TextEncoder wants its own bf16 umt5 build and rejects native ComfyUI's scaled fp8; native CLIPLoader(type=wan) accepts fp8. (2) PACKAGING — LTX LTXVGemmaCLIPModelLoader wants a directory encoder; LTXAVTextEncoderLoader wants a single-file fp4-mixed .safetensors. (3) EXACT NAME — t5xxl_fp8_e4m3fn.safetensors (4.89GB) and t5xxl_fp8_e4m3fn_scaled.safetensors (5.16GB) are distinct, not interchangeable.
Fix: Match the encoder file to the node's precision + packaging + exact filename; fuzzy substitution fails hard.
A .gguf model downloaded fine but doesn't show in the Unet/loader dropdown
Cause: ComfyUI-GGUF's UnetLoaderGGUF reads a dedicated 'unet_gguf' folder key (fed from both unet and diffusion_models). models/unet is the reliably-covered location; the equivalent .safetensors goes in models/diffusion_models.
Fix: Route .gguf diffusion weights to models/unet (canonical, always covered). A GGUF in diffusion_models may not appear depending on ComfyUI/GGUF version — don't rely on it.
Workflow loads only one diffusion model and produces poor/incomplete video; user under-provisions disk expecting one checkpoint
Cause: Wan 2.2 14B uses a two-model expert split — a high_noise AND a low_noise checkpoint (both ~fp8_scaled ~14GB) sampled in sequence. One 'model' is actually two files. (5B variant is a single ti2v model; i2v also needs clip_vision_h.)
Fix: Download BOTH the high_noise and low_noise 14B checkpoints (~28GB disk). VRAM stays ~one expert — they sample sequentially and ComfyUI swaps/unloads between them. Use umt5_xxl (not standard t5xxl or a CLIP); VAE differs by version (5B: wan2.2_vae, 14B: wan_2.1_vae).
Hitting a specific error message? Browse ComfyUI error fixes.
Frequently Asked Questions
How much GPU memory is allocated for Wan 2.2?
The listed ModelPilot variants use 48–80GB cloud GPUs. Local memory needs vary with the variant, precision, quantization, and workflow settings.
How much does it cost to run Wan 2.2?
Starting at $0.72/hr on a dedicated GPU. Charges are calculated from actual running time, with auto-stop when credits run out.
How long does Wan 2.2 take to deploy?
Video models typically take 15–30 minutes for first deployment (model download + setup). Subsequent starts are faster.
Can I run Wan 2.2 on my local GPU?
It depends on the selected variant, precision, quantization, and workflow settings. Compare the variants below with your available VRAM; the table shows ModelPilot's cloud GPU allocation, not a universal local minimum.
Ready to deploy Wan 2.2?
Pick your GPU and have it running in minutes. No infrastructure setup required.