Model Memory Usage Factor Override
Lie to ComfyUI's VRAM estimator
- model
- MODEL
Before ComfyUI samples, it guesses how much VRAM the model will need and uses that guess to decide how aggressively to offload weights to system RAM. That guess is a heuristic, and heuristics are sometimes wrong - too cautious and it offloads more than necessary, so sampling crawls; too optimistic and you hit an out-of-memory crash mid-run. This node is the manual override: it scales the estimate up or down so you can correct a bad guess instead of living with it.
It's part of KJNodes, kijai's utility pack. This is squarely an expert escape hatch - the kind of low-level lever you reach for when you're squeezing a Flux- or Wan-class model onto a card that's right at the edge of fitting.
How it works
ComfyUI's memory management keeps as much of the model on the GPU as it thinks is safe and streams the rest from RAM. The "memory usage factor" feeds that safety calculation. Scale it down and ComfyUI believes the model is lighter than it is, so it keeps more resident and offloads less - faster, but you're betting you won't OOM. Scale it up and it plays it safe, offloading more to avoid a crash at the cost of speed. It's a multiplier on an estimate, not a hard VRAM cap.
The inputs and output that matter
- model - the model to patch. The override rides along with it.
- memory_usage_factor - the multiplier (default 1). Values above 1 make ComfyUI more conservative (more offloading, safer against OOM); values below 1 make it keep more on the GPU (faster, riskier). The range is wide, but you're usually nudging within a fraction of 1, not swinging to extremes.
The output is the same MODEL with the override attached - chain it into your sampler like any model patch.
Installing it
ComfyUI Manager → search KJNodes for ComfyUI → install → restart. Or cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r ComfyUI-KJNodes/requirements.txt, and restart.
Where people get burned
- This isn't the first thing to try. If you're OOMing on a big video model, the community's usual moves - block swapping, fp8 weights, offload settings, the VRAM-saving attention nodes kijai ships for Wan - do more heavy lifting. This factor is a fine-tune on top, not a replacement for them.
- Push it down too far and you OOM anyway. Telling ComfyUI the model is lighter than it is buys speed right up until it doesn't fit, then it crashes. If you lowered the factor and started crashing, that's the cause - raise it back.
- Leave it at 1 unless you have a reason. The default estimate is right often enough. Reach for this only when you've measured a real problem: needless offloading slowing you down, or an OOM you're trying to nudge past.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| memory_usage_factor | FLOAT | 1.0000–100 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |