larryvrh

/

MiniMax-H3-Turbo-Lora

like 530

Hi @larryvrh , thank you for releasing the MiniMax-H3 Turbo LoRA and the reference generate.py.

I made a third-party ComfyUI custom sampler based on the dual-clock Euler logic in your script:

https://github.com/shuaixn/ComfyUI-MiniMaxH3DualClockSampler

The node samples the joint MiniMax-H3 video/audio latent with separate sigma updates for video (shift = 12) and audio (shift = 3). In my tests, this resolved the severe audio clipping and noise that occurred when using the stock single-clock ComfyUI Euler sampler at 4 steps.

The repository includes:

• A custom MiniMax H3 Dual-Clock Euler sampler node
• A validated converter that adds the required diffusion_model. prefix to the original LoRA keys
• ComfyUI installation and workflow wiring instructions
• Chinese and English documentation
• Explanations of the dual-clock sampling logic and why a custom sigma list alone is not sufficient
• Basic tests for the video/audio integration and packed ComfyUI latent handling

My current known-good starting configuration is:

• Full, non-pruned FL2VA BF16, or full INT8 ConvRot
• The non-EMA minimax_h3_turbo_4step.safetensors
• Converted ComfyUI-prefixed LoRA keys
• Load LoRA (Bypass, Model Only)
• LoRA strength: 1.0
• Scheduler: simple
• Steps: 4 or 8
• The custom dual-clock Euler sampler

The full BF16 FL2VA model is the closest match to your validation environment. I also tested the full INT8 ConvRot model locally. Pruned checkpoints are not recommended because some AdaLN LoRA targets have incompatible shapes.

This is an unofficial community compatibility node and is not affiliated with you or Comfy-Org. It follows the current implementation in generate.py and may need to be updated if the upstream sampling logic changes.

At 4 steps, the audio is now clean and coherent in my tests, although its quality is still slightly lower than a normal 20-step generation. Using 8 steps gives a cleaner result.

If you have time, I would really appreciate any corrections, especially regarding my interpretation of the audio velocity scaling and the separate video/audio sigma updates. Feel free to share or link the repository if you think it could help ComfyUI users.

Thanks again for releasing the LoRA!

I got over fitting result and noise in the video when using the newest turbo lora, patching with your script. 8 steps. sound is ok but frames are totally un-usable

Thanks for testing. The newest Turbo LoRA checkpoint is different from the early 4-step preview that my sampler was built for.
Please try the author’s official ComfyUI node and example workflow first, using the exact model, LoRA, sampler, and step settings from the author.
If you want to use my repository, please follow the README exactly: full non-pruned FL2VA model, Load LoRA (Bypass, Model Only), Simple scheduler, denoise 1.0, and no additional sampler or shift override. My sampler is fixed to video shift 12 and audio shift 3.
If the frames are still unusable, please share the exact LoRA filename, base model, steps, sampler, scheduler, LoRA strength, and the [MiniMaxH3DualClock] log line.

Hi @larryvrh , I completed a controlled comparison between the initial checkpoint and minimax_h3_turbo_4step_ckpt500.safetensors.

I kept the same full non-pruned base model and the same workflow settings, and tested the following paths:

1. Initial LoRA, ComfyUI-prefixed, bypass model-only loader + my dual-clock sampler: video looks normal.
2. ckpt500, ComfyUI-prefixed, bypass model-only loader + my dual-clock sampler: severe oily/waxy textures, excessive saturation and exaggerated skin/vein details at both 4 and 8 steps.
3. Original unmodified ckpt500 + your MiniMax-H3 Turbo LoRA loader + my sampler: the same visual artifacts remain.
4. Original unmodified ckpt500 + your LoRA loader + your official Turbo sampler: the artifacts still remain, including color shifts between frames, excessive saturation and oily-looking details.

Because the artifacts follow ckpt500 across both LoRA loaders, both samplers and both 4/8-step settings, while the initial checkpoint remains normal, this appears to be related to the ckpt500 weights rather than key conversion or sampler compatibility.

I also compared the effective LoRA updates (B @ A) for all 259 layer pairs:

• No NaN/Inf or damaged tensors were found.
• Global effective update norm of ckpt500 is approximately 1.835× the initial checkpoint.
• Median per-layer norm ratio is 1.622×.
• 90th percentile is 2.090×.
• Maximum layer ratio is 3.590×.
• Global cosine similarity between the two effective LoRA updates is approximately 0.451.

This suggests that ckpt500 is not merely a slightly stronger continuation of the initial checkpoint: its update magnitude is substantially larger and its update direction has also changed considerably. Visually, it looks more like an overcooked checkpoint or training drift than simple under-training, although inference results alone cannot formally prove overfitting.

Could you confirm whether ckpt500 is expected to use a lower LoRA strength than 1.0, or whether this visual behavior is a known issue that may be addressed by a later checkpoint?

Thanks again for releasing the weights and official ComfyUI integration.

Do these custom nodes work similarly as Kijai's audio fix PR for ComfyUI core? This one: https://github.com/Comfy-Org/ComfyUI/pull/15243

Do these custom nodes work similarly as Kijai's audio fix PR for ComfyUI core? This one: https://github.com/Comfy-Org/ComfyUI/pull/15243

My custom node was made specifically to reproduce the Turbo LoRA author's generate.py inference path in ComfyUI. The Turbo LoRA reference uses dual-clock Euler integration: video uses shift 12, while audio uses shift 3. With the stock single-clock ComfyUI sampling path, the audio trajectory was incorrect and produced severe noise/clipping at 4 steps.
Kijai's PR appears to address the more general MiniMax H3 issue at the ComfyUI core level. Instead of implementing the correction in a custom sampler, it rescales/carries the audio latent so regular samplers can operate on a compatible shared schedule, while the model restores the audio-side scaling internally. It also aims to support more sampler types, including stochastic samplers.
So my node is a Turbo-LoRA-focused compatibility implementation for the author's dual-clock Euler workflow, while Kijai's PR is a broader upstream solution for MiniMax H3 sampling. For Euler they may be mathematically related, but I have not yet tested the PR against this Turbo LoRA, so I would not claim they are fully equivalent yet. Thanks for sharing the link.