H3 SPEED · Sample ONE Stage (T8 EXP)

MiniMaxH3SPEEDStageSampleEXPT8 does one thing: it calls the native H3 guider's sample once, for one stage's sigmas, with the model, conditioning, sampler and noise you wired in from outside. No loop over stages. No second pass. No retry, no cache lookup.

If that sounds like a node that shouldn't need to exist - Core's SamplerCustomAdvanced does the same job - the reason it does exist is the third output. stage_result is a typed receipt of what actually executed, and the SPEED handoff won't accept anything less.

Inputs

All seven are required, and four of them are just Core's sampler inputs renamed by function:

• model - this stage's model. In SPEED splits, each stage can have its own branch and LoRA chain.
• positive - conditioning from this stage's MiniMaxH3SPEEDStageSetupEXPT8 (or from MiniMaxH3SPEEDRelayApplyEXPT8 if you're relaying).
• av_latent - the stage's AV canvas from Stage Setup.
• sampler, sigmas - also from Stage Setup.
• noise - for stage 0 this is your normal noise provider; for later stages it's the NOISE from MiniMaxH3SPEEDDCTTransitionEXPT8. This is the wiring people get wrong.
• stage_spec - the same stage's T8_SPEED_STAGE_SPEC. The sampler validates it against the model and settings rather than trusting the wire.

Outputs: av_latent, stage_result, report_json. The latent goes on to the next DCT transition, the stage result goes to MiniMaxH3SPEEDStageSaveEXPT8 (or straight into the transition if you don't need to freeze it), and the report is your evidence that the call happened with the sigmas you meant.

The subtle bit: this is not x0

The description is unusually precise about it - the output is "the public-flow state used by DCT Transition, not a decoded x0". On a flow-matching model the sampler's terminal state and the model's predicted clean latent are different objects, and DCT expansion has to operate on the former. That's why you can't substitute a Core sampler here and expect the pack's stage result contracts to accept it, and why the receipt explicitly separates the two: stage_result keeps x_sigma and denoised_output distinct, and a stage saved with denoised_output picked by mistake will be rejected as a resume source for a transition.

Also note what "a live result is not portable persistent cache proof" means in practice. A stage that just ran in this process is fine to feed forward. If you want to reuse it tomorrow, save it - that's MiniMaxH3SPEEDStageSaveEXPT8 - because a MODEL or effect stack the pack can't authenticate won't be silently claimed as restorable.

Install

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

Exit ComfyUI properly and restart, then hard-refresh the tab. Manager search: MiniMax H3 Audio T8. There is no pip step; the pack's requirements.txt is empty by design (Torch et al. come from ComfyUI). A recent core is required - these nodes sit on the newer node API and native H3 support, so an older core means red nodes, not a warning.

Gotchas

A stage sampler with everything wired but a mismatched stage_spec fails rather than sampling. A stage sampler with noise from a plain noise node on stage 1+ will run, but it's not the SPEED transition you asked for - the picture will tell you. And if you're comparing against the whole-chain SPEED runner, expect small differences: the split route's numerical reference is the old node, but the pack never claims bit-identity for effects and LoRAs it can't authenticate. Read the report_json when something looks off - it's a report, not a log.