ComfyUI Reloads the Model Every Run: Why and Fixes

If every queued prompt re-reads your checkpoint from disk, the --cache-* flags are not your fix — they cache node results, not model weights. Weights get evicted for two different reasons: ComfyUI's memory estimator decides the model will not fit and forces a partial load, which then streams the missing weights over PCIe on every single step; or DynamicVRAM re-stages the model after a workflow, dtype or LoRA change and never settles again. One console line separates them, and the fastest single test is relaunching with --disable-dynamic-vram.

This is a performance symptom rather than a crash, which is why it is so hard to search. There is no error string to paste. People describe it in prose — "it reads from the disk every time I change the prompt", "RAM is maxed and nothing offloads", "the first run was 25 seconds and now every run is three minutes" — and those descriptions fragment into a dozen different queries that never meet.

Flag names, help text and log strings below were read from ComfyUI on master in August 2026: comfy/cli_args.py, comfy/model_patcher.py, comfy/model_base.py and comfy/model_management.py. This subsystem changed substantially through 2026, so treat python main.py --help on your own install as more current than any article, including this one.

Which Console Line Tells You It Reloaded?

ComfyUI already tells you whether the model fit. Most people never see the line because the useful half is logged below the default threshold.

Three strings matter. The first is at INFO level, so you have it already — it is printed from comfy/model_management.py every time a model is brought in:

Requested to load <ModelClassName>

If that line appears once at the start of a session, you are fine. If it appears before every generation, your model is being evicted between prompts — that is the whole diagnosis, and it is the exact evidence used in issue #14276, where the reporter noted "Requested to load ZImageTEModel_" appearing on every single prompt after a workflow switch.

The second pair comes from comfy/model_patcher.py and tells you whether the load was whole or partial. These are the format strings, verbatim:

"loaded completely; {} {:.2f} MB loaded, full load: {}"
"loaded partially; {} {:.2f} MB loaded, {:.2f} MB offloaded, {:.2f} MB buffer reserved, lowvram patches: {}"

A real example, quoted by the reporter of issue #15585 on an RX 7800 XT:

partially; 6140.00 MB usable, 5468.00 MB loaded, 7062.31 MB offloaded

Read it left to right. Usable is the VRAM budget ComfyUI believes it has for this model. Loaded is what made it onto the card. Offloaded is the remainder, which now lives in system RAM and has to cross the PCIe bus during sampling — not once, but on every step, for every generation. That third number is your slowdown, expressed in megabytes. After a fix in the same issue, the same model reported "completely; 12939.60 MB usable, 12532.86 MB loaded" and the run went from roughly 15 minutes per image to 328 seconds.

The third string is the one you are probably missing. model_management.py logs the per-model breakdown through a custom level:

detail("Model loaded: patcher=%s model=%s ram_mb=%.1f vram_mb=%.1f", ...)

detail() is defined in comfy/internal_logging.py as DETAIL = 15 — between DEBUG (10) and INFO (20). Your console is at INFO by default, so every one of those lines is being discarded. Lower the threshold below 15 with ComfyUI's --verbose argument (its help reads "Set console logging with no values or LEVEL, or add a LEVEL FILE log output. May be repeated.") and the RAM-versus-VRAM split for every model appears. On a DynamicVRAM install you will also start seeing the staging line from ModelPatcherDynamic, which reports Model ... prepared for dynamic VRAM loading followed by how many megabytes were staged and how many patches were attached.

Two more lines worth recognising, both from model_management.py: Unloading <ClassName> and <N> models unloaded. If those appear between your generations, something is deliberately freeing the model, and the next section is why.

Why Does the Model Reload on Every Prompt Change?

Start with the misconception that costs people the most time: ComfyUI's --cache-* flags have nothing to do with model weights. They control the execution cache — the results of individual nodes, so that changing your prompt does not re-run the upstream half of the graph. Model residency is handled somewhere else entirely, in the model-management layer. This is why --cache-classic "fixes" the symptom for some people and does nothing at all for others: it changes whether the loader node re-executes, not whether the weights survive.

The one place they meet is --cache-none, whose help text is explicit: "Reduced RAM/VRAM usage at the expense of executing every node for each run." Every node includes your checkpoint loader. If --cache-none is in your launch script, remove it and retest before you change anything else — you have asked ComfyUI to re-execute the loader on every queue, and it is obliging. The memory-management section of our complete ComfyUI guide covers where each layer sits if you want the fuller picture.

Beyond that, the reload has four documented causes:

