ComfyUI Is Wasting Your VRAM: How –reserve-vram (Even Negative Values) Reclaims GPU Memory

If you upgraded ComfyUI recently and noticed your generation times got slower while nvidia-smi showed your GPU sitting at half capacity, you are not imagining it. The shift to dynamic VRAM and async offload as default behaviors changed how ComfyUI decides how much video memory to use — and on a surprising number of setups, it now under-utilizes the card instead of maximizing it.

This guide explains what the memory flags actually control, why “just disable dynamic VRAM” is not always the right answer, and how the --reserve-vram flag — including its counterintuitive negative values — can force ComfyUI to use the GPU memory you already paid for. Everything below is documentation analysis and current maintainer guidance, not fabricated benchmark numbers.

Why your GPU sits idle after the update

ComfyUI’s memory management has changed in three ways that interact in non-obvious ways:

• Dynamic VRAM is now on by default. Historically ComfyUI loaded entire model weights into VRAM up front. With dynamic VRAM enabled, it loads weights in smaller chunks and offloads them to system RAM when the card would otherwise exceed its budget. This is great for preventing out-of-memory (OOM) crashes, but it means the GPU is often kept deliberately below full occupancy.
• Async offload is now on by default — but not everywhere. Async offload moves weights the model is about to use onto the GPU ahead of time, overlapping the transfer with in-flight computation. The catch, confirmed by maintainers, is that it is not implemented for ComfyUI-GGUF. So users running quantized GGUF models get none of the speedup, and can even feel like the new default is slower than the old manual offload behavior.
• VRAM estimation became more conservative. To avoid the OOM reports that flooded the issue tracker, the memory estimator now leaves more headroom. The net effect for users who had a tuned, almost-full-card setup is that ComfyUI now “plays it safe” and leaves 25–50% of the card unused.

The result is the regression described in Comfy-Org issue #11081: GGUF models that used to run at 80–90% VRAM now sit at ~45–55%, with generation speed that feels slower despite the lower memory pressure.

Diagnosing whether you actually have this problem

Before you change any flag, confirm the symptom. This is a two-minute check, and it is the difference between fixing a real problem and cargo-culting a launch argument you don’t need.

Run your normal workflow and, while it is sampling, open a second terminal and run:

nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu --format=csv

You are looking for two patterns:

1. Low memory utilization. If memory.used is stuck well below memory.total (say, 8 GB used on a 16 GB card) while the model is actively sampling, ComfyUI is intentionally holding back.
2. Low GPU utilization paired with high system RAM usage. If the card is idle while your system RAM climbs, weights are being offloaded to CPU and streamed back in — the classic offload-thrash signature. The earlier post on ComfyUI system RAM OOM walks through the RAM side of this same mechanism.

If instead your card is pegged near 100% and times are fast, the defaults are working for you — leave them alone. The flags below are for people whose card is demonstrably being under-used.

The –reserve-vram flag and how negative values work

--reserve-vram tells ComfyUI to keep a fixed amount of GPU memory in reserve rather than using it for model weights. Its original purpose is to leave room for your operating system, display manager, browser, or other applications that share the GPU, so that ComfyUI doesn’t grab every last byte and starve your desktop.

It accepts a value in gigabytes, for example:

python main.py --reserve-vram 1.5

This reserves 1.5 GB for everything else and lets ComfyUI fill the remainder. So far, so intuitive. The part that surprises people is that the value can be negative. A Comfy-Org maintainer, responding directly to a performance-regression report in issue #11568, suggested exactly this:

“Try varying the --reserve-vram setting to see if it helps. You can go negative if you want it to use more VRAM than the default.”

A negative reserve effectively flips the flag from “keep this much free” to “use this much extra beyond the estimator’s conservative guess.” For example, --reserve-vram -1 nudges ComfyUI to treat the card as if it had roughly an extra gigabyte of usable space, pushing the memory allocator back toward full occupancy. The trade-off, as the maintainer’s phrasing implies, is that you take on the risk the estimator was trying to protect you from: a possible OOM.

Think of it as a dial between two failure modes. Too much reserve wastes capacity; too aggressive a negative value invites CUDA out of memory. The right setting is the most negative value your specific workflow tolerates without crashing.

How to tune it safely (step by step)

