Nodes/ComfyUI-MiniMax-H3-LongMedia/MiniMax H3 • VRAM Cache Cleanup (internal)
ComfyUI Node

MiniMax H3 • VRAM Cache Cleanup (internal)

The post-run VRAM flush that tells you how much it clawed back

By vizart-vj·Created 14 days ago·Updated 2 days ago· 71
MiniMax H3 • VRAM Cache Cleanup (internal)
  • latent
  • vram_guard_state
  • memory_profile_state
  • block_trace_state
  • latent
  • report
sampler_report

Long H3 runs fragment the CUDA cache like nothing else. After a 15-second multi-segment generation, ComfyUI can be holding hundreds of MB of reserved-but-unused blocks, and the next run starts from a worse position than it needs to. MiniMaxH3LatentLabVRAMCacheCleanup is the pack's internal cleanup crew: it waits for sampling to finish, snapshots CUDA memory, soft-empties the cache, snapshots again, and reports exactly what it released.

The node is a passthrough with a side effect, and the side effect is the point. In: latent (LATENT), sampler_report (STRING - the runtime report from the sampler), and optionally vram_guard_state, memory_profile_state, and block_trace_state (the pack's custom diagnostic state objects). Out: the same latent, plus report - the sampler report with a post_sampling_vram_cleanup block appended.

What the report tells you

The appended block includes allocated/reserved/cached memory before and after the flush, plus released_reserved_mb and released_cached_mb. That's the honest number: how many megabytes of reserved VRAM this run was leaving on the table. If your long runs are creeping toward OOM run after run, this report is where you see the leak surface - a big cached_before_mb means you were carrying a ballooning cache into the next pass.

The optional state inputs fold in even more diagnostics if you've been running the VRAM Pressure Guard and memory profiling: first-step memory profile, OOM counters, per-block memory traces. Wire them all and the report becomes a proper post-mortem document for a failed run.

Do you need to touch it?

Almost certainly not, and the name gives it away - "(internal)". This node is placed by the LongMedia runtime (and shows up in saved workflows) after sampling, and its job is housekeeping plus telemetry. The beginner-friendly move is to leave it where the workflow puts it and use its report output as the answer to "how much VRAM did that actually need." If you're building your own hand-rolled continuation chain, keeping it at the end of the chain is a genuinely good habit.

Install

One pack, no extra deps:

cd ComfyUI/custom_nodes
git clone https://github.com/vizart-vj/ComfyUI-MiniMax-H3-LongMedia

Restart ComfyUI, or ComfyUI Manager → "MiniMax H3 LongMedia".

Gotchas

  • It only does real work when CUDA is available - on a CPU-only machine it just passes the latent and report through.
  • It needs the latent input to be connected, and that's deliberate: the dependency guarantees the sampler actually finished before the cache flush runs.
  • Pack-wide caveat, as ever: the H3 weights are excluded from the US, EU, UK and South Korea under the community license.

Boring, automatic, and quietly essential. When a 30-second H3 run used to choke and now it doesn't, part of the answer is this node sweeping up after itself.

CategoryMiniMax H3/LongMedia/LongMedia

Inputs (5)

NameTypeDefaultDescription
latentLATENT
sampler_reportSTRING
vram_guard_stateoptH3_VRAM_GUARD_STATE
memory_profile_stateoptH3_MEMORY_PROFILE_STATE
block_trace_stateoptH3_BLOCK_MEMORY_TRACE_STATE

Outputs (2)

NameTypeDescription
latentLATENT
reportSTRING