If you run ComfyUI on a mid-range GPU, you have almost certainly pasted a launch command that ended in --lowvram or --novram without really knowing what the flag does. The three VRAM management flags in ComfyUI—--lowvram, --novram, and --normalvram—are among the most misunderstood settings in the entire tool, and picking the wrong one either crashes you with torch.cuda.OutOfMemoryError or silently makes your generations two to five times slower.
This guide breaks down what each flag actually does at the memory-management level, how to tell which one you need, and how to verify the change actually took effect. Where I describe internal behavior, this is documentation analysis of ComfyUI’s source and official docs—not fabricated benchmarks. I flag real measurements only where I have them.
The Three Flags and What They Actually Do
ComfyUI exposes three mutually exclusive VRAM modes, controlled by launch flags. You should use exactly one of them, never two.
–normalvram (the default)
With no flag at all, ComfyUI behaves as if --normalvram is set. It loads model weights onto the GPU and keeps them there for the entire session, moving only intermediate tensors and activations as needed. This is the fastest path because weights stay resident and do not need to be re-uploaded between jobs.
You should use this when your largest model (diffusion model plus text encoders and VAE) fits comfortably in available VRAM with headroom for activations. On a 16 GB card running an SDXL-class model, this is usually fine. On the same 16 GB card running a Wan2.2-Animate 14B-class video model, it is almost certainly not.
The failure mode of --normalvram is abrupt: the first job that asks for more VRAM than the card has throws torch.cuda.OutOfMemoryError: CUDA out of memory and the queue halts. If you are hitting OOM only on larger models or batches, you are likely a candidate for a more aggressive offload mode.
–lowvram
--lowvram keeps model weights on the GPU but moves them to regular system RAM between jobs, re-uploading only the layers needed for the current operation. In practice this means most of the model is streamed into VRAM as the compute graph runs, then released. It trades memory for speed: you can run models that are marginally larger than your VRAM, but each generation pays a re-upload cost.
This is the right choice when your model fits in VRAM only some of the time, or when you switch between several large models frequently on a card that cannot hold them all. It is slower than --normalvram but far faster than --novram.
A useful mental model: --lowvram keeps the model “nearby” in shared system memory and moves pieces onto the GPU on demand, whereas --normalvram keeps everything resident.
–novram
--novram keeps model weights entirely on the CPU (in system RAM) and uploads them to the GPU incrementally as each section is computed. It is effectively the most aggressive offload mode. This lets you run models that exceed your VRAM by a large margin—but at the cost of a substantial speed penalty, because the PCIe bus becomes the bottleneck.
Reach for --novram only as a last resort: when the model absolutely will not fit with --lowvram, and you would rather wait than upgrade hardware. The speed difference between --lowvram and --novram is frequently large enough to be the deciding factor between a usable tool and an unusable one.
How to Pick the Right Flag for Your Card
A practical decision sequence that covers most real cases:
1. Model fits in VRAM with headroom → use the default (--normalvram, i.e., no flag). Fastest, simplest.
2. Model fits only sometimes, or you hot-swap large models → add --lowvram.
3. Model exceeds VRAM but you refuse to wait for a cloud GPU → add --novram and accept the slowdown.
4. Still OOM even with --novram → the problem is probably not the diffusion model. Check text encoders, the VAE, and whether you are loading multiple checkpoints at once.
Note that these flags are coarse. Modern ComfyUI and many custom nodes offer finer-grained controls—such as per-node force_offload, or model-specific block-swap and offload-device settings for the Wan video models—that can be more effective than a global --novram. If you are already using those node-level controls, a global VRAM flag may not be necessary at all.
How to Verify the Flag Actually Took Effect
A flag in the right position but attached to the wrong process does nothing. The single most reliable verification is to watch VRAM usage during a generation while monitoring with nvidia-smi:
watch -n 1 nvidia-smiObserve the MiB used for your process while a job runs. Under --normalvram, usage climbs and stays near its peak. Under --lowvram, you will see memory usage rise and fall as layers stream in and out. Under --novram, usage stays low and the generation is visibly slower.
You can also confirm the active mode from the startup log. ComfyUI prints its memory-management mode (or the relevant offload settings) at launch; check the console output after startup. If you launched via a systemd service or a background script, make sure the flag is actually present in that invocation—many people edit their main.py command in one place and launch from another.
For deeper visibility into what a given model actually needs, run a single job and watch both VRAM (nvidia-smi) and system RAM (free -h). A model that fits under --lowvram will show heavy VRAM utilization with modest RAM growth; a model being pushed to --novram will show near-maximum system RAM usage during generation.
Common Pitfalls and Traps
Using more than one flag. Passing --lowvram --novram is contradictory. Only the last-processed one wins, and what you observe may not match your intent. Use exactly one.
Confusing ComfyUI flags with A1111 flags. Both tools use --lowvram and --novram, but their semantics differ. Do not transplant an A1111 habit onto ComfyUI and assume identical behavior.
Expecting a flag to fix a fundamentally too-small card. A global flag cannot create VRAM. If a 14B video model needs roughly 15 GB and you only have 8 GB, --novram will technically run it but may be pathologically slow—longer than simply renting a cloud GPU. The flag is a knob, not a miracle.
Ignoring node-level offload. For the Wan2.2-family video models specifically, block-swap and offload-device settings often beat a blanket --novram because they keep the hot layers on the GPU while swapping only the cold ones. We covered those exact settings in our guide to running Wan2.2 Animate 14B on 16 GB with BlockSwap.
Chasing VRAM flags before checking which process actually launched. If two ComfyUI instances or a stale daemon are running, your edited flag may never reach the process you interact with. Check ps aux | grep -i comfy to confirm the correct invocation is live.
From a Real Two-Instance Setup
On our own T2 box we run two ComfyUI instances against a single 16 GB card: a systemd-managed instance on port 18188 and a manually launched one on 18189 for Flux 1-dev. That setup makes the flag question concrete—you cannot simply apply one global flag and call it done, because two instances compete for the same VRAM pool.
The takeaway from running both is that VRAM flags are per-process, not global. Each main.py invocation gets its own decision, and the winning strategy is to size each instance’s flag to the heaviest model it will load, not to the card as a whole. If one instance runs an SDXL workflow and the other runs Flux, the Flux instance is the one that needs a more aggressive offload mode. Applying --novram to the SDXL instance would only slow it down for no benefit.
This also means the first diagnostic step when one instance starts OOM-ing is not to tweak flags blindly but to check the other instance’s current VRAM footprint with nvidia-smi. A co-resident process often explains an OOM that your own workflow cannot.
Conclusion
--lowvram and --novram are not magic performance toggles—they are explicit trade-offs between memory footprint and generation speed, applied per-invocation. Use --normalvram (no flag) when your model fits, escalate to --lowvram when it fits only sometimes or you hot-swap models, and reserve --novram for models that genuinely exceed your VRAM. Always verify with nvidia-smi that the flag you think is active actually is, and remember that on multi-instance setups each process needs its own decision sized to its heaviest model.
For the authoritative reference on ComfyUI’s command-line options, see the official ComfyUI documentation and the ComfyUI GitHub repository. If you are specifically wrestling with large video models, the BlockSwap and offload-device approach we documented for Wan2.2 Animate is usually the better lever than any global flag—see our broader open-source video generation stack guide for context.
Leave a Reply