← Blog
August 17, 2026

Wan 2.2 on an RTX 5090: ComfyUI, GPU requirements, and video generation

Wan 2.2 can generate 720p video on a single RTX 5090.

But that answer only applies cleanly to part of the Wan 2.2 family.

The Wan2.2-TI2V-5B model is a 5-billion-parameter hybrid model designed for both text-to-video and image-to-video generation. Its official implementation supports 720p output at 24 frames per second and can run with 24GB of GPU memory when model and text-encoder offloading are enabled. ComfyUI goes further and says its native offloading can make the 5B workflow fit within about 8GB of VRAM.

The larger Wan2.2-A14B models are different. They use a Mixture-of-Experts architecture containing roughly 27B total parameters across two 14B experts. Only one expert is active during each stage of denoising, but the official Wan inference path still specifies at least 80GB of VRAM for single-GPU 14B inference.

So if you have one 32GB RTX 5090 cloud GPU, I would start with Wan2.2-TI2V-5B.

That gives you text-to-video and image-to-video in one model, enough memory headroom for a practical ComfyUI workflow, and 720p output without beginning the project by fighting GPU memory.

What is Wan 2.2?

Wan 2.2 is an open video-generation model family from the Wan team at Alibaba.

The original release covers three main video-generation models:

Model Parameters Main job Resolution
Wan2.2-TI2V-5B 5B Text-to-video + image-to-video 720p
Wan2.2-T2V-A14B 27B total / ~14B active per step Text-to-video 480p and 720p
Wan2.2-I2V-A14B 27B total / ~14B active per step Image-to-video 480p and 720p

The family has since expanded with Wan2.2-S2V-14B for speech-driven video and Wan2.2-Animate-14B for character animation and replacement. The official repository describes Animate as a unified model for transferring movement and expression or replacing a character while preserving motion.

The open Wan 2.2 models are released under Apache 2.0, which permits commercial use subject to the license terms.

That makes the licensing situation considerably simpler than some of the image-generation models we covered earlier in this series.

What is different about Wan 2.2?

Two technical ideas are particularly important.

The first is Mixture-of-Experts video diffusion.

The second is a much more compressed video representation in the 5B model.

Together, they attack two different problems: increasing model capacity without paying the full compute cost at every denoising step, and making high-definition video feasible with much less hardware.

The 14B models use two different experts

Wan 2.2's A14B architecture separates the denoising process into two stages.

A high-noise expert handles the earlier part of generation, when the model is establishing broad composition and motion.

A low-noise expert takes over later, when the video needs finer details.

Each expert is around 14B parameters.

Together, they total roughly 27B parameters, but only one expert is active at a given denoising step. The Wan team says this keeps the active computation and GPU-memory requirement much closer to a 14B model than a dense 27B model.

That does not mean the model suddenly becomes a small GPU workload.

Both expert weight sets still exist.

The architecture saves computation by choosing which expert works at each stage. It does not erase the other expert from storage.

Why the 5B model is more interesting for one GPU

Wan2.2-TI2V-5B takes a different approach.

It is a dense 5B model paired with a high-compression video VAE.

The Wan team says the VAE compresses video across time, height, and width at a ratio of 4 × 16 × 16. With an additional patchification stage, the overall representation becomes even more compact.

The practical result is much more important than the compression terminology:

the 5B model can generate 720p video at 24 fps on a single consumer-class GPU.

The official repository reports a five-second 720p clip in under nine minutes on a single consumer GPU without specialized optimization.

That is still far from real-time video generation.

But it changes the infrastructure problem from “large data-center GPU” to “one high-end GPU.”

Wan 2.2 GPU requirements

The most useful summary is:

