Mpi Tiny Vae Loader

When you're generating video, ComfyUI shows you a live preview of the in-progress latent - and for most models that preview is decoded by a tiny autoencoder (a TAE or TAEHV), a mini VAE that's cheap enough to run every sampler step. It's not the real VAE; it's a fast approximation just for previews. The catch: ComfyUI's own VAELoader can only build certain TAE architectures, and MiniMax H3's taeh3 isn't one of them. It raises a state-dict size mismatch and refuses to load. MpiTinyVaeLoader exists to load the one core can't.

The technical detail is worth knowing because it explains the error you'll hit. Core picks a TAE's decoder width from the latent channel count, and only has a code path for specific shapes. H3's taeh3 is a 24-channel latent with a 12-wide decoder - core builds it 3 wide instead and dies on size mismatch for decoder.22.bias: [12] vs [3]. This node rebuilds the two edge convolutions at the correct width, does a strict state-dict load that matches all 128 tensors exactly, and corrects the spatial ratios and latent scaling core's fallback branch got wrong (taeh3 is 16× spatial and needs no rescaling). Anything core can already handle is passed straight through to VAELoader's own code path - so it's a safe drop-in for any tiny decoder, H3 or not.

What you feed it and what it feeds

• vae_name - a dropdown of tiny decoders in models/vae. For MiniMax H3, that's taeh3.
• Output: vae - the tiny decoder, wired into MpiVideoSamplingPreview, which does the actual in-progress decode for the sampler.

Install

Part of ComfyUi-MpiNodes. ComfyUI Manager (search "MpiNodes" / publisher "mad-pony-interactive"), or:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

Restart. Then put the taeh3 weights file in ComfyUI/models/vae/. No other dependencies - but note this node only makes sense if you're doing MiniMax H3 video, because for SD/SDXL/Flux the core loader already handles their tiny decoders fine.

The real-world situation

If you're on H3 and your sampling previews come out as blocky colour blobs, that's this problem wearing its other face: core silently falls back to a Latent2RGB approximation when it can't build the tiny decoder - previews still appear, they're just useless for judging the frame. That silent fallback is exactly why the author built this loader: wire taeh3 through it into MpiVideoSamplingPreview and the previews decode properly. You don't need it for anything else, and it won't hurt if you feed it a decoder core handles - it just passes through. It's a narrow, boring fix for a specific, maddening bug.