MiniMax H3: malloc graph keeps its VRAM between sampling steps, so step 2 OOMs on model_output.float() with ~28 MB free

Open
  • Is something wrong?
#17,701 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python, pytorch
Domain
backend, machine-learning

Research direction

Start with comfy/ldm/minimax/model.py and trace how malloc_graph_begin() and output copying interact with cleanup_malloc_graph() in comfy/model_prefetch.py. Reproduce the reported step 2 OOM with the linked long-sequence workflow, then check whether releasing the graph after each forward is safe and whether it affects shorter runs or cards with more VRAM. Done when repeated sampling steps complete without the OOM and the graph's intended reuse behavior is addressed.

Written by the indexing model from the issue text.

Description

MiniMaxH3Model.forward (comfy/ldm/minimax/model.py) calls comfy.model_prefetch.malloc_graph_begin() around the blocks, but cleanup_malloc_graph() only runs from cleanup_prefetch_queues() when sampling ends. From step 2 on, the graph's arena keeps its physical pages after the forward returns, so the next ordinary allocation outside the graph fails. On a 12 GB card it is the 40 MB model_output.float():

  File "comfy/model_base.py", line 263, in _apply_model
    return self.model_sampling.calculate_denoised(sigma, model_output.float(), x)
torch.OutOfMemoryError: Allocation on device 0 would exceed allowed memory. (out of memory)

At that point torch.cuda.mem_get_info() reported about 28 MB free while PyTorch held under 700 MB allocated. --vram-headroom 1.5 did not change it. An aimdo DETAIL trace showed vbar_mb=0, so the memory was not model weights.

Environment: ComfyUI v0.45.0 (code also checked unchanged on master b2f6707443), comfy-aimdo 0.6.0, comfy-kitchen 0.2.41, PyTorch 2.15.0+cu132, RTX 3060 12 GB, Linux, Dynamic VRAM on (default). Workflow: the official video_fastvideo_fasth3_t2v / i2v / video_fasth3_ominiref_r2v templates with length 362 (15 s) at 1344x768, about 109k video tokens. Reproduced three times at the end of step 2's forward with the T2V template (after working around the RoPE cache issue, #17700).

Fix direction. The forward's outputs are copied into tensors allocated outside the graph (out[0].copy_(graph_out[0])), so releasing the graph after each forward is safe; the next step records a new one, as step 1 does. Locally this wrapper fixed it, and step time went from about 130 s to 117 s:

def forward(self, x, *args, **kwargs):
    out = original_forward(self, x, *args, **kwargs)
    if long_sequence(x) and comfy.model_prefetch.malloc_graph_recording():
        comfy.model_prefetch.cleanup_malloc_graph()
    return out

I gated it on 50k+ video tokens to leave short runs alone. A maintainer should decide whether keeping the graph across steps is meant to save re-recording time, and if so, whether the arena can return its pages between forwards instead. Not verified: behaviour on cards with more VRAM, where the graph may fit and reuse may be faster.

Filed by Claude Opus 5.5 in Claude Code.

Dominant language
Python
Stars
146k
Forks
17.4k
Avg merge
19h 44m
Merged PRs (30d)
178

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Comfy-Org/ComfyUI

All issues in Comfy-Org/ComfyUI

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.