Wan 2.2 model Official single-GPU guidance One 32 GB RTX 5090?
TI2V-5B ≥24 GB with official offloading; ComfyUI can use considerably less Yes
T2V-A14B ≥80 GB in official Wan implementation Not through the reference single-GPU path
I2V-A14B ≥80 GB in official Wan implementation Not through the reference single-GPU path
S2V-14B ≥80 GB in official Wan implementation Not through the reference single-GPU path
Animate-14B Workflow-dependent Treat as a heavier 14B-class workflow

The 5B row is the one I would build around first.

Hivenet's RTX 5090 instances provide 32GB of GDDR7 VRAM per GPU, so the card sits comfortably above the official 24GB guidance for TI2V-5B while leaving more room than a 24GB configuration.

Why does ComfyUI say the 5B model can fit in 8GB?

Because software architecture matters.

The official Wan command keeps more of the inference pipeline in the conventional runtime and documents a 24GB configuration with:

--offload_model True
--convert_model_dtype
--t5_cpu

ComfyUI's native workflow can move model components between GPU and system memory more aggressively, and its official documentation says the 5B model should fit well in approximately 8GB VRAM with native offloading.

That does not mean 8GB and 32GB give you the same experience.

Offloading saves VRAM by moving work elsewhere.

Moving weights and other data between system memory and GPU memory takes time.

With 32GB available, the useful goal is not to prove that the workflow can survive in the smallest possible footprint. It is to keep enough of the pipeline close to the GPU that generation remains practical.

What can Wan2.2-TI2V-5B do?

The 5B model handles two tasks in the same checkpoint:

Text-to-video

You provide a description and the model generates the clip.

Image-to-video

You provide a starting image plus an optional text prompt describing the desired motion or scene development.

That second mode makes Wan 2.2 particularly interesting alongside the image-generation part of this content cluster.

You could, for example:

  1. create a controlled starting frame with FLUX
  2. refine the composition until the still image is right
  3. send that image to Wan 2.2
  4. describe the movement rather than asking a video model to invent the entire frame and movement simultaneously

Our FLUX.1 [dev] cloud GPU guide covers the first half of that workflow.

Wan 2.2 handles the second.

Text-to-video or image-to-video?

I would use text-to-video when the concept itself is still exploratory.

You are asking the model to decide:

  • composition
  • subjects
  • visual details
  • movement
  • camera behavior
  • scene development

That gives you creative range, but also more variables that can go wrong.

Use image-to-video when the starting composition matters.

An image gives the video model a visual anchor for:

  • character appearance
  • product design
  • location
  • colors
  • framing
  • lighting
  • art direction

Then the prompt can concentrate more heavily on movement.

For controlled creative production, that division of labor is often easier to manage.

Step 1: start from the ComfyUI cloud GPU setup

This tutorial assumes you already have the environment from our ComfyUI cloud GPU guide:

  • one RTX 5090 VM
  • a working NVIDIA/PyTorch environment
  • current ComfyUI
  • browser access over SSH
  • enough disk for large model files and video outputs

If not, set that up first.

There is no benefit in repeating the ComfyUI installation while trying to diagnose a video model at the same time.

For private access, Hivenet recommends SSH port forwarding rather than exposing a personal web UI directly to the internet.

Step 2: update ComfyUI before loading the Wan workflow

Wan 2.2 support is built into current ComfyUI.

The official documentation warns that missing nodes in the Wan workflow often mean the ComfyUI installation is out of date.

Update your installation using the method appropriate to how you installed ComfyUI.

If you cloned it manually:

cd ComfyUI
git pull

Then reactivate the same Python environment and update dependencies if the release requires it.

Do not install a third-party Wan custom node merely because an old tutorial says you need one.

There are useful community implementations, but native ComfyUI support already exists.

Start there.

Step 3: load the official Wan2.2 5B workflow

In ComfyUI, open:

Workflow → Browse Templates → Video

Search for:

Wan2.2 5B

The official workflow supports both text-to-video and image-to-video.

Using the template gives us a known-good graph before we start changing model paths, frame counts, resolutions, or custom nodes.

That is the same rule we used for FLUX:

first make the official workflow work. Then customize it.

