Wan 2.2 on 16GB VRAM: Fix Slow GGUF Offloading and Reclaim Wasted GPU Memory

You paid for a 16 GB card, and you expect Wan 2.2 to use it. So it’s frustrating when you open a monitoring tool mid-generation and watch your VRAM sit at roughly 7–9 GB while generation crawls. You aren’t out of memory, you aren’t crashing — you’re just slow, and a chunk of your GPU is sitting idle. This is a real, reported issue, not a misconfiguration on your end, and it has a name and a fix path.

This article covers the recent GGUF offloading regression in ComfyUI, how to confirm you’re affected, the knobs that actually matter (blocks_to_swap, offload_device, and the launch flags), and a few diagnostics that will tell you which lever to pull. Everything here is grounded in upstream issue trackers and official documentation. Where I describe a setting or a symptom, I link to where it’s documented so you can verify it yourself before changing anything.

First, what changed: the deprecation of the WAN Block Swap node

For a long time, the WanVideoBlockSwap node in Kijai’s ComfyUI-WanVideoWrapper was the primary way to control how much of a Wan model stayed in VRAM versus being swapped to CPU memory. The node produced a block_swap_args dictionary that you handed to the model loader, letting you specify exactly how many transformer blocks to offload. This is documented in the node’s guide: the node lets you “specify a number of transformer blocks to swap to CPU memory, with additional settings to configure offloading of specific model components.”

That node has since been removed and deprecated in the current ComfyUI core path. The consequence is spelled out in ComfyUI issue #11081: after the Block Swap node was removed, GGUF models “now only use ~45–55% of VRAM (~7–9 GB on a 16 GB 4080) even in NORMAL_VRAM mode.” In other words, the manual offloading behavior that used to hit 80–90% VRAM is gone, and default automatic offloading is more conservative — leaving performance on the table.

This matters because of a subtle truth in the issue thread: GGUF in ComfyUI does not currently take advantage of async offload or memory pinning. One maintainer-adjacent commenter states it plainly: async offload “is not implemented for ComfyUI-GGUF,” and “neither is the recent memory pinning feature.” So a GGUF-loaded Wan 2.2 model falls back to a slower, more conservative memory path than a native fp8/fp16 load, and the deprecated Block Swap node used to be the workaround for exactly this.

How to confirm you’re affected

Before touching any setting, collect two numbers during an actual generation. Start ComfyUI with the frontend, load a Wan 2.2 GGUF workflow, and run a short video (for example, 640×480 at 81 frames, which is the configuration referenced in the issue thread). While it’s generating, watch VRAM in nvidia-smi or a panel like Crystools.

watch -n 1 nvidia-smi

Two signals, combined, point at the regression:

• VRAM stays in the 45–55% band on a card that previous versions filled to 80%+.
• Generation takes noticeably longer from a cold start than it used to, with a “calculating” or load phase before the model actually lands in VRAM.

The issue report also shows a useful diagnostic line from the console: a log entry like loaded partially: 3114.55 MB usable, 1106.95 MB loaded, 3404.00 MB offloaded. If you see a large “offloaded” figure alongside low utilization, that’s the conservative offloarding at work — the model is being pulled to CPU that a fuller card could hold.

The levers that actually move memory

blocks_to_swap and offload_device in WanVideoWrapper

If you want the manual control back that the deprecated node used to provide, the same concepts now live on the model loader itself. ComfyUI-WanVideoWrapper exposes a blocks_to_swap setting — the number of transformer blocks moved to CPU — alongside an offload_device option that controls where offloaded weights live (typically CPU vs. “main device”). The block-swap node’s own documentation describes the mechanism: “specify a number of transformer blocks to swap to CPU memory” to reduce VRAM usage.

The practical rule: if your card has VRAM to spare and you’re seeing the conservative half-utilization, reduce the number of blocks being swapped (or set blocks_to_swap to 0) so more of the model stays resident. The trade-off is always the same — fewer blocks swapped equals lower VRAM pressure removed but potentially higher peak VRAM. On a 16 GB card running the 14B model, keep an eye on nvidia-smi and back off one block at a time if you creep toward an out-of-memory error.

