ModelsWan-AIWan2.2-T2V-A14B
providerWan-AI /

Wan2.2-T2V-A14B

12.6 DZD/ second

Wan 2.2 T2V brought Mixture-of-Experts into video diffusion, and it split the work along an axis language models cannot use: time. Two fourteen-billion-parameter experts divide the denoising process between them — one handling the early steps where overall layout is decided, the other the later steps where detail is refined. Twenty-seven billion parameters in total, fourteen active at any step, so inference cost and GPU memory stay close to a single-expert model. The handover point is computed from the signal-to-noise ratio rather than set by hand, and the team published the ablation that proves the design: four configurations tested, the full two-expert version reaching the lowest validation loss.

PublicVideo720P480PMoEDiffusion
Wan2.2-T2V-A14B
ArchitectureDiffusion MoE
Context Windowvideo

Wan 2.2 T2V A14B

Two experts, one video. Twenty-seven billion parameters, fourteen active per step.


MoE, But Split Along Time

The architectural idea, and it is genuinely different from Mixture-of-Experts as language models use it.

In a language model, a router picks experts per token. Different words, different experts, all within one forward pass.

In a diffusion model there are no tokens to route. There is a denoising trajectory — a sequence of steps that starts from noise and ends at an image. So Wan 2.2 splits the experts across that sequence instead.

ExpertStageJob
High-noiseEarly stepsOverall layout
Low-noiseLate stepsRefining detail

Each expert carries about 14B parameters. Total: 27B. Active at any step: 14B.

That is the whole argument. Doubling total capacity while inference computation and GPU memory stay nearly unchanged, because only one expert runs at a time and the two never overlap.

Wan 2.2 computational efficiency: parameter count against inference cost for the two-expert design

And it matches how diffusion actually works. Early steps decide where things are and how the scene is composed — the model is working from almost pure noise and making structural decisions. Late steps decide what things look like — texture, edges, fine motion. Those are different problems, and before this one network had to do both.


The Handover Is Computed, Not Configured

A detail that separates this from a hand-tuned pipeline.

The transition point between the two experts is determined by the signal-to-noise ratio — a metric that decreases monotonically as the denoising step advances.

Not a fixed step number. Not a tunable you have to get right. The switch happens when the trajectory crosses a measurable threshold, which means it adapts rather than assuming every generation denoises at the same rate.


They Published the Ablation

Uncommon, and it is what turns the architecture from a claim into an argument.

The team tested four configurations:

ConfigurationWhat it isolates
Previous generation baseline, no MoEThe starting point
Previous model as low-noise + new high-noise expertDoes the high-noise expert alone help?
Previous model as high-noise + new low-noise expertDoes the low-noise expert alone help?
Full two-expert designBoth together

Wan 2.2 performance comparison across model configurations

The full version achieved the lowest validation loss — meaning its generated video distribution sits closest to ground truth, with better convergence.

Why that matters more than the headline number. Testing each expert in isolation against the old model is the experiment that rules out "the new model is just better trained." Both halves contribute, and the combination beats either one swapped into the old architecture. That is a real result rather than a bar chart.


Specifications

Model IDWan-AI/Wan2.2-T2V-A14B
Total parameters~27B
Active per step~14B
Experts2 — high-noise, low-noise
Expert size~14B each
TransitionDetermined by signal-to-noise ratio
Resolutions480P and 720P
TaskText to video
ReleasedJuly 2025
LicenceApache 2.0

Both resolutions are supported by the same repository — 480P and 720P from one model rather than separate checkpoints.


Capabilities

CapabilityValue
input_typestext
output_typesvideo
resolutions480P, 720P
endpoint/v1/video/generations
streamingNot applicable
deterministicNo
requires_promptYes

The Family Around It

Wan 2.2 ships as a set of task-specific models sharing the two-expert design, and knowing which is which prevents the wrong choice.

ModelTask
T2V-A14BText to video — this model
I2V-A14BImage to video
S2V-14BSpeech to video
Animate-14BCharacter animation
TI2V-5BText and image to video — dense, not MoE

The 5B model is the interesting exception. It is a high-compression dense design rather than a two-expert MoE, released specifically for more efficient deployment. If 27B is more than your hardware allows, that is the alternative within the same generation rather than a different generation entirely.

The image-to-video sibling is documented as achieving more stable synthesis with reduced unrealistic camera movements — a specific failure mode the MoE design addresses, and worth knowing if wandering camera motion is what has been spoiling your output.


Using Wan 2.2 T2V on DEVUP AI

Endpoint: POST https://api.devupai.com/v1/video/generations

Video generation is synchronous — a request may hold the connection open for several minutes. Set a generous timeout.

The response returns a signed URL in data[0].url, valid for 300 seconds, alongside a _devup object with the request cost and your remaining balance. Download the file rather than storing the URL.

Python

PYTHON
import requests

DEVUP_API_KEY = "$DEVUP_API_KEY"
MODEL = "Wan-AI/Wan2.2-T2V-A14B"

response = requests.post(
    "https://api.devupai.com/v1/video/generations",
    headers={
        "Authorization": f"Bearer {DEVUP_API_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "model": MODEL,
        "prompt": "A serene mountain lake at sunrise, with mist rising from the water and pine trees reflected on the surface.",
    },
)

