Nodes/ComfyUI-MiniMax-H3-LongMedia/MiniMax H3 • First-Step Memory Profiler (internal)
ComfyUI Node

MiniMax H3 • First-Step Memory Profiler (internal)

See exactly what your first denoise step costs in VRAM

By vizart-vj·Created 14 days ago·Updated 2 days ago· 71
MiniMax H3 • First-Step Memory Profiler (internal)
  • sampler
  • block_trace_state
  • sampler
  • profile_state
max_history_entries20000

Long-form H3 generation is a memory puzzle, and the most useful single fact about any run is how the first denoise step behaves. That's when the model layers are all resident and the packed sequence is at its noisiest - the peak. If the run is going to OOM, it usually OOMs there. This internal node is a SAMPLER wrapper that snapshots the CUDA allocator before, during and after that first step, so you can see the peak in megabytes instead of fighting a vague "out of memory" traceback.

How it works

Give it a sampler (any SAMPLER object) and it hands back a wrapped sampler plus a profile_state. The wrapper intercepts the sampler's sample() call, records allocator state before anything runs, then captures per-step snapshots - with special attention to the first step. If a step OOMs, it grabs an OOM snapshot (counters, which block, the memory picture at the moment of death) and records it in the state instead of losing it.

Inputs worth knowing:

  • max_history_entries (default 20000) - how many allocator history entries the profiler keeps. Lower it on constrained machines if the profiler itself feels heavy.
  • block_trace_state (optional) - wire the output of the Block Memory Tracer in here and the two reports get correlated: the profiler tells you the step-level peak, the tracer tells you which transformer block caused it.

Outputs

  • sampler - the wrapped sampler. Feed this into your sampling graph as normal.
  • profile_state (H3_MEMORY_PROFILE_STATE) - the report card: first_step_snapshot, steps history, oom flag, oom_counters, and oom_snapshot with the OOM's oom_message. Read the JSON and you'll know whether you died in block 34 of step 1 or in the VAE decode.

When to use it

This is squarely a "something's wrong and I need numbers" node, not a production-workflow node - note the "(internal)" in its display name and the fact that ComfyUI hides it from the normal node menu. Reach for it when a 15-second pass OOMs at a weird spot, when you're comparing whether attention chunking or MLP chunking bought you more headroom, or when you're A/B testing memory_mode settings and want proof one of them actually cut the peak.

Install

Ships in 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, plus the H3 checkpoint and its two VAEs from MiniMaxAI/MiniMax-H3 (and remember the community license excludes the US, EU, UK and Korea).

Troubleshooting

If first_step_snapshot is null, the profiler never saw a completed first step - the crash happened before sampling, usually during model load or conditioning, which is itself a finding. If the run doesn't OOM but you still want the peak, the profiler still records it, so you can read off the headroom before pushing longer. One honest warning: this node is for diagnosis, not daily use. The pack's production answer is sampler_mode=auto, Dynamic VRAM left on, and fixed segmentation sized to your card (roughly 7–10 s on 16 GB, 5–8 s on 12 GB, 4–6 s on 8 GB). Profiling is how you learn your card's real ceiling; the auto path is how you stay under it.

CategoryMiniMax H3/LongMedia/LongMedia

Inputs (3)

NameTypeDefaultDescription
samplerSAMPLER
max_history_entriesINT200001000–200000
block_trace_stateoptH3_BLOCK_MEMORY_TRACE_STATE

Outputs (2)

NameTypeDescription
samplerSAMPLER
profile_stateH3_MEMORY_PROFILE_STATE