MiniMax H3: VRAM budget underestimated for short clips; the resulting OOM then persists for that exact graph across restarts but not slightly changing the workflow
- Dominant language
- Python
- Stars
- 133k
- Forks
- 15.7k
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 158
Description
Core-node MiniMax H3 workflow only (UNETLoader / CLIPLoader / MiniMaxH3ReferenceToVideo /
SamplerCustomAdvanced), no custom nodes involved in the failure.
## 1. The estimate is too optimistic for short clips
buffer reserved, same workflow, only duration changed:
2s -> 514 MB reserved -> 16257 MB weights kept resident, 3739 MB offloaded
6s -> 1258 MB reserved -> 0 MB resident, 11957 MB offloaded
10s -> 1323 MB reserved -> 0 MB resident, 19996 MB offloaded
At 2s the estimate of 514 MB leads ComfyUI to keep 16 GB of weights on the card.
Actual peak then far exceeds the estimate:
Allocated peak : 23339 MiB
GPU reserved peak : 28928 MiB (RTX 4090, 24564 MiB)
i.e. reserved peak exceeds the physical card. At 10s or more the larger estimate leads to
full offload - slow, but stable. So the failure is strongly duration-dependent: short
clips fail, at 10s instead this OOM never occurs - overnight batches of 12+ clips complete without it.
It appears only when generating very short clips (1-2s), where the estimate is smallest.
## 2. Once it fails, it keeps failing for that graph
After the first OOM, every subsequent run of the same workflow OOMs at the same point.
No effect: restarting ComfyUI, rebooting the machine, --cache-none, --reserve-vram,
UnloadAllModels / ClearCache nodes (VRAMdebug confirms 24 GB free before the model loads),
select-all + cut + paste of the whole graph.
What does restore correct behaviour, immediately and reliably:
- inserting any unrelated node (e.g. ShowAny) anywhere in the graph
- changing any parameter on any node
Reverting either change brings the failure straight back, with the same duration setting.
We suspect the (incorrect) budget decision is cached under a key derived from graph
structure + node parameter values, since that is exactly the set of changes that clears
it - and it survives a process restart, which a purely in-memory cache should not.
We have not looked at the code, so this is only an observation of the behaviour.
## Environment
ComfyUI 0.33.0, Windows 11, python 3.13.12, torch 2.13.0+cu130, NVIDIA driver 610.88
RTX 4090 (24 GB) + RTX 3090, flags: --disable-dynamic-vram
minimax_h3_fl2va_pruned_int8_convrot + 8-step turbo LoRA + video VAE fp16
Full logs for a failing and a passing run attached:
[fail.txt](https://github.com/user-attachments/files/31113064/fail.txt)
[success.txt](https://github.com/user-attachments/files/31113065/success.txt)
Contributor guide
Research direction
Start by comparing the attached fail.txt and success.txt logs and reproducing the Core-node MiniMax H3 workflow with the stated duration changes. Trace the VRAM budget decision and any graph- or parameter-based persistence implicated by the report. Done means short clips no longer exceed the RTX 4090 budget or retain a failing result for the unchanged graph, while the reported longer-clip behavior remains stable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python, pytorch
- Domain
- ai, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100