MiniMax H3 video generation ~4x slower since v0.32.0 at full resolution - regression from #15486 (v = v.clone())
- Dominant language
- Python
- Stars
- 133k
- Forks
- 15.7k
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 158
Description
**Summary**
Since v0.32.0, MiniMax H3 video generation at full resolution (1280x736, 362 frames, 20 steps) is ~4x slower than in 0.31.1: ~26 min -> an estimated ~2 hours. Small resolutions (e.g. 512x512) are unaffected. Reproduces on 0.32.0 and 0.33.1, with both the int8 full model and the fp8 pruned model.
**Environment**
- ComfyUI v0.33.1 (also reproduced on v0.32.0), Windows 11
- RTX 5070 Ti 16 GB, torch 2.13.0+cu130, Python 3.13
- Launched with `--use-sage-attention --disable-cuda-malloc`; DynamicVRAM + async offload are on by default
- Models: `minimax_h3_fl2va_int8_convrot.safetensors` and `minimax_h3_fl2va_pruned_fp8_scaled.safetensors` + qwen3vl 32B int8 text encoder
**Symptoms (during sampling)**
- First step takes >5 minutes (vs ~90 s/step in 0.31.1)
- GPU SM utilization ~99% but power draw only ~96 W (vs ~230 W)
- Memory bandwidth utilization ~3% (vs ~20%)
- GPU temperature stays ~45 C (vs ~59 C)
**Bisection**
1. 0.31.1 + comfy-kitchen 0.2.28 -> fast (~90 s/step)
2. 0.31.1 + comfy-kitchen 0.2.30 -> fast (~90 s/step) - comfy-kitchen ruled out
3. 0.33.1 stock -> slow (first step never finished within 5 min 41 s)
4. 0.33.1, 512x512 short clip -> normal speed (only the full-size job is affected)
The regression appeared in the same update that introduced #15486 ("Fix peak memory issue with H3").
## Appendix: Run Records
### A. Normal run - ComfyUI 0.30.2 (baseline, 2026-08-14)
- Full 15s video (1280x736, 362 frames, 20 steps) total: 26m20s
- GPU util avg 97.1%, VRAM avg 15.1GB, temp avg 61.7C, power avg 263W (max 296W), fan 53%
- Output: MiniMax_H3_00001_.mp4 (5.6 MB)
### B. Abnormal run - ComfyUI 0.33.1 (2026-08-14, manually cancelled)
- Cancelled after 12.3 min; progress bar estimated ~2 hours total
- GPU util avg 98%, VRAM avg 15773MB, temp avg 45.1C, power avg 92.6W (max 191.9W), fan 20.2%
- nvidia dmon sampling: SM 99% / memory bandwidth 3% / power 83W - GPU stuck in inefficient state
### Comparison
| Metric | 0.30.2 normal | 0.33.1 abnormal |
|---|---|---|
| 15s video total | 26m20s | ~2h (est.) |
| Per sampling step | ~79s | 341+s |
| GPU power | 263W | 92.6W |
| GPU temp | 61.7C | 45.1C |
| Mem bandwidth | normal | 3% |
| Fan | 53% | 20.2% |
### Raw record files (attached to this issue)
- Normal (0.30.2): [run1_summary_0.30.2.txt](https://github.com/user-attachments/files/31116114/run1_summary_0.30.2.txt), [monitor_20260814_142019.csv](https://github.com/user-attachments/files/31116109/monitor_20260814_142019.csv), [monitor_20260814_142309.csv](https://github.com/user-attachments/files/31116113/monitor_20260814_142309.csv)
- Abnormal (0.33.1): [run2_partial_summary_0.33.1.txt](https://github.com/user-attachments/files/31116116/run2_partial_summary_0.33.1.txt), [monitor_20260814_145800.csv](https://github.com/user-attachments/files/31116108/monitor_20260814_145800.csv)
Contributor guide
Research direction
Start by reviewing the change from #15486, especially the `v = v.clone()` regression named in the title, and compare the H3 sampling path between v0.31.1 and v0.33.1. Reproduce with the reported 1280x736 workload and a smaller resolution, using the attached run summaries and GPU monitoring records to compare performance. Done means full-resolution generation returns near the former per-step timing without regressing the small-resolution case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, pytorch
- Domain
- backend, machine-learning, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100