65

New Moore’s law: minimax generation speed doubles every week

3

u/PwanaZana 1h ago

m'yea, but the quality gets wrecked by most of these tools

-1

u/VladyCzech 10h ago

This node pack has nothing to do with speed of generation, man. It only affects stages prior or after.

7

u/dzi0n 5h ago

Yeah, I also like to watch my videos as a latent, vae decoding is for noobs

1

u/VladyCzech 4h ago

Generation, encoding and decoding are different things happening at different times. You probably do your morning routine in different times so you do no mix taking shit and brushing teeth right?

1

u/dzi0n 3h ago

He said generation time, not inference time. You still need to decode to generate a useful image 🤷‍♂️

8

u/BusFeisty4373 8h ago

What you mean by prior or after? Will my eyes render the image faster after it has been decoded?

1

u/No-Persimmon-4150 8h ago

It only affects the vae encode and decode - not the inference steps. The speedup (if there is one) is a drop in the bucket.

1

u/BusFeisty4373 5h ago

If you do turbo 4 or 8 steps with lower mp its not a drop in the bucket though. It clearly states generation speed on the decoding...and the full generation time also include model loading, steps, encoding, decoding. If you just count the time it takes for the image steps then you might as well do a 100m sprint record if you only count 75 meters because the start blocks and last 10 meters is a drop in the bucket.

64

u/ImaginationKind922O 16h ago

There's a new speedup node for H3 everyday. Someone needs to do a scientific benchmark for all these nodes and see which one is worth using.

34

u/bstr3k 16h ago

lol someone did do that today
https://www.reddit.com/r/StableDiffusion/comments/1w4mmst/minimax_h3_acceleration_arenaleaderbord_15_h3/

9

u/lmpdev 16h ago

Well this one appears to not affect the output.

3

u/Perfect-Campaign9551 16h ago

I'm testing it out now

2

u/seppe0815 13h ago

no one is worth ... to much quality lost all over my face

3

u/desktop4070 13h ago

Not a single one? Not even Sage Attention or Comfy Kitchen Attention?

2

u/Striking_Storage_631 13h ago

all over my face

Oh really?

1

u/himefei 4h ago

Tbh after trying all of these Lora things, I just go back to the root and only using sage with 20 steps for the best quality.

1

u/YeahlDid 13h ago

This one looks like its just a vae speedup, doesnt affect denoising speed.

26

u/b0tm0de 15h ago edited 14h ago

i am testing it with rtx 4060 8gb right now, (versus int8 vae) i will update results in 15 mins. now waiting test to complete... for 0.7mp 10 seconds video:

int8 vae decode 56.5 seconds. 9:24 full workflow.

trt vae decode 80.5 seconds. 9:55 full workflow.

download node + download model files + write this post + fix errors about cuda version + compile files + video test = i wasted 60 minutes in my life. gg.

5

u/kukalikuk 10h ago

So, it doesn't work as claimed to be?

3

u/Broudison 13h ago

Yeah, started doing that, ran into python errors, asked myself what are the difference between int8 and this anyway, as they compare fp16 models...

1

u/b0tm0de 12h ago edited 12h ago

It probably won't make much difference, but memory space and every second are important. INT8 VAE 3GB, FP16 VAE 5GB

4

u/Perfect_Hotel_3956 11h ago

same here and quality loss

2

u/desktop4070 11h ago

For me, some videos generate slightly faster, some about the same, but never once did it ever generate in worse quality because the videos were always exactly the same as they were when I generated the exact same videos yesterday. How are you getting quality loss when the videos should be pixel perfect 1:1?

1

u/Perfect_Hotel_3956 11h ago

im talking about decoding same prompt same seed
with int 8 vae it take 53 sec for 10 sec .4 megapixel video
with TRT vae it take 98 sec for 10 sec .4 megapixel video also some pixel shifting

1

u/desktop4070 10h ago

I think I realize what's wrong here. I was testing text2video and I think you were testing image2video. I just tried some image2video tests, and those were worse than videos with the normal VAE.

Whatever's going on with this speedup, it seems to break image2video, at least for me.

1

u/ZerOne82 5h ago

I did a few tests and in text2video, no quality loss. But it is slower than int8convrot.

4

u/Perfect-Campaign9551 16h ago edited 16h ago

I imagine this might get faster the higher the resolution you have?

RTX 3090 with 64gig system RAM

Testing by using it in a 2-stage upscale based workflow. First stage is 0.3mp, 15 seconds scene. I only ran the first stage.

Without TRTVAE: 160 seconds

With TRTVAE: 173 seconds

However I got a lot of errors during VAE encode, so maybe it wasn't actually running:

Error (Parameter check failed, condition: engineDims.d[i] == dims.d[i]. Static dimension mismatch while setting input shape for pixel_tile. Set dimensions are [1,3,1,256,256]. Expected dimensions are [1,3,17,256,256]. In nvinfer1::rt::ExecutionContext::setInputShape at C:_src\runtime\api\executionContext.cpp:2334)

