MiniMax H3 • VRAM Cache Cleanup (internal)
The post-run VRAM flush that tells you how much it clawed back
- latent
- vram_guard_state
- memory_profile_state
- block_trace_state
- latent
- 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
latentinput 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.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | LATENT | — | |
| sampler_report | STRING | — | |
| vram_guard_stateopt | H3_VRAM_GUARD_STATE | — | |
| memory_profile_stateopt | H3_MEMORY_PROFILE_STATE | — | |
| block_trace_stateopt | H3_BLOCK_MEMORY_TRACE_STATE | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| latent | LATENT | — |
| report | STRING | — |