Comfy-Org / Comfy-Org/ComfyUI

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

Open
#15,663 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.