The first time it happened I almost posted the clip.
I had a clean prompt, a locked seed, a minimal graph I trusted, and a 24-frame target on the 3090. The preview looked solid. Subject held together. Lighting stayed consistent. Motion felt intentional instead of wobbly. I let the full run finish, dropped the MP4 into the timeline, and watched it once with the volume off.
Frames 1 through 11 were good.
Frame 12 was where the jacket changed color.
By frame 15 the collar had decided on a new shape.
By frame 20 the whole torso was negotiating a different outfit.
The render looked great. For eleven frames.
That single failure taught me more about Wan2.2 temporal behavior than a dozen successful highlight clips. This post is the post-mortem: what I saw, what I measured, what I wrongly blamed, and the concrete checks I now run before I trust any longer sequence.
The Exact Setup That Produced the Failure
I keep the conditions boring on purpose so the failure has nowhere to hide.
GPU: used RTX 3090 (24 GB), power-limited for sustained runs
Resolution: 480p
Frame count: 24
Seed: fixed
Workflow: the smallest graph I had already validated on shorter clips
Precision: fp16, no quantization, light offloading only if the peak threatened the ceiling
Prompt: simple, single-subject, controlled background
The short 8-frame and 12-frame versions of the same prompt and seed had been stable enough that I treated 24 frames as a safe next step. That assumption was the first mistake.
What the Failure Actually Looked Like
It was not random noise. It was structured drift.
Early frames: clothing color, fabric texture, and silhouette stayed consistent with the prompt.
Mid sequence: subtle hue shift on the main garment, then a change in collar geometry.
Later frames: the model appeared to “re-sample” the clothing identity while keeping the face and overall pose roughly intact.
The background remained more stable than the subject. That pattern mattered. It suggested the problem was not global latent collapse but a selective failure in how identity was maintained across frames.
I exported the individual frames and laid them out in order. The transition was not a single catastrophic jump. It was a progressive renegotiation that became obvious only when you watched the sequence at speed and then scrubbed it frame by frame.
The Things I Blamed First (and Why They Were Wrong)
1. The Prompt
I did what most people do. I added more descriptive clothing language. I tried negative prompts aimed at “clothing change,” “outfit shift,” and “inconsistent wardrobe.” None of it fixed the drift. The failure was not that the model lacked clothing instructions. It was that the temporal mechanism was not holding the identity it had already established.
2. Not Enough Steps
I increased steps. The individual frames got slightly cleaner. The clothing still changed. More steps made the early frames prettier and did nothing to stop the mid-sequence identity shift.
3. The Sampler
I swapped samplers. Some produced softer motion. Some produced sharper frames. The clothing drift remained. Sampler choice affected texture and motion character far more than it affected long-range identity lock.
4. Seed Luck
I tried nearby seeds. A few delayed the failure by a couple of frames. None eliminated it. The problem was not a single unlucky seed; it was a systematic weakness that appeared once the sequence length crossed a threshold my shorter tests had never reached.
What Actually Correlated With the Failure
After the obvious suspects failed, I started changing one variable at a time and logging the frame at which the clothing identity broke.
The strongest correlations I found in that series:
Frame count. Sequences at 8–12 frames rarely showed the failure. At 16 frames it appeared occasionally. At 24 frames it became common.
Memory pressure. Runs that pushed closer to the 24 GB ceiling showed earlier or more severe drift. Runs with more headroom sometimes delayed it.
VAE behavior. When I isolated the decode stage and compared different VAE handling, the visual character of the drift changed. The VAE was not the sole cause, but it was clearly involved in how the failure presented.
I am careful here. Correlation is not a full causal proof. What I can say with confidence is that the failure was reproducible under the logged conditions and that certain variables moved the failure point in consistent directions.
The Practical Checks I Now Run
Before I trust a workflow for anything longer than a short test, I do the following:
Generate a short sequence (8–12 frames) and a longer sequence (24+ frames) with the identical seed and settings.
Scrub both frame-by-frame looking specifically for identity drift in clothing, hair, and facial features.
Record peak VRAM and note whether the longer run approached the ceiling.
Save the failed longer output with the same care I save the good short one. The failure is data.
Only then decide whether the workflow is ready for further variation or whether it still needs isolation work.
This sounds slow. It is slower than posting a pretty 11-frame loop. It is much faster than discovering the same clothing-change bug on a client deadline.
Why This Failure Matters Beyond One Bad Clip
Temporal consistency is not a cosmetic extra. It is one of the main reasons people abandon video workflows after the novelty wears off. An image model can hide a lot of sins in a single frame. A video model has to keep the story coherent across time.
When a render looks great for eleven frames and then quietly rewrites the subject’s wardrobe, the problem is not that the user wrote a bad prompt. The problem is that the system’s ability to maintain identity has a limit, and that limit is reachable on consumer hardware under ordinary settings.
Documenting the limit is more useful than pretending it is not there.
What I Changed in My Own Practice
I stopped treating short successful previews as evidence that a longer run would hold. I started budgeting frame count as a first-class cost, the same way I budget resolution and precision. I also began keeping a small library of “known failure seeds” so I could re-test the same hard cases after changing model loading, VAE handling, or memory settings.
The eleven-frame failure became a regression test.
Closing
The render looked great. For eleven frames.
Then it taught me the difference between a lucky preview and a workflow I could actually trust.
I still keep that failed MP4. It is more instructive than most of the clean clips I generated the same week.
Run the test. Save the settings. Show the failure.
If you can’t reproduce it, it’s not a workflow.
