WanAnimate2Cache

Wan Animate 2 - Alibaba's motion-transfer model, in ComfyUI core since August 2026 - spends most of every sampling step recomputing the same thing: the pose branch, i.e. the activations from your driving video, which don't change between steps. This node notices that and caches them. The payoff is roughly half the generation time. The catch is spelled out in the node's own description: about 12.5 GB of system RAM at 480×832, 81 frames, in bf16 - and it scales with resolution and length.

Where it goes

It's a model wrapper, pure and simple. Load your Wan Animate 2 model, pass it through WanAnimate2Cache, and feed the output MODEL to the sampler - the same model your WanAnimate2ToVideo node produces conditioning for. Nothing else about your graph changes; you've just memoized the expensive part.

The two dials that matter

• device - cpu (RAM) or gpu (VRAM). Default is cpu for a reason: at typical sizes the cache won't fit in VRAM alongside a 14B model. gpu can be faster if it does fit - and if you suddenly start hitting VRAM errors, this is the first thing to flip back.
• dtype - default stores activations in the model's compute dtype; int8 halves the cache, int4 quarters it, with a "convrot" trick to keep accuracy. Start at default and compress only if RAM is actually tight.

How the caching works

The pose branch's per-block inputs get stored - storing the input rather than its K/V halves the memory, and re-projecting K/V on read costs only ~4% of re-running the block. Slots are keyed per distinct pose sequence, least-recently-used ones get evicted when the store device runs low on memory, and everything is freed when the graph finishes. You're not leaking; the cache is scoped to the run.

The gotcha that bites everyone

Context windows. If you're generating long video with context windows, each window is cached separately, so RAM scales with the window count. Worse: use a uniform schedule and the windows shift every step, so nothing ever recurs and the cache never hits - you pay the RAM and get none of the speedup. The node description is blunt about it: use the static_standard schedule. If you're wondering why the node "isn't doing anything", that's why.

Troubleshooting

• "Why is my RAM pegged?" - expected, up to ~12.5 GB at the reference settings. Drop resolution or length, or switch to int8/int4.
• "No speedup?" - check that you're on a static_standard schedule, and that the model is actually the Wan Animate 2 one. This cache does nothing for the plain Wan model.
• It's flagged is_experimental in core, so expect the knobs to move as it matures.

If you've ever sat through an Animate render thinking "that pose branch is doing the same math every single step" - this node is that complaint, fixed.