ComfyUI Got Slower and Won’t Fill Your VRAM After an Update? Here’s Why (and the Flags That Fix It)

You upgraded ComfyUI, fired up the same Wan 2.2 or GGUF workflow that ran beautifully yesterday, and something is off. The generation completes, but it feels slower. Worse, when you glance at nvidia-smi, your GPU is sitting at 7–9 GB of VRAM on a 16 GB card, where it used to sit at 13–14 GB. The model fits, but ComfyUI won’t actually use the headroom you paid for.

This is not your imagination, and it is not a corrupted install. It is the fallout from a deliberate change in how ComfyUI core handles model offloading — and it caught a lot of people off guard. This guide walks through the symptom, the root cause, how to confirm it on your own machine, and the launch flags that give you back manual control (with the OOM trade-offs clearly spelled out).

First, the Symptom: Slower, With Unused VRAM

The telltale signature is a combination of three things that appear together, usually right after a git pull or an update to a recent build:

1. Throughput drops — the same workflow takes more seconds-per-iteration than before.
2. VRAM sits at roughly 45–55% of your card in NORMAL_VRAM mode, even though the model could use far more.
3. The model “thinks” for a while before sampling — a visible stall where ComfyUI seems to be computing or moving weights into memory before the first step actually runs.

This exact pattern was reported in ComfyUI issue #11081, titled “Performance Regression: GGUF models run noticeably slower with only ~50% VRAM usage after removing WAN Block Swap node.” The reporter and multiple commenters measured the same thing: a 16 GB RTX 4080 holding only 7–9 GB of a GGUF model in NORMAL_VRAM mode, with slower generation than the old manual-offloading behavior that filled 80–90% of the card.

The Root Cause: The Block Swap Node Became a No-Op

To understand what changed, you need to know what the wanBlockSwap node was and what happened to it. The node existed to let you run Wan video models on a GPU that technically cannot hold them by paging some of the model’s transformer blocks out to CPU RAM and swapping them back in during the forward pass. Up to 40 blocks could be shuffled off the card, trading speed for a lower VRAM floor.

What changed is that ComfyUI core eventually added automatic memory offloading. Core now decides how much to page to CPU based on your actual VRAM, without needing any node in the graph. Once that landed, the manual wanBlockSwap node was redundant — and, crucially, it could fight the built-in offloading, which is what produced instability. So ComfyUI core now intercepts the wanBlockSwap class and swaps in a no-op. As documented on the official node reference (comfy.icu / wanBlockSwap): “on a current ComfyUI, you’re installing a passthrough.”

The node is not broken — it is deliberately switched off. You can leave it in an old workflow and lose nothing, or delete it and lose nothing. That part is expected behavior.

The unexpected part is what came next. For many users, ComfyUI’s built-in auto-offloading turned out to be more conservative than the old manual block swap — it leaves more VRAM on the table, which in some cases means slower generation. The issue thread documents maintainers acknowledging the offloading “is due for a recalibration” and asking for benchmark data to repro the discrepancy.

Diagnose It on Your Own Machine Before Touching Anything

Before you start flipping flags, confirm the regression is actually what you’re hitting. The fastest way is to run a known workflow once and watch the numbers.

Step 1 — Watch VRAM during a real run:

watch -n 1 nvidia-smi

Run your workflow and note two numbers: the peak VRAM during sampling, and the peak during the text-encoder / model-load phase. If the sampling peak is stuck at ~50% of your card while you’re in NORMAL_VRAM mode (no --lowvram/--medvram flags), you’re seeing the conservative offload.

Step 2 — Confirm how you launched ComfyUI: check the exact command line, because the flags you did (or didn’t) pass are the entire story here.

ps aux | grep main.py

Step 3 — Check whether offload features are enabled: on a current Nvidia build, --async-offload is on by default, and dynamic VRAM is auto-enabled. These defaults are part of what changed. If you launched with no memory flags at all, you’re running the new default behavior — which is exactly the behavior people are reporting as slower.

Important caveat from the issue thread: --disable-async-offload and --disable-pinned-memory (the latter used in some tests) are performance-critical, so treat them as diagnostic toggles, not permanent fixes.

The Flags That Give You Control Back

All of these are documented in the official ComfyUI startup-flags reference. Here is what each one actually does and when it helps.

--reserve-vram (the “trick” that’s actually a real flag)

--reserve-vram <GB> tells ComfyUI how much VRAM to reserve for your OS and other software. The default is OS-dependent. People in issue #11081 discovered that passing a negative value — for example --reserve-vram -1 — effectively “tricks” the memory estimator into using more of the GPU, because the reserved amount is treated as less than the real requirement. This is the one the thread calls “just a funny trick,” and it comes with a serious caveat: squeezing the estimator too far produces OOM crashes.

