Nodes/ComfyUI_NativeBlockSwap/native WanvideoBlockswap
ComfyUI Node

native WanvideoBlockswap

Park half of Wan's transformer in system RAM and stop OOMing

By lum3on·Created 8 months ago·Updated 4 months ago· 1
native WanvideoBlockswap
  • model
  • MODEL
blocks_to_swap20
offload_img_embfalse
offload_txt_embfalse
use_non_blockingfalse

The name is basically a job description. Wan 2.1 and 2.2 are big diffusion transformers - the 14B alone has 40 blocks and a serious appetite for VRAM, which is why your 8GB or 16GB card OOMs the moment you push past 81 frames at 720p. This node fixes that without touching quality: it takes the diffusion model, parks most of its transformer blocks in system RAM, and lets your GPU keep only what it's actually working on. Same weights, bit for bit. You're just changing where they sit.

That's the appeal, and it's a genuinely popular move in the Wan community - one r/StableDiffusion regular put block swap "right up there with SageAttention" as a must-use for Wan workflows. The trade is a small, PCIe-bound slowdown. On a fast setup that's been measured at "a few percent"; the bigger point is that offloading makes the model fit in the first place. Think of it as the residency cousin of the "only quantize if it doesn't fit" rule from the KB - a way to gain VRAM headroom before you start dropping precision.

How it works

One class, and it's a reimplementation of the block swap from Kijai's WanVideoWrapper, wired into ComfyUI's native loader path instead of a whole wrapper. It clones your model and registers a callback that fires when the model loads onto the GPU (the ON_LOAD patcher hook). At that point it walks the transformer's blocks list: blocks 0 through blocks_to_swap get moved to ComfyUI's offload device - system RAM by default - and the rest stay on the GPU. Then, optionally, the text and image embeddings get offloaded too, the CUDA cache is emptied, and you get a patched model back.

Two honest caveats. First, the callback only acts if your model is a Wan 2.1/2.2 base (WAN21/WAN22 in the source), which is exactly what the native ComfyUI Wan loaders give you - so it covers 2.1, 2.2, VACE, Camera, HuMo, Animate and S2V variants per the README, but nothing else. Second, this is the static version: blocks are parked at load time and ComfyUI's own memory management pages them back as the sampler runs. It's not the rolling "preload the next block while the current one executes" trick some blockswap writeups hype. Don't expect magic; expect a smaller VRAM ceiling in exchange for some RAM and a bit of transfer time.

The inputs that matter

  • model (MODEL): your Wan diffusion model from the checkpoint or UNet loader. Wire the node's output into the sampler, not your original loader - the node returns a patched clone.
  • blocks_to_swap (0–40, default 20): the dial that does the work. The 14B model has 40 blocks, the 1.3B has 30 - so on the little guy anything above 30 is dead weight. Start around 8–12 and raise until your render fits; every block you park is one you pay PCIe transfer for. (Minor code quirk: indices 0 through blocks_to_swap get offloaded, so a 0 still sends the very first block away.)
  • offload_img_emb / offload_txt_emb: shove the embeddings into RAM too. A few hundred MB more off for basically no downside.
  • use_non_blocking: async memory copies, faster but reserving more RAM. Flip it if you have RAM to spare.

Output is a single MODEL socket - straight into your sampler.

Installing it

ComfyUI Manager, search "ComfyUI_NativeBlockSwap", or the old-fashioned way:

cd ComfyUI/custom_nodes
git clone https://github.com/lum3on/ComfyUI_NativeBlockSwap.git
cd ComfyUI_NativeBlockSwap
python -m pip install -r requirements.txt

Restart ComfyUI and it appears as "native WanvideoBlockswap" under the ComfyUI_NativeBlockSwap category. The entire Python dependency is tqdm, so there's no venv archaeology or Triton ordeal - and no model downloads, since it works on the Wan checkpoints you already have.

Where people get burned

The number one failure mode is using it when you don't need it. If your card already fits the model, block swap buys nothing and just adds transfer overhead - slower for no gain. Reach for it when the model genuinely doesn't fit or you want headroom for bigger resolutions and longer clips.

The second is swapping into the wrong kind of memory. GPU↔RAM bandwidth is roughly a tenth of VRAM bandwidth, so you're now PCIe-bound; that's fine, but if your system RAM is short and Windows starts paging to disk, you've gone from "a few percent slower" to "20 minutes a step." Keep it in RAM, not swap.

And if nothing visibly happens at all: you fed it a non-Wan model (the callback silently no-ops), or you wired the original loader's MODEL into the sampler instead of the node's output. It's a small, young pack from a new author - one node, no ecosystem - but the one thing it does, it does cleanly. On an 8–16GB card, it's worth the 30 seconds to install.

CategoryComfyUI_NativeBlockSwap

Inputs (5)

NameTypeDefaultDescription
modelMODEL
blocks_to_swapINT200–40Number of transformer blocks to swap, the 14B model has 40, while the 1.3B model has 30 blocks
offload_img_embBOOLEANfalseOffload img_emb to offload_device
offload_txt_embBOOLEANfalseOffload txt_emb to offload_device
use_non_blockingBOOLEANfalseUse non-blocking memory transfer for offloading, reserves more RAM but is faster

Outputs (1)

NameTypeDescription
MODELMODEL