MiniMax H3 实时预览 - Star7

MiniMax H3 is a 33B omni-modal video model that makes genuinely good clips with native audio - and it is slow locally. On the pack author's own RTX 2080 Ti benchmark, a single sampling step of a 1.0MP / 10-second clip takes anywhere from 60 to 190 seconds depending on the attention backend you pick. That's a five-to-fifteen-minute queue where the only feedback is a progress bar, and if the framing is wrong or the motion is garbage you find out at the very end. That's the problem MiniMaxH3LivePreviewStar7 exists to kill.

It comes bundled in the star7code/minimax-h3-chunk-star7 pack, which is mostly about activation chunking and attention backends for running H3 on limited VRAM. This node is the quality-of-life half: a MODEL pass-through that shows you a looping, low-res preview of the whole timeline after each sampling step, rendered from the actual latent mid-sampling rather than a final-frame-only peek. If you've used TAESD or the "preview during sampling" trick on SDXL, it's that same idea, upgraded for video.

How it works

The node takes a MODEL in and hands the same MODEL back out - the model output of your loader chain goes in, and the model output you wire into the Guider comes out. Under the hood it clones the model and attaches a wrapper to ComfyUI's OUTER_SAMPLE patcher hook, so every sampling step gets a callback. In that callback it:

1. grabs the current latent x0,
2. pulls preview_frames evenly-spaced frames across the time axis (not the first N - evenly spread, so you see the full arc of motion),
3. downscales the latent to your chosen preview resolution before decoding, which is what keeps it cheap,
4. decodes through TAEH3 - a tiny 24-channel video autoencoder, ~22MB, totally separate from the real H3-VAE - and
5. encodes the result as an animated WEBP and ships it over ComfyUI's websocket to the node's own in-canvas preview panel.

The decode and encode run on a background thread so they don't stall sampling, and only the latest frame set is kept - no queue buildup on long renders. Clever bit: the preview read only touches a clone of the latent, so the sampler-owned tensor is never disturbed.

The inputs that matter

Three of them, and they're all straightforward:

• preview_frames (default 25, range 4–64) - how many frames are pulled across the timeline for the loop. 25 at 6fps-ish is a decent loop; drop it if previews feel slow.
• preview_resolution (256 / 384 / 512, default 512) - the longest edge of the preview. 512 is a good default; go 256 on a cramped card.
• first_step_only (default off) - decode once at Step 1 and skip the rest. The one genuine trap here: leave it off while you're still tuning, because the first step is the noisiest and least representative frame of what you're about to get. Once the workflow is dialed in, flip it on to reclaim the VRAM and cycles for the actual render.

One quirk worth knowing: the backend silently resets preview_frames to 25 if it ever receives a value under 4, a guard against older frontend builds that briefly serialize a fresh INT widget as zero. So don't panic if a 3 somehow snaps back to 25.

Wiring it in

Straight line from the pack README:

UNET Loader -> LoRA -> Activation Chunk - Star7 -> Live Preview - Star7 -> Guider -> Sampler
                                                        `-> Scheduler --------------> Sampler

Only the model path goes through the preview node; the Scheduler keeps feeding the Sampler directly. Order matters: the preview node sits after the chunk node, so it previews the patched model you're actually going to sample with.

Install and the one gotcha

ComfyUI Manager, search "MiniMax H3 Activation Chunk - Star7", or:

cd ComfyUI/custom_nodes
git clone https://github.com/star7code/minimax-h3-chunk-star7.git

Then restart ComfyUI. Good news: the pack declares zero pip dependencies, so there's no requirement-file roulette. The only thing this node wants is taeh3.safetensors in models/vae_approx, and it downloads that itself in the background from madebyollin/taehv, SHA-256 verified. That's also the gotcha: on your first run the preview panel will sit on "waiting for sampling" while the download quietly finishes in the background - by design it never blocks sampling. The README's promise is that previews start at the next sampling step after the download completes, and if the download only lands at the very last step, you get one catch-up preview. Practical advice: run the workflow once, let it finish, then run again - the second run previews from Step 1.

Common issues

The most common "problem" is really the first-run download above - it's not broken, it's patient. If the download outright fails, only the preview is disabled; the generation keeps going, which is the right failure mode. The preview is deliberately approximate - TAEH3 is a toy decoder next to the real VAE - so judge composition, motion, and pacing on it, not fine detail or final color. And it's H3-specific: it expects a 24-channel video latent (or the H3 audio+video nested tensor), so drop it in front of a Wan or LTX graph and it disables itself with an error rather than crashing the render.