WAN 2.2 image-to-video in production: how we make clips in batches

WAN 2.2 image-to-video is the model behind our video orders: a still goes in, a short vertical clip comes out. This guide walks through the ComfyUI workflow we run in production, node by node, with the settings copied from the graph file.

Facts about WAN 2.2 come from the official repository, model cards and ComfyUI docs; numbers about our pipeline come from our own graph and test runs.

What WAN 2.2 image-to-video is, and why we use it

WAN 2.2 is an open video model family from Alibaba’s Wan team, released in July 2025 with weights and inference code under the Apache 2.0 license. That covers WAN itself; LoRAs, upscalers and audio models in the same graph have their own terms (see our guide on Civitai model licenses).

The image-to-video model, I2V-A14B, is built from two experts of about 14B parameters each: 27B in total, 14B active at any step. The high-noise expert runs the early denoising steps and sets layout and motion; the low-noise expert takes over later and refines detail. The official code switches between them at a signal-to-noise threshold; in ComfyUI you do it by hand, with one loader and one sampler per expert. Officially the model supports 480P and 720P (480×832, 832×480, 720×1280, 1280×720), and its default clip is 81 frames at 16 fps, a little over 5 seconds.

Why we use it: a clip costs GPU time rather than a per-clip vendor fee, every node is ours to change, and the graph can be frozen so that clip 300 of a batch comes out of the same pipeline as clip 3.

Our WAN 2.2 ComfyUI workflow, step by step

One run turns one start image and a short brief into one vertical clip of about 10 seconds with music.

The upscale takes 624×1104 to roughly 1560×2760, above the 1080×1920 that vertical platforms use.

Music is optional in orders: by default clips are delivered without sound, and on request the pipeline generates a background track or we lay your own track over the clip.

The motion director

One generic motion prompt for a whole batch gives generic motion, and writing a prompt per image by hand doesn’t scale. So the first node in our graph is a vision-capable LLM running locally, on the same GPU machine as WAN. It gets the start image and a short brief and returns JSON with three fields. Its system prompt asks for the subject exactly as it appears in the image, two or three concrete actions, a camera hint, and music tags with the ambient sounds of the scene.

The brief stays short and plain:

The woman from the image slowly lifts the cup, takes one sip and smiles at the camera.
One continuous action. Steady medium shot, no camera move.

Two clips and the seam

One generation in our graph is 81 frames, about 5 seconds. To get 10, the graph takes frame 81 of the first clip as the start image of the second. Clip 2 is a fresh generation with its own prompt and noise, so the seam around the 5-second mark is the weakest point of the pipeline. We traced it to two causes:

1. Camera jump. The director writes “medium shot” for part 1 and “close-up” for part 2, and WAN renders exactly that. The fix is a camera lock in the director’s system prompt: same shot size and angle in both parts, no zoom at the cut, part 2 starts from the pose where part 1 ends, the same camera phrase word for word in both prompts.
2. Prop or action swap. If the brief asks for several actions, the director spreads them across the parts, and clip 2 starts with a different object in hand. Camera lock doesn’t fix this; a brief with one continuous action for all 10 seconds does.

A clean joint needs both fixes. Busy backgrounds with flying objects or lightning can still change slightly in the second clip; calm scenes hold up much better.

Why the start frame decides everything

In image-to-video the first frame is the instruction the model trusts most: identity, clothing, light, palette and composition all come from it. WAN won’t repair a weak frame; it animates the flaws too. Before a batch we check every start image:

• Format. Vertical, close to 9:16, at least as large as the working size (624×1104 in our main build).
• Room to move. If a hand will rise or a head will turn, leave space for it. A subject cropped at the edge it moves toward is a common source of broken clips.
• The action starts in the frame. Animating a cup that is there works better than asking the model to bring one in.
• Details that must stay. Glasses, hats, chains and logos should be clearly visible. Small accessories are the first things to drift, during a clip and across the seam.
• No text on top. Captions and watermarks get smeared; add titles in editing.

The frames of a batch should also be consistent with each other. When they don’t exist yet, we make them first: from references with FLUX.1 Kontext [pro] or Nano Banana, or as catalog stills through our AI product photos service.

What WAN 2.2 does well, and where it breaks

Reliable enough for batch work: one slow, continuous action by one subject; soft physics such as smoke, steam, rain, water, fabric, hair and fur; light moving across a scene; a steady shot or a slow push-in.

