ComfyUI Dynamic VRAM Broke My Workflow: What It Does, Why It OOMs, and How to Fix It

What Dynamic VRAM actually changed

If you updated ComfyUI recently and your once-stable workflow suddenly throws CUDA out of memory, hangs at Model Initializing..., or crashes a TensorRT node, the cause is almost certainly Dynamic VRAM. It shipped as the default memory system in stable ComfyUI and silently changed how every model weight is loaded, cached, and offloaded on your GPU.

Dynamic VRAM is ComfyUI’s replacement for the old “estimate-based” memory manager. Historically, ComfyUI tried to predict how much memory a model and its layers would need before running, then reserve enough free VRAM so the operation would not OOM mid-way. That prediction step was the source of a whole class of bugs: underestimated layers, aggressive offloading that thrashed between RAM and VRAM, and models getting pushed out to the Windows page file.

The new system drops prediction entirely. It is built on a custom PyTorch allocator called aimdo (the AI Model Dynamic Offloader) that loads model weights on demand, in the exact millisecond a tensor is needed for a calculation, and frees them the moment they are done. The Comfy team describes the core innovations in their announcement post and the deeper technical write-up at the comfy-aimdo repository.

Why the update suddenly causes OOMs and slowdowns

On paper Dynamic VRAM is strictly better: lower system RAM usage, no page-file paging, faster model loads, and the ability to run models larger than your physical RAM. The problem is that it also changed two behaviors a lot of people were relying on, and those regressions are what show up as “my workflow broke.”

1. Higher VRAM usage is now the norm

Dynamic VRAM deliberately keeps more of the model resident in VRAM because that is the fastest memory available. If you had tightened your workflow to run at 14.8–15.4 GB on a 16 GB card, the new allocator’s more aggressive caching can push you over the edge into a hard OOM. This is not a bug in your workflow; it is the allocator using the card more aggressively than the old manager did.

2. Cached weights stopped respecting the old flags

Several users on the official Dynamic VRAM discussion thread report that --reserve-vram no longer behaves the way it used to, and that model-unloading behavior changed even when they try to work around it. On an Intel Arc iGPU under Linux, one user reports workflows that used to run fine now OOM and get killed by the OS’s own out-of-memory killer rather than by ComfyUI’s graceful error path.

3. Third-party nodes that allocate their own VRAM break

The clearest, most reproducible breakage is with TensorRT-based nodes. ComfyUI_TensorRT and ComfyUI-Rife-Tensorrt allocate GPU memory through their own nvinfer1::DefaultAllocator, which fights with the new dynamic allocator. Users see an error like:

[E] [defaultAllocator.cpp::nvinfer1::internal::DefaultAllocator::allocate::53]
Error Code 1: Cuda Runtime

The same discussion thread also documents Expected all tensors to be on the same device errors on an RTX 5090 with 128 GB of system RAM, and measurable slowdowns of 2× or more on 4090/5090 servers using the Impact Pack and efficiency nodes — where the allocator keeps re-loading parts of the model that the old system would have left cached.

How to confirm Dynamic VRAM is your problem

Before reaching for the disable flag, run two quick checks so you are fixing the right thing.

1. Check your ComfyUI version. Dynamic VRAM is enabled by default in the latest git builds and in stable releases from roughly three weeks after the announcement. If you updated in that window and only then started seeing OOMs or slowdowns, the update is the most probable cause.
2. Compare against the old behavior. If the same workflow that ran cleanly yesterday now OOMs or takes dramatically longer, and you have not changed the workflow or the model, the memory manager is the variable that changed under you.
3. Watch for the telltale signature. “Model Initializing…” hanging, VRAM that fills more aggressively than before, and errors specifically from TensorRT-node allocators are the three most common fingerprints reported.

Note that --lowvram and --normalvram from the older memory model are separate concepts — if you are already managing VRAM with those launch flags, Dynamic VRAM sits underneath all of them and changes the baseline behavior those flags were tuned against.

The fix: disable Dynamic VRAM (and when not to)

The immediate, well-documented workaround is to launch ComfyUI with the disable flag, which reverts to the older estimate-based model loading:

python main.py --disable-dynamic-vram

How you add it depends on how you launch ComfyUI:

• Portable (Windows): edit run_nvidia_gpu.bat (or your launch batch file) and append the flag to the python main.py line, then save and relaunch.
• Manual install: add it directly to your python main.py launch command.
• Desktop app: the flag is passed through the app’s startup arguments. Several users report the Desktop app does not yet expose a clean toggle, so if you are on Desktop and need the flag, launching the server directly is the reliable path until a UI option ships.

There is also an inverse flag, --enable-dynamic-vram, which turns the feature on for systems where it is not auto-enabled — the official startup flags reference lists it as “auto on Nvidia, ROCm 7.14+”. The full flag documentation lives at docs.comfy.org.

The important nuance: do not disable it reflexively. On memory-constrained hardware, on Windows 11 with an NVMe SSD, and on single-GPU Nvidia setups, Dynamic VRAM is genuinely faster and lets you run larger models without paging. The people reporting problems are mostly on multi-GPU setups, TensorRT workflows, iGPU/Linux configurations, or servers where the old caching behavior was load-bearing for their specific node stack. If you are on a single RTX card doing straight image generation, the new default is very likely an improvement — measure your total workflow time (not it/s) before deciding.

What to do instead of just disabling it forever

The disable flag is a stopgap, and the Comfy team has stated they are actively fixing reported regressions (AMD support is next on the roadmap, and WSL is not planned at all). If you want the new allocator’s benefits without the breakage, here is a more durable path:

1. Isolate the culprit. Disable custom nodes one at a time — especially TensorRT nodes, the Impact Pack, and efficiency nodes — and re-run. On one documented case, disabling the TensorRT wrapper alone resolved the allocator conflict while keeping Dynamic VRAM on.
2. Update everything. The Comfy team recommends the latest PyTorch 2.10 with CUDA 13 for best performance under the new allocator. A stale torch build interacts poorly with it.
3. Test a clean install. One user on the discussion thread rolled back after calling the feature “buggy as hell and untested,” only to have problems recur — a clean reinstall with the proper requirements is worth trying before declaring it broken.
4. Report it properly. If the issue persists, the team explicitly asks for a detailed issue with full logs, the workflow, your hardware, and your OS. Performance reports should compare total workflow execution time, not it/s, because the allocator changes where time is spent.

Bottom line

Dynamic VRAM is a real, well-engineered improvement that shipped as a default and broke a minority of non-standard setups. The failure pattern is consistent: aggressive VRAM caching, a new allocator that conflicts with third-party allocators, and changed unloading behavior that the old flags no longer control. If your workflow regressed immediately after an update, --disable-dynamic-vram is the correct first step to confirm the cause, followed by isolating the specific node or upgrading your PyTorch rather than leaving the feature permanently off. Treat the flag as a diagnostic, not a permanent setting.

Note: this article is a documentation-based analysis of the shipped behavior, the official announcement, and the developer discussion thread. It is not a local benchmark — no performance numbers here are from tests run on this site’s hardware.