Skip to main content

Deploy Wan 2.1

Video

Wan 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)

ModelGPUVRAMPriceAction
Wan 2.1 T2V 14B
Text-to-Video
A100 80GB PCIe80 GB$1.85/hrDeploy
Wan 2.1 I2V 14B
Image-to-Video
A100 80GB PCIe80 GB$1.85/hrDeploy

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.

Includes ComfyUI with video-optimized workflows. Video models require more GPU memory for frame buffers.

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.