How to try it:

python main.py --reserve-vram -1

Start small and validate with a real generation. If it OOMs, back off toward 0 or a small positive value. This is a heuristic, not a guaranteed win — but it is the single most direct way to push ComfyUI to use more of a card it is leaving idle.

--disable-async-offload

Async offload moves weights you’re about to use to the GPU ahead of time while earlier computation finishes. It’s on by default on Nvidia. The catch, noted explicitly by a maintainer in the thread, is that it is not implemented for ComfyUI-GGUF. So on GGUF models in particular, async offload can actually slow down the text-encoder phase rather than speed it up. Disabling it is a legitimate thing to test:

python main.py --disable-async-offload

Test both states on the same workflow and time it. On a GGUF model you may see a measurable difference; on non-GGUF models the results are less predictable.

--disable-dynamic-vram

Dynamic VRAM is auto-enabled on Nvidia (and ROCm 7.14+). It’s part of the newer automatic memory management that displaced the manual block-swap node. Disabling it reverts to estimate-based model loading:

python main.py --disable-dynamic-vram

Some users report this returns their old (fuller, faster) VRAM usage pattern. Like everything here, it’s empirical — flip it, measure, keep or revert.

One more flag worth knowing about while you’re in there: --disable-smart-memory makes ComfyUI aggressively offload to RAM instead of keeping models resident. It’s the opposite direction from what you want when the complaint is unused VRAM, but it’s useful to know the full dial exists so you don’t confuse it with the flags above.

Common Pitfalls When You Start Tuning

Pitfall 1 — Fighting the built-in offloader instead of tuning it. The whole reason the wanBlockSwap node was disabled is that manual offloading conflicts with core’s automatic offloading. Don’t go reinstall an old manual swap node and stack it on top — you’ll reintroduce the instability that got it removed. If you genuinely want manual block control, the documented route is Kijai’s ComfyUI-WanVideoWrapper, which still exposes a real, working block-swap control.

Pitfall 2 — Disabling the performance flags permanently. --disable-async-offload and --disable-pinned-memory are performance flags. Pinned memory in particular matters. Maintainers in the thread explicitly warned that these options are “performance critical.” Test them, but don’t bake them into your permanent launch script without measuring the net effect first.

Pitfall 3 — Judging the fix off the loading stall alone. The 3–5 minute “thinking before it loads” stall some users report is a separate symptom from steady-state throughput. Time the sampling iterations (seconds-per-iteration), not total wall-clock, when comparing flag configurations. That’s the number that tells you whether you actually got faster.

Pitfall 4 — Assuming every update caused it. If you roll back ComfyUI and the behavior persists, it’s not a simple regression on a single commit — the issue thread notes users who downgraded still saw the new behavior, because other components (like the Template package) also need to be downgraded in lockstep. Treat a full rollback as a multi-component operation, not a one-file swap.

Verification: How to Know You Actually Fixed It

After you’ve picked a flag combination, verify with numbers, not vibes:

1. Peak VRAM during sampling should now be meaningfully higher (closer to your card’s real capacity) than the ~50% you started from.
2. Seconds-per-iteration on an identical seed/prompt should be lower.
3. Run it three times and confirm no intermittent OOM — an estimator trick that works once and crashes on the fourth run is not a fix.
4. If you’re on a 16 GB card and the model legitimately doesn’t fit at full precision, confirm your GGUF quantization choice hasn’t quietly changed — the offloading regression and a changed quant can mask each other.

For a deeper look at how offload flags interact with your specific card, see our earlier piece on ComfyUI --lowvram vs --novram vs --normalvram, and for the block-swap basics themselves, our guide on how block_swap and offload_device actually work in ComfyUI.

Conclusion

The slowdown is real, it’s caused by a deliberate architectural change (the wanBlockSwap node becoming a no-op in favor of core auto-offloading), and the fix is a matter of re-taking manual control over a memory estimator that is currently more conservative than the old behavior. The levers are --reserve-vram (including the controversial negative-value “trick”), --disable-async-offload for GGUF models where async offload isn’t implemented, and --disable-dynamic-vram to revert to estimate-based loading. Every one of these is empirical — measure seconds-per-iteration and peak VRAM, watch for intermittent OOM, and don’t permanently disable performance flags you haven’t A/B tested. The maintainers have flagged the offloading as due for recalibration, so the clean fix may arrive upstream — but until it does, these flags are the difference between a card that’s half-used and one that’s earning its price.