ComfyUI Out of Memory After Updating: Fix Dynamic VRAM and Pinned Memory Regressions

You updated ComfyUI to a recent build, restarted it, and suddenly workflows that ran fine yesterday now die with a CUDA out of memory error — even though nvidia-smi shows gigabytes of VRAM still free. The generation hangs at “Model Initializing…”, or ComfyUI crashes the moment you switch from one checkpoint to another. It is not your hardware, and it is not your workflow. It is almost certainly the new memory-management code that ComfyUI now enables by default.

This guide walks through the two features causing the most post-update OOM reports — Dynamic VRAM and pinned memory — how to diagnose which one is biting you, and the exact launch flags that restore stability. Everything below is grounded in the official Dynamic VRAM announcement and the ComfyUI startup-flags documentation, so you can verify each flag against your own install.

What Changed: Dynamic VRAM Is Now On by Default

Dynamic VRAM is ComfyUI’s new memory optimization and is now enabled by default in recent stable builds. Its goals are genuinely good: lower system RAM usage, faster execution on memory-constrained hardware, faster model loads, and — ironically — the elimination of VRAM out-of-memory errors caused by insufficient weight offloading.

The mechanism is the part that trips people up. Dynamic VRAM streams model weights between system RAM and the GPU more aggressively than the older estimate-based allocator did, and it intentionally holds more weights in VRAM when headroom exists. The official announcement is explicit that “higher VRAM usage is normal due to using VRAM more effectively.” On most single-GPU Nvidia Linux and Windows setups this works well.

But when it interacts badly with a specific driver, a multi-GPU configuration, or a custom node that assumes the old allocation behavior, the failure mode looks exactly like a memory leak or a false OOM. The symptoms users report are consistent and reproducible:

• OOM on model switch. ComfyUI crashes when you swap from one checkpoint to another (for example, Flux Klein base to the non-base variant) without fully restarting the process, even with tens of gigabytes of VRAM free.
• Hang at “Model Initializing…”. The queue stalls before any sampling begins.
• TensorRT node breakage. Nodes such as ComfyUI_TensorRT and ComfyUI-Rife-Tensorrt fail with Cuda Runtime allocation errors under Dynamic VRAM.

If any of these appeared immediately after an update, treat the new allocator as the prime suspect before you touch resolution, batch size, or sampler settings.

Diagnose Before You Disable: Is It Dynamic VRAM or Pinned Memory?

Two related features shipped close together, and the r/comfyui threads that walk people through fixes nearly always test them in a specific order. Follow it and you will find the narrowest fix instead of nuking both features at once.

1. Check the trigger. Did the OOM start after a git pull / portable updater run, with no workflow or model changes? If the answer is yes and you are on a single GPU, it is a memory-management regression, not a workflow problem.
2. Rule out multi-GPU first. Several reports resolved simply by pinning --cuda-device to one GPU at startup. If you run multiple GPUs, try this before disabling anything — it costs you nothing and keeps Dynamic VRAM’s streaming benefits.
3. Test pinned memory first. Add --disable-pinned-memory. This is the narrower fix. It removes the pinned-host-memory path while keeping Dynamic VRAM active.
4. Only then disable Dynamic VRAM. If the OOM persists, launch with --disable-dynamic-vram, which falls back to the older estimate-based allocator.

The ordering matters because these flags exist to give you an escape hatch without throwing away every performance gain. On most affected systems, one flag is enough.

Reproducible Fix: Launch Flags That Restore Stability

ComfyUI flags can be added to the launch command directly, to your .bat file on Windows, or to your launch script on Linux:

python main.py --disable-pinned-memory

If that does not resolve it, escalate to:

python main.py --disable-dynamic-vram

On multi-GPU machines, add device pinning regardless of which flag you end up needing:

python main.py --cuda-device 0

If you run ComfyUI on Windows via the portable build, open update/update_comfyui.bat or your launch .bat file and append the flag to the line that invokes python, then relaunch. On Linux, edit whatever script or systemd unit you normally use to start ComfyUI. After changing flags, fully stop the process and restart — changing flags without a clean restart will not take effect because the allocator is initialized at startup.

Two related flags are worth knowing when you tune memory behavior:

• --reserve-vram <GB> — reserves a fixed amount of VRAM that ComfyUI will attempt to keep free above the default headroom. Useful on shared cards where other apps need guaranteed VRAM.
• --lowvram / --novram — legacy aggressive offload modes that force more offloading to system RAM. They are heavier-handed than the two flags above and should be a last resort.

These flags are documented in the official ComfyUI Startup Flags reference, which lists the full set including several Dynamic VRAM headroom options.

Common Pitfalls and How to Avoid Them

The most common mistake is assuming the OOM is your fault and reacting by degrading the workflow — lowering resolution, cutting batch size, or switching to a smaller model — when the real issue is allocator behavior. Before you shrink a perfectly good workflow, check the flags. The memory-management code changed; your hardware and your prompt did not.

A second pitfall is the Windows Task Manager red herring. The official announcement warns that on Windows, Task Manager may not show lower RAM usage under Dynamic VRAM because cached weights remain in RAM when memory is plentiful. Do not use Task Manager readings to conclude the feature is “leaking” — that cached memory is released when other applications need it.

A third pitfall is a blue screen during a forced close. Multiple reports describe terminating the ComfyUI terminal while it was stuck (for example, mid-VAE-encode) and hitting a blue screen. If a generation appears frozen, give it a moment and prefer a clean shutdown over killing the process, and apply the flag fix before your next launch so you are not repeatedly hard-closing a wedged process.

Finally, treat a broken custom node as a separate signal. If the only thing failing is a TensorRT node while normal samplers work fine, the node is incompatible with Dynamic VRAM — disable the feature rather than uninstalling the node, and report the incompatibility upstream so it can be fixed.

Verifying the Fix

After restarting with the corrected flags, confirm the regression is actually gone rather than assuming it is. A reliable sequence:

1. Reproduce the trigger. Run the exact workflow (or the exact model-switch action) that produced the OOM. It should complete without touching memory-related settings.
2. Check the queue. Confirm the generation that used to hang at “Model Initializing…” now proceeds to sampling.
3. Confirm the flag took effect. Look at the ComfyUI startup log — the launch argument list is echoed when the server starts, so verify --disable-pinned-memory or --disable-dynamic-vram appears there.
4. Watch the trade-off. Disabling Dynamic VRAM re-enables the older allocator, which generally uses more system RAM. Keep an eye on RAM usage for one full run and make sure you are not trading a VRAM OOM for a system-RAM OOM.

If the narrow fix resolved it, do not re-enable the feature until a ComfyUI update notes a related fix — these regressions are actively tracked, and the maintainers ask for detailed issue reports (log, workflow, hardware, OS) to resolve them.

Conclusion

A post-update ComfyUI OOM with VRAM to spare is almost never a sign that you need more vRAM. It is almost always a sign that a new memory-management default is interacting badly with your configuration. The remedy is a one-line launch flag — --disable-pinned-memory first, then --disable-dynamic-vram — plus --cuda-device on multi-GPU systems. Diagnose in that order, verify with the original trigger workflow, and you will be back to stable generation without downgrading your models.

If you are squeezing large video models onto a modest card, the same class of offloading choices matters in a different way. For a deep dive into running Wan2.2 Animate 14B within 16 GB of VRAM, see our guide on Wan2.2 Animate BlockSwap settings, and for the broader open-source stack, read running Wan2.2, CogVideoX, and Mochi on consumer hardware.