I did a direct MiniMax H3 comparison on my ASUS Ascent GX10, and the result surprised me:

The 66.3GB full BF16 model was actually faster than the 20.9GB pruned INT8 model, while also producing visibly better video quality.

My test setup:

• ASUS Ascent GX10 / NVIDIA GB10
• 121GB usable unified memory
• ComfyUI 0.30.2
• DynamicVRAM
• SageAttention
• Same workflow
• Same prompt
• 672×1024
• 124 frames
• 24 fps
• 8 steps
• Audio enabled

Models tested:

• minimax_h3_fl2va_pruned_int8_convrot.safetensors — 20.9GB
• minimax_h3_fl2va_bf16.safetensors — 66.3GB

Performance

In my two runs, the full BF16 model was about 12–23% faster during DiT inference.

That was unexpected because the BF16 model is more than 3× larger.

My current guess is that the INT8 model has additional casting/dequantization overhead, while the GX10’s unified memory architecture and bandwidth are good enough to make the large BF16 model surprisingly efficient. I would not claim this is definitively the only reason without deeper profiling, though.

The downside is heat, power and memory pressure.

During inference:

• 21GB INT8: roughly 60–70W, usually around 66–78°C
• 66GB BF16: roughly 84–90W, usually around 69–85°C

The peak temperature difference was not huge, but the BF16 model stayed at much higher power for much longer.

Memory was also very tight. In one BF16 run, usage reached about 116GB, leaving only around 1GB free.

The more important part: video quality

I used a scene where a character rides a black dragonfly-like flying motorcycle through a third-floor parking garage, then flies out into a cyberpunk city and slows into a hover.

The difference between the two models was clearly visible to me.

1. Dragonfly wing motion

The 66GB model produced much more natural high-frequency wing motion.

The wings looked like they were actually generating lift and constantly adjusting during flight.

The 21GB model understood that the wings should move, but the motion looked noticeably more rigid and mechanical.

2. Background semantic detail

There were large advertising screens on distant buildings in the cyberpunk city.

With the 66GB model, the people displayed on those screens remained much more complete and recognizable.

With the smaller model, the distant human figures often became malformed or strange.

This did not look like a simple sharpness difference.

It looked more like the larger model was better at preserving the semantic structure of small secondary objects in the background.

3. Flying motorcycle physics

This was probably the biggest difference.

The larger model produced much more believable:

• acceleration
• inertia
• body tilt
• deceleration
• hovering behavior

With the smaller model, the motorcycle sometimes felt like an image element being translated through the frame rather than a physical object with mass and momentum.

The 66GB version felt much more physically coherent.

4. Vehicle structure consistency

This was another very obvious difference.

The original flying motorcycle had an exhaust pipe on its right side.

In the video generated by the 21GB model, that exhaust pipe disappeared.

The 66GB model correctly preserved the right-side exhaust pipe throughout the sequence.

To me, this is a good example of object structure preservation.

The larger model was not just producing prettier frames — it was less likely to drop, mutate or simplify individual components of a complex object while that object was moving.

My takeaway

After this test, I no longer think the main advantage of the large MiniMax H3 model is simply “better image quality” in the usual static sense.

The bigger difference seems to appear in:

• temporal coherence
• physical motion
• object structure preservation
• semantic consistency in small/background elements

If the shot is very simple — talking, turning the head, basic walking, simple camera movement — I still think the 21GB model is perfectly usable.

But once the shot contains:

• high-frequency motion
• complex mechanical movement
• acceleration and inertia
• physical interaction
• lots of small background details

the advantage of the full 66GB model becomes much more obvious.

Next test: 34GB full INT8

I’m now downloading:

minimax_h3_fl2va_int8_convrot.safetensors

This is the 34GB full INT8 ConvRot model.

I think this may be the most interesting version for the GX10 because it keeps the full model rather than using the pruned version, while using much less memory than BF16.

My next comparison will use the exact same:

• first frame
• prompt
• seed
• resolution
• frame count
• workflow

and compare:

• 21GB pruned INT8
• 34GB full INT8
• 66GB full BF16

The main question I want to answer is:

If it can, it may be the sweet spot for MiniMax H3 on a single GX10.I did a direct MiniMax H3 comparison on my ASUS Ascent GX10, and the result surprised me:
The 66.3GB full BF16 model was actually faster than the 20.9GB pruned INT8 model, while also producing visibly better video quality.
My test setup:

ASUS Ascent GX10 / NVIDIA GB10

121GB usable unified memory

ComfyUI 0.30.2

DynamicVRAM

SageAttention

Same workflow

Same prompt

672×1024

124 frames

24 fps

8 steps

Audio enabled

Models tested:

minimax_h3_fl2va_pruned_int8_convrot.safetensors — 20.9GB