Issue #14618 is the canonical version of the complaint — its title is literally "ComfyUI keeps loading models on every prompt change". The environment was an RTX 3060 with 12,287 MB of VRAM and 32,751 MB of system RAM on Windows, ComfyUI 0.26.0 with torch 2.9.0+cu126, custom nodes disabled. The reporter's own summary is the best description of the symptom anyone has written: "previously, everything was cached in memory, and the disk didn't keep reading. Right now, even though I have free memory, the memory is not used, and the disk is used on every change."

Issue #14276 is the more infuriating variant, because it has a trigger and no recovery. On an RTX 5070 Ti (16GB) running ComfyUI v0.23.0-10, executions ran at 23-28 seconds until a workflow or model-dtype switch, after which every prompt reloaded and ran at 120-190 seconds with no way back except a full restart. The reporter's framing is the correct expectation: "After the first load, models should remain staged in Dynamic VRAM and not reload on every prompt." Their workaround was --disable-dynamic-vram.

The practical read: if your slowdown started at a specific moment in a session, restart ComfyUI before you debug anything. If it is there from the first prompt of a fresh session, it is configuration or the estimator, and the next section applies.

Can the Memory Estimator Force a Partial Load?

Yes, and this is the most interesting failure in the family, because the model fits perfectly well — ComfyUI just thinks it does not. Before loading, ComfyUI predicts how much memory sampling will need. If the prediction exceeds what it believes is available, it loads the model partially and streams the rest. Over-predict, and you get PCIe thrashing on hardware that had room to spare.

Here is the prediction, verbatim from BaseModel.memory_required() in comfy/model_base.py:

if comfy.model_management.xformers_enabled() or comfy.model_management.pytorch_attention_flash_attention():
    dtype = self.get_dtype_inference()
    area = sum(map(lambda input_shape: input_shape[0] * math.prod(input_shape[2:]), input_shapes))
    return (area * comfy.model_management.dtype_size(dtype) * 0.01 * self.memory_usage_factor) * (1024 * 1024)
else:
    area = sum(map(lambda input_shape: input_shape[0] * math.prod(input_shape[2:]), input_shapes))
    return (area * 0.15 * self.memory_usage_factor) * (1024 * 1024)

Two formulas, chosen by whether ComfyUI thinks you have a memory-efficient attention backend. Work the arithmetic at bf16, where dtype_size is 2 bytes:

• Efficient branch: area × 2 × 0.01 × factor = area × 0.02 × factor
• Fallback branch: area × 0.15 × factor
• Ratio: 0.15 ÷ 0.02 = 7.5×

That is not an estimate of ours; it is division. And it is exactly the gap measured in issue #15585, "--use-flash-attention is ignored by the memory estimator, causing a 7.5x overestimate → forced partial load / PCIe thrashing" (open, 13 August 2026). The condition tests for xformers or PyTorch flash attention and not for the separately-enabled flash-attention backend, so a user who launched with --use-flash-attention fell into the conservative branch anyway. The reporter's figures: 2,534 MB predicted on the efficient formula versus 19,008 MB on the fallback — 19,008 ÷ 2,534 = 7.5, the same number the arithmetic predicts. On an RX 7800 XT with 16GB, a 19GB prediction guarantees a partial load.

A second flavour of the same bug: issue #15356, "LTXAV memory estimate differs by ~128x between video-only and nested AV latents, causing PCIe thrashing" (open, 6 August 2026). Same mechanism, different input shapes, far larger error.

What to do about it. You cannot patch the estimator from a launch flag, but you can steer which branch it takes and how much headroom it has:

1. Check which attention backend you actually enabled. If you passed --use-flash-attention, try a run without it. On builds affected by #15585 the conservative branch may be costing you far more than the attention kernel saves.
2. Stop reserving VRAM you do not need to. Every gigabyte you hold back is a gigabyte the estimator subtracts from "usable", which is what pushes a borderline model over into a partial load.
3. Compare the reported "usable" number with your card. If loaded partially says 6,140 MB usable on a 16GB card, something is claiming ten gigabytes — another application, another model still resident, or a headroom setting.

Which Flags Actually Control Cache Retention?

Two separate groups, and conflating them is the whole problem. Help text below is quoted from comfy/cli_args.py on master, not paraphrased.

Group one: the node-result cache. These four are a mutually exclusive argparse group — pass two and the launch is rejected. None of them keeps model weights resident.

Group two: weight residency. These are the ones that decide whether a checkpoint survives between prompts.

Note the last two rows. --disable-smart-memory is frequently recommended in older threads, and its own help text describes exactly the behaviour you are trying to stop. --lowvram is inert whenever DynamicVRAM is active, which is the default — its help string says so.

It is also worth knowing that no flag has ever existed to control model-weight caching directly. Issue #9250 is a still-open feature request from August 2025 asking for a --no-cache-models startup flag — which is the clearest possible evidence that the --cache-* family does not govern models.

What Should You Change First?

One change at a time, timing the same workflow after each. ComfyUI prints "Prompt executed in X seconds" after every run, so you have a free stopwatch. Use a graph you actually run rather than a toy one — an SDXL graph and a video graph land on opposite sides of this, and our ComfyUI FLUX workflow guide has one you can freeze as a baseline.

1. Remove --cache-none and --disable-smart-memory from your launch script if either is there. Both instruct ComfyUI to do the thing you are complaining about.
2. Restart ComfyUI. If the slowdown appeared partway through a session after a workflow or model switch, #14276 says a restart is the only recovery. Test this before spending an evening on flags.
3. Add --disable-dynamic-vram and retest. This is the highest-information single test on the page: it swaps the on-demand loader for the older estimate-based one. If the reloads stop, you know which subsystem owns your problem.
4. Read the load line. loaded completely means residency is your issue; loaded partially means capacity or estimation is, and the offloaded megabytes tell you how badly.
5. If it says partially, attack "usable" rather than the model. Drop --reserve-vram, close whatever else is on the GPU, and check nothing is still resident from a previous workflow.
6. If you have VRAM headroom, try --highvram. Its documented job is keeping models in GPU memory instead of unloading them to CPU memory after use — which is precisely the behaviour you want back.
7. Only then consider storage. --fast-disk prefers disk-backed loading and helps on fast NVMe. On a hard disk or a network share it points the wrong way entirely.

If you are here because a specific model is simply too big for your card rather than because a working setup regressed, the fix is a smaller build, not a flag: Run FLUX on a low-VRAM GPU covers the quantisation options, FLUX VRAM requirements by GPU lists what each card holds, and the VRAM calculator will tell you before you download anything.

When Is This an Out of Memory Problem Instead?

Reload thrash and out-of-memory are the same subsystem behaving differently, and the fixes diverge. The distinction is simple: if you get a completed image slowly, you have a thrash problem and this page applies. If the process dies, you have a capacity problem and the flags above will not save you.

Issue #12332, "Maxed Out RAM, ComfyUI Is Not Offloading Properly" (open since 6 February 2026), is the boundary case. On an RX 7900 GRE with 16GB VRAM, 32GB of DDR5 and ROCm 7.3, a WAN 2.2 image-to-video workflow that had run "dozens of times without problems" started exhausting VRAM, then RAM, then swap. The log shows "Memory: 10.38GB used / 15.98GB total (5.60GB free)" before the low-noise model loads, and then the run ends with a single word from the kernel: Killed. Disabling custom nodes, smart memory and pinned memory changed nothing.

Killed with no traceback is the Linux OOM killer, not a ComfyUI error. If that is what you have, you are out of system RAM, and the useful direction is reducing what must be resident at once, not tuning retention.

Some arithmetic that helps calibrate expectations, taken from constants in comfy/model_management.py. ComfyUI holds back EXTRA_RESERVED_VRAM, which is 400 MB, or 600 MB on Windows, and its minimum inference reserve is 0.8 GB + extra_reserved_memory():

• Linux or macOS: 0.8 × 1024 MB + 400 MB = 1,219 MB ≈ 1.19 GB
• Windows: 0.8 × 1024 MB + 600 MB = 1,419 MB ≈ 1.39 GB

So on a 12GB card you are budgeting against roughly 10.6GB on Windows or 10.8GB elsewhere, not 12GB, before anything else on your desktop takes a share. A model that "should just fit" often does not, and the partial load that follows is the thrash this page is about.

Two more open reports worth reading before you conclude anything about your own hardware: #15759, "Memory management changes and leaks after v0.30.2->v0.33.1 update" (20 August 2026), and #14907, "0.27.1 - Memory Usage Degraded even more AGAIN" (12 July 2026). If your regression coincides with an update, you may simply be looking at one of those.

On AMD hardware specifically, issue #13730 reports LTX 2.3 stalling during "Requested to load LTXAV" on an RX 7900 XTX unless dynamic VRAM, pinned memory and async offload are all disabled — a useful combination to know about if you are on ROCm. Our AMD ROCm local AI setup guide covers the surrounding stack.

What Is Still Unverified Here?

• We did not reproduce any of this on our own hardware. Every figure above is either quoted from a linked GitHub issue, quoted from ComfyUI's source, or derived by arithmetic we show in full. There is no bench here and no benchmark table pretending there is one.
• The 7.5× ratio is arithmetic, not a measurement. It follows from two constants in memory_required() at a 2-byte dtype. At fp32 the same division gives 0.15 ÷ 0.04, or 3.75×. Your model's memory_usage_factor cancels out of the ratio but absolutely determines the absolute numbers, and it differs per architecture.
• Several of these issues are open and will move. #14618, #14276, #15585, #15356, #12332, #15759, #14907 and #15666 were open at the time of writing. Click through before you rebuild a workflow around a workaround.
• --disable-dynamic-vram is a diagnostic, not a recommendation. On a machine with fast storage and plenty of RAM, DynamicVRAM does useful work, and turning it off can cost you the ability to run a large model at all. Time both, on your workflow, before making it permanent.
• Custom nodes can cause this on their own. A node that reloads a model, patches weights, or holds a reference that prevents unloading will produce the same symptom. #14618's reporter disabled custom nodes and still saw it; that test costs one restart and rules out an entire category.

FAQ

Why does ComfyUI reload the model every time I change the prompt?

Because the weights were evicted between runs, not because the prompt invalidated them. The usual causes are --cache-none in your launch script (its help text says it executes every node for each run, loader included), DynamicVRAM re-staging after a workflow or dtype switch, or a memory estimate that forced a partial load. Watch for Requested to load before each generation — if it is there every time, the model is being unloaded every time.

Do the --cache flags stop ComfyUI reloading models?

No. --cache-ram, --cache-classic, --cache-lru and --cache-none control the execution cache — the stored results of individual nodes — not model weight residency. The only one that touches this symptom is --cache-none, which makes it worse by forcing the checkpoint loader to re-run on every queue. Model residency lives in the model-management layer and is governed by the DynamicVRAM and VRAM-state flags.

What does "loaded partially" mean in the ComfyUI console?

That the model did not fit in the VRAM budget ComfyUI calculated, so part of it stayed in system RAM and has to cross PCIe during sampling. The line reports usable, loaded and offloaded megabytes plus the number of lowvram patches. A large offloaded figure is the direct cause of a slow generation — in issue #15585 a 7,062 MB offload corresponded to roughly 15 minutes per image, versus 328 seconds once the model loaded completely.

Why is my RAM maxed out when ComfyUI should be offloading?

Offloading moves weights to system RAM, so a full RAM reading is offloading working, not failing — until it exhausts RAM and swap. Issue #12332 documents exactly that progression on a 16GB AMD card with 32GB of system RAM, ending in the process being Killed by the kernel. If you are reaching swap, you have a capacity problem rather than a retention problem, and reducing what must be resident is the direction that helps.

Is --disable-dynamic-vram safe to leave on permanently?

It is safe in the sense that it restores ComfyUI's older estimate-based model loading, which is what every guide written before 2026 assumes. Whether it is right for you is a benchmark question: DynamicVRAM is a genuine improvement on some configurations and a regression on others. Time the same workflow with and without it and keep whichever wins on your machine.

How do I see ComfyUI's per-model memory breakdown?

Lower your console log level. The line Model loaded: patcher=... model=... ram_mb=... vram_mb=... is emitted at a custom level of 15, defined in comfy/internal_logging.py as DETAIL, which sits below the default INFO threshold of 20 and is therefore discarded. Use ComfyUI's --verbose argument to drop the threshold and those lines appear, giving you the RAM-versus-VRAM split for every model in the graph.

Sources

• ComfyUI — comfy/cli_args.py — every flag name, default and help string quoted above, including the mutually exclusive cache group and --verbose
• comfy/model_base.py — BaseModel.memory_required(), the 0.01 and 0.15 constants and the attention-backend condition
• comfy/model_patcher.py — the loaded completely / loaded partially / Unloaded partially format strings and the dynamic staging line
• comfy/model_management.py — Requested to load, Unloading, the Model loaded: detail line, EXTRA_RESERVED_VRAM and minimum_inference_memory()
• ComfyUI issues #9250, #12332, #13730, #14162, #14276, #14618, #14907, #15275, #15356, #15585, #15666, #15759 — titles, dates and open/closed states as listed in the tracker in August 2026