VRAM/RAM Manual Override

If ComfyUI keeps misjudging how much memory you have - telling you a model won't fit when it should, or loading something it can't and OOMing - this is the hammer. VRAM/RAM Manual Override (class VRAMOverrideNode) is one node and one job: it makes ComfyUI report whatever VRAM and RAM numbers you tell it to, so the automatic memory manager budgets against your numbers instead of the ones it detected.

That's it. That's the whole pack, and it's worth being clear about what it is and isn't. It doesn't free memory, it doesn't compress anything, and it doesn't add VRAM. It lies to ComfyUI about how much you have, and ComfyUI's offloading logic does the rest. Which is exactly what some people need, and a foot-gun for everyone else.

How it works

ComfyUI's memory manager asks a handful of questions before every load and generation: how much VRAM is free? how much is total? how much system RAM is on hand? Those answers (get_free_memory, get_total_memory, get_vram_max_free_lib, get_torch_memory_stats in comfy.model_management) decide how much it keeps on the GPU versus offloading to system RAM.

This node monkey-patches all of them to return your numbers instead of real ones, sets ComfyUI's internal VRAM_TOTAL/RAM_TOTAL constants, and - because some parts of the stack query PyTorch and psutil directly - patches torch.cuda.get_device_properties() and psutil.virtual_memory() too, so every query in the whole process sees the fake values. A nice touch: the patch wrapper handles both the int and tuple returns that different ComfyUI versions use, which tells you the author is chasing a moving target.

Two reasons you'd bother. First, a genuine misdetection bug - some Windows/driver setups report a wild free-VRAM number and ComfyUI tries to use VRAM that isn't there, or conversely reports almost nothing and crawls while offloading. Forcing the real figure fixes that. Second, manual allocation: if you want to keep, say, 8 GB of a 24 GB card free for a game or another job while generating, tell the node vram_gb is 16 and ComfyUI will hold back the rest.

The two knobs

Only two inputs, both integers:

• vram_gb - VRAM in GB to report. Default 8, range 1–128.
• ram_gb - system RAM in GB to report. Default 32, range 1–512.

It's an output node with no outputs - drop it anywhere in a workflow, queue the prompt, and the patch applies process-wide for the rest of the session. Re-run it with different values and it re-patches.

Installing

ComfyUI Manager, search VRAM_Fix_Comfy (the registry display name is "VRAM FIX COMFY"), install, restart. Or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/tj5miniop/VRAM_Fix_Comfy

Then restart ComfyUI. There are no model downloads and no extra dependencies - it only uses torch and psutil, both already present. That's the whole install story.

Where people get burned

The startup hook is the trap. The pack doesn't wait for you to use the node - merely installing it runs apply_memory_patch(8, 32) on import, so every session starts with ComfyUI convinced you have 8 GB of VRAM. On a 12 GB card that means needless offloading and slowness from second one. If you install this, put the node in a workflow with your real numbers and run it, or uninstall.

Second, lying high is how you get a hard crash. If ComfyUI thinks it has more VRAM than is actually free, it stops offloading, and torch.cuda.OutOfMemoryError is what replaces graceful degradation. Lying low is merely slow - GPU↔RAM shuffling over PCIe is roughly an order of magnitude slower than VRAM, and the community verdict is that it's usually "not worth it."

Third, be careful with shared workflows. Anyone who drops this node into a graph they post - say, 24/64 for their rig - is shipping a memory-lie that runs on your machine the moment you queue it. And because it replaces functions in model_management, a ComfyUI update that renames internals will silently break or ignore the patch. It's a blunt instrument from a tiny, unvetted pack (it has essentially no community footprint). For the common "model barely fits" case, the smarter lever is a quantized GGUF - the KB's rule of thumb: try default memory flags before reaching for memory hacks at all. Reach for this node when detection is actually wrong, not when you're hoping it'll conjure VRAM that isn't there.