Wan2.2 at 480p vs. 720p: Quality, Speed, and Failure Rate

Resolution is the variable everyone reaches for first.
It is also one of the easiest ways to turn a stable workflow into an unstable one without realizing why.

I ran a controlled comparison of Wan2.2 at 480p and 720p using the exact baseline I previously locked: same minimal graph, same seed, same prompt, same frame count, same sampler settings, same VAE, same 24 GB RTX 3090. The only intentional change was resolution. Everything else stayed frozen so the differences would be attributable to that single variable.

This post reports what actually changed in quality, wall-clock time, peak VRAM, and failure behavior. No marketing language. Just the measured trade-offs on consumer hardware.

If you can’t reproduce it, it’s not a workflow. Resolution is part of the contract.

Test Conditions

• GPU: used RTX 3090 (24 GB), power-limited for sustained runs

• Workflow: minimal baseline graph previously documented

• Frame count: 24 (chosen because it already surfaces temporal issues)

• Seed: fixed

• Precision: fp16

• Offloading: disabled for the pure comparison

• Prompt and negative prompt: identical

• VAE: identical file and decode settings

I generated multiple runs at each resolution to separate one-off variation from systematic behavior. Peak VRAM, total time, and visual failure modes were logged for every run.

Quality: What Improved and What Did Not

Detail and Sharpness

720p produces visibly higher spatial detail. Fine textures on clothing, hair edges, and background elements resolve more cleanly. On a large monitor the difference is obvious. On a phone it is smaller but still present.

Temporal Behavior

Higher resolution did not automatically buy better temporal consistency. The clothing-identity drift I previously characterized at 24 frames still appeared at 720p. In some runs it arrived at a similar frame number; in others it arrived slightly earlier under the increased memory pressure. Resolution is not a free upgrade for temporal lock.

Color and Contrast

Color stability was broadly comparable when the VAE remained the same. The larger failure mode was not a sudden color explosion but the same progressive softening and identity renegotiation already seen at 480p, sometimes made more noticeable because the extra detail gave the drift more surface area to show itself.

Overall Impression

720p looks more refined when the sequence holds together. When the sequence starts to fail, the failure is often more visible simply because there is more information being corrupted.

Speed: The Real Cost

Wall-clock time increased significantly at 720p. On the 3090 the jump was not linear with pixel count; the combination of larger latents, higher activation cost, and longer sampling per frame pushed total render time well beyond the 480p baseline.

For evening testing this matters. A configuration that takes twice as long cuts the number of controlled experiments I can finish after Nora goes to bed. Speed is not just a convenience metric; it is a throughput metric for learning.

VRAM and Stability

Peak VRAM rose noticeably at 720p. The 480p baseline left a usable margin on the 3090. The 720p runs climbed much closer to the ceiling. That reduced margin showed up in two ways:

1. Higher chance of near-OOM behavior if any other process was active.

2. Greater sensitivity to small graph changes (extra nodes, different custom node versions, or background browser tabs).

I could still complete clean 720p runs with the minimal graph. Comfort decreased. The card moved from “I can leave it and trust it” to “I should watch the first thirty seconds of the run.”

Failure Rate Observations

I care about failure rate more than peak prettiness.

At 480p, with the baseline settings, the known temporal failure modes appeared at a measurable but manageable frequency. At 720p the same failure modes remained present and, under memory pressure, sometimes appeared earlier or more severely. The higher resolution did not suppress the clothing-drift class of errors; it simply rendered them at higher fidelity.

This is the key practical takeaway: moving to 720p without addressing the underlying temporal and memory behavior can increase the visibility of failures rather than eliminate them.

When I Choose 480p

• Rapid iteration and variance testing

• Debugging temporal issues

• Any session where I need multiple controlled runs in one evening

• Establishing whether a new sampler, VAE, or loading method actually helps

480p is not a compromise I am ashamed of. It is the resolution that lets me learn fastest on the hardware I own.

When I Step Up to 720p

• Final checks on a configuration that already looks stable at 480p

• Client-facing or portfolio output that will be viewed larger

• Specific tests whose entire point is resolution-related behavior

I treat 720p as a deliberate promotion, not the default.

Practical Recommendations

1. Lock every other variable before you change resolution.

2. Record peak VRAM and wall-clock time at both resolutions.

3. Scrub the full sequence for identity drift; do not judge only the first twelve frames.

4. If 720p pushes you into offloading or quantization, treat those as additional variables that must be measured, not as invisible background magic.

5. Keep a 480p baseline package so you always have a fast, known-good reference.

   

Closing

480p and 720p are not just two points on a quality slider. They produce different speed profiles, different memory profiles, and different failure visibilities on a 24 GB RTX 3090. The higher resolution wins on spatial detail when everything holds. It does not automatically win on temporal stability or iteration speed.

I will continue to use 480p as the workhorse resolution for most controlled experiments and step to 720p only when the baseline behavior is already understood. That is the only way I have found to keep the comparisons honest.

Run the test. Save the settings. Show the failure.

The settings are part of the result.