Over the last few weeks, a specific class of ComfyUI problem has exploded across Reddit and GitHub: workflows that ran fine a month or two ago now silently balloon system RAM, spill into the page file, and die with an out-of-memory error. The user is on 32GB of RAM and a 16GB GPU, the model is one they have run a hundred times, and yet a 9GB model suddenly consumes 30GB+ of RAM plus another 28GB of page file. The culprit is not a single bug but a collision of two independent changes landing around the same time: the new Dynamic VRAM memory allocator that rolled out in ComfyUI, and a memory regression reported against PyTorch 2.8. This article explains what each of them does, how to diagnose which one is biting you, and the concrete fixes that are actually working for people.
The Symptom: RAM Spikes on Workflows That Used to Fit
The canonical report comes from a Reddit user who had 32GB of RAM and 16GB of VRAM. After a round of ComfyUI updates (pulled to get Qwen image-edit support), their Wan workflows that had worked two months prior began crashing with OOM immediately. Qwen image edits worked once and then OOM’d on the next run, forcing a full restart between each image. A 9GB model running alongside an fp8 T5 XXL was eating 30GB+ of RAM plus 28GB of page file — more than a much larger Flux model consumed under Forge. The user’s resolution, documented in their update, was to downgrade to PyTorch 2.7.1 while keeping the latest ComfyUI, after which the RAM issue disappeared entirely.
The key diagnostic clue in almost every report is the same: the RAM usage is out of proportion to the model size, and it grows across runs rather than dropping back after a generation completes. If your task manager shows committed memory climbing toward your physical RAM limit and then the page file spiking right before the crash, you are almost certainly looking at one of the two causes described below — not a “your GPU is too small” problem.
What Dynamic VRAM Actually Changes About Memory
In late 2026, ComfyUI shipped a new memory system called Dynamic VRAM, built on an internal project the team calls the AI Model Dynamic Offloader (aimdo). It is a custom PyTorch VRAM allocator designed to do on-demand offloading of model weights instead of predicting memory needs up front. The official Comfy blog announcement is the best single reference for the internal mechanics, and it is worth reading before you touch any flags.
Three things changed that matter for the RAM-OOM problem:
- A new safetensors loader. Files are now opened and mapped to uncommitted, file-backed memory rather than deep-copied into the PyTorch model. The weights are assigned by pointer to uncommitted memory. This is why model loader nodes complete almost instantly in Dynamic VRAM mode.
- Models are no longer unloaded from VRAM back into RAM. Previously, unloading a model to free VRAM meant writing it back to system RAM — and in multi-model workflows this is exactly what caused RAM exhaustion and page file churn. Under Dynamic VRAM, the VRAM is simply freed and the model returns to the uncommitted load state.
- Weights stay cached in RAM if you have plenty of it. The official discussion announcing Dynamic VRAM spells this out explicitly: Windows Task Manager may not show lower RAM usage, because cached weights are deliberately kept in RAM to speed things up. The critical difference from before is that these cached weights should never end up in the page file and should be unloaded to make room when other applications need the memory.
So if you are on a recent ComfyUI build and your RAM appears high but your system is otherwise stable, part of that “high” usage may simply be the new caching behavior working as intended. The page-file spike is the real red flag — that is the behavior Dynamic VRAM was supposed to eliminate, and if you still see it, something else is wrong.
The PyTorch 2.8 Regression Is a Separate, Identifiable Problem
Running in parallel with the Dynamic VRAM rollout is a memory regression tracked against PyTorch 2.8. GitHub issue #9259 collects reports of OOM problems that appear specifically after installing the stable PyTorch 2.8 build, with users confirming that the same workflow is fine on 2.7.x and broken on 2.8. The most frequently cited fix in that thread and in the Reddit reports linked above is the same: pin PyTorch back to 2.7.1 while keeping ComfyUI current.
Disentangling “Dynamic VRAM is misbehaving” from “PyTorch 2.8 is leaking” matters, because the fixes are different. If your RAM problem started immediately after a PyTorch version bump rather than a ComfyUI update, the PyTorch downgrade is the more targeted move. If it started after a ComfyUI update on an already-current PyTorch, the Dynamic VRAM flags are your first stop.
How to Diagnose and Fix the RAM OOM
Work through these in order. Each step is cheap and reversible.
Step 1: Confirm it is a page-file / committed-memory crash
Open your OS memory monitor (Task Manager on Windows, free -h or htop on Linux) and watch a known-bad workflow run. Note whether committed memory or the page file climbs toward the physical limit right before the crash. A model using RAM out of proportion to its on-disk size, combined with page-file growth, points at unloaded/cached-model memory rather than a genuinely undersized GPU.
Step 2: Try disabling Dynamic VRAM
Launch ComfyUI with the --disable-dynamic-vram flag. This is the officially documented workaround for several known problems — notably TensorRT custom nodes such as ComfyUI_TensorRT and ComfyUI-Rife-Tensorrt crash under the new allocator, and some users on high-RAM servers (64GB+) report roughly a 2x slowdown because weight caching that previously worked is no longer effective. If your RAM OOM disappears with the flag, you have isolated the cause to Dynamic VRAM.
Step 3: If the regression tracks PyTorch, downgrade to 2.7.1
If the problem appeared after a PyTorch 2.8 install and is unaffected by the Dynamic VRAM flag, pin PyTorch back. On a portable install the relevant command is a version-pinned pip install (pip install torch==2.7.1 — verify your CUDA build string against the official PyTorch instructions) rather than an unpinned upgrade. The Reddit report and issue #9259 both confirm this resolves the RAM spike for affected users.
Step 4: Verify with a controlled re-run
After each change, run the exact same workflow that crashed and compare the total workflow execution time (not it/s) and peak committed memory. The Comfy team explicitly asks users reporting Dynamic VRAM performance problems to compare total execution time, because the per-iteration rate can look worse while the end-to-end run is unchanged or better.
Update First, and Don’t Chase Two Ghosts at Once
Before any of the flag surgery above, make sure you are on the current ComfyUI build. Dynamic VRAM was, at the time it was first announced, only enabled by default in the latest git version, and several issues discussed in the rollout thread were fixed in subsequent releases. The team has been explicit that they want detailed bug reports — full logs, workflow, hardware, and OS — for any remaining issues. If you are running an older build, you may be debugging behavior that has already been patched.
It is also easy to confound the two causes. A user who updates ComfyUI (pulling in both Dynamic VRAM and a newer PyTorch at once) cannot tell which change broke them without isolating one variable. Change one thing at a time — flag first, then version pin — and record the peak memory after each step. That discipline is the difference between a 20-minute fix and a week of flailing.
What This Means for Local AI Hardware Decisions
The Dynamic VRAM feature is genuinely good news for people on memory-constrained hardware — the official framing is that it makes it possible to run models larger than your RAM without paging, and to avoid the “VRAM OOM because weights were not offloaded enough” failure mode. If you have been sizing a build around physical RAM as the hard ceiling for model size, the allocator’s on-demand offloading changes that calculus. For a deeper look at squeezing large models onto limited VRAM, see our earlier writeup on running Wan2.2 Animate 14B on 16GB VRAM with BlockSwap.
That said, the rollout has real rough edges. The slowdown reports on high-RAM machines and the TensorRT breakage are reminders that a new allocator interacts with every custom node differently. If you run a production workflow that depends on TensorRT or on a large in-RAM weight cache for speed, treat Dynamic VRAM as an opt-in during this transition window rather than trusting the default silently — and keep the --disable-dynamic-vram escape hatch in your launch script until you have measured your own numbers.
Conclusion
If ComfyUI has started eating your system RAM and OOMing on workflows that used to fit, you are almost certainly hitting one of two things: the transition to the Dynamic VRAM allocator (whose new caching can look like a leak but whose page-file behavior is what really matters) or the PyTorch 2.8 memory regression. Confirm which one by watching committed memory and page file, then apply the targeted fix — --disable-dynamic-vram for the allocator, a pin back to PyTorch 2.7.1 for the regression. Update to the latest build first, keep your launch flags in version control, and change one variable at a time. None of this requires a bigger GPU.
References
- Dynamic VRAM in ComfyUI: Saving Local Models from RAMmageddon (Comfy blog)
- Dynamic Vram: the massive memory optimization is now enabled by default (Comfy-Org discussion #12699)
- comfy-aimdo: AI Model Demand Offloading Allocator (GitHub)
- after install pytorch stable 2.8, having problems with OOM (Comfy-Org issue #9259)
Leave a Reply