MiniMax-H3 TRT Compiler

If you've got a MiniMax-H3 workflow running, you already know the VAE can be the slow part - the transformer gets all the attention and then everything grinds to a halt during encode/decode. This node is the fix: it takes the ONNX export of the H3 VAE and compiles it into a TensorRT engine, the format that lets your NVIDIA GPU run the graphs at near-native speed. The pack claims up to about 1.7x on encode/decode, which for long video clips is the difference between a bathroom break and a coffee run. Same author who built the beloved ComfyUI-FlashVSR_Ultra_Fast video upscaler, so the performance-first design is a theme.

It's an output node with no outputs - you don't wire it into anything. You run it once, it writes .engine files to disk, and then you load those with the MiniMax-H3 TRT VAE Loader forever after. A compile job is a one-time cost; you only redo it when you switch machines, change TensorRT versions, or delete the engines.

How it actually works

Under the hood it's a standard TensorRT build, with a few choices baked in by the author:

• It parses the ONNX with trt.OnnxParser.parse_from_file - deliberately, because the decoder is big enough that its weights live in a separate .onnx.data file, and parse-from-file is what reads that correctly.
• FP16 is enabled when your TensorRT build supports it (which it will, on any modern NVIDIA GPU).
• It allocates a 4GB workspace for the decoder and 8GB for the encoder while building.
• Engines get fixed input shapes: the decoder takes a latent_tile of (1, 24, 7, 16, 16) and the encoder a pixel_tile of (1, 3, 17, 256, 256). Fixed shapes sound restrictive, but the loader handles arbitrary video sizes by tiling internally - you don't have to match these yourself.
• Output lands next to the source ONNX as a same-named .engine file.

It also clears VRAM before it starts building, because TensorRT compile is memory-hungry and the pack author has clearly been burned by OOM crashes mid-build.

The inputs that matter

Only three, all on the required list:

• decoder_onnx and encoder_onnx - dropdowns that list every .onnx in your models/vae folder. Pick the H3 decoder and encoder.
• delete_onnx_after_compile - a boolean, default off. Ticking it deletes the source ONNX from disk after a successful compile, which reclaims roughly 5GB (the decoder is huge). Handy if you're space-poor, but it means recompiling later means re-downloading the models. I'd leave it off until you're sure the engines work.

It's in the MiniMax_H3/Acceleration category, along with the two loaders, so it's easy to find.

Setting up the first compile

The install is the pack-standard one - ComfyUI Manager (search ComfyUI-H3VAE_TRT) or:

cd ComfyUI/custom_nodes
git clone https://github.com/lihaoyun6/ComfyUI-H3VAE_TRT
python -m pip install -r ComfyUI-H3VAE_TRT/requirements.txt

That requirements file is exactly one line: tensorrt. It's NVIDIA-only, so an AMD or Intel GPU (or Apple Silicon) means this node - and the whole TRT path - is off the table; the direct-ONNX loader is your fallback there. Download all three files from lihaoyun6/MiniMax-H3-VAE-ONNX into ComfyUI/models/vae, then run the node.

Where people get burned

• Missing .onnx.data. The decoder won't parse if the external weights file isn't right next to the .onnx. HF lists them as separate downloads - get all three.
• "TensorRT library not found!" means the tensorrt pip package isn't importable in ComfyUI's Python environment. Reinstall it, and make sure you're not running the pack under a different Python than your pip install used.
• VRAM spikes during build. The 4GB/8GB workspaces stack on top of whatever else you have loaded. Close other workflows; the node tries to free memory first, but a clean slate is safer.
• After it finishes, it tells you to press R to refresh the model list - do that, or the TRT loader's dropdown won't show the new .engine files.