沐阳 H3 · 输出显存释放（内部）

The last barrier in the pack's memory chain, and the simplest. Once the merged IMAGE and AUDIO output exists, it unloads the models.

It's the bookend to H3ConditionMemoryBarrier and H3RefineMemoryBarrier: those free memory between stages so the next stage has room, and this one frees memory after the finished product exists so the next queue isn't starting on a card that's still holding a 33B video model it will never use again.

Inputs and outputs

• images (IMAGE) - the merged picture.
• audio (AUDIO) - the merged soundtrack.
• stage (STRING, default output complete) - a label for the log, so a multi-stage run's output tells you which barrier fired.

Outputs are images and audio, passed through. The description is specific about one detail: it does not copy the output tensors. That matters more than it sounds like it should. A naive release node that cloned its outputs to "be safe" would double the resident size of your finished video in RAM right at the moment you're also trying to free memory. This one hands the same objects along and touches nothing.

Like the pack's other barriers, it declares itself always-changed so the cache can't skip it. Cleanup is a side effect; a cached side effect is a bug waiting for its second queue.

Do you ever wire this?

No. Category 沐阳 H3/内部, and in a Director or long-video-expansion graph it's already in the built subgraph - it sits right before the save node, on both the picture and the audio wires.

Its practical value is diagnostic. When a long job finishes and the next job immediately OOMs, or when you notice VRAM never dropping back after a render, you now know there's supposed to be a node that handles that and which one it is. If someone's hand-built graph omits it - perfectly possible, it's an internal node - that's your answer.

The chain, as a whole

Four barriers, four different problems:

1. H3PreConditionMemoryBarrier - evict stale DiT before conditioning, so the reference VAE isn't fighting several GB of weights for space.
2. H3ConditionMemoryBarrier - after CLIP/VAE encoding, clear them before pass 1.
3. H3RefineMemoryBarrier - after the pass-2 latent and conditioning are ready, clear pass 1, VAEs and the upscaler before loading the pass-2 model.
4. This one - after the output exists, unload everything.

If you're on a 16GB card and something is dying, the useful question is which side of which barrier it died on. Dying during conditioning is a different fix from dying at pass-2 step zero. The pack's README notes that on 16GB Windows cards the automatic memory profile evicts pass-1, VAE and upscaler residency before the pass-2 model loads, and retries once after a real OOM - so an OOM that then succeeds on retry is the system working, not failing.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang

Restart ComfyUI and hard-refresh the browser; it's under 沐阳 H3/内部. No Python dependencies - the pack declares an empty list, and the node is a call into ComfyUI's own model-management layer.

One caveat

Releasing the model at the end of a job means the next job reloads it from disk. If you're running a batch of short H3 jobs back to back, that reload is a real cost and you might not want this barrier firing between them - which is another reason it's an internal node with a sensible default position rather than something you sprinkle around. For more on where memory problems actually show up in ComfyUI graphs, troubleshooting is the broad map.