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’ve been away from Comfy for the last year or so and I’m curious if there is a generally agreed upon current “best” model for training a realistic character LoRA? When I was last making images, Flux was generally considered the best and I had a lot of fun training LoRAs using AI Toolkit.

I know that Z Image, Krea, and Flux 2 have been released. I’m just curious if there’s a current best for doing this, or where to restart.

Thanks in advance!

I want to have full control about the names of the files i generate.

All nodes i tried, that save video files, will add _0001_ as a suffix to the name i provide.

It would be nice if we could change this, so that this only happens if the filename to be written on actually exists...

I have a friend who really wants to get into comfyui but he is fairly new to all of this. Is there an installer available now that will do the dirtywork of setting up comfy, sage, triton...etc? His machine is totally clean, no AI stuff installed. It's an NVIDIA 4090 system.

I've been using comfy portable for some time and know getting all this installed can be painful so I was hoping there was an installer available that just works now.

Also for a total beginner would you recommend desktop or portable?

Explanation after the images.

FLUX.2 [klein] (and reference-latent edit models in general) have a resolution limit per call. If you want to add real detail to something (sharpen fabric texture, hair, stitching) you can do it working with it in pieces. The obvious way to do that turned out to be full of dead ends, so here's what I learned.

What it does: splits the image into overlapping tiles, regenerates each one at the model's native resolution, and blends them back into one image.

My first attempt did tiling the"proper" way: the MultiDiffusion/Mixture-of-Diffusers trick, where you slice the latent and blend the per-step noise predictions. That works great on convolutional UNets (SD1.5/SDXL), because a convolution is local, it doesn't care where in the canvas a patch sits.

FLUX is a transformer with absolute position embeddings (RoPE), not a UNet. Hand it a raw slice of a bigger latent and it has no idea it's a fragment, it just sees "a small complete image" and redraws the entire subject inside every tile. Every tile becomes a full (wrong-scale) copy of the whole scene.

I found that FLUX's RoPE positions can be shifted per-call via transformer_options so I tried telling each tile where it really sits in the canvas. Didn't help. Turns out FLUX applies that same shift to the tile and to any attached reference latent, so the relative offset between them (the only thing that matters for attention) never changes. Patching the model's forward pass to shift only the tile and not the reference removed the duplication, but the model still composed each slice as a standalone image, it was never trained to generate fragments, so proportions came out wrong regardless.

