Swan Load H3 Latent Upscaler Model

MiniMax H3 is a 33B omni-modal video model that generates picture and audio together, and like every video model worth running, you don't render your final resolution in the first pass. The standard production pipeline is generate small, then go up - Wan users have been doing it at 480p since forever, because a second pass at higher resolution is cheaper than a first pass there.

The catch with H3 is that "go up" can mean lifting the latent, without a decode round trip. That's what a learned latent upscaler is, and it's a separate checkpoint you have to download and load. This node is the loader for it. Boring job, genuinely annoying if you skip it, because nothing downstream will work without the handle it returns.

What it actually hands you

Not a MODEL. Not a VAE. It returns learned_upscaler, typed H3_LATENT_UPSCALER - a provider object that carries the loaded network, the device and the precision, and exposes one method for lifting a clean video latent to an exact target grid. Two things in this ecosystem know how to consume that type:

• the upscaler input on Swan H3 Transition Lift (same pack), and
• the learned_upscaler input on MiniMax-H3-Flow-Aligned-Regenerate (xmarre), which is where the H3_LATENT_UPSCALER contract comes from (api_version = 1, kind minimax_h3_learned_latent_upscaler).

So if you were hoping to feed a stock Upscale Model Loader output somewhere or plug this handle into a random upscale node, no. It's a handshake between packs, not a general-purpose model.

How it works

The network is a LatentResizer3D - a 3D-conv resizer ported from LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler and vendored into this pack so there's no runtime dependency on that repo. On load it reads the state dict, infers the architecture from the weights themselves (channel count off conv_in.weight, block counts off the block names, temporal kernel off the depthwise conv), then loads strict=True. Architecture sniffing means an H3 upscaler of a different size still loads; it also means a non-H3 checkpoint gets caught before it wastes your time.

At inference it normalizes the 24-channel H3 latent with H3's own per-channel mean/std, builds a scale embedding from the average of your width and height ratios, and lets the network trilinearly interpolate to the exact target size internally - chunked along time with overlapping segments blended, so a long clip doesn't explode VRAM. Loaded models are cached per name::device::precision, so a second Transition Lift node in the same graph reuses the same weights instead of loading twice.

The settings that matter

model_name is a dropdown of whatever sits in models/latent_upscale_models (.pth and .safetensors; files with "h3" in the name are sorted to the top). If it shows (place checkpoints in models/latent_upscale_models), the folder is empty or ComfyUI hasn't rescanned.

precision defaults to fp16 and you should leave it there - bf16 is an option for a card that prefers it, fp32 mainly exists for debugging. device is cuda or cpu, and the node quietly falls back to cpu if CUDA isn't available, which will work and be slow. offload_after_upscale pushes the cached model back to CPU after every lift; leave it off unless you're tight on VRAM, since it re-uploads on the next lift.

Install

Grab it from ComfyUI Manager - search Swan_Bits (registry display name ComfyUI_Swan_Bits) - or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/swan7-py/ComfyUI_Swan_Bits
# restart ComfyUI

There's no requirements.txt in this pack, and that's accurate rather than sloppy: the only imports are torch, einops and ComfyUI itself, and einops ships with ComfyUI. Nothing to pip install, no build step.

You do need the weights, and this is the part the README leaves thin. Drop the H3 latent-upscaler checkpoint into ComfyUI/models/latent_upscale_models/, create the folder if it isn't there, and restart so ComfyUI rescans:

mkdir -p ComfyUI/models/latent_upscale_models

Where people get burned

That folder often doesn't exist. ComfyUI does not reliably auto-create latent_upscale_models, and the community has been tripping over it since LTX-2.3 shipped latent upscalers into the same path - the fix in that thread was exactly the mkdir above plus a restart. If your download fails with a weird path error, that's usually why.

That folder is shared with LTX. LTX-2.3 latent upscalers live in latent_upscale_models too, so the dropdown will happily list them - you get a clear error about missing conv_in.* weights rather than garbage output, but it's a five-second confusion if you don't know the folder is shared.

Finally, on the licence: the pyproject points at a LICENSE file that isn't actually in the repo, so treat the README's "free to use" as the grant. It also says nothing about the H3 weights themselves, which are covered by MiniMax's own territory-restricted community licence.