YuE2 卸载/取消
The 'unload' node that doesn't unload anything
- model
- status
In a normal ComfyUI pack, "unload" means "free the VRAM". Here it doesn't, and the pack will happily tell you so - the endpoint's own response message translates to the worker is isolated per task and doesn't occupy model VRAM when idle. There's nothing to free. YuE2 runs in its own process, it loads when a job starts and lets go when the job ends.
So what is this node for?
What it actually does
Two jobs, both useful: it reports the state of the service, and it can cancel the running job.
Required inputs are model (from YuE2 模型服务, mostly so the node has a reason to exist in the graph) and cancel_current. Optional: force_cancel. Output: status - a JSON string of the service's response, which includes the current job and the number of jobs queued behind it.
Set cancel_current on and queue, and the worker cancels whatever is currently running. Turn on force_cancel as well and it escalates past the polite cooperative check to killing the worker outright.
Like the export node, this is an output node that reports a non-comparable change state, so it fires on every queue rather than being cached.
When to reach for it
You've queued a five-minute song, you've realized the lyrics are wrong, and you don't want to alt-tab into the WebUI at 127.0.0.1:8189 to hit stop. Wire this node up, tick cancel_current, queue. Useful for the same reason every cancel button is useful: it stops you from force-quitting ComfyUI because you can't reach the thing that's burning GPU.
It's also the honest answer to "what's actually running". The status output tells you the current job ID and the queue depth, which in a single-GPU serial worker is real information - tasks share one queue, so your third queue press isn't running in parallel, it's waiting in line.
The fine print
Cancellation is cooperative. The worker checks for a cancel request between units of work, not mid-unit. During the acoustic stage that's a token or a chunk; during VAE decode it's noticeably laggy, and the pack's own documentation warns about exactly that. So a cancel that takes ten seconds isn't broken.
Force-cancel kills the worker, and the next job pays for it. A cold start means the service reloads the model before anything else happens, which is a slow first run that looks like a hang. That's often still the right call when a job is genuinely stuck - just know the trade.
This is not a memory-management node. If you saw it in the node list and assumed it clears YuE2 out of VRAM, no such operation exists here, because there's nothing resident to clear. If you're chasing VRAM, the budget on YuE2 模型服务 is the lever, and the note there applies: it's a ceiling the worker enforces, not a reservation.
Don't put it in the middle of a pipeline. It's an output node; it belongs on its own branch, queued when you want it. Wiring it upstream of a generation does nothing helpful.
If there's a takeaway, it's that this pack's node names describe jobs in a pipeline, not ComfyUI mechanics. The loader doesn't load, and the unloader doesn't unload - both are fine once you know what they're for.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model | YUE2_MODEL | — | |
| cancel_current | BOOLEAN | false | — |
| force_cancelopt | BOOLEAN | false | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |