If you updated ComfyUI recently and suddenly started seeing CUDA out-of-memory errors on a card that ran the same workflow fine a week ago, you are not alone — and the regression may not be your workflow at all. The culprit is a feature called Dynamic VRAM, and since a recent stable release it ships enabled by default on NVIDIA hardware on Windows and Linux.
Dynamic VRAM is a genuine, well-engineered improvement to how ComfyUI manages model weights in memory. In normal operation it lowers system RAM usage, removes a whole class of out-of-memory crashes, and speeds up model loading. But because it replaces the old memory manager with a completely different allocation strategy, it also introduces a handful of sharp, reproduce-able failure modes — especially for users running custom nodes that assume the old allocator’s behavior.
This article explains what Dynamic VRAM actually does under the hood, how to recognize when it is the thing breaking your workflow, and exactly which flag to use when you need to turn it off. It is a documentation-based reference, cross-checked against the official ComfyOrg announcement and the project’s startup-flag reference; it does not fabricate benchmarks or first-run performance numbers.
What Dynamic VRAM Actually Changes
Before this feature, ComfyUI used an estimate-based memory manager. It tried to predict how much memory a model would need before inference, then kept enough VRAM free so that the operation could complete without running out. That prediction was inherently brittle — get it wrong in one direction and you waste VRAM, get it wrong in the other and you crash with an OOM.
Dynamic VRAM throws the prediction out entirely and replaces it with a just-in-time allocator the ComfyOrg team calls the AI Model Dynamic Offloader (aimdo). When you load a model, ComfyUI creates a structure called a Virtual Base Address Register (VBAR). Creating a VBAR costs zero physical VRAM — it only consumes GPU virtual address space, which is effectively free and unlimited. The actual model weights are “faulted in” only at the exact millisecond a given layer is needed for a computation.
That is the key shift. In the old system, loading a model meant committing its physical VRAM up front. In the new system, VRAM is consumed lazily, layer by layer, as the sampler actually touches each weight. When VRAM fills up and a new weight has no room, ComfyUI does not crash — it copies just that single layer into a temporary regular GPU tensor, executes the operation, then frees it. The result, in the ideal case, is that the largest models can run on the smallest budgets without depending on your operating system’s slow page file.
The new RAM behavior is also worth calling out. ComfyUI now uses its own safetensors loader that maps files to uncommitted, file-backed memory rather than deep-copying weights into a PyTorch model. On Windows you may still see high RAM usage in Task Manager because ComfyUI keeps what it can for speed — but, unlike the old design, those cached weights will never be pushed to the page file, and the OS can reclaim the memory the instant another application needs it.
How to Recognize a Dynamic VRAM Problem
The tricky part is that Dynamic VRAM failures rarely announce themselves by name. They surface as ordinary-looking errors on hardware that worked before. Here are the most commonly reported symptoms, drawn from the official announcement thread and linked GitHub issues.
Symptom 1 — TensorRT nodes throw a CUDA allocator error. If you use ComfyUI_TensorRT or ComfyUI-Rife-Tensorrt, you may see a trace that ends in something like:
[E] [defaultAllocator.cpp::nvinfer1::internal::DefaultAllocator::allocate::53]
Error Code 1: Cuda RuntimeTensorRT ships its own allocator and does not play well with ComfyUI’s new dynamic one. The ComfyOrg team has explicitly confirmed this as a known incompatibility. This one is unambiguous: if you rely on TensorRT and the error starts after an update, Dynamic VRAM is the prime suspect.
Symptom 2 — OOM on cards that had plenty of headroom. Several users on high-end hardware (including one on an RTX 4090 running klein9b) reported new out-of-memory errors immediately after updating, on workflows that “worked perfectly” before. New OOM after an update — especially with no other change — is a classic regression signature.
Symptom 3 — RAM fills up and never comes back down. A GitHub issue titled “Maxed Out RAM, ComfyUI Is Not Offloading Properly” documents VRAM, RAM, and eventually swap being exhausted, with ComfyUI’s own Settings → About panel still reporting whatever free RAM it saw at launch. Users report that --cache-ram 16 and --cache-ram 32 do not reliably fix it, and that native (non-Docker) installs behave the same as containerized ones.
If you hit any of these, the first step is to isolate the variable: reproduce the failure on a clean workflow with custom nodes disabled. That is the same discipline ComfyOrg itself asks for in their troubleshooting guide — rule out custom nodes before touching core behavior.
The Fix: Disable Dynamic VRAM for the Affected Session
ComfyUI exposes a dedicated startup flag to turn the feature off. According to the official startup-flags reference, the flag is simply:
python main.py --disable-dynamic-vramThis reverts ComfyUI to the previous estimate-based model loading behavior. Add it to whatever launch command you already use — for example, a typical manual launch becomes:
python main.py --disable-dynamic-vram --listen 0.0.0.0 --port 8188If you launch through the desktop application or a portable distribution, the same flag belongs in your launcher’s command-line or config, not in a workflow. It is a startup flag, so you must fully restart ComfyUI for it to take effect — changing it mid-session does nothing.
For the inverse situation — hardware where Dynamic VRAM is not auto-enabled but you want to force it — there is a matching --enable-dynamic-vram flag. The reference notes it is automatic on NVIDIA and on ROCm 7.14+; WSL is currently not planned for support.
Adjacent flags worth knowing
Two other flags sit right next to this one and are often confused with it. They do not disable Dynamic VRAM, but they change its behavior in the narrow ways their names suggest:
--vram-headroom GB— reserves extra VRAM above ComfyUI’s default headroom, so the allocator tries to keep that many gigabytes completely free even counting VRAM used by other apps. Increase this if your desktop compositor or a browser is competing for the same card.--reserve-vram GB— reserves VRAM for the OS and other software explicitly, separate from the dynamic headroom.
These give you finer control than a blunt on/off switch. If your only issue is that the OS stutters while ComfyUI runs (rather than a hard crash), try --vram-headroom 2 before reaching for the nuclear --disable-dynamic-vram.
Why You Might Not Want to Disable It
Before you pin --disable-dynamic-vram permanently, consider what you are giving up. The old estimate-based manager existed precisely because it allowed some control over predictable memory use; the new allocator removes an entire category of crashes and, on memory-constrained hardware, is the difference between running a large model and watching it page out to disk.
The official announcement lists concrete wins: lower system RAM usage, faster initial model loads and LoRA application, the ability to run models that exceed your physical RAM, and — importantly — the elimination of the page-file bound model unloading that used to plague multi-model workflows. If your workflow is GPU-light and you use no TensorRT nodes, Disabling it may cost you speed for no benefit.
A healthy rule of thumb: leave Dynamic VRAM on by default, and only disable it when you can attribute a specific failure to it. The three symptoms above give you concrete attribution clues. When in doubt, the fastest diagnostic is a binary test — run the exact same JSON workflow once with default flags and once with --disable-dynamic-vram, and compare which one completes.
Verifying the Diagnosis
How do you confirm Dynamic VRAM is really your problem, rather than a genuinely OOM-bound workflow? Run this short checklist before you file any bug report:
- Reproduce on a clean workflow. Load the default text-to-image template with no custom nodes. If it runs clean while your custom workflow fails, the problem is node-level, and disabling Dynamic VRAM may or may not be the right fix — but you have isolated the layer.
- Flip the flag once. Re-run the failing workflow with
--disable-dynamic-vram. If it completes, the feature was the trigger. Note that this is a workaround, not a root cause — report it upstream so the incompatibility gets fixed. - Check the About page. If RAM is being exhausted, note whether
Settings → Aboutreports a free-RAM figure that no longer matches reality. That stale reading is itself a known symptom documented in the RAM-offloading issue. - Capture full logs. ComfyOrg’s own bug-report guidance asks for full logs, the workflow JSON, and your OS/GPU/PyTorch version. Screenshots of just the red error text are rarely enough to diagnose a memory-manager interaction.
If your issue is TensorRT-specific, the workaround is effectively mandatory until the maintainers of those nodes update them for the new allocator — the --disable-dynamic-vram flag is the documented stop-gap.
Conclusion
Dynamic VRAM is a real improvement, not a bug — but shipping it enabled by default means its rough edges are now yours to trip over. The telltale signs are TensorRT allocator errors, unexplained OOM on hardware that previously had headroom, and RAM that climbs without ever coming back down. In each case the fast, reversible diagnostic is the same: restart once with --disable-dynamic-vram and see whether the failure disappears.
Keep the feature on when your workflow is healthy, because it is genuinely faster and less RAM-hungry for most pure-SD or SDXL pipelines. Reach for the off switch only when you have attributed a specific crash to it — and when you do, open an issue upstream with full logs so the incompatibility gets fixed on the real side of the equation.
If you are tuning memory on a constrained card more broadly, our guides to ComfyUI’s VRAM launch flags and to running the Wan 2.2 Animate 14B on 16 GB via BlockSwap cover the surrounding model-loading landscape. For the authoritative behavior of every flag referenced here, see the official ComfyUI startup-flags reference and the ComfyOrg Dynamic VRAM announcement.
Leave a Reply