VRGDG YuE2 Unload Models

A 3B music model parked in VRAM is not a small thing, and ComfyUI's own memory manager has no idea it exists. This node is the manual lever: flip unload on, and the pack closes its cached YuE2 pipelines and empties the CUDA cache.

It's a utility node, not a feature. But it's the difference between "I generated a song and now my video workflow is OOM-ing" and "I generated a song, and I moved on."

Why it's needed at all

It depends entirely on which runtime mode you're in, and this is the honest fine print:

isolated_process (the recommended mode): each generation run spawns its own worker, the worker loads YuE2, does the job, and exits. Its memory dies with it. Running this node in that setup is close to a no-op - and it returns exactly that, in the node's own words: it reports how many pipelines it unloaded (usually zero) and notes that isolated workers exit after each run.
in_process_experimental: YuE2 is imported straight into ComfyUI's interpreter, and the pack caches loaded pipelines in a module-level dictionary keyed by configuration. That's why the second generation is faster than the first - and why the model is still sitting on your GPU minutes after you're done with it. This is the case the node was written for.

Note the asymmetry, because it's the part people miss: ComfyUI's own "unload models" behavior covers ComfyUI's models. The YuE2 cache lives in the pack's module state, so nothing else in the UI can free it.

Inputs and outputs

Inputs: one. unload, a boolean, default true, and its tooltip says what it does - release cached in-process YuE2 models and empty the CUDA cache. Set it to false and the node politely does nothing and tells you so.

Outputs: one. status, a string - how many pipelines it closed, plus the reminder that isolated workers exit on their own. It's an OUTPUT_NODE, which matters practically: it executes whenever the graph runs, even if nothing consumes its output. You don't have to wire status anywhere for the unload to happen.

How to place it

Put it at the end of a graph that generates music. That's the whole usage. Two situations where it earns its keep:

Music then video in one session. You render a song in-process, then switch to a Wan or LTX workflow. Dropping this node at the end of the music section frees the model before the video model tries to allocate.
Iterating on configs. The pack's cache is keyed by model, VAE, device, memory budget, backend, quantization, offload, cache dir and hash-verify settings - so changing any of those loads a new pipeline and leaves the old one cached. If you've been fiddling with memory_budget_gib for an hour, you've probably got more than one 3B model resident. This node clears all of them.

It closes pipelines inside the pack's own lock and only calls torch.empty_cache() if CUDA is available, so it's safe on CPU-only boxes. If a pipeline refuses to close cleanly it prints a warning to the console rather than raising and killing your queue - which means if you do see a "Pipeline close warning" line, that's a real signal worth reading, not noise.

Install

Same pack, same route as everything else here: ComfyUI Manager, search vrgamedev, or

cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl.git

Restart ComfyUI and add the node by name. There's nothing else to configure - it has no model paths and no dependency beyond the pack, and it doesn't need the YuE2 virtualenv to exist, since all it does is drop references and empty a cache.

The realistic take

If you followed the pack's own recommendation and stayed in isolated_process mode, you may never need this node - your memory is already being returned every run, at the cost of reloading the model each time. Add it anyway if your graphs mix music and video. It costs nothing, it can't break a queue, and the machinery it talks to is invisible from everywhere else in the UI. That's a fair description of most of the plumbing in ComfyUI: boring until it's the reason you're out of VRAM.