native WanvideoBlockswap
Park half of Wan's transformer in system RAM and stop OOMing
- model
- MODEL
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 throughblocks_to_swapget 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.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| blocks_to_swap | INT | 200–40 | Number of transformer blocks to swap, the 14B model has 40, while the 1.3B model has 30 blocks |
| offload_img_emb | BOOLEAN | false | Offload img_emb to offload_device |
| offload_txt_emb | BOOLEAN | false | Offload txt_emb to offload_device |
| use_non_blocking | BOOLEAN | false | Use non-blocking memory transfer for offloading, reserves more RAM but is faster |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |