Comfy-Org/desktop

Fork 0

mirror of https://github.com/Comfy-Org/desktop.git synced 2026-11-04 23:47:43 +00:00

[GH-ISSUE #1741] [Bug]: ComfyUI Desktop Update Causes Full Model Unload After Every Generation (DynamicVRAM / Async Weight Offloading) #538

New issue

Open

opened 2026-10-31 22:14:13 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-31 22:14:13 +00:00

Owner

Originally created by @iamddtla0620 on GitHub (Jun 11, 2026).
Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1741

App Version

Environment
• ComfyUI Desktop (official installer version)
• Windows 11
• GPU: NVIDIA RTX 3060 12GB
• RAM: 32GB
• PyTorch: 2.10.0+cu128
• CUDA: cu128
Current version:
ComfyUI version: 0.24.1
Problem Summary
After updating ComfyUI Desktop to Core 0.24.1, model execution became significantly slower.
Previously, after generating an image, the loaded checkpoint, CLIP, text encoder and VAE remained resident in VRAM. Subsequent generations would start immediately.
After the update, ComfyUI unloads all models after every generation.
The next generation always triggers a complete reload of:
• Checkpoint
• CLIP (Lumina2)
• Text Encoder (ZImageTEModel_)
• AutoencodingEngine (VAE)
This dramatically increases generation time.
Evidence
ComfyUI startup log:
Set vram state to: NORMAL_VRAM
Using async weight offloading with 2 streams
DynamicVRAM support detected and enabled
VRAM mode is NORMAL_VRAM.
No LOW_VRAM or NOVRAM mode is enabled.
Runtime Behavior
Every generation produces messages similar to:
Requested to load ZImageTEModel_
Model ZImageTEModel_ prepared for dynamic VRAM loading.

Requested to load Lumina2
Model Lumina2 prepared for dynamic VRAM loading.

Requested to load AutoencodingEngine
Model AutoencodingEngine prepared for dynamic VRAM loading.
After generation completes:
Prompt executed in ~155 seconds
VRAM Verification
Using:
nvidia-smi -l 1
Observed behavior:
Before generation:
VRAM usage ~10-11 GB
After generation completes:
VRAM usage drops to ~936 MB
This confirms that the models are actually being unloaded from VRAM rather than simply being remapped.
The next generation must reload all models again.
Additional Findings
Comfy settings file contains no user-configurable options related to:
• DynamicVRAM
• Weight Offloading
• Async Weight Offloading
• Memory Management
• Model Cache
• Model Retention
Example:
"Comfy.Server.LaunchArgs": {}
"Comfy.Server.ServerConfigValues": {}
There appears to be no exposed UI setting or configuration file entry allowing users to disable this behavior.
Expected Behavior
The previous behavior was:

Load model once
Generate image
Keep model resident in VRAM
Subsequent generations reuse loaded models
This provided significantly faster generation times.
Actual Behavior
Current behavior:
Load model
Generate image
Unload all models
VRAM drops to ~936 MB
Reload all models for next generation
Request
Please provide:
• A way to disable DynamicVRAM unloading.
• A way to disable async weight offloading.
• A "Keep models loaded in VRAM" option.
• Documentation describing the new memory management behavior introduced in 0.24.x.
This behavior causes substantial performance regression on RTX 3060 12GB systems compared to previous releases.

Expected Behavior

As stated above.

Actual Behavior

As stated above.

Steps to Reproduce

As stated above.

Debug Logs

Browser Logs

No response

Settings JSON

No response

Other

No response

Originally created by @iamddtla0620 on GitHub (Jun 11, 2026). Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1741 ### App Version Environment • ComfyUI Desktop (official installer version) • Windows 11 • GPU: NVIDIA RTX 3060 12GB • RAM: 32GB • PyTorch: 2.10.0+cu128 • CUDA: cu128 Current version: ComfyUI version: 0.24.1 Problem Summary After updating ComfyUI Desktop to Core 0.24.1, model execution became significantly slower. Previously, after generating an image, the loaded checkpoint, CLIP, text encoder and VAE remained resident in VRAM. Subsequent generations would start immediately. After the update, ComfyUI unloads all models after every generation. The next generation always triggers a complete reload of: • Checkpoint • CLIP (Lumina2) • Text Encoder (ZImageTEModel_) • AutoencodingEngine (VAE) This dramatically increases generation time. Evidence ComfyUI startup log: Set vram state to: NORMAL_VRAM Using async weight offloading with 2 streams DynamicVRAM support detected and enabled VRAM mode is NORMAL_VRAM. No LOW_VRAM or NOVRAM mode is enabled. Runtime Behavior Every generation produces messages similar to: Requested to load ZImageTEModel_ Model ZImageTEModel_ prepared for dynamic VRAM loading. Requested to load Lumina2 Model Lumina2 prepared for dynamic VRAM loading. Requested to load AutoencodingEngine Model AutoencodingEngine prepared for dynamic VRAM loading. After generation completes: Prompt executed in ~155 seconds VRAM Verification Using: nvidia-smi -l 1 Observed behavior: Before generation: VRAM usage ~10-11 GB After generation completes: VRAM usage drops to ~936 MB This confirms that the models are actually being unloaded from VRAM rather than simply being remapped. The next generation must reload all models again. Additional Findings Comfy settings file contains no user-configurable options related to: • DynamicVRAM • Weight Offloading • Async Weight Offloading • Memory Management • Model Cache • Model Retention Example: "Comfy.Server.LaunchArgs": {} "Comfy.Server.ServerConfigValues": {} There appears to be no exposed UI setting or configuration file entry allowing users to disable this behavior. Expected Behavior The previous behavior was: 1. Load model once 2. Generate image 3. Keep model resident in VRAM 4. Subsequent generations reuse loaded models This provided significantly faster generation times. Actual Behavior Current behavior: 1. Load model 2. Generate image 3. Unload all models 4. VRAM drops to ~936 MB 5. Reload all models for next generation Request Please provide: • A way to disable DynamicVRAM unloading. • A way to disable async weight offloading. • A "Keep models loaded in VRAM" option. • Documentation describing the new memory management behavior introduced in 0.24.x. This behavior causes substantial performance regression on RTX 3060 12GB systems compared to previous releases. ### Expected Behavior As stated above. ### Actual Behavior As stated above. ### Steps to Reproduce As stated above. ### Debug Logs ```powershell ``` ### Browser Logs _No response_ ### Settings JSON _No response_ ### Other _No response_

bsakaguchi added the

bug

performance

Potential Bug

labels

2026-10-31 22:14:13 +00:00

bsakaguchi commented

2026-10-31 22:14:14 +00:00

Author

Owner

@beeeeswax commented on GitHub (Jun 15, 2026):

Noticed same huge drop in repeated runs of the same workflow on a 5090 system with 64GB RAM so it affects both ends of the spectrum. --disable-smart-memory helped a little, but some models still seem to be getting flushed after every use.

For example I have a workflow with multiple chained detailers, all using the "Load Diffusion Model" node and z-image turbo bf16 as the model. Before these changes, I could cancel the workflow during detailing, re-roll the seed and start again and detailing would start again immediately. Now, every time I cancel to re-roll I have to wait for "Model Initializing...". Very frustrating.

@beeeeswax commented on GitHub (Jun 15, 2026): Noticed same huge drop in repeated runs of the same workflow on a 5090 system with 64GB RAM so it affects both ends of the spectrum. --disable-smart-memory helped a little, but some models still seem to be getting flushed after every use. For example I have a workflow with multiple chained detailers, all using the "Load Diffusion Model" node and z-image turbo bf16 as the model. Before these changes, I could cancel the workflow during detailing, re-roll the seed and start again and detailing would start again immediately. Now, every time I cancel to re-roll I have to wait for "Model Initializing...". Very frustrating.

bsakaguchi commented

2026-10-31 22:14:14 +00:00

Author

Owner

@forbiddenworld commented on GitHub (Jun 21, 2026):

I have a 3080 10GB card and I noticed the same. Each subsequent image generation loads all the models again.
In the ComfyUI desktop app I added the start-up argument "--disable-dynamic-vram" and now it behaves as before. Each subsequent image generation starts immediately and the models do not get unloaded (right clicked the instance and chose "manage" then the "Startup Args" tab).

@forbiddenworld commented on GitHub (Jun 21, 2026): I have a 3080 10GB card and I noticed the same. Each subsequent image generation loads all the models again. In the ComfyUI desktop app I added the start-up argument "--disable-dynamic-vram" and now it behaves as before. Each subsequent image generation starts immediately and the models do not get unloaded (right clicked the instance and chose "manage" then the "Startup Args" tab).

bsakaguchi commented

2026-10-31 22:14:14 +00:00

Author

Owner

@iamddtla0620 commented on GitHub (Jun 21, 2026):

@forbiddenworld
Your solution is indeed effective.

@iamddtla0620 commented on GitHub (Jun 21, 2026): @forbiddenworld Your solution is indeed effective.

bsakaguchi referenced this issue

2026-10-31 22:18:03 +00:00

[PR #538] [MERGED] v0.4.0 #919

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Comfy-Org/desktop#538

No description provided.

Rows
Columns