MiniMax H3 Progressive Sampler (staged)

MiniMax H3 is the good kind of open-weight video model and the bad kind to run: 33B, native stereo audio, and a video latent whose token count scales with latent_t * (h // 2) * (w // 2). Double the spatial resolution and you're paying roughly four times the tokens, sixteen times the attention. This node exploits something cheaper: early flow-matching steps only settle coarse structure, so they don't need full token density. Run the first chunk of the schedule on a smaller latent grid, upscale the x0 estimate at the stage boundary, finish at the target resolution. The honest number is ~1.6–2x faster if 55% of steps run at half scale - not the 4x the math whispers, and the README says so. That honesty is the whole reason to trust it.

It comes from the ComfyUI-Hillobar pack, a single-node pack by a new author, and it's a drop-in replacement for the sampler stage in a native H3 workflow. Feed it a latent already at final resolution; it shrinks internally, which keeps the VRAM estimate an over-reservation instead of an under-reservation. Each stage is its own guider.sample() call - conds, the packed AV layout, latent_shapes and the VRAM reservation are rebuilt per stage, and no ComfyUI internals get mutated. Between stages it pulls the x0 estimate out of the sampler's callback and upscales it with your chosen method to seed the next stage; the audio stream rides through, its carry scale undone and re-applied so nothing drifts. The memory planner is pinned to the final packed shape, so a partially-resident model's partial-load split is computed once and left alone instead of re-partitioning at every boundary.

The inputs that matter - there are only seven, and most of them are the boring plumbing you'd feed KSampler anyway:

• guider, sampler, sigmas, latent_image, noise_seed - identical roles to any ComfyUI sampling chain. noise_seed is the base; each stage gets seed + stage_index, so stages aren't seeded identically.
• schedule - the one that matters. Comma-separated scale:end_percent stages, default 0.5:0.55, 1.0:1.0: 55% of steps at half the spatial latent grid, then full size. It must end with 1.0:1.0, and stages may never shrink the grid mid-run (that would throw away detail you've already resolved). Use 1.0:1.0 alone as an A/B baseline to measure what you're actually saving.
• upscale_method - how the x0 is stretched between stages. bicubic is the default and fine; bislerp if you're a latent-space native.
• verbose - logs per-stage grid size, token count and elapsed seconds. Leave it on; it's the only way to see whether your schedule actually paid for itself.

The outputs - output (the finished latent) and denoised_output (the last x0 estimate, when the sampler reports one). Wire output into the same decode you'd use for a plain H3 sample; denoised_output is a bonus that can be cleaner for some downstream passes.

Supported conditioning: text-to-video (t2va) and reference-to-video (ref2va), because reference blocks carry their own latent_h/latent_w and stay self-consistent when the target grid changes. Keyframe (fl2va) conditioning and noise masks are not supported - both raise a clear error rather than producing a silently wrong video.

Install

ComfyUI Manager, search ComfyUI-Hillobar, or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/Hillobar/ComfyUI-Hillobar
# restart ComfyUI

There are no extra dependencies - nothing beyond what ComfyUI already installs, and the code relies on comfy.nested_tensor, the H3 model base and the AV-latent nodes, all in a current ComfyUI. The H3 weights themselves (a ~42.5GB download from HuggingFace) are the real requirement, and they carry the MiniMax H3 Community License, which excludes the US, EU, UK and South Korea from its Applicable Territory. If you're in one of those regions you're not licensed to run the local weights at all, and this node is pointless without them.

Where people get burned

• The sampler must report denoised in its callback, or there's no x0 to upscale and the node raises at the first boundary. If you see that RuntimeError, switch samplers - the stock H3 ones report it.
• You need at least as many steps as stages. A 2-step sampling run on the default 2-stage schedule fails with a clear error.
• Expect ~1.6–2x, not more. The win is bounded by how much of the schedule runs small. Measure with verbose on before you trust any claimed speed-up.
• It only accepts H3 models, and it checks, loudly. Don't wire it into a Wan or LTX graph.

As a brand-new pack this hasn't accumulated community war stories yet, but the failure modes above are all guarded in code, which is more than most samplers offer. If you run H3 locally and your renders feel like they're melting your GPU, this is the cheapest free lunch on the menu.