Step 4: download the three model components

The native 5B ComfyUI workflow currently uses three files.

Diffusion model

wan2.2_ti2v_5B_fp16.safetensors

Put it in:

ComfyUI/models/diffusion_models/

Text encoder

umt5_xxl_fp8_e4m3fn_scaled.safetensors

Put it in:

ComfyUI/models/text_encoders/

VAE

wan2.2_vae.safetensors

Put it in:

ComfyUI/models/vae/

The resulting structure should look like:

ComfyUI/
└── models/
   ├── diffusion_models/
   │   └── wan2.2_ti2v_5B_fp16.safetensors
   │
   ├── text_encoders/
   │   └── umt5_xxl_fp8_e4m3fn_scaled.safetensors
   │
   └── vae/
       └── wan2.2_vae.safetensors

Restart ComfyUI or refresh the model lists if necessary.

Step 5: verify the workflow before changing anything

Check that the workflow's model-loading nodes point to:

wan2.2_ti2v_5B_fp16.safetensors

for the diffusion model,

umt5_xxl_fp8_e4m3fn_scaled.safetensors

for the text encoder, and

wan2.2_vae.safetensors

for the VAE.

These are the exact components ComfyUI currently documents for the native 5B workflow.

If a loader is red, solve the file-path problem first.

Changing sampling settings will not fix a model that ComfyUI cannot find.

Step 6: generate your first text-to-video clip

Leave the image input disabled.

Use a prompt that describes a scene with one clear motion.

For example:

Wide cinematic shot of a yellow kayak drifting slowly across
a still mountain lake at sunrise. Thin fog moves across the
water. The camera makes a slow forward push toward the kayak.
Soft natural light, realistic water reflections, calm movement.

This is more useful for a first test than:

An epic cinematic masterpiece with incredible movement
and breathtaking visuals.

The first prompt tells the model:

  • what exists
  • what moves
  • how it moves
  • what the camera does
  • what the environment does
  • how the scene should look

Video prompts need temporal information.

A beautiful description of a still frame does not tell a video model what should happen next.

A useful Wan 2.2 prompt has four parts

For practical testing, I would think about prompts as:

Subject + action + camera + environment

For example:

Subject:
A red vintage sports car

Action:
drives slowly along a wet mountain road

Camera:
low tracking shot moving alongside the car

Environment:
early morning fog, wet asphalt reflections,
soft overcast light, realistic cinematic photography

Combined:

A red vintage sports car drives slowly along a wet mountain
road. Low tracking shot moving alongside the car. Early
morning fog drifts between the trees and reflections shimmer
on the wet asphalt. Soft overcast light, realistic cinematic
photography.

You can add complexity later.

Start with motion the model can understand.

Describe motion explicitly

Image prompts often focus almost entirely on appearance.

Video prompts need verbs.

Compare:

A woman in a long red coat standing on a train platform.

with:

A woman in a long red coat walks slowly along an empty train
platform while wind moves the coat and her hair. The camera
tracks beside her at walking speed. A train passes in the
background.

The second version describes change over time.

That is what the model has to generate.

Useful motion language includes:

  • walks toward
  • turns slowly
  • raises
  • falls
  • drifts
  • swings
  • rotates
  • accelerates
  • pans
  • tracks
  • pushes in
  • pulls back
  • tilts
  • circles

The more important a movement is, the less I would leave it implicit.

Keep the first clip short

Video generation multiplies mistakes across frames.

A longer clip means:

  • more frames
  • more compute
  • more opportunities for temporal drift
  • larger outputs
  • longer feedback cycles

Start with the default workflow length.

Do not turn the first successful generation into a 20-second experiment.

Get the motion right first.

Then spend compute on duration.

Step 7: monitor GPU memory during generation

On the VM:

watch -n 1 nvidia-smi

Video generation is a better stress test than staring at idle VRAM after the model loads.