The goal is to find the sweet spot where your card runs near full capacity without OOM. This is an iterative process, not a one-shot fix, and it depends entirely on your model, resolution, and workflow:

1. Baseline first. Run your workflow with default settings and record nvidia-smi peak memory and iteration time. You need numbers to know if a flag actually helped — “feels faster” is not a measurement.
2. Reduce the reserve gradually. If you previously set --reserve-vram 1 or higher, first try lowering it toward 0 and re-measure. For many users, simply dropping an unnecessarily high reserve is enough.
3. Step into negative territory slowly. Start at --reserve-vram -0.5, then -1, re-running your workflow each time. Watch for two things: peak VRAM (should edge closer to memory.total) and any OOM error.
4. Back off at the first OOM. If a workflow that used to run cleanly now throws CUDA out of memory, you have passed the safe limit. Move back up one step and keep that value.
5. Confirm the fix persisted. Re-launch and verify the flag is being picked up — ComfyUI prints its startup arguments to the console, and you can always run with --help to confirm the flag name for your version, since flags have shifted across releases.

Two caveats worth stating plainly. First, negative reserves are a workaround, not a promised interface — the maintainer framed it as something to try, and its behavior can change between versions. Second, aggressive negative values on a card that is also driving your display can make the entire desktop stutter or kill other GPU apps, because you are deliberately reducing the headroom those apps rely on.

When to use native formats instead of fighting dynamic VRAM

Here is an important nuance many guides skip: the Comfy-Org team’s own recommendation is not “disable dynamic VRAM” but “try native formats instead.” A changelog entry for the dynamic VRAM work is explicit — the project added a prompt to “try native formats instead of disabling dynamic VRAM.”

The reason ties back to the GGUF gap. Dynamic VRAM and async offload work best with native (non-GGUF) model formats such as fp8, which are what the core team optimizes against. GGUF, which lives in a separate library (ComfyUI-GGUF), does not yet get the async-offload or memory-pinning benefits. So if you are running a GGUF quantized video model and seeing under-utilization, you have two coherent paths:

• Stay on GGUF and tune memory by hand — using --reserve-vram (possibly negative) to push occupancy back up, accepting that you manage the OOM risk yourself.
• Switch to the native fp8 weight if one exists for your model, letting the new memory manager do what it was designed to do. This is often the lower-friction fix in the long run, at the cost of a larger download and slightly different quality/speed characteristics.

There is no universally correct answer — it depends on whether a native weight is available for your model and how much VRAM you have to spare. What is universal is the diagnosis: know whether your card is actually under-used before you reach for a flag at all.

Pitfalls that make people think the flag “doesn’t work”

A few common failure modes make tuning look ineffective when the real problem is elsewhere:

• Wrong config is being read. If you are on Comfy Desktop, launch flags in the command line may be overridden by desktop settings, or vice versa. Confirm which configuration actually governs your instance before concluding the flag is broken.
• The bottleneck isn’t VRAM. Offload improves memory, not raw compute. If your card is memory-constrained but also compute-bound, reclaiming VRAM may not speed anything up at all. Check GPU utilization, not just memory, before attributing slowness to memory.
• Text encoder on CPU. A separate regression had text encoders (like umt5) running on CPU, which tanks encode time regardless of how much VRAM you reclaim. If nvidia-smi shows ~0% GPU during the encode step, the problem is device placement, not memory budget.
• Mixing flags that fight each other. Combining --reserve-vram with --lowvram or --novram produces contradictory instructions to the allocator. Use one memory strategy, not several at once. The earlier guide on ComfyUI offload flags explains what each mode does before you stack them.

Conclusion

The move to dynamic VRAM and async offload made ComfyUI dramatically more robust for memory-constrained setups, but the trade-off is that some cards now run well below capacity by default — and GGUF users, in particular, get the conservative side of the deal without the async-offload payoff. Before reaching for a fix, measure your card. If it is demonstrably under-used, --reserve-vram is the surgical dial: lower your existing reserve first, then step into negative values cautiously, backing off at the first OOM.

If a native fp8 weight exists for your model, that is often the cleaner long-term fix than hand-tuning a negative reserve — it lets the new memory manager do what it was built to do. Whichever path you take, the guiding principle is the same: treat VRAM tuning as a measured experiment with a recorded baseline, not a guess.