ComfyUI Removed the WAN Block Swap Node: Why Your Wan 2.2 / GGUF Workflow Just Broke (or Got Slower)

If you opened a saved Wan 2.2 image-to-video (or GGUF) workflow recently and found a red node where your block swap used to be — or the same workflow now runs but leaves half your VRAM idle and feels slower — you are not doing anything wrong. ComfyUI removed the WAN Block Swap node, and the change ripples through every workflow that depended on it.

This post explains exactly what happened, why the ComfyUI team did it, how to tell which of the two symptoms you are hitting, and the fixes that actually work as of ComfyUI v0.39.x. The source material here is the official changelog, an open GitHub regression report, and community threads — not guesses. If your goal is simply to understand what block_swap and offload_device do under the hood before it was removed, see our earlier deep-dive on how block_swap and offload_device actually work.

What Got Removed, and Why

The WAN Block Swap node was a third-party convenience node that let you choose which layers of a Wan video model stayed on the GPU (the “blocks”) and which got offloaded to system RAM, so a large model could squeeze into a smaller card. It was popular precisely because it gave hands-on control over VRAM usage.

ComfyUI’s own changelog describes the change this way: “Enhanced block swap functionality by removing potentially harmful native custom node implementations.” The ComfyUI team added the node to a deny list in the source file comfy_extras/nodes_nop.py, which effectively blacklists it from being registered. The reasoning the team has given is that ComfyUI’s built-in memory management is now expected to handle layer offloading on its own, and a parallel native implementation could conflict with it — or behave in ways the core loading path cannot account for.

The practical consequence is binary: any workflow JSON that still references the node will fail to load it, and anything that relied on its manual offloading now falls back to ComfyUI’s automatic memory estimator.

Symptom 1: Red Node and the Workflow Stops at 0%

This is the immediate, visible failure. If your workflow was built when the block swap node was still available, the saved JSON still contains its node ID and connections. On load, ComfyUI cannot instantiate the node, so you get a red “missing node” error, and queued jobs either refuse to start or hang at 0% progress because the graph is incomplete.

Here is how to confirm it and what to do:

• Confirm the node is the culprit. Look for a red node labeled “WAN Block Swap” or “WanVideoBlockSwap” in the graph. The console will typically print a missing-node or import-failed message naming the exact node type.
• Bypass it, don’t replace it. The general guidance from the community is that native ComfyUI memory management now handles offloading on its own, so in most Wan 2.2 and GGUF workflows you can simply delete the node and reconnect the model loader output directly to the sampler. If you are using the Kijai ComfyUI-WanVideoWrapper pack, that wrapper already manages memory and never needed the extra node. For the specific VRAM settings that still work on a 16 GB card, see our Wan2.2 Animate 14B BlockSwap guide.
• Reconnect cleanly. After deleting the node, wire the diffusion model output straight through, then reload the workflow. Save a fresh copy so the stale reference is gone permanently.

The screenshot-style symptom to watch for is a node that looks dark red with no defined output socket — that is the blacklist at work, not a random crash.

Symptom 2: No Error, but GGUF Models Use Only ~50% VRAM and Run Slower

This is the subtler, more confusing regression, and it is documented in GitHub issue #11081. After the block swap node was removed, users reported that GGUF models — not just Wan, but other architectures too — loaded in NORMAL_VRAM mode while using only roughly 45–55% of available VRAM (about 7–9 GB on a 16 GB RTX 4080). Before the change, manual offloading routinely pushed VRAM occupancy to 80–90%, and generation actually felt faster.

Why the slowdown? Two interacting factors, per the issue thread:

• Async offload is not implemented for ComfyUI-GGUF. The “loaded partially … offloaded” behavior you see in the console means weights are being moved to and from the GPU on demand, but the async prefetching path that would hide that latency does not cover the GGUF loader. The result is the text encoder or transformer appearing to run on CPU while the GPU idles at 0–low utilization.
• Memory estimation is now more conservative. With the manual override gone, ComfyUI’s estimator keeps more headroom, which is safer for OOM avoidance but leaves performance on the table for users who knew their exact budget.

Note that this is explicitly labeled a performance regression by the reporter and acknowledged by maintainers in the thread, who also confirmed that “LoRA pinning will be added” in a future change to address the offloaded-LoRA cost.

Diagnostic Walkthrough: Which Symptom Do You Have?

Work through these in order before changing anything. Each step is cheap and read-only.

• Check your ComfyUI version. Run git log --oneline -1 inside the ComfyUI directory, or read the version from the startup banner. The block swap removal landed in recent releases, so if you are on a current build, assume the node is gone even if you still have old workflow files that reference it.
• Search your workflow JSON. Open the raw .json and grep for block or BlockSwap or your old node’s exact type string. If it is present, you are on symptom 1.
• Watch the console on load. Lines like loaded partially … MB offloaded combined with low GPU utilization and a slow s/it point to symptom 2.
• Compare VRAM occupancy. If nvidia-smi shows your card at ~50% during a Wan/GGUF run that used to sit at 80–90%, that is the regression signature.

Understanding which bucket you are in matters because the fixes are different, and applying the wrong one wastes time.

Fixes and Workarounds That Actually Help (Right Now)

Let’s go through the options from safest to most aggressive, with the tradeoffs made explicit.

1. Delete and rewire the node (symptom 1)

The low-risk fix. Remove the stale node, connect the loader directly to the sampler, and save a new copy of the workflow. If you are on Kijai’s wrapper, this is the officially community-blessed path — the wrapper does its own memory management.

2. Remove the blacklist entry (symptom 1, if you truly need the old node)

Community users point out that editing or deleting the relevant entry in comfy_extras/nodes_nop.py restores the node. If you go this route, understand the consequences: the ComfyUI team will not support or fix a node it deliberately blacklisted, and subsequent updates may re-remove it. Treat this as a temporary bridge, not a permanent fix.

3. Use a negative --reserve-vram to reclaim headroom (symptom 2)

In the regression thread, a user reported experimenting with a negative value such as --reserve-vram -1 to “trick” the memory estimator into using more of the GPU. This can restore higher VRAM occupancy and speed, but it is described by the reporters themselves as “just a funny trick” with the explicit downside of possible out-of-memory crashes. Only try it if you are comfortable watching for OOM and understand it may destabilize other models.

4. Wait for the acknowledged fixes (symptom 2, long term)

The maintainers in the issue thread acknowledged the async-offload gap for GGUF and stated that LoRA pinning is coming. If you are not in a hurry, the cleanest outcome for the GGUF slowdown is the upstream improvement rather than a fragile local hack.

There is no one-size-fits-all answer, but the decision tree is simple: red node → rewire or remove the blacklist; slow-but-not-erroring → evaluate reserve-vram with OOM awareness, or wait for upstream.

How to Verify the Fix Worked

Whatever path you take, confirm the result instead of trusting that the error disappeared.

• Graph is clean. Reload the workflow and confirm there are no red nodes and the queue runs past 0%.
• VRAM occupancy is what you expect. Run nvidia-smi during generation. After a rewire, occupancy should reflect the model’s real footprint; after a reserve-vram tweak, it should rise toward your target.
• Speed is sane. Watch the s/it (or it/s) figure in the console. If the text encoder step is suddenly taking minutes while the GPU idles, you are still on the async-offload symptom, not an improvable one.
• Save a clean copy. Persist the fixed workflow under a new filename so the stale node reference cannot silently resurface.

If the “wait for upstream” route is your choice, bookmark the issue and re-test on a later release — the maintainers have already tied the symptom to concrete planned work.

References

• ComfyUI official changelog — the entry documenting the block swap removal.
• GitHub issue #11081 — the performance regression report for GGUF models.
• comfy_extras/nodes_nop.py — the source file that blacklists removed nodes.

If you have hit this on a different model than Wan 2.2, the same diagnosis generally applies — check your workflow JSON for stale nodes first, then look at your VRAM occupancy curve before touching launch flags.