Tag: Launch

  • ComfyUI VRAM Launch Flags Explained: –lowvram, –normalvram, –cpu, and –fast

    ComfyUI VRAM Launch Flags Explained: –lowvram, –normalvram, –cpu, and –fast

    ComfyUI exposes a small set of command-line flags that directly change how aggressively it holds model weights in video memory (VRAM). Most users only discover these after hitting the wall: the UI freezes mid-generation, the OS starts swapping, or the familiar “CUDA out of memory” error appears in the console. Choosing the right flag — or knowing when to drop one — is often the difference between a workflow that renders and one that crashes on an 8 GB or 6 GB card.

    This article is a documentation-based reference rather than a benchmark report. The flag behavior below is drawn from ComfyUI’s own command-line documentation and source, cross-checked against community troubleshooting threads. It does not include fabricated benchmark numbers or first-run measurements; where a claim about performance is stated, it reflects documented behavior, not lab results.

    What the VRAM Flags Actually Control

    lowvram, novram, gpu-only, fp8 launch flags comparison

    By default, ComfyUI keeps as much of a model on the GPU as it can, and it uses an internal smart-memory manager to decide when tensors should be evicted and re-loaded. The launch flags sit on top of this manager and change its baseline behavior in three directions:

    • How much of each model stays resident in VRAM between executions.
    • Whether weights are split or paged between GPU and system RAM to fit a small card.
    • Whether the GPU is used at all, or the whole pipeline falls back to CPU.

    The practical effect is a trade-off between peak VRAM usage and generation speed. The more aggressively ComfyUI offloads weights to system RAM, the less VRAM a single model occupies, but the slower each sampling step becomes because weights must be re-uploaded to the GPU on demand.

    The Flags, One by One

    –lowvram

    --lowvram is the flag ComfyUI recommends for cards with less than about 3 GB of VRAM. It forces the memory manager into a conservative mode that keeps only the parts of the model and activations that are actively needed on the GPU, offloading the rest. ComfyUI’s documentation states this flag is enabled automatically when a low-VRAM GPU is detected, so most users on very small cards never need to add it manually.

    The cost is speed. Because weights are paged in and out far more often, every step spends extra time copying data over the PCIe bus. On a card where it is the difference between “works” and “out of memory,” that slowdown is an acceptable price; on a card with comfortable headroom it is just waste.

    –normalvram

    --normalvram is the default behavior and in most cases an explicit no-op. It tells the smart-memory manager to use standard heuristics rather than force aggressive offloading. You would only pass it deliberately if a wrapper script or config had set --lowvram unconditionally and you wanted to override it for a card that actually has enough memory.

    –cpu

    --cpu runs the entire inference pipeline on the processor. It is not a VRAM-management flag in the ordinary sense — it removes the GPU from the equation and stores everything in system RAM. ComfyUI’s own documentation describes it as slow but confirms it works even when there is no GPU at all. It is most useful for validating that a workflow, custom node, or API call is structurally correct before you spend time on an actual GPU, or for smoke-testing an install on a headless server.

    –fast

    --fast is the opposite side of the dial. It disciplines the smart-memory manager to keep more weights resident on the GPU for longer, trading higher VRAM usage for a lower frequency of model reloads. It is a throughput-oriented flag for cards that have headroom but are being slowed by the manager’s conservative eviction. If you see generation lag that is not explained by image size or sampler steps, and nvidia-smi still shows free VRAM, --fast is worth testing — but monitor memory closely, since it directly raises the chance of an OOM on a card near its limit.

    How to Pick the Right Flag

    Start from your actual VRAM, not from guesswork. The decision tree is short:

    • Less than ~3 GB--lowvram (usually auto-detected), and expect slow generations.
    • 4–6 GB → leave the defaults in place, reduce resolution, and consider a tiled VAE for large upscales before touching flags.
    • 8–12 GB → default behavior should be fine for SD1.5 and SDXL. Reach for --fast only if you measure idle reloads, not as a reflex.
    • 16 GB and up → defaults, with --fast as an optional throughput tweak for tight loops.

    The flags are coarse tools. They change the whole server’s memory posture; they cannot target a single node or model. If only one part of a workflow (say, a VAE decode at 4096×4096) is blowing the budget, the more surgical fixes are usually a tiled VAE decode, a smaller latent, or offloading one heavy model — not re-launching the whole server under --lowvram.

    Verifying Which Mode You Are Actually Running

    Because --lowvram can be auto-detected, the flag in your launch command may not reflect what the server decided. Two checks disambiguate:

    • Read the startup banner. On launch, ComfyUI prints the VRAM it detects and, on very low-memory GPUs, the conservative mode it selected. The first dozen lines of the console are the fastest confirmation.
    • Watch the GPU during a generation. nvidia-smi (or the equivalent for your vendor) shows whether VRAM is near-saturated or mostly idle while system RAM climbs. Consistently near-zero GPU utilization with high CPU use is a strong hint that weights are being paged out — the signature of --lowvram-style offloading or a CPU fallback.

    There is no single “correct” flag. The right choice is the one that keeps your largest workflow inside the VRAM ceiling at a speed you can tolerate, and every flag here just moves that trade-off line.

    Common Pitfalls

    • Stacking flags blindly. Passing contradictory flags or over-riding a wrapper script’s defaults without checking can produce a server that is both slow and memory-hungry. Read what your launcher is already passing before adding more.
    • Assuming --fast is always faster. On a card near its VRAM ceiling it causes OOM instead of speed. It only helps when there is idle headroom being under-used.
    • Treating flags as a substitute for workflow fixes. A 4K upscale that overflows 8 GB will still overflow under --lowvram if the single activation itself does not fit. Tiled decode and smaller latents address the real cause.

    Conclusion

    ComfyUI’s VRAM launch flags are a small API over a single trade-off: how much model weight stays on the GPU versus how often it is reloaded. --lowvram shrinks the footprint for tiny cards, --cpu removes the GPU entirely for smoke tests, --fast holds more in memory for throughput when there is headroom, and --normalvram is the default you rarely need to state. Start with your measured VRAM, keep the flags out of the way unless a specific card size demands one, and prefer surgical workflow fixes for isolated overflow. For the authoritative list and current behavior, consult ComfyUI’s official repository, and see its documentation sections on command-line arguments and memory management. If you are running model-heavy pipelines on consumer hardware, our guide to the open-source video generation stack on consumer hardware covers the surrounding VRAM constraints in more depth.

    🛠️ Resources & Tools Mentioned

    Tools our readers use most for AI tools:

    Disclosure: We may earn a commission if you sign up through these links. All recommendations are independent.

    How This Article Was Tested

    This article was written by Junjie (俊杰) based on hands-on operation of a local AI workstation running Zorin OS on an AMD Ryzen 7 255 with an RTX 5060 Ti 16GB. The commands, file paths, and node configurations shown in this article were executed against that setup before publication. Where a step depends on a specific model version, the version is named in the relevant section so the result can be reproduced.

    Where the article references an external tool, the integration was verified by direct API call or by reading the source repository. When a result depends on a third-party service that may change, the date of the verification is noted in the article footer.

    What This Article Does Not Cover

    Configurations that were not tested on the workstation referenced above — for example, behaviour on a different GPU family, behaviour on a headless cluster, or interactions with closed-source wrappers — are explicitly out of scope. The article is written to be reproducible on the most common consumer-grade ComfyUI / local AI setup, and recommends the reader verify any deviation before depending on the result.

    AI assistance was used to organize notes and to draft explanatory prose, but the technical claims, command outputs, and node configurations were checked against a running environment. If a step in this article does not work as written, please open an issue via the Contact page with the exact command, the error output, and the model or node version in use.