MiniMax H3 Generation V2 (Acceleration + Clean Decode)

The Render Backend is the training-wheels sampler. The Generation Backend V2 is the one the Shotboard actually uses in production. It's the same core sampling loop - sigma shift, custom sampler, video + audio decode - but wrapped in the H3 workflow's full memory contract: optional Turbo LoRA, acceleration patches, VRAM cleanup before the decode, and motion-context trimming when continuity is active.

How it works

The V2 reads its sampling contract from the Shotboard plan itself - the sampling block in the plan JSON owns seed, steps, sampler, scheduler, denoise, and both shifts. The widgets on the node are kept only as a legacy fallback so older workflow JSONs still run. That's a deliberate design decision in this pack: the Settings node is the execution truth, the node widgets are a compatibility shim. Change a value on the node and it may be ignored if the plan disagrees.

When the plan enables Turbo (the MiniMax H3 Turbo route), the node applies the Turbo LoRA to the model, warns if the LoRA file isn't found, and checks that your step count is sane for the turbo profile - it'll log a warning if you're running 4 steps when the profile expects 6–8. Then it applies acceleration (_accelerate - the Adaptive Cache / Spectrum-style path the plan requests) and sigma shift.

The "clean decode" in the display name is literal: before decoding video and audio, it drops the noise, guider, sampler, and sigmas, runs _clean_vram_before_decode(), and only then calls VAEDecode and VAEDecodeAudio. On a 12GB card that frees enough VRAM to make the difference between decoding and OOMing.

Inputs

The required set mirrors the Render Backend - model, positive, latent, video_vae, audio_vae, chunk_index, seed/steps/sampler/scheduler/denoise/shifts - plus cine_linx so it can read the plan, and an optional motion_state (an IAMCCS_H3_MOTION_CONTEXT) for the native AV continuity path. When native_av_context motion is active, the node trims the pinned context frames from the decoded output and hands you exactly the export window.

Outputs

native_frames and native_audio are the decoded segment, ready for the Face Detailer router or a checkpoint save. bridge_last_frame is the final frame of this render, saved so the next segment can use it as its opening - that's the "last-frame bridge" the whole continuity story depends on. sampled_latent keeps the raw latents, and native_fps + report tell downstream nodes the frame rate and what the backend actually did.

Installing it

Part of IAMCCS-nodes - ComfyUI Manager (search "IAMCCS") or git clone https://github.com/IAMCCS/IAMCCS-nodes.git into custom_nodes. The Turbo route additionally needs the ComfyUI-MiniMax-H3-Turbo pack (by Larryvrh) and its Turbo LoRA; acceleration options like Adaptive Cache come from their own packs. On a cold run, the README says to look for log lines in this order: conditioning complete, pre-sampler barrier, then Requested to load MiniMaxH3. If you see the sampler kick in before those, a dependency isn't doing its job.

Gotchas

The biggest trap is the step-count one - Turbo profiles silently won't override your authored steps, they just warn. So if you crank the plan to 8 steps but left the old 20 in a legacy widget, you'll get a warning and the authored value wins. And because the plan owns the contract, changing the visible widgets and expecting the V2 to obey is a recipe for "why is it still using the old seed?" - change the Settings node, not the backend.