MiniMax H3 Unload All

This pack caches things aggressively. The streaming DiT, both VAEs, and the 32B text encoder all stay resident between runs so your next generation doesn't pay the load cost again. That's great for iteration and brutal if you've run several generations - suddenly your system RAM is full of a 42 GB checkpoint you're no longer using, and VRAM is still holding a model you've moved on from. MiniMax H3 Unload All is the reset button: one node, no inputs, and it frees every cached model, VAE, and encoder the pack is holding onto.

How it works

It's an output node that calls three cleanup paths in one go: the model lifecycle's unload_all() (the streaming DiT handle), the VAE registry's unload_all_vaes(), and the text encoder's unload_all_encoders(). It returns nothing. Drop it into a workflow when you want that to happen at a specific point - for example at the end of a batch, or in a workflow whose next job is a different model and you don't want H3's footprint squatting on your RAM.

A workflow-practical detail: since it's a node, it only fires when its graph executes. The classic use is to wire it so it runs after your decode/save step - it's an output node, so it executes at the right time in the queue, and the frame wires are the trigger.

The inputs and outputs

None. No required or optional inputs, no outputs. It's a terminal node by design - which is also why you can't accidentally wire anything through it.

Installing it

Pack-wide routine - ComfyUI Manager search "MiniMax H3", or:

cd ComfyUI/custom_nodes
git clone https://github.com/xiaolibai-sys/ComfyUI-MiniMaxH3
pip install -r requirements.txt

then restart. Nothing to configure.

Common issues

• "Why is my next run loading models again?" That's the point. After Unload All fires, the next H3 generation re-streams everything - the trade you asked for. Only put it in the path if you actually want the memory back (e.g. before running a non-H3 workflow in the same session).
• It ran but memory didn't drop. Python and CUDA don't always return VRAM to the OS immediately, and torch's allocator holds some freed blocks. If you're on Linux, nvidia-smi may still show a large footprint - that's the allocator, not a leak.
• No node to connect it to. It's deliberately isolated - that's the design. Wire it after your last output node and let it be the caboose.