SemBridge Unload

Every ComfyUI install eventually meets the same wall: the audio part of the graph finishes, the video part wants the card, and something is sitting on three gigabytes that ComfyUI's own model manager doesn't know about. SemBridge keeps its model in its own resident slot rather than going through ComfyUI's checkpoint machinery, so the usual "unload models" button doesn't see it. This node is the eviction notice.

It does one thing: frees the resident SemBridge model. No inputs required, one output, and you can leave it dangling at the end of a graph.

Why a node and not a setting

You have two ways to get the memory back. The first is keep_loaded on the Loader - set it off and the pack releases the model after every single generation. The second is this node, which releases it once, where you put it.

Which to use depends on the shape of your session. If you're iterating on the same voice, keep keep_loaded on and put Unload at the tail of the workflow: reloading costs about six seconds on a warm file cache, and paying that on every queue is a bad trade. If the graph is one long chain - SemBridge speaks, then a Wan or LTX render eats the rest of the card - turn keep_loaded off, or drop Unload in between, and stop the audio model squatting under the video model.

Mechanically it's unglamorous: the pack's resident slot is set to nothing, a garbage collection runs, and torch.cuda.empty_cache() returns the freed blocks. That's it. There's no offloading to system RAM, no re-quantising, no magic - the next generation reloads from disk.

The one input, and why it's a bit of a hack

after is an optional AUDIO input whose only purpose is to give the node something to depend on. ComfyUI executes a node when its inputs are ready, so if you want the unload to happen after your audio is written, wire the generation node's audio into after. Otherwise the scheduler is free to run it whenever, and "whenever" might be before the render you were trying to free memory for.

It's an execution-order trick, not a data dependency - nothing reads that audio. Which is why it's typed AUDIO and why you'd wire it from whichever node produced the last sound in the graph.

The node is marked non-idempotent in the pack's source, which matters more than it sounds. ComfyUI caches node results and skips re-execution when nothing upstream changed. A pure "free the model" utility that got cached would run once and then politely do nothing for the rest of your session. The non-idempotent flag forces it to actually execute on every queue.

Output

report, a STRING - small JSON with two fields: unloaded, whether there was a resident model to free, and cuda_allocated_mib, what torch still reports as allocated afterwards. Wire it into a text display node, or just watch it in the console when something doesn't add up.

Read unloaded: false as "there was nothing resident", not as failure - if keep_loaded was off on the Loader, the model was already gone by the time this ran.

Install

Comes with the pack. If SemBridge is in custom_nodes and you've restarted, it's in loaders/sembridge, right next to the Loader.

cd ComfyUI/custom_nodes
git clone https://github.com/hiroki-abe-58/ComfyUI-SemBridge
python -m pip install -r ComfyUI-SemBridge/requirements.txt

The node needs no weights to run, so it will happily appear and execute on a machine where you haven't downloaded the 4.3 GB model yet - you just get unloaded: false. As with anything in this pack, a ComfyUI old enough to lack the V3 node API will fail at import rather than showing the node.

Two things that look like bugs

VRAM doesn't read zero afterwards. cuda_allocated_mib is torch's allocator talking, and freeing it returns blocks to the driver without tearing down the CUDA context - ComfyUI itself is still holding a few hundred megabytes, and nvidia-smi will show a floor that never goes away. Judge by whether your next model loads, not by the number.

Freeing doesn't help if the other model was never going to fit. SemBridge takes about 2.9 GiB at bfloat16, and a 29-second utterance pushed peak allocation to 4.3 GiB. If you're within a gigabyte of the edge, do the unload before the big model starts and expect the allocator to need a moment; if you're over by four, unload at the end of the graph and re-run - which is also the reason keep_loaded exists as an option rather than a fixed behaviour.