H3 Stage · Independent UNET Load After Result (T8 EXP)

Two-stage H3 workflows want different models for the two stages. The obvious way to do that is two UNETLoader nodes side by side, which ComfyUI will happily queue - and which on a 33B joint audio-video model means you can find yourself holding two large model allocations at once. That's the difference between finishing a run and watching your card run out of memory.

MiniMaxH3StageUNETLoaderAfterEXPT8 fixes the ordering. It takes a completed stage as an input, verifies the receipt says the preceding stage actually completed, and then loads this stage's diffusion model through Core's own UNETLoader. Because the completed stage is a hard dependency, the graph can't legally load the second model before the first stage is done.

Inputs

• completed_stage - a T8_STAGE_RESULT. In practice this is either the stage_result straight from MiniMaxH3StageSamplerEXPT8 (when you're running both stages in one graph) or the output of MiniMaxH3StageLoadEXPT8 (when you're resuming only the HIGH stage from a frozen LOW). This is the node's whole ordering mechanism.
• unet_name - a combo populated from models/diffusion_models, i.e. the same list Core's loader shows. Same names, same folder.
• weight_dtype - default, fp8_e4m3fn, fp8_e4m3fn_fast, or fp8_e5m2. Core's options, unchanged. If you're running a quantised H3 base, pick the matching dtype; on a 16 GB card an fp8 path is usually the difference between fitting and not.

Outputs: model (a normal MODEL - wire it into that stage's setup and LoRA chain as usual) and report_json, which records that the model was loaded after a verified completion, plus the preceding stage's identity hash and the boundary note.

The honest caveat in the source

Two details from the implementation worth knowing, because they're the kind of thing people discover by surprise.

First, this deliberately calls Core's loader rather than cloning an existing MODEL. ComfyUI may deduplicate two bare loader nodes with the same file into one shared patcher anyway - and cloning a shared patcher can't isolate two live model_sampling owners, which would quietly break a two-clock schedule. Calling the loader is the safe choice, but it means the pack can't promise you two fully independent copies of the network.

Second, it may cost you CPU/RAM/VRAM until the earlier model is released. Loading later is not the same as loading less. If both stages run in one graph, the peak is still two models if the framework hasn't freed the first one - the ordering just gives it a chance to, and stops the load from happening concurrently.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Restart ComfyUI fully, then refresh the page - this pack's nodes need a recent core and won't appear at all on an old frontend. Manager search term: MiniMax H3 Audio T8. No Python dependencies are installed by the pack (empty requirements file, by design), so the install can't break ComfyUI's Torch/CUDA stack.

Your H3 model files go in models/diffusion_models. The unet_name dropdown lists exactly what's there, so a missing model shows up as an empty list rather than a mystery error later.

Gotchas

If you hand it a stage result that came from a frozen load of a different stage than expected, it fails rather than loading anyway - which is the point of passing a typed receipt instead of a boolean. If your two-stage graph still OOMs at the transition, the fix isn't a smaller batch; it's lowering canvas or frame count, and making sure only one H3 job is queued at a time. The pack's own notes on 16 GB cards are unambiguous: one generation at a time, and if you can't, run the stages as separate jobs with a save/load between them.