Watch:

  • allocated VRAM
  • GPU utilization
  • memory peaks
  • whether generation spills heavily into system memory
  • whether the process approaches the 32GB limit

The RTX 5090 provides 32GB VRAM, while Hivenet's one-GPU instance also has separate system memory available to the runtime.

Those two pools are not interchangeable.

Offloading to system RAM can make a workflow fit.

It can also make it slower.

Step 8: try image-to-video

Enable the workflow's image input.

The native ComfyUI workflow uses the same 5B model for image-to-video. You supply an image, and Wan 2.2 uses its aspect ratio when creating the video latent.

Choose a clear image with a composition you want to preserve.

Then prompt primarily around movement.

For example, if the input is a portrait of someone beside a window:

The person slowly turns toward the window and looks outside.
A light breeze moves the curtains and loose strands of hair.
The camera makes a very slow push forward. Natural afternoon
light, subtle realistic movement.

Notice what the prompt does not spend much time describing.

The person's appearance is already in the image.

Use the prompt budget for what changes.

Image-to-video is often the more controllable workflow

Text-to-video asks one model call to solve two large problems:

  1. design the frame
  2. animate it

Image-to-video lets you solve them separately.

That is useful for:

  • product videos
  • character consistency
  • branded visual styles
  • architectural scenes
  • controlled compositions
  • art-directed campaigns

You can iterate on the starting frame cheaply with an image model, then spend the heavier video compute only once the frame is worth animating.

A practical workflow could be:

FLUX
 ↓
approved starting frame
 ↓
Wan 2.2 image-to-video
 ↓
selected clip
 ↓
upscale / edit / encode

Our FLUX.1 [dev] guide and ComfyUI workflow guide cover the first two pieces of that pipeline.

720p at 24 fps is already a serious compute workload

Wan2.2-TI2V-5B natively supports 720p output at 24 frames per second.

Five seconds at 24 fps represents around:

5 × 24 = 120 frames

that have to remain temporally coherent.

This is why AI video is substantially more compute-intensive than creating one 1024 × 1024 image.

The model has to solve:

  • image quality
  • motion
  • object persistence
  • character consistency
  • camera movement
  • temporal continuity

across an entire sequence.

A five-second clip is not “five seconds of GPU work.”

What about the 14B Wan 2.2 models?

Use them when you need the additional model capacity enough to justify the infrastructure.

The A14B models use two specialized experts:

high-noise expert
       ↓
transition during denoising
       ↓
low-noise expert

Each is approximately 14B parameters, giving the model roughly 27B parameters in total while keeping about 14B active during each denoising step.

ComfyUI's current native 14B text-to-video workflow uses separate FP8 high-noise and low-noise model files:

wan2.2_t2v_high_noise_14B_fp8_scaled.safetensors
wan2.2_t2v_low_noise_14B_fp8_scaled.safetensors

alongside an FP8 UMT5 text encoder and the compatible Wan 2.1 VAE.

That is much more model state than the 5B workflow.

Can the 14B model run on an RTX 5090?

This is where I would avoid an overly confident yes.

The official Wan reference implementation specifies at least 80GB VRAM for single-GPU T2V-A14B and I2V-A14B inference, even with model offloading and dtype conversion enabled.

ComfyUI's FP8 models and native offloading can change the memory behavior, and community implementations offer more aggressive low-memory approaches.

But that is different from saying:

Wan2.2 14B needs 32GB.

The official source does not support that claim.

If your target is one RTX 5090, use the 5B model.

If you specifically need the 14B model, treat it as a larger-memory or heavily offloaded workload and benchmark the exact ComfyUI implementation you plan to use.

Don't confuse 14B active parameters with 14B of stored weights

This is the same trap we discussed with Mixture-of-Experts language models.

Wan calls these models A14B because approximately 14B parameters are active during a step.

But the two-expert architecture contains roughly 27B total parameters.

That matters for:

  • checkpoint storage
  • model loading
  • CPU memory
  • offloading
  • GPU-memory planning

“14B active” describes computation.

It does not mean the complete model contains only 14B parameters.

This is exactly the kind of distinction that disappears in simplistic GPU requirement tables.

What is Wan 2.2 Animate?

Wan2.2-Animate-14B is a later model in the Wan 2.2 family designed around character animation and character replacement.

It can use motion and expression from a reference performance to animate another character, or replace a character while preserving the driving movement. The Wan team released the model and inference code in September 2025, and it was later integrated into Diffusers.

That makes it a different problem from ordinary text-to-video.

Instead of asking:

Generate a person dancing.

you can work with a source performance and ask the model to transfer that performance to another character.

ComfyUI now has a dedicated Wan2.2 Animate native workflow as well.

If character animation becomes a major search or product opportunity for us, it deserves its own tutorial rather than being squeezed into this one.

What about speech-to-video?

Wan2.2-S2V-14B generates video from:

  • audio
  • a reference image
  • an optional text prompt

and can also use pose guidance.

The official implementation supports 480p and 720p and uses the length of the input audio to determine video duration when a clip count is not set.

Again, the official single-GPU path specifies an 80GB-class GPU.

That makes S2V a very different deployment target from the 5B hybrid model.

The Wan 2.2 family is broad.

You do not need to run every branch of it on the same hardware.

How much disk space do Wan 2.2 workflows need?

Plan generously.

AI video environments accumulate more data than image-generation environments because you are storing:

  • model weights
  • text encoders
  • VAEs
  • starting images
  • workflow JSON
  • preview renders
  • final video
  • intermediate frames
  • alternative generations

And the 14B workflows use multiple large model files rather than one small checkpoint.

The one-GPU RTX 5090 configuration on Hivenet currently includes 250GB of local disk; larger GPU configurations scale the included storage upward.

That is useful working space.

It is still not an archive.

Move valuable outputs and reusable workflow files somewhere persistent before terminating an instance.

Save the workflow with the video

This becomes even more important for video than it was for FLUX.

An output clip by itself does not tell you:

  • which Wan model produced it
  • seed
  • frame count
  • resolution
  • prompt
  • negative prompt
  • text encoder
  • workflow version
  • custom nodes
  • starting image
  • model precision

Keep the ComfyUI JSON.

For example:

wan-product-shot/
├── workflows/
│   ├── product-i2v-v01.json
│   ├── product-i2v-v02-motion.json
│   └── product-i2v-v03-camera.json
├── input/
│   └── product-frame.png
├── output/
│   ├── test-01.mp4
│   └── final.mp4
└── notes.md

That is enough structure to turn experimentation into something you can repeat.

Change one kind of motion at a time

Video prompting becomes difficult when a prompt requests too many simultaneous events.

For example:

The actor walks toward the camera, turns around, jumps over a
chair, the camera circles them, the lights change to red,
rain starts falling, and the room transforms into a forest.

The model now has many temporal relationships to coordinate.

A simpler test:

The actor walks slowly toward the camera while the camera
moves backward to maintain the same framing.

lets you evaluate whether the core motion works.

Then add:

Soft rain begins falling in the background.

Then perhaps change the camera.

Iterating this way is slower in prompt count and much faster in understanding what failed.

Camera language is especially useful in video prompts

Image-generation prompts can describe a camera without any actual camera movement.

In video, the camera can become part of the action.

Useful instructions include:

  • static camera
  • slow push in
  • slow pull back
  • tracking shot
  • pan left
  • pan right
  • tilt up
  • orbit around the subject
  • handheld movement
  • locked-off wide shot
  • low-angle tracking shot

If camera movement matters, state it.

Otherwise the model has to decide for you.

Keep motion physically plausible before making it spectacular

One good way to stress-test a video model is to start with normal physics.

Try:

A glass of water sits on a wooden table.
A hand enters from the right, picks up the glass,
and moves it slowly out of frame.
Static camera.

