MiniMax H3 TRT VAE 编码＋解码 (T8 EXP)

Same loader as the decoder node, plus two more engine sockets so that reference image and reference video encoding also run on TensorRT. The pack's own line on it is refreshingly direct: decoder-only is the recommendation, full encoding differences can affect what the sampler produces, and single-image encoding showed no speed benefit on the reference machine. It exists because you might want it, not because you should.

So read the rest of this as a map of when the full path is defensible, and what to check if you go anyway.

The additional inputs

Beyond native_video_vae, decoder_engine, runtime_directory and cpu_output_budget_mib - all identical to the decoder-only node - you get two more:

• image_encoder_engine - a T1 engine, the single-frame path. The tooltip's point is that this does not silently pad your single reference image into a 17-frame clip: it's a separate export of the genuine single-frame encode, which is why you need a separately prepared T1 ONNX graph.
• video_encoder_engine - the T17 video encoder, which chunks internally so you don't have to slice reference video yourself.

Outputs are video_vae and report_json, same as the decode-only node: it's a drop-in replacement for the video VAE socket, with audio VAE left alone.

The honest case against it

Encoding feeds the sampler. A decode you'd argue about pixel by pixel; an encode you've wrapped in a different execution backend is upstream of every step that follows. If your conditioning shifts even slightly, you get a different video and a seed comparison that no longer means anything.

That's not theoretical hand-waving, it's the pack's own framing: encoding differences may affect subsequent sampling, and the quantised options show how large those differences can get. On a real 0.5MP / 73-frame decode, the W4A16 decoder measured about 45.32 dB PSNR against native, whereas the FP16 engine sat around 61 dB. Forty-five dB is generally fine to look at and it did pass review on the author's clips - but it's a different picture, not a free lunch.

Combine that with no measured benefit for single-image encoding, and the sensible conclusion is plain: use the decoder-only node unless you have a specific long-reference-video encode workload that you've timed yourself.

Install

Manager → search MiniMax H3 Audio T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Restart fully. Prerequisites, in order, all serial and none of it automatic:

<ComfyUI-Python> -m pip install --target <ComfyUI>/models/vae/h3_trt/runtime/site-packages tensorrt-cu13==10.13.3.9.post1

Then the decoder ONNX + .onnx.data under models/vae/h3_trt/, a flex graph generated locally by the bundled CPU tool, and - new for this node - the T1 graph exported from your native weights with trt_vae_prepare_t1.py --execute, which uses the GPU briefly. That export verifies itself against the previously validated T1 graph hash and refuses to overwrite a different existing file, which is the right kind of stubbornness: a mismatched graph produces subtly wrong conditioning rather than an error.

Check with the installation node, then compile decoder-flex, encoder-t1 and encoder one at a time - each build wants 12GB free VRAM, 24GB RAM and 20GB disk, and one at a time means exactly that.

Traps

Refresh ComfyUI's model lists after compiling, or the new engine folders won't appear in the dropdowns. If you move the runtime directory or change the driver, rebuild - engines are bound to those identities and the node won't self-heal at generate time.

And keep your normal native-VAE workflow saved somewhere. This is an experimental node in an experimental feature; when the encode path misbehaves, the fast diagnosis is to swap back to the native video VAE and see whether the oddity follows the engine or your prompt.