Poor or unreliable:

• Complex camera moves. Orbits and fly-throughs need sides of the subject that aren’t in the start image, so the model invents them.
• Fast action. Stunts and fights. The Lightning model card lists artifacts on extremely large motion and vehicles moving in reverse as known limitations of its text-to-video version, a useful warning for image-to-video too.
• Hands in close-up. Fingers merge, multiply or bend the wrong way.
• Text and logos in motion. They start exact, because the first frame is your image, then blur or change shape.

WAN 2.2 i2v settings: Lightning LoRA, steps, resolution, fp8

Our values next to the official Wan2.2 defaults for I2V-A14B:

Lightning LoRA. Wan2.2-Lightning from the lightx2v team is a step-distilled version of the A14B models; its model card says it needs only 4 steps without the CFG trick and claims a 20× speed-up. For image-to-video it is two LoRAs, one per expert, loaded with LoraLoaderModelOnly. We use 8 or 6 steps, slightly more than the 4 it was distilled for; each step adds sampling time. The split between the experts:

High-noise:  KSamplerAdvanced  steps 8, start 0, end 4, add_noise on,  leftover noise on
Low-noise:   KSamplerAdvanced  steps 8, start 4, end 8, add_noise off, leftover noise off
Both:        cfg 1.0, euler, simple, ModelSamplingSD3 shift 5.0

A side effect of CFG 1.0. At CFG 1.0 ComfyUI skips the negative pass entirely, so in a Lightning graph the negative prompt does nothing. Steer with the positive prompt and the start frame.

Resolution. 624×1104 is close to 9:16, both sides are multiples of 16, and the pixel count sits between official 480P and 720P. We generate at a middle size and leave the final size to the RTX upscale. The lighter build uses 480×848 and SageAttention instead of PyTorch’s default attention.

fp8 and VRAM. The fp8 e4m3fn scaled files are about 15 GB per expert, half the size of fp16; the text encoder is umT5-XXL in fp8, the VAE is the Wan 2.1 one. The official repository says its single-GPU command for A14B at 1280×720, with --offload_model True --convert_model_dtype, needs at least 80 GB of VRAM. Our graph is heavier than WAN alone, because the director LLM (about 20 GB of weights) and the music model share the card: we require at least 64 GB and run on rented RTX PRO 6000 Blackwell cards with 96 GB.

Speed, on our hardware on the day we measured, one run each on a single RTX PRO 6000 Blackwell: the main build took about 7 minutes from the start of the run to the finished 10-second clip with music; the lighter build executed the graph in about 3 minutes.

Scaling WAN 2.2 image-to-video to a batch

General mechanics are in how to scale a ComfyUI workflow to thousands of generations. Specific to WAN:

1. A pilot batch first. A sample of the set, difficult images included. It fixes the brief style and settings, and the client approves the look.
2. A frozen pipeline. ComfyUI version, custom nodes on pinned commits, model files checked by checksum. A new idea for a setting becomes a new version of the graph; the running batch stays on the old one.
3. A pool of GPUs. Small batches run on our own cards, large ones on rented GPUs (we use Vast.ai), several instances in parallel. Each new instance downloads about 70 GB of weights, so a cold start takes minutes. We give each one 110 GB of disk; an early attempt ran out of space while pulling the LLM.
4. An upscaler check. RTX Video Super Resolution depends on the host’s driver and graphics libraries, not just the GPU model: the same card with a different driver failed to load the effect. Rental listings don’t show this, so every new instance runs a short VSR test while booting, and one that fails is replaced.
5. A director that varies. The WAN seed controls only the noise; the LLM writes new prompts every run, so the same seed and brief don’t give the same clip. Save the prompts of any clip you may need to reproduce.
6. Review by hand. Someone watches every clip: the seam, faces and hands, props, labels. Rejects go back for another generation.

When it’s easier to hand it to us

If you need finished clips rather than a pipeline project, that is our bulk image-to-video generation service. We run this graph or your own WAN workflow, review every clip by hand and deliver mp4 files as a ZIP archive or a folder link. Prices start from $1.50 per clip for a short 5-second clip; longer clips, like the 10-second ones described here, and higher resolutions are quoted on request. Setup and the pilot batch are included; the minimum order is $50.

Send a few images and the motion you want through the request form.