ComfyUI Dynamic VRAM Default Is Breaking Workflows: OOM Errors, TensorRT Failures, and How to Fix or Disable It

If your ComfyUI workflows suddenly started failing after a routine git pull or a desktop-app update, you are probably running into Dynamic VRAM — the new memory system that ComfyUI shipped stable in early spring 2026 and enabled by default. The feature is genuinely impressive on paper: it promises to slash system RAM usage, let you run models larger than your physical RAM, and eliminate out-of-memory crashes. But a sizable number of users are reporting the opposite: workflows that worked perfectly for months now throw OOM errors, TensorRT nodes crash with CUDA runtime failures, and Linux users are watching the OS kill their ComfyUI process.

This article explains what Dynamic VRAM actually changed, why it breaks specific setups, how to diagnose whether it is the cause of your problems, and the exact flag to turn it off. No speculation or faked benchmarks — every claim below is grounded in the official ComfyUI announcement, the official troubleshooting guide, and the official GitHub discussion where the maintainers are tracking regressions.

What Dynamic VRAM Actually Changed

To understand the failures, you need to understand what changed under the hood. The old ComfyUI memory model was predictive: before each inference step, it estimated how much memory every model in the graph would need, then did its best to keep that much free. When the estimate was too low, you got a classic “comfy tried to allocate” OOM. When it was too high, ComfyUI offloaded weights to CPU RAM despite your GPU having room to spare.

Dynamic VRAM replaces that whole approach with a custom PyTorch allocator the Comfy team calls the AI Model Dynamic Offloader, or aimdo. Instead of predicting, it reacts: model weights are placed into a virtual buffer (a “VBAR”) that costs zero physical VRAM, and the allocator offloads weights on demand only when the primary PyTorch allocator comes under real pressure. The official announcement cites several intended wins:

• Lower system RAM usage — weights are mapped as uncommitted, file-backed memory rather than deep-copied into PyTorch.
• No more page-file thrashing — cached weights are never pushed to the OS page file, so a 20 GB model no longer silently destroys your disk.
• Higher VRAM utilization — you will often see more VRAM used than before, which the team says is normal and intended.
• No model unload — ComfyUI now holds weights for the lifetime of the loaded model instead of unloading them back to RAM between runs.

That last change is the key to understanding most of the breakage. Under the old system, model weights moved from VRAM to RAM and back constantly. Under Dynamic VRAM, they stay put. For a single-model workflow that is faster and cleaner. For a multi-model workflow — especially one that mixes ComfyUI core with custom nodes that assume the old behavior — it can create exactly the OOM conditions the feature was meant to prevent.

Symptoms That Point to Dynamic VRAM

The first question is always: is this actually the cause? The following symptom set strongly indicates Dynamic VRAM is the culprit, especially when they appear together and immediately after an update:

1. OOM errors on a card that previously “just worked”

The most common complaint in the GitHub discussion is a 4090-class or larger card that ran a workflow fine for weeks, then started throwing “out of memory” after the update. One user with a 4090 running the klein9b model reported persistent OOM where before it was flawless. If your VRAM abundance did not change and your workflow did not change, the memory manager is the variable that moved.

2. TensorRT custom nodes failing with CUDA runtime errors

Dynamic VRAM breaks the allocator assumptions that TensorRT nodes rely on. Multiple users report that ComfyUI_TensorRT and ComfyUI-Rife-Tensorrt now fail at allocation time with a message like:

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

This is not a problem with your TensorRT install. It is the custom PyTorch allocator stepping in where TensorRT expects a standard CUDA allocation path.

3. Linux OOM-killer or Windows “low virtual memory” crashes

On Linux, several users describe ComfyUI and its terminal being killed by the kernel — not ComfyUI erroring out gracefully, but the OS stepping in to free memory. On Windows, the equivalent is a blue screen following an Event Viewer entry of “Windows successfully diagnosed a low virtual memory condition.” This class of crash is the most serious because it takes the whole session down, not just one generation.

4. “Expected all tensors to be on the same device” errors

One user on an RTX 5090 with 128 GB of system RAM — hardware that should be immune to memory pressure — hit Expected all tensors to be on the same device, but got index is on cuda:0 on load. This is a device-placement consistency bug tied to the new loading behavior, and disabling custom nodes does not fix it.

5. aimdo allocation-accounting errors

If your log shows repeated lines like aimdo_cuda_free_async: could not account free right before a crash, that is the Dynamic VRAM offloader itself failing to track memory — a bug in the new allocator, not in your workflow.

How to Confirm Dynamic VRAM Is the Cause

Don’t guess. Run a controlled check before you change anything permanently:

1. Note your ComfyUI version. Dynamic VRAM shipped stable in March 2026 and is on by default in recent git builds and the desktop app. If you recently updated, that is your window.
2. Reproduce with a minimal workflow. Load the default “first generation” workflow from ComfyUI. If that works but your real workflow fails, the trigger is a specific node or model-placement pattern in your graph.
3. Disable custom nodes. The official guide is explicit that most reports trace back to custom nodes. Temporarily disable them and re-run. If the error persists with core-only nodes, the issue is more likely the memory system itself than any single node.
4. Read the actual failure, not the summary. Click Show report on the “Prompt execution failed” dialog or read the terminal tail. Look for the specific strings above: defaultAllocator, aimdo_cuda_free_async, same device, or a kernel OOM-killer message.

If one or more of those signatures is present and your setup matches a reported case (large card, TensorRT, multi-model, or Linux), Dynamic VRAM is very likely the variable. The fix is a single launch flag.

Fixing It: The --disable-dynamic-vram Flag

The immediate, officially documented workaround is to launch ComfyUI with Dynamic VRAM disabled. From the startup flags reference, the command is:

python main.py --disable-dynamic-vram

Combine it with your existing flags as needed. For example:

python main.py --listen 0.0.0.0 --port 8188 --disable-dynamic-vram

Windows Portable users add the flag to the launch .bat file (for example run_nvidia_gpu.bat) rather than running it from a terminal. Desktop-app users should check the app’s advanced settings; if a flag field is not exposed there, fall back to a manual install or the portable build so you can control the launch line.

Why disabling is the right first response

Disabling reverts you to the previous estimate-based loading behavior — the one your workflow already ran on successfully. That is a low-risk rollback, and it instantly tells you whether Dynamic VRAM was the cause: if your workflow works again with the flag set, you have confirmed the diagnosis and gained a functioning setup while the maintainers stabilize the feature.

Two important caveats from the discussion:

• --reserve-vram may no longer be respected. Some Linux users report that even with --disable-dynamic-vram, the new loading behavior keeps models resident and no longer unloads them, which can still lead to crashes on constrained systems. If disabling alone is not enough, combine it with a conservative --lowvram or --normalvram mode appropriate to your card.
• Multi-GPU and SageAttention setups are affected separately. Users on multi-GPU systems report breakage that disabling Dynamic VRAM only partly resolves. If you depend on multi-GPU or SageAttention, check the discussion thread for the latest state before assuming a single flag fixes you.

Common Pitfalls When Working Around This

Avoid these mistakes, which show up repeatedly in the threads:

1. Comparing it/s instead of total wall-clock time. Dynamic VRAM can change the per-step timing. The maintainers explicitly ask users to compare total workflow execution time, because a lower it/s does not necessarily mean a slower workflow when weight loading is included.
2. Assuming higher VRAM usage means a leak. The official guidance is that higher VRAM occupation is expected and healthy under the new system. Don’t chase it as a bug.
3. Reinstalling everything on a hunch. One user did a clean install and still hit OOM. The problem is the memory system, not a corrupted install. Diagnose first, reinstall last.
4. Relying on the page file as a safety net. One of Dynamic VRAM’s design goals is to stop using the page file. If you had a bloated page file masking memory errors before, those errors will now surface. Fix the root cause instead of re-enlarging the page file.
5. Forgetting that WSL and AMD are unsupported. The feature is for NVIDIA on native Windows and Linux only. WSL is explicitly not planned, and AMD support is listed as a future step. If you run either, your experience does not reflect the intended behavior.

Verifying Your Fix and Deciding What to Keep

After applying --disable-dynamic-vram (plus any mode flag), verify deliberately rather than assuming:

1. Re-run the exact workflow that failed, not a trimmed-down copy. Confirm it completes end to end multiple times — OOM and allocator errors are often intermittent.
2. Watch the terminal, not just the image. A clean completion with a readable image but error spam in the log is still a broken state.
3. If TensorRT is your blocker, confirm your TensorRT nodes load and allocate without the defaultAllocator error after disabling.
4. On Linux, keep an eye on dmesg for OOM-killer entries rather than trusting that a single successful run means the kernel will behave.

Your end state should be a deliberate choice, not a knee-jerk rollback you keep forever by accident:

• If Dynamic VRAM works for you and you are on a supported NVIDIA/native setup with no TensorRT dependency, leave it on and enjoy the lower RAM usage and faster loads.
• If it breaks your workflow, keep --disable-dynamic-vram pinned in your launch script or .bat file, and subscribe to the GitHub discussion so you know when the specific regression affecting your setup is resolved.
• If you are uncertain, pin the flag now and test the feature again after the maintainers ship a few rounds of regression fixes — the discussion thread makes clear this is an actively patched, fast-moving area.

Conclusion

Dynamic VRAM is a real engineering improvement that will genuinely help most memory-constrained NVIDIA users — it is not a broken feature. But enabling a custom allocator by default means every workflow that depended on the old memory behavior is now a potential regression, and the OOM, TensorRT, and multi-GPU failures reported in the official discussion are that playing out in practice.

The practical takeaway is simple: learn the one flag that takes you back to known-good behavior (--disable-dynamic-vram), use it to confirm your diagnosis, then decide with data whether to stay on or off. If you have not yet read the underlying launch flags, our earlier walkthrough of ComfyUI’s VRAM flags (--lowvram, --normalvram, and friends) is the natural companion piece for tuning the fallback here.