result = response.json()
# result["data"][0]["url"] contains the signed URL to the generated video
video_url = result["data"][0]["url"]
video_response = requests.get(video_url)

with open("output.mp4", "wb") as f:
    f.write(video_response.content)

cURL

BASH
curl -X POST "https://api.devupai.com/v1/video/generations" \
  -H "Authorization: Bearer $DEVUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Wan-AI/Wan2.2-T2V-A14B",
    "prompt": "A serene mountain lake at sunrise, with mist rising from the water and pine trees reflected on the surface."
  }'

Requesting inline bytes instead

If five minutes is not enough for your pipeline to fetch the file.

PYTHON
response = requests.post(
    "https://api.devupai.com/v1/video/generations",
    headers={
        "Authorization": f"Bearer {DEVUP_API_KEY}",
        "Content-Type": "application/json",
    },
    json={
        "model": MODEL,
        "prompt": prompt,
        "response_format": "b64_json",
    },
)

result = response.json()
entry = result["data"][0]

if "b64_json" in entry:
    import base64

    with open("output.mp4", "wb") as f:
        f.write(base64.b64decode(entry["b64_json"]))
else:
    # Above the 20 MB inline limit the response falls back to a URL, with a note in _devup.
    # This is a delivery fallback, not an error — the request is billed normally.
    print(result["_devup"].get("note"))
    with open("output.mp4", "wb") as f:
        f.write(requests.get(entry["url"]).content)

Handle both shapes. A 720P clip can exceed the inline limit, and code that only reads b64_json fails on exactly the requests you cared about.


Writing Prompts for a Two-Expert Model

The architecture suggests how to structure a prompt, and it is a useful frame even if the model does not literally read it that way.

The high-noise expert decides layout. Where things are, how the frame is composed, what the camera is doing. Give it that: subject placement, camera movement, framing.

The low-noise expert refines detail. Texture, material, light quality, fine motion. Give it that too: surface descriptions, lighting quality, small movements.

A prompt that covers both — composition and detail — feeds both halves of the model. One that says only "a beautiful mountain lake" leaves both guessing.

Practical habits for video prompts:

Describe motion, not just the scene. A still description produces a still-feeling clip.

Name the camera movement. Slow pan, aerial, static wide, close-up. Without it, framing varies between runs for no reason you control.

State the light. Direction, quality, time of day. Nothing else contributes as much to whether a clip reads as real.

Keep the prompt focused. An overly complex brief divides attention and produces inconsistent results rather than executing everything.


480P or 720P

One model, two resolutions, and the choice is about iteration rather than quality ceiling.

Prototype at 480P. Composition, camera movement, lighting direction, and subject behaviour are all visible there, and those are the only things a draft needs to answer. Generation is faster and the file is smaller.

Render the final at 720P once the shot is right. The composition carries across; only the detail changes.

And 720P is where the inline size limit bites. A longer clip at the higher resolution is the case that falls back to a URL, which is another reason to settle the shot before stepping up.


Self-Hosting Notes

Relevant if you are running it rather than calling it.

Diffusers integration is available — the T2V, I2V, and TI2V models were all integrated at release, alongside ComfyUI support for the previous generation.

Torch 2.4.0 or later is required. If flash_attn fails to install, the documented workaround is to install the other requirements first and flash_attn last.

Prompt extension is a separate step. The reference inference process starts with a basic version that skips it — worth knowing, because prompt extension is part of how the published results were produced, and a bare implementation is not running the same pipeline.

Weights are published for both experts. Twenty-seven billion parameters to store even though only fourteen run at a time — the memory saving is at inference, not on disk.


Where It Fits

Text-to-video generation at 480P or 720P, with layout stability as the design goal.

Scenes where composition matters — the high-noise expert exists specifically to get structure right before detail is added.

Self-hosted video work, where Apache 2.0 and Diffusers integration make it unusually accessible for a model of this capability.

Prototyping and iteration, where the dual-resolution support lets you settle a shot cheaply before committing.

Not for image-to-video or character animation — those are separate models in the same family, sharing the architecture.

Not for long clips. This generation targets short video; later generations in the line extended duration substantially.


Practical Notes

Prompt for both composition and detail — the architecture splits along exactly that line.

Prototype at 480P, finish at 720P.

Set a long client timeout; generation is synchronous and runs for minutes.

Download within five minutes, or request inline bytes.

Handle both response shapes — 720P clips can exceed the inline limit.

Pick the right family member. Text-to-video, image-to-video, speech-to-video, and animation are separate models here.

If your hardware cannot hold 27B, the 5B dense model in the same generation is the alternative.


Limitations

Text input only. For image-to-video, a sibling model handles it — this one does not.

480P and 720P. No higher resolution at this generation.

Short clips. Duration was extended in later releases; this generation targets brief video.

Not deterministic. The same prompt produces a different clip each run. Keep the file.

27B on disk, 14B active. The MoE saving is in compute and inference memory, not in storage.

Prompt extension is separate. The published results used it; a basic implementation does not.

Signed URLs expire after 300 seconds.

No audio. Generated clips are silent; audio arrived in later generations of this family.

Apply your own moderation. Filter prompts on public paths and review output before publishing.