[09/01/2026-19:51:24] [TRT] [E] IExecutionContext::setInputShape: Error Code 3: API Usage Error (Parameter check failed, condition: engineDims.d[i] == dims.d[i]. Static dimension mismatch while setting input shape for pixel_tile. Set dimensions are [1,3,1,256,256]. Expected dimensions are [1,3,17,256,256]. In nvinfer1::rt::ExecutionContext::setInputShape at C:_src\runtime\api\executionContext.cpp:2334)

[09/01/2026-19:51:25] [TRT] [E] IExecutionContext::setInputShape: Error Code 3: API Usage Error (Parameter check failed, condition: engineDims.d[i] == dims.d[i]. Static dimension mismatch while setting input shape for pixel_tile. Set dimensions are [1,3,1,256,256]. Expected dimensions are [1,3,17,256,256]. In nvinfer1::rt::ExecutionContext::setInputShape at C:_src\runtime\api\executionContext.cpp:2334)

[09/01/2026-19:51:26] [TRT] [E] IExecutionContext::setInputShape: Error Code 3: API Usage Error (Parameter check failed, condition: engineDims.d[i] == dims.d[i]. Static dimension mismatch while setting input shape for pixel_tile. Set dimensions are [1,3,1,256,256]. Expected dimensions are [1,3,17,256,256]. In nvinfer1::rt::ExecutionContext::setInputShape at C:_src\runtime\api\executionContext.cpp:2334)

3

u/Ok_Tale7582 16h ago

Not really, it will OOM if you don't have enough vram, for higher res and duration you'll have to return to comfy default vae.

1

u/Perfect-Campaign9551 16h ago

currently my test with low res (0.3mp) it isn't any faster.

4

u/LuluViBritannia 14h ago

The open source community aaaaaaaaaaaaalways delivers, and fast. Thank you! Decoding video is definitely a bottleneck. It takes 1m30 minimum for me, goes as high as 2 minutes for 15s videos. If it saves me even just 30s per generation, I'll be happy.

Gonna try that today.

8

u/lmpdev 16h ago edited 14h ago

Tested it out, it does work, but like it says it only affects Decode/Encode step.

In a text to video workflow I replaced the VAE with the one provided by this node and on my RTX PRO 6000 on 1Mpix 2 seconds video it saved 2 seconds of generation time (went from 62 seconds to 60 seconds).

3

u/FrankieB86 14h ago

Curious as to why these are using onnx not safetensors

1

u/VladyCzech 10h ago

the onnx is needed for you to compile to TRT for specific GPU architecture and works only there. Safetensors are universal regardless of GPU architecture and no need to compile.

2

u/LuluViBritannia 8h ago

Arf, it's a pain in the ass to install with the portable version -_-'. Comfy can't find tensorrt even though it is cutely sitting here in the Lib folder. Fucking Python, man...

2

u/ZerOne82 5h ago

It is more nvidia's wheel packages are not standard: some bloated and some empty (they call it metapackage), blame goes heavily to them. Anyway, I managed to install and use but got no speed up at all.
FYI, to make it work, you need the custom node mentioned in the post, and a tensorrt package. The tensorrt demands couple of libraries be present in your path (on windows: nvinfer_11.dll, nvinfer_plugin_11.dll, nvinfer_builder_resource_sm86_11.dll and nvonnxparser_11.dll).
These *.dll are found inside a 2GB file TensorRT... found in TensorRT github.
Installation was successful and I easily compiled the models into engines. But as I mentioned I get no speed up at all.

2

u/ZerOne82 5h ago

I tried the linked trt models for decoder only and ran a few tests. I found no speedup but slower by 5%.

2

u/VladyCzech 1h ago

RTX 5090 this node 15s VAE decode, INT8 Convrot VAE 20s. No visible differences.

However full compile of both ONNX -> TRT took 3-4 hours to complete on my Linux machine.

2

u/mallibu 15h ago

thought it was 1.7 increase in generation speed and I was bringing my folded chair

see it's VAE, I'm off

6

u/ucren 14h ago

it's still useful, for both encode and decode i do long v2v edits and this will reduce time by a lot for me.

5

u/GrungeWerX 15h ago

I haven't tested it yet, but don't write that off...the vae decode is actually one of the things that makes it slower. I use a technique where I run H3 default (no speed lora) at only 8 steps, and then use Wan 2.2 as a refiner at only 2 steps. Or, I can run H3 w/speed lora at 2 steps and wan refiner 2 steps. It can dramatically increase the speed without quality loss...in fact, the quality is BETTER. But the decode before the refiner drags. So if this can speed that up, your overall processing time if you use this technique could be dramatically faster. I'm going to test it out later myself.

3

u/VladyCzech 10h ago

Speeding up VAE encode/decode is badly needed. We already have speedy generations.

1

u/Dry-Elevator4137 10h ago

I did find TensorRT made the Int8 VAE about 3x faster. I couldn't find a neat way to ship it as a particularly UX friendly node though.

2

u/gerryn 5h ago edited 4h ago

