☁️BizyAir WanImageToVideo

If you've built a Wan workflow with ComfyUI's own native nodes before, this one will look familiar - same shape as core's WanImageToVideo: conditioning and a VAE in, latent out, with the usual width/height/length/batch controls. The difference is entirely in where the compute happens. This version wants BizyAir's own conditioning and VAE types, not the generic ones your local CLIP/VAE loaders produce, because the whole point is running Wan on BizyAir's cloud instead of your own GPU.

That's the actual value proposition: Wan 2.1 is a genuinely good open i2v model, but the 14B tier wants real VRAM, and even the lighter tiers add up in generation time. This node lets you build the same graph shape without owning the hardware for it.

What it does

Takes a conditioned prompt and an optional start image, and produces a LATENT you feed to a matching sampler and VAE-decode step, same as you would with local Wan. It's a graph-building block, not a one-shot pipeline - you still need to wire a sampler after it.

Inputs and outputs that matter

• positive / negative - BIZYAIR_CONDITIONING, not the plain CONDITIONING type. These need to come from BizyAir's own cloud text-encode nodes upstream, not a standard CLIPTextEncode.
• vae - BIZYAIR_VAE, same story: a BizyAir-flavored VAE loader, not your local one.
• width (default 832) / height (default 480) - both capped at 960, in steps of 16. That default resolution isn't arbitrary - it lines up with Wan's own standard 480p working resolution.
• length (default 81, up to 960, steps of 4) - the default is set right at Wan's actual native clip length. 81 frames is what the model was trained to generate coherently in one shot; cranking the slider past that doesn't buy you a longer coherent clip, it buys you the model trying to extrapolate past what it knows, which is exactly the kind of degradation the wider Wan ecosystem builds chunking/extension tools to work around. Treat "longer than 81" here as "needs a proper extension technique," not "just raise the number."
• batch_size - how many clips to generate in one call.
• clip_vision_output (optional) - feeds richer image conditioning into the generation, same role it plays in local Wan i2v graphs.
• start_image (optional) - the actual reference frame the video kicks off from.

Outputs are positive and negative passed through (still BizyAir-typed, so they chain into further cloud nodes) plus latent, which needs a sampler and VAE-decode downstream to become a real video.

How to install it

• ComfyUI Manager - search "BizyAir", install, restart.
• Manual - cd ComfyUI/custom_nodes && git clone https://github.com/siliconflow/BizyAir.git, restart.
• Comfy CLI - comfy node install bizyair.

Set your API key first - the in-app login prompt or bizyair.siliconflow.cn. This node executes on BizyAir's cloud, so it's billed against your account regardless of whether you're using open weights underneath.

Common issues & troubleshooting

Inputs won't connect / show red. This is the most common trip-up with this node specifically. If you're wiring in output from a normal ComfyUI CLIPTextEncode or VAELoader, the types won't match - BIZYAIR_CONDITIONING and BIZYAIR_VAE only come from other BizyAir cloud nodes. You can't mix a local text-encoding chain into this node; the whole upstream path needs to be BizyAir nodes.

Motion falls apart or the clip loops oddly past a certain length. You're past the 81-frame native window. That's expected behavior for Wan in general, not a bug in this node - pull length back down, or reach for one of the Wan extension approaches (chaining generations, using the last frame of one clip to start the next) rather than expecting one call to hold coherence indefinitely.

BizyAir wasn't something you meant to install. A ComfyUI Manager bug used to mis-resolve missing nodes onto this pack, which is where "is this safe" reports online come from. It's a legitimate commercial pack, safe to remove via the Manager if you don't need it.