This tests:

  • object persistence
  • hand/object interaction
  • occlusion
  • movement
  • scene consistency

If the model cannot keep the glass coherent through that interaction, adding explosions probably will not improve the diagnosis.

Fancy demos are useful for marketing.

Simple motion is better for evaluation.

How to evaluate an AI video model

Do not judge the model solely from the most impressive clip you can generate.

Create a repeatable prompt set covering things your application actually needs.

Look at:

Prompt adherence
Did the requested action happen?

Temporal consistency
Do people and objects remain recognizable across frames?

Motion quality
Does movement look physically plausible?

Interaction quality
Do hands, tools, clothing, and objects interact correctly?

Camera control
Did the requested movement occur?

Scene stability
Do the background and geometry drift?

Identity consistency
Does the subject remain the same person or object?

Failure rate
How many generations have to be discarded?

That last metric matters commercially.

A model that creates a stunning usable clip once in ten attempts can cost more than a slightly less impressive model that succeeds eight times out of ten.

Video cost should be measured per usable output

Hivenet currently lists RTX 5090 Compute from €0.75 per GPU-hour with per-second billing.

So the infrastructure calculation is:

GPU runtime in hours × €0.75

But “cost per generated video” is usually the wrong metric.

A better one is:

total GPU cost
÷
number of usable clips

Suppose one workflow creates twenty clips and only two are acceptable.

Your practical generation cost is spread across those two.

This is why prompt quality, workflow stability, and model choice have economic consequences.

A faster GPU does not fix a workflow that produces unusable output.

Video generation rewards bursty GPU use

Creative video work tends to come in bursts:

launch
→ generate
→ inspect
→ adjust
→ generate again
→ export
→ stop

That is a good match for on-demand compute.

Hivenet bills Compute per second while the instance is running.

The discipline matters.

If you spend two hours reviewing clips while the GPU sits idle in another tab, you are still renting the GPU.

Save the workflow.

Stop the instance when the session is finished.

Restart when you need it again.

Wan 2.2 or a commercial video generator?

Self-hosting Wan 2.2 gives you things a hosted video product may not:

  • model access
  • workflow control
  • repeatability
  • custom ComfyUI pipelines
  • local model files
  • programmatic automation
  • control over when models update
  • the ability to combine the model with other open components

A commercial hosted video service gives you something equally valuable:

someone else operates the infrastructure.

If you need ten clips and the hosted service already produces them well, running Linux and downloading model weights is unlikely to improve your life.

Self-host when the control matters.

Use a managed service when it does not.

Wan 2.2 fits naturally into a broader ComfyUI pipeline

The interesting thing about running Wan through ComfyUI is that the video model no longer has to be the whole application.

You can create workflows like:

Generate starting frame with FLUX
           ↓
     image processing
           ↓
    Wan 2.2 I2V
           ↓
      frame upscale
           ↓
     post-processing
           ↓
        output

or:

input product image
       ↓
background preparation
       ↓
Wan 2.2 image-to-video
       ↓
video processing
       ↓
output

That is where the ComfyUI workflow model becomes valuable.

The GPU is running a pipeline rather than one isolated model.

Is Wan 2.2 still worth running?

Yes, when its open ecosystem and workflow control matter to you.

Video generation is moving quickly. There will always be a newer model.

Wan 2.2 still has several practical advantages:

  • open weights
  • Apache 2.0 licensing
  • native ComfyUI support
  • text-to-video and image-to-video
  • a relatively lightweight 5B option
  • heavier models for higher-capacity workflows
  • character animation
  • speech-driven generation
  • Diffusers integration
  • a mature collection of community optimizations

Those are operational qualities.

Model selection should include them.

The newest benchmark leader is not automatically the easiest model to build around.

Which Wan 2.2 model should you use?

For one RTX 5090, start with:

Wan2.2-TI2V-5B