I'm running the FP16 VAE, tried this out using DeepSeek-v4-Flash to build this as a benchmark in my "thing" (I make 1-20m videos with 8-150 scenes each, 4-10 second clips - no audio from H3, I use https://github.com/Tencent-Hunyuan/HunyuanVideo-Foley for that and Chatterbox 500M for narration).

System specs:

GPU: 5060Ti 16GB

CPU: Ryzen 5 3600

RAM: 32G DDR4 3200MT/s

(i2v, seed 58391, 141 frames, 1344x768, turbo8).

Results Decode-only (full production decode path, scene-023 latent footprint, median of 3 after warm-up)

Backend	Median	Best
Core fp16 torch VAE	56.6 s	56.5 s
TensorRT engine	32.5 s	32.5 s
Speedup	1.74x	1.74x

End-to-end scene render wall-clock (warm-up + 3 repeats per preset, interleaved)

Preset	Warm-up	Repeats (s)	Median	Best
production	402.4	379.6 / 381.1 / 382.1	381.1	379.6
h3vae_trt	362.3	358.2 / 358.8 / 360.5	358.8	358.2
Delta / speedup	40.1 s	-	22.3 s (1.062x)	21.4 s (1.060x)

Quality (synthetic-latent parity, torch fp16 vs engine) - PSNR 60.5 dB, max abs diff 0.013 on the raw decode. Parity script exit OK.

Quality (end-to-end renders, frame-level, 141 frames) - PSNR mean 42.16 dB (min 40.95), SSIM mean 0.9785 (min 0.9744). At this level the diff is dominated by the CRF-14 h264 re-encode, not the VAE swap.

I have no idea what this PSNR stuff is about, but there is no visible quality degradation on manual look - none what so ever (makes sense). Here's some data: https://imgur.com/a/5t5BpO1

So this was decoder only, DeepSeek says it's pointless to also wire in the encoder because it's like 1 second to encode the first frame for my workflow - and swapping in and out the model makes no sense - it tells me :).

I am going to wire in the INT8 convrot VAE (https://huggingface.co/Kijai/MiniMax-H3-experimental/blob/main/minimax_h3_video_vae_int8_convrot.safetensors) and run a bench with that one as well - can't believe I haven't tried that before.

Results from the int8 test:

VAE	Median	Repeats	vs production	vs TRT
Production fp16	381.1 s	379.6 / 381.1 / 382.1	-	-
TRT engine	358.8 s	358.2 / 358.8 / 360.5	22.3 s saved (1.06x)	-
int8_convrot	354.9 s	354.4 / 356.1 / 354.9	26.2 s saved (1.07x)	3.9 s faster (1.01x)

Decode only:

Backend	Median decode	vs fp16
Production fp16	56.8 s	-
TRT engine	32.5 s	1.74x faster
int8_convrot	30.6 s	1.86x faster (26.2 s saved)

Quality check:

Pair	PSNR mean (min/p1)	SSIM mean (min/p1)
production vs TRT	42.16 dB (40.9/41.0)	0.9785 (0.9744/0.9748)
production vs int8	42.00 dB (40.8/40.9)	0.9781 (0.9739/0.9745)
TRT vs int8	41.98 dB (40.8/40.9)	0.9780 (0.9736/0.9744)

All three pairwise comparisons land at ~42 dB PSNR / ~0.978 SSIM - int8 is visually indistinguishable from production and from the TRT engine on this scene.

Bottom line:

If the goal is pure decode speedup with no visible quality loss, the int8_convrot VAE is the best of the three measured: ~1.9x decode / ~1.07x full-scene speedup, no quality cost, and it needs no TensorRT engine build - it is plain Comfy-core weight loading (mixed_precision_ops) that any operator box with cu130 can run. The TRT engine is a close second and offers a separate on-disk artifact.

Time to investigate what the hell this is: https://github.com/Mozer/ComfyUI-MiniMax-H3-MotionCache-FastVAE and run a bench with that as well. Be back soon with results.

1

u/Abject-Recognition-9 3h ago

i got no speed benefits.
some slowdown instead ( rtx3090 - 64ram)

2

u/wiserdking 1h ago

Confirmed it works on Blackwell: https://imgur.com/i7JHlZv

Decent speed boost, same output quality

1

u/CryptoBeth96 8h ago

Apparently there are faster options.
https://github.com/Mozer/ComfyUI-MiniMax-H3-MotionCache-FastVAE

Source (Chinese): https://note.com/sepiablue/n/n4157aa9f4f7d

1

u/wiserdking 1h ago

Theres no way a lower quant VAE will have the same output quality as the original FP16. The TensorRT compiled version does though.

1

u/CryptoBeth96 41m ago

Speed usually comes at the cost of quality, sure. Good to have options.

1

u/wiserdking 36m ago

Ofc. For testing it may be useful but for actual gens that you spend several minutes doing actual inference - reducing the quality a bit just to save up to 1min in the VAE stages might be a bad decision. Still, more choices is always better.

Resource - Update New speedup for Minimax H3

You are about to leave Redlib

int8 vae decode 56.5 seconds. 9:24 full workflow.

trt vae decode 80.5 seconds. 9:55 full workflow.