MiniMax H3 • First-Step Memory Profiler (internal)
See exactly what your first denoise step costs in VRAM
- sampler
- block_trace_state
- sampler
- profile_state
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,stepshistory,oomflag,oom_counters, andoom_snapshotwith the OOM'soom_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.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| sampler | SAMPLER | — | |
| max_history_entries | INT | 200001000–200000 | — |
| block_trace_stateopt | H3_BLOCK_MEMORY_TRACE_STATE | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| sampler | SAMPLER | — |
| profile_state | H3_MEMORY_PROFILE_STATE | — |