Base MinimaxH3 (Turbo Merge)
This model is unchanged/untrained from the base model listed. The model was quantized from the source FP32/BF16 model. BOTH THE FL2VA and REF2VA models are 8 step models.
Requirements:
Update CUDA to 13.4.2
Update Pytorch to 13.2
Update at minimum comfy-aimdo, comfy-kitchen
Basic workflow shows how to use both first frame text guided and first frame last frame with comfy kitchen backend node to speed up generation by 60% (This prevents pyattention fallback which is slow)
pytorch version: 2.13.0+cu132
xformers version: 0.0.35
Using xformers attention
ComfyUI version: 0.35.0
comfy-aimdo version: 0.5.5
comfy-kitchen version: 0.2.34
Consider --disable-dynamic-vram if you are having OOM issues after a few generation or crash when trying to use comfy kitchen vs pyattention
Note: INT Convrot Group size is 64 vs 256 on the comfy supplied models
NF4 version of the reference to video/audio model works but the quality is very low
Description
FAQ
Comments (17)
Any chance on RTX40608gb+64gbDDR5-5200?
I would use the INT8 version, but with offloading you could use the BF16
INT8 has native support on 40xx and 30xx the other quants do not.
it's works for me 3090ti, INT8, 32ram
Thank you so much, please do also the REF2VA variants.
👍
您好,生成的手部总是有虚影,是不是还需要加一个加速lora
I haven't noticed ghosting on the videos I have tested
@Felldude 谢谢回复,我增加了一个4步加速lora后解决了问题~
It runs fine with 0.6M/10s, but encounters an OOM error when using 0.8M/15s with 8 steps; in fact, OOM occurs consistently at this resolution and duration. This issue does not arise when using other fusion-accelerated models or the official H3 INT8-pruned model. Could you explain the reason for this?
Key Differences: Model Loading and Peak Attention Strategies
The fact that other models run successfully implies that your 12GB VRAM—utilizing VRAM-to-RAM swapping strategies—should theoretically handle the 0.8M/15S workload. However, this merged model fails, likely because it does not employ an optimal low-VRAM strategy.
Differences in Model Loading Strategies
Running H3 on a 12GB card relies on a "sequential offload" strategy: only the layer currently being computed remains in VRAM, while the rest are offloaded to system RAM, keeping VRAM usage around 2–3GB. Since other models run normally, their loaders are evidently executing this strategy correctly. In contrast, logs for this merged model show 10.12 GiB of weights resident in VRAM; it likely failed to offload them promptly, effectively "pinning" a large volume of weights in VRAM and leaving negligible free space.
Differences in Peak Attention Mechanism Usage
With long sequences like 0.8M/15S, peak VRAM usage for the attention mechanism spikes dramatically. Tests show that in long-sequence scenarios, specific attention implementations can reduce peak VRAM from ~11.3GB to ~7.1GB. While other models may default to memory-efficient attention paths (such as chunked attention), this merged model appears forced onto a high-peak path, immediately hitting the 12GB limit.
⚙️ The "Last Straw" Triggering the OOM Error
The error in the logs occurred during an int8_linear computation within comfy_kitchen, specifically failing when attempting to allocate a 2.33 GiB temporary tensor.
This indicates a "heavy" step in the merged model's INT8 quantization computation path: it requires the allocation of a massive intermediate activation tensor all at once during linear layer calculations. Other models likely employ smarter chunked quantization or streaming processing to avoid such large, instantaneous allocations. Because this model's internal structure has been modified, it inadvertently triggered a path requiring high temporary VRAM. 💡 Recommendations
Since you have verified that the 0.6M/10S setting works fine while 0.8M/15S consistently crashes, the most straightforward approach is to use the 0.6M/10S or 0.7M configuration for this model.
If you are determined to run 0.8M/15S with this model, you could try the following:
Force-enable a more VRAM-efficient attention mechanism: Ensure that a node like "MiniMax H3 Memory Efficient Sage Attention" (or a similar low-VRAM attention patch) is connected in your workflow.
Add the --lowvram launch argument: Include --lowvram in your launcher settings to force ComfyUI to offload weights to system RAM more aggressively.
If these measures do not resolve the issue, the conclusion is clear: this specific merged model cannot stably handle 0.8M/15S tasks on 12GB of VRAM until its INT8 computation path and loading strategy are optimized. Sticking to 0.6M or 0.7M, or reverting to a model you have already verified, would be the more hassle-free choice.
Convrot size is 64 rather then 256 it sounds like for 8GB and 12GB cards this is the likely cause
Thank you very much for releasing this model. I have several H3 models on hand and wanted to try the one you published, but I ran into an issue. I felt it was important to provide timely feedback—this isn't a complaint, and I appreciate your reply!
Environment:
GPU: RTX 4070 SUPER 12GB
RAM: 32GB
ComfyUI: 0.36.0
PyTorch: 2.13.0+cu130
Model: baseMinimaxh38Step_comfyFI2vaPruned_int8.safetensors
Task:
0.8M / 15S, 8 steps, euler + simple
Error Details:
text
torch.OutOfMemoryError: Allocation on device 0 would exceed allowed memory.
Currently allocated: 10.12 GiB
Requested: 2.33 GiB
Device limit: 11.99 GiB
Occurred during the sampling phase: comfy_kitchen int8_linear → quantize_and_rotate_rowwise (before reaching VAE decoding).
"You mentioned changing the transformation size from 256 to 64; where exactly can this parameter be modified? Is it convrot_groupsize? I didn't see this option in the loader or the quantization configuration. If the default is 256, could you provide a quantized version with a size of 64 or 128, or expose this parameter in the node? Other users with 12GB cards might encounter the same issue."
@aaronkong2022342 Its a quality parameter during quantitation not modifiable after the fact. Try using --disable-dynamic-vram if the issue persist then its likely that the higher quality quant is not usable by low vram
@Felldude Understood. Thank you for your efforts—thank you!