Wan Chunk FeedForward

If you're running Wan video and bumping into out-of-memory errors right at the edge of your card, this is one of the nodes that can get you under the line. It reduces peak VRAM by chunking the feedforward (MLP) activations inside the model, computing them in pieces instead of all at once. When a heavy edit is spiking your memory at exactly the wrong moment, that peak reduction is sometimes the whole difference between a finished render and a crash.

It's from kijai's KJNodes, and kijai is the person who wrote the ComfyUI integration for a lot of the Wan-family models, so these little VRAM nodes come straight from the person who knows where the memory actually goes. The KB records a user measuring this node (paired with the Sage Attention patch) saving "almost 4GB" of peak VRAM on a 1080p object-removal workload, that's the kind of headroom it buys.

How it works

The feedforward layers in a transformer briefly hold large intermediate activation tensors. This node splits that computation into chunks and processes them sequentially, so the model never materializes the whole activation at once, and the peak drops. You pay a little speed for the extra loop iterations, and you save memory. That's the trade, and it's usually a good one when the alternative is not running at all.

Heads up: the node's own description flags it as experimental and warns it may change the model output. Chunking is not perfectly free, numerically, so treat it as a "make it fit" tool, not something you leave on when you have VRAM to spare.

The inputs and outputs that matter

• model - the Wan model to patch; patched model out.
• chunks (default 2, range 1–100) - how many pieces to split the feedforward into. More chunks = lower peak VRAM but more overhead (slower). Start at 2 and only raise it if you're still OOMing. Cranking it to 100 will save the most memory and hurt speed the most.
• dim_threshold (default 4096, range 1024–16384) - only chunk feedforwards whose dimension exceeds this, so small layers that wouldn't benefit are left alone. The default is reasonable; lower it to chunk more aggressively, raise it to chunk less.

The output is model, wired into your sampler.

Installing it

You'll have KJNodes already if you're doing Wan work. If not: ComfyUI Manager → search KJNodes for ComfyUI → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-KJNodes
pip install -r ComfyUI-KJNodes/requirements.txt

Restart ComfyUI. No extra dependency for this one; it's a pure memory-management patch on the model you're already running.

Common issues

Still OOMing. Chunk harder: raise chunks, and consider lowering dim_threshold so more layers get chunked. Then stack it with the other Wan memory tricks, the WanVideo Mem Eff Sage Attention patch, fp8 weights, block swapping, since the real wins come from combining them (that "almost 4GB" figure was this node plus Sage Attention together).

The output looks slightly different than without it. That's the documented behavior, chunking the feedforward can nudge the result. If exact reproducibility matters, turn it off when you don't need the memory. It's a fit-it-under-the-limit tool.

It got slower. Expected. You're trading throughput for peak memory. If you have VRAM headroom, you don't need this node at all, and you shouldn't pay the speed cost.

Which one first? If you're stacking memory nodes, this and the Sage Attention patch are complementary, feedforward chunking attacks the MLP activations, Sage attacks the attention memory. Use both when you're really tight.