Deploy Wan 2.1
VideoWan 2.1 is the previous generation of Alibaba's video generation models. While superseded by Wan 2.2, these 14B models remain stable and well-tested for production video generation workflows.
Deploy Wan 2.1 in minutes
Starting at $1.85/hr on dedicated GPU
Available Variants (2)
| Model | GPU | VRAM | Price | Action |
|---|---|---|---|---|
Wan 2.1 T2V 14B Text-to-Video | A100 80GB PCIe | 80 GB | $1.85/hr | Deploy |
Wan 2.1 I2V 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 a 80GB cloud GPU to this deployment. 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 $1.85/hr with no setup required.
Use Cases
- ✓Stable video generation
- ✓Text-to-video workflows
- ✓Image-to-video conversion
- ✓Legacy pipeline compatibility
Related Models
Known Issues & Fixes
Real failures from running Wan 2.1 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.1?
The listed ModelPilot deployment uses a 80GB cloud GPU. Local memory needs can vary with precision, quantization, and workflow settings.
How much does it cost to run Wan 2.1?
Starting at $1.85/hr on a dedicated GPU. Charges are calculated from actual running time, with auto-stop when credits run out.
How long does Wan 2.1 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.1 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.1?
Pick your GPU and have it running in minutes. No infrastructure setup required.