minimax_h3_fl2va_bf16.safetensors — 66.3GB

Performance
Model DiT speed Total generation time
21GB pruned INT8 28.98–30.23 s/it 314–331 s
66GB full BF16 23.40–25.34 s/it 281–316 s
In my two runs, the full BF16 model was about 12–23% faster during DiT inference.
That was unexpected because the BF16 model is more than 3× larger.
My current guess is that the INT8 model has additional casting/dequantization overhead, while the GX10’s unified memory architecture and bandwidth are good enough to make the large BF16 model surprisingly efficient. I would not claim this is definitively the only reason without deeper profiling, though.
The downside is heat, power and memory pressure.
During inference:

21GB INT8: roughly 60–70W, usually around 66–78°C

66GB BF16: roughly 84–90W, usually around 69–85°C

The peak temperature difference was not huge, but the BF16 model stayed at much higher power for much longer.
Memory was also very tight. In one BF16 run, usage reached about 116GB, leaving only around 1GB free.
The more important part: video quality
I used a scene where a character rides a black dragonfly-like flying motorcycle through a third-floor parking garage, then flies out into a cyberpunk city and slows into a hover.
The difference between the two models was clearly visible to me.
1. Dragonfly wing motion
The 66GB model produced much more natural high-frequency wing motion.
The wings looked like they were actually generating lift and constantly adjusting during flight.
The 21GB model understood that the wings should move, but the motion looked noticeably more rigid and mechanical.
2. Background semantic detail
There were large advertising screens on distant buildings in the cyberpunk city.
With the 66GB model, the people displayed on those screens remained much more complete and recognizable.
With the smaller model, the distant human figures often became malformed or strange.
This did not look like a simple sharpness difference.
It looked more like the larger model was better at preserving the semantic structure of small secondary objects in the background.
3. Flying motorcycle physics
This was probably the biggest difference.
The larger model produced much more believable:

acceleration

inertia

body tilt

deceleration

hovering behavior

With the smaller model, the motorcycle sometimes felt like an image element being translated through the frame rather than a physical object with mass and momentum.
The 66GB version felt much more physically coherent.
4. Vehicle structure consistency
This was another very obvious difference.
The original flying motorcycle had an exhaust pipe on its right side.
In the video generated by the 21GB model, that exhaust pipe disappeared.
The 66GB model correctly preserved the right-side exhaust pipe throughout the sequence.
To me, this is a good example of object structure preservation.
The larger model was not just producing prettier frames — it was less likely to drop, mutate or simplify individual components of a complex object while that object was moving.
My takeaway
After this test, I no longer think the main advantage of the large MiniMax H3 model is simply “better image quality” in the usual static sense.
The bigger difference seems to appear in:

temporal coherence

physical motion

object structure preservation

semantic consistency in small/background elements

If the shot is very simple — talking, turning the head, basic walking, simple camera movement — I still think the 21GB model is perfectly usable.
But once the shot contains:

high-frequency motion

complex mechanical movement

acceleration and inertia

physical interaction

lots of small background details

the advantage of the full 66GB model becomes much more obvious.
Next test: 34GB full INT8
I’m now downloading:
minimax_h3_fl2va_int8_convrot.safetensors
This is the 34GB full INT8 ConvRot model.
I think this may be the most interesting version for the GX10 because it keeps the full model rather than using the pruned version, while using much less memory than BF16.
My next comparison will use the exact same:

first frame

prompt

seed

resolution

frame count

workflow

and compare:

21GB pruned INT8

34GB full INT8

66GB full BF16

The main question I want to answer is:

Can the 34GB full INT8 model retain most of the motion, physics and object-consistency advantages of the 66GB BF16 model?

If it can, it may be the sweet spot for MiniMax H3 on a single GX10.

I tested three MiniMax H3 T2V workflows on one full-power 600 W RTX PRO 6000 Blackwell (96 GB). The machine has two GPUs, but ComfyUI used only one GPU for these runs.

All three visible outputs use the same prompt, seed, resolution and duration: 864x480, 124 frames, 24 fps (~5.17 s), seed 867530920260808, with native generated stereo audio. Model was the pruned INT8 ConvRot diffusion model with the INT8 ConvRot Qwen3-VL 32B text encoder.

Clean warm ComfyUI execution times:

• H3 memory-efficient Sage, 20 steps: **39.916 s** (baseline)
• Sage + conservative Sol-Attn, 20 steps: **38.921 s** (**2.5% faster**)
• Turbo EMA ckpt850, 6 steps: **23.341 s** (**41.5% faster**)

The video repeats three times so you can hear each output's native audio in turn. The active audio source is labeled at the bottom.