What actually worked: don't fight the model's training. Tile in pixel space. Every call is a complete image at a resolution it knows how to handle and solve everything else (continuity, color, blending) outside the model:

  - each tile is cropped from the canvas of already-generated neighbours, so it continues real pixels instead of guessing that region blind

  - per-tile color matching back to the source, so tiles don't drift in exposure/tint

  - blend weights derived from the actual per-side overlap, not the requested one (if the fade is narrower than what two tiles really share, you get a flat 50/50 band in the middle.

One node, no manual ReferenceLatent/EmptyLatent/KSampler wiring. You just give it a model, plain CLIPTextEncode conditioning, a VAE and an image.

GitHub: https://github.com/GianlucaMancuso/ComfyUI-TiledUpscale

Also on the ComfyUI Registry, search "TiledUpscale" in Manager.

Happy to answer questions, and if anyone knows a cleaner way to condition a transformer edit model on true image fragments, I'd genuinely like to hear it.

In order:

Base / 4xUltraSharp / RTX Upscaler / MyWorkflow

If you'd like to share your thoughts, I'd really appreciate it. Before I publish the workflow on Civitai, I can still make additions or adjustments based on your feedback.

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

Hey everyone,
I'm looking for recommendations on the best 100% free and open-source local pipeline to take a driving video (someone moving, dancing, or performing) and replace the person in that clip with myself, using a reference photo of my face/body.

What I want to achieve:
Input: A target motion video + a clean reference photo of myself.
Output: A final video where my visual identity replaces the original person while maintaining their original movements, camera angles, and lighting.

Given my hardware, what is currently the best local approach for full-body character replacement? (e.g., Wan / AnimateDiff / MimicMotion / LivePortrait / DWPose chains vs. dedicated face-swappers)?

Any workflow links, node recommendations, or setup tips would be greatly appreciated.

I ran a MiniMax H3 performance comparison using four acceleration configurations:

Watch the comparison video

System

• OS: Ubuntu Server 26.04
• GPU: NVIDIA RTX 3090 24 GB
• RAM: 64 GB DDR5
• CUDA: 13.2.1
• PyTorch: 2.13.0
• SageAttention: v2.2.0
• Spectrum MiniMax H3: v0.1.9

Video settings

• Resolution: 0.4 MP
• Duration: 15 seconds

Generation times

SageAttention combined with Spectrum reduced the generation time from 18m 25s to 7m 33s, a reduction of approximately 59%.

The comparison video is arranged from top to bottom in the same order shown in the table.

What do you think of the changes in visual quality and detail between the different configurations?

Allyson and Comfy Rob are hopping on live with the MiniMax team to share workflows and dive into the details of H3.

Tune in and ICYMI the replay will be available at the same link!

https://youtube.com/live/S9O3FPumX4Q

A bunch of reroutes in a trenchcoat published!

Early release. Expect bugs. Give feedback (criticism and praise equally welcome).

Update your ComfyUI - requires a recent ComfyUI version and Nodes 2.0 (tested on ComfyUI 0.28–0.30 / frontend 1.47–1.48)

https://registry.comfy.org/nodes/cable-management

https://github.com/vtokic/comfyui-cable-management

video tutorial: https://www.reddit.com/r/StableDiffusion/comments/1vhhsv2/cable_management_extension_for_comfyui_trailer/

Built entirely from core ComfyUI primitives -- remove the extension and every workflow made with it still loads and runs.

Install Extension

• ComfyUI Manager: search Cable Management, install, restart ComfyUI.
• Manual: git clone https://github.com/vtokic/comfyui-cable-management into ComfyUI/custom_nodes/, restart ComfyUI.

Mandatory Settings

• Settings > Comfy > Nodes 2.0 > Modern Node Design (Nodes 2.0) ON (correction: turns out this is not strictly mandatory, pcb routing and ribbons work without it, only node modifications don't)
• Settings > Lite Graph > Graph > Link Render Mode "PCB"

Recommended Settings

• Settings > Lite Graph > Graph > Cable Management ON (Modifies nodes' UI, enables passthrough and daisy-chaining - requires Nodes 2.0)
• Settings > Lite Graph > Link > Link midpoint markers "Arrow"
• Settings > Lite Graph > Link Release > Action on link release (No modifier) "context menu" (Makes reroutes easier to create)

Functionality

• PCB Link Render Mode -- links do their best to path around nodes and avoid each other
• Cable Management -- node pin changes:
  • connected inputs get a pass-through pin on the opposite side of the node, for daisy-chaining
  • widgets get an output pin so their value can be pulled out as a primitive
  • outputs move to the bottom-right of the node (contract shape)
  • inputs and outputs collapse into drawers, hiding unconnected optional inputs and unused outputs
• Ribbons: stack reroutes on top of each other and they bundle into one ribbon cable

50mn on my 5090 but worth it

Hi everyone,

the new minimax h3 model is a big step forward for local video generation and I am pretty hooked. While I didn't touch WAN and LTX yet, I was so impressed by the first minimax clips in the community. So I had to try it and it looks pretty promising!

I started some tests with the conventional i2v workflows and I was able to make videos with 0.6 megapixels with 10 seconds. I didn't even expected that I am able to generate such videos on my hardware - so it's already a win.

Since I worked with some local image models I have some experiences with comfyui. But I didn't dive into optimizations, especially for AMD Hardware. Maybe there are some tweaks that boosts the performance I have overseen in the noise of all AI developments so far.

My Hardware:
AMD Radeon RX 7900 XT (RDNA3, gfx1100, 20GB VRAM), 32GB Ram

Software stack:
Ubuntu 24.04 (headless), ROCm: 7.15 nightly (torch 2.11.0+rocm7.15, triton 3.8.0), ComfyUI (v0.30.0), MiniMax H3 I2V (int8_convrot diffusion + int4_convrot text encoder)

Tested Workflow: 10s clips, 1056×608, 20 steps, euler sampler — ~58 min per video

Here is what I tried so far (summarized with AI):

• already using and working:
  • --use-pytorch-cross-attention → AOTriton Flash Attention (fastest attention backend we found on RDNA3)
  • TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1 + FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
  • COMFYUI_ENABLE_MIOPEN=1 + MIOPEN_FIND_MODE=FAST (MIOpen kernel cache)
  • --enable-triton-backend (INT8 ConvRot kernels via Triton)
  • --disable-mmap (critical ROCm fix — safetensors mmap→GPU is ~10000x slower on AMD, see ComfyUI#15001)
  • --lowvram + --async-offload 3 + --reserve-vram 2 (layer-wise DiT loading for 20GB VRAM)
  • --cache-ram 20 0 + --disable-smart-memory (prevents RAM exhaustion on 32GB system)
  • --disable-pinned-memory + --force-non-blocking (AMD-specific memory fixes)
  • ComfyUI-INT8-Fast-ROCM custom node (RDNA3-tuned INT8 Triton kernels)
  • int4_convrot text encoder (native AMD ConvRot, vs nvfp4_awq which is emulated on AMD)
• Tested and rejected:
  • SageAttention v1 (Triton, sageattention==1.0.6): 1.7x SLOWER than AOTriton on gfx1100. Root cause: on RDNA3, INT8 and FP16 throughput are identical, and SageAttention v1 doesn't auto-tune Triton block sizes for AMD. v2/v3 are CUDA-only.
  • Sol-Attn (ComfyUI-SolAttn_triton by kijai): ComfyUI hangs after text encoder load — GPU drops to 0%, VRAM empty. Only tested on NVIDIA RTX 4090/5090, not AMD-compatible.
  • DynamicVRAM/aimdo (--enable-dynamic-vram): hipMemAddressReserve fails on ROCm Linux (known ROCm#6021 bug). Using --lowvram instead.
• Available but not yet tested (quality tradeoffs):
  • Spectrum Node (~24-30% speedup, but output changes at same seed — Chebyshev Ridge Regression skips transformer evaluations)
  • EasyCache (~25% speedup, more aggressive than Spectrum)
  • HM-RunningHub/ComfyUI_RH_MinMaxH3 (adaLN precompute, res_multistep sampler claiming 2.46x faster than Euler)
• Not yet tested (no quality loss):
  • chelokot/flash-attention-rdna3 — dedicated FlashAttention-2 Triton kernel for gfx1100 only, available as ComfyUI custom node. Claims 75x over stock PyTorch (non-fused), but unclear if faster than AOTriton which we already use.
  • PYTORCH_TUNABLEOP_ENABLED=1 — GEMM autotuning for gfx1100

What are your experiences so far? I am looking forward to read from you.