It gives you:

  • text-to-video
  • image-to-video
  • 720p
  • 24 fps
  • a comfortable one-GPU path
  • native ComfyUI support

Use T2V-A14B when text-to-video quality justifies a much heavier workload.

Use I2V-A14B when higher-capacity image-to-video is the goal.

Use S2V-14B when audio drives the video.

Use Animate-14B when transferring a performance or replacing a character is the task.

Do not choose the 14B version because 14 is larger than 5.

Choose it because the output is better enough to justify the infrastructure.

Wan 2.2 FAQ

What is Wan 2.2?

Wan 2.2 is an open video-generation model family from the Wan team at Alibaba. It includes models for text-to-video, image-to-video, hybrid text/image-to-video, speech-driven video, and character animation.

Is Wan 2.2 open source?

The open Wan 2.2 models are published under the Apache 2.0 license, which permits commercial use, modification, and redistribution subject to its terms.

Can Wan 2.2 run on an RTX 5090?

Yes. Wan2.2-TI2V-5B can run on a single GPU with at least 24GB VRAM using the official offloaded configuration, so a 32GB RTX 5090 is a suitable target.

How much VRAM does Wan 2.2 need?

It depends on the model and implementation. The official Wan code specifies at least 24GB for TI2V-5B with offloading and at least 80GB for the A14B T2V and I2V models. ComfyUI says its native 5B workflow can fit around 8GB VRAM using offloading.

What is Wan2.2-TI2V-5B?

It is a 5-billion-parameter dense Wan 2.2 model supporting both text-to-video and image-to-video generation in one checkpoint. It uses the high-compression Wan2.2 VAE.

Does Wan 2.2 generate 720p video?

Yes. The 5B hybrid model and the A14B T2V/I2V models support 720p generation. The 5B model supports 720p at 24 frames per second.

How fast is Wan2.2-TI2V-5B?

The Wan team reports that the 5B model can generate a five-second 720p video in under nine minutes on a single consumer-grade GPU without specialized optimization. Actual performance depends on GPU, runtime, precision, offloading, workflow, and generation settings.

What does A14B mean in Wan 2.2?

The A14B models use two experts with about 14B parameters each. Together the architecture contains roughly 27B total parameters, while about 14B are active during each denoising step.

Why does Wan 2.2 use two experts?

One expert handles the high-noise early denoising stage and focuses more on overall layout, while the second handles the low-noise later stage and refines detail.

Does Wan 2.2 work in ComfyUI?

Yes. ComfyUI has native workflow templates for Wan2.2 5B text/image-to-video, 14B text-to-video, 14B image-to-video, and first/last-frame video generation.

What files does the Wan2.2 5B ComfyUI workflow need?

The current native workflow uses wan2.2_ti2v_5B_fp16.safetensors, umt5_xxl_fp8_e4m3fn_scaled.safetensors, and wan2.2_vae.safetensors.

Can Wan 2.2 turn an image into video?

Yes. The 5B hybrid model supports image-to-video as well as text-to-video. Wan also publishes a separate higher-capacity I2V-A14B model.

What is Wan 2.2 Animate?

Wan2.2-Animate-14B is a character-animation and replacement model. It can transfer movement and expressions from a reference performance or replace a character while preserving the driving motion.

Does Wan 2.2 support audio?

Wan2.2-S2V-14B supports speech-driven video using audio, a reference image, and optional text. The official implementation also supports pose guidance.

Should I use Wan 2.2 5B or 14B?

Use 5B when you want a practical single-GPU workflow. Move to the A14B models when their higher model capacity gives you enough improvement to justify much greater memory and compute requirements.

Is Wan 2.2 better for text-to-video or image-to-video?

It supports both. Text-to-video gives the model more creative freedom, while image-to-video gives you more control over starting composition, identity, and visual design.

Your next workload belongs on Hivenet.

Pick one AI, compute, or storage workload and see the difference for yourself. Spin it up in minutes, or let our team map your fastest path to production.

Shader gradient background