GGUF dynamic-vram

[cmpx123]

Feature Idea

DynamicVRAM announcement should document that custom GGUF loaders using GGUFModelPatcher(ModelPatcher) do not use ModelPatcherDynamic, so GGUF UNet/CLIP remain on legacy lowvram behavior unless a wrapper such as ComfyUI-MultiGPU handles placement.

Existing Solutions

No response

Other

No response

[yamatazen]

@city96 Please check this

[cmpx123]

Thanks. To clarify, this is mainly a documentation / expectation issue, not a complaint against ComfyUI-GGUF.

DynamicVRAM is enabled by default in ComfyUI, so users may assume that GGUF UNet/CLIP loaders also benefit from it. However, current GGUF loaders that use their own GGUFModelPatcher(ModelPatcher) path do not automatically use ModelPatcherDynamic.

This makes the behavior confusing: logs may show legacy loaded partially / loaded completely behavior for GGUF models, while users expect DynamicVRAM behavior.

A short note in the DynamicVRAM documentation/announcement would help, for example:

DynamicVRAM applies to models loaded through ComfyUI's Dynamic ModelPatcher path. Custom nodes using their own ModelPatcher, including some GGUF loaders, may remain on legacy lowvram/offload behavior unless they explicitly support DynamicVRAM.

There is already work in progress on the GGUF side:
city96/ComfyUI-GGUF#427

I think documenting the current limitation would prevent users from misdiagnosing GGUF memory behavior as a ComfyUI regression.

[lovexiaofan123]

I personally strongly recommend adding a description of dynamic memory usage to the new announcements. This is because the generation speed can vary, sometimes slowing it down and sometimes speeding it up. Therefore, users should manually turn the logs on or off as they perceive these changes, rather than having a default setting for it to be enabled.