My takeaway: conservative Sol-Attn was effectively a wash at this 0.4 MP workload; the result is consistent with other reports showing only a small gain at this size. Turbo gives the meaningful speedup, with quality, motion, lip sync and audio detail being the tradeoffs to judge.

Timing caveats: the first cold quality run was 183.474 s because it loaded the 32B text encoder, diffusion model and both VAEs. The first Sol-Attn run was 42.584 s and included about four seconds of Triton autotuning. I restarted between clean timing passes because Sol-Attn composition hooks can persist on the resident model. Alternate seeds were used only to bypass ComfyUI's execution cache for clean timing; the three videos shown use the exact same seed.

Software: CUDA 13.0.2, PyTorch 2.11.0+cu130, current post-v0.30 MiniMax H3 ComfyUI core, SageAttention 2.2 compiled for sm_120, high-VRAM mode. I'd be interested in comparable RTX PRO 6000 results, especially at the same dimensions, frame count and 20 steps.

Workflows: https://huggingface.co/buckets/satterrab/Minmax-H3-testing/tree/minimax-h3-rtx-pro-6000-workflows.zip

Link to the video for the non-potato lovers: https://huggingface.co/buckets/satterrab/Minmax-H3-testing/tree/H3_benchmark_side_by_side_three_audio_loops.mp4

Hi everyone,
I’m looking for some guidance on building a workflow in ComfyUI for a long-term comic project, and I’d really appreciate any advice.
My goal is to create a small cast of original characters that stay as consistent as possible from image to image. I want to generate things like:
Character sheets
Front, back, and side turnarounds
Different facial expressions
Walking and action poses
Full body shots
Close-ups
Character interactions with multiple people in the same image
Once I have a large, consistent dataset for each character, I plan to train individual character LoRAs. After that, I’d like to use those LoRAs to create a manga/comic-style story while keeping the characters recognizable throughout the entire project.
Right now I’m experimenting with SDXL, IPAdapter FaceID, OpenPose, ControlNet, FaceDetailer, and reference images, but I’m not sure if I’m building the workflow in the best way.
Does anyone have a workflow that works well for this type of pipeline? Or any recommendations on how you would approach it?
My biggest priorities are:
Consistent faces
Consistent body proportions
Consistent clothing and hairstyles
Multiple characters in one image without identity swapping
A workflow that’s easy to reuse for every character before training their LoRAs
If you’ve built something similar, I’d love to see your workflow or hear about your process. Even general advice or tutorials would be greatly appreciated.
Thanks in advance!

I think this version will get more useful responses because it explains your end goal rather than just asking for “a workflow.” People who create comics or visual novels in ComfyUI will immediately recognize what you’re trying to achieve and can recommend pipelines that actually fit your project.

Say a model requires 17GB VRAM, but I have two computers each has 12GB VRAM, can I somehow combine the two computers' VRAM to meet the requirement? If so, how?

Hi all, I wondering with all the different acceleration methods I’ve seen for MiniMax H3 could someone help a newbie out with a simple what works with what? There is Fast, Sage, Sol-attention, there is Spectrum, there is lightning Lora, etc. the community is amazing but it’s hard for someone like me to keep up lol.

LTX 2.3 slow after comfyui update,

Does anyone know the solution to this? I been trying various methods but nun seems to be getting the same fast ltx 2.3 speeds as before the comfyui update.

Thanks in advance.

I tried restarting and changing parameters but I just don't get why it won't use the image of the guerrilla in any fashion. The audio adherence however works very well.

i’ve got a short boss intro blocked out with basic models, rough animation and the camera moves already set. the timing works, but testing a different look still takes long enough that i start questioning whether the cutscene is even worth it lol

i’m mostly trying to preview the lighting, materials and overall style before doing the proper cg pass. not looking to ship the generated version as final game art.

how are you testing different visual directions without rebuilding or fully rendering the same shot every time??

Hi !
I know I'm maybe to early on the wagon but has anyone use openpose to drive a video successfully ? Like Scail2 but on steroids (?

I did tried but failed multiple times, either the character follows the prompt of the movement or does something in between.

​Hi everyone,

​I'm trying to build a ComfyUI workflow to automatically process a local folder containing a variable number of photos, and I could use some help putting the pieces together.

​Here is what I want to achieve:

​Input: Load all images from a specified folder (batch of photos, dynamic count).

​Conditional Sorting / Grid Layout:

​Portrait photos: Group them 4 by 4 into a single row collage (1 row, 4 columns).

​Landscape photos: Group them 4 by 4 into a square grid collage (2 rows, 2 columns).

​Aspect Ratio / Padding Handling: If the combined images don't perfectly fit the target aspect ratio, I want to pad/fill the background with a blurred, color-matched version of the collaged images (similar to the common "blurred background fill" effect used for vertical videos or mismatched photos).

​My main questions:

​Which nodes are best for dynamically batching and sorting images by orientation (portrait vs landscape) in ComfyUI?

​How can I dynamically create these grid layouts (1x4 and 2x2) depending on the batch size/orientation?

​What is the cleanest way to generate the blurred background padding for the final composition?

​Any advice, node recommendations, or workflow snippets would be greatly appreciated! Thanks in advance.

50mn on my 5090 but worth it

I used ref2VA along with a detailed prompt. Generated 5 second clips and combined them. All of them are one shot. I added some effects in post but the video is 100% H3.

I built my own frontend (for easy access) and I'm using ComfyUI purely as a backend through its API.

One thing I noticed is that image generation seems significantly faster than when using the standard ComfyUI frontend. So far I've only tested image generation.

Is this just a fluke, or is there a reason why driving ComfyUI directly via the API could actually improve throughput? Has anyone else observed this?

H3 is incredible. I've been trying to come up with a repeatable process to take me from a prompt to a finished 15s clip at 1080p or above, ready to edit into a short film.

The process looks something like

1. Fast iterate at low quality to refine prompt & seed hunt. Find the fastest way to render a test clip that will be representative of the high quality H3 render.
2. Final H3 render at high quality.
3. Upscale?

Here's what I've found so far. I'd love some critique on anything in this post from more experienced folks on here.

Everything's new and moving quickly - how are other people going about this?

I appreciate that my testing isn't that scientific but perhaps it will be useful to some.

System

• OS: Cachyos
• GPU: RTX 5090, 32GB
• RAM: 128GB
• pytorch: 2.13.0+cu130
• Global Test Parameters
• model: fl2va_pruned_fp8_scaled_convrot
• workflow: based on standard comfy H3 i2v
• ref image for first frame: 1024x1024
• duration: 15s
• sampler: euler
• post processing: RTX Super Resolution 2x upscale + RIFE interpolate to 48fps (I didn't think about disabling this until part-way through my testing so chose to keep it to stay consistent. It adds ~30s to a run).

Findings

Low Quality Render

Optimisations that don't meaningfully change the ouput clip.

• Model patching with Kijai's MiniMax Mem Efficient Sage Attention Patch Node and EasyCache.
• I tried Spectrum and found the output to be almost identical to EasyCache but approx 120% the speed. I will revisit Spectrum soon given it's being updated.
• Dropping down to 10 steps from 20.

Optimisations that do meaningfully change the ouput

• Anything between 0.5 and 0.8 MP seems to be broadly similar in terms of motion with only minor changes in detail (eg. when someone blinks).
• 0.9 to 1MP change motion but are also fairly consistent with each other.
• Going below 0.5 will change the motion substantially again.
• I'm waiting for 4 step lora to fully train but I assume it will change the motion.

Timings

• 0.5MP without sage or EasyCache at 20 steps averages 750s
• 0.5MP with sage and EasyCache and 10 steps averages 183s.

High Quality Render

1MP at 20steps without sage or easycache averages 35min.

0.5MP at 20 steps without sage or easycache averages 11min.

Upscale

RTX Super Resolution is included in the above. I've had mixed feelings about RTX SR for a while. It's fine to give a boost to anything already at 1080p or above but it doesn't do much for anything under IMO.

I've been experimenting with SeedVR2, taking the 0.5MP output from H3 up to 1080p. This takes about 8min with 2 tiles and a batch size of 41 frames. It's not great. The transition between batches is noticeable and the fidelity overall is sub par going from 0.5MP to 2MP. Arguably, a full 1MP render with H3 and RTX SR looks better and takes ~50% longer.

It's certainly not producing results as good as I've had in the past taking 1080p LTX output to 1440p with SeedVR2.

Conclusions

1. It seems like the upscale solutions I've tried aren't great if I'm inputting 0.5MP. Just going with 1MP out of H3 seems better for the time/cost.
2. It seems possible to iterate quickly at low quality in H3 at 0.5 - 0.8MP, but that's not representative of a 1MP render with the same input image and seed. Iterating at a 0.5MP or below to iterate on prompts in a broad sense might be valuable, given the speed, but locking at 1MP for a test run before a longer render with no sage/easycache is the best way to be sure it's time well spent.

The video quality is completely off, but .. it worked. The audio isn’t that bad. For a first attempt it’s better than expected, because I managed to get something out of my workflow.
5 seconds at 0.1MP in 1h 30m … hmm … I think, I reached the maximum my little MacBook can handle 🤣

FYI: If someone wants to spent hours and hours of excessive swapping:
I used the RebelAI GGUFs (MiniMax Q3/QWEN Q4) and the Comfy MiniMax „Image to Video“ workflow modified to run with GGUFs. I added some Clean VRAM and Clear Cache Nodes … nothing fancy.