MiniMaxH3LatentLabBlockMemoryTracer

When a 33B video model OOMs, the stock error message tells you almost nothing. "CUDA out of memory" doesn't say which layer blew up, how close you were to fitting, or whether the peak was in attention, the MLP, or the final projection. This node exists to answer that question: it's an internal first-forward VRAM tracer that wraps the guider and instruments H3's transformer blocks, one at a time, so you can see where the memory actually went.

How it works

Give it a guider and a max_blocks count (default 128) and it returns a wrapped guider plus a block_trace_state. The mechanism is neat: it registers per-block patches into patches_replace['dit'] for the first N double-blocks. On the first forward pass, each patch records the CUDA allocator's allocated and reserved memory before and after that block runs - the peak, the worst block, the worst stage, and if you crash, the OOM snapshot including which block you died in.

That's the important part: the trace is captured on the first forward pass, which is where the peak almost always happens. The max_blocks input is just the ceiling for how many blocks get instrumented (H3's stack is 50 blocks, so 128 covers it with room to spare). It skips blocks that already have a patch installed rather than clobbering them, and notes the skips in the state.

Outputs

• guider - pass it on to your sampler. The tracing runs invisibly during sampling.
• block_trace_state (H3_BLOCK_MEMORY_TRACE_STATE) - the payload. It carries worst_block, worst_block_peak_allocated_mb, the allocator backend, whether the first forward finished or OOMed, and oom_block / oom_message when things went sideways.

You'll mostly read this state through the console or by feeding it forward - the sibling First-Step Memory Profiler takes an optional block_trace_state on its input, so these two are designed to work as a chain.

When you'd bother

Honestly? Rarely. This is a diagnostics node hiding in the "internal" tier, and the display name is just the raw class name with no friendly label. You pull it out in two situations: you're tuning a long-sequence run and want to know whether the 24 GB that freed up came from attention chunking or MLP chunking, or you're trying to squeeze one more second of video out of a card that OOMs at a specific spot. The trace turns that trial-and-error into a number.

Install

Part of ComfyUI-MiniMax-H3-LongMedia - Manager search "MiniMax-H3-LongMedia", or:

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

restart, and have the H3 weights (checkpoint + video and audio VAEs) on hand. Same license caveat as everything H3: the community license geofences out the US, EU, UK and Korea.

Troubleshooting

If the trace state comes back with fallback_reason set, the patches didn't install cleanly - usually because another custom node already owns the dit patch slots it wanted. The tracer is cooperative, so an existing patch from a LoRA or memory pack wins. And if you're seeing oom_block: null after an OOM, the crash happened outside a traced block (often in the VAE or conditioning), which is still useful - it rules out the transformer stack as the culprit. For production runs, remember the pack's real advice: keep Dynamic VRAM on, don't launch with --disable-dynamic-vram, and let the Long Media Sampler's auto memory profile do the tuning - this tracer is for the days you need to understand, not guess.