The –reserve-vram trick (documented, use with care)

The issue thread surfaces a genuinely useful hack: negative values for the --reserve-vram launch flag. ComfyUI reserves a chunk of VRAM and sizes the model load around that estimate; passing a negative value (for example --reserve-vram -1) “tricks” the current memory estimation into using the GPU more fully — with the author’s own caveat that it risks OOM if you overdo it. This is presented in the issue itself as “just a funny trick,” so treat it as a diagnostic, not a permanent config.

python main.py --reserve-vram -1

The flags to test when diagnosing

The issue reporter isolated the behavior by toggling two launch flags: --disable-pinned-memory and --disable-async-offload. Since GGUF already skips async offload and memory pinning, these flags are diagnostic rather than fixes, but they’re worth knowing. More importantly, the thread contains a maintainer note that pinned memory is “performance critical” — so if you’re on native (non-GGUF) weights, you generally want pinning on, not off.

Does this affect you, or is it something else?

It’s easy to misdiagnose slow generation. Before you conclude it’s the regression, rule out three non-causes:

• Thermal throttling. A card that’s hitting its thermal ceiling drops clocks, which looks identical to “slow” in the frontend. Check nvidia-smi for temperature and clock speed before blaming ComfyUI.
• The text-encoder tax. The issue thread notes the Wan text encoder “takes way longer with async offload turned on.” If your bottleneck is at the start of a run, it may be the encoder load, not the diffusion model.
• System RAM spillover. If your system RAM is small relative to the model, offloaded blocks and the model’s overflow land on a slow page cache. free -h during a run will tell you if you’re spilling to disk.

If none of those apply and you’re on a recent ComfyUI with a GGUF Wan 2.2 model that won’t fill your card, you’re most likely on the reported regression path.

A practical recovery sequence

Here’s a repeatable order of operations for a 16 GB card running Wan 2.2 GGUF:

1. Baseline. Run the workflow once and record VRAM utilization and wall-clock time. Watch nvidia-smi and note the peak and the average.
2. Check for the offload line. Look for the loaded partially / offloaded log line described above to confirm conservative offloading is active.
3. Reduce blocks_to_swap incrementally (toward 0) on the loader, re-running a short test after each change, until VRAM utilization rises toward a healthy band without tripping OOM.
4. Only if needed, test --reserve-vram -1 on a short run to see whether fuller utilization actually translates to faster wall-clock time — then revert unless the gain is meaningful and stable.
5. Verify stability with your real production resolution and frame count, since higher resolution and longer videos raise peak VRAM and can turn a “safe” setting into an OOM.

Conclusion

Slow Wan 2.2 GGUF generation on an under-filled GPU is not your imagination, and it’s not a driver problem you need to chase. It’s a documented offloading regression that followed the deprecation of the WAN Block Swap node, and it shows up as a card stuck at roughly half utilization. The fix is a matter of measuring first — VRAM, offload log lines, and wall-clock time — then pulling the right lever: blocks_to_swap, offload_device, and, when you understand the OOM risk, the --reserve-vram flag.

Because this is an active upstream issue, the behavior will likely change as the ComfyUI core improves GGUF offloading. Track issue #11081 and the official Wan2.2 memory optimization announcement for updates before you bake any workaround into your production launch script. If you’re already deep into video-generation tooling on this hardware, read our guide to running Wan2.2, CogVideoX, and Mochi on consumer hardware, and the piece on Wan2.2-Animate and what it means for local motion generation.

Note on evidence: this article is a documentation and source-based analysis of a reported upstream regression. No benchmark numbers here are invented — every figure (the ~45–55% utilization, the 640×480 / 81-frame reference, the offloaded log line, and the --reserve-vram trick) is quoted directly from the linked GitHub issue and official sources, so you can verify each claim for your own environment.