沐阳 H3 · 二采显存屏障（内部）

This is the barrier with the most interesting failure behind it, and the pack's source comments are worth reading if you like watching someone chase a bug that only appears on segment 2.

The setup: a long job runs pass 1 for a segment, then pass 2. In a multi-segment run the first-pass and second-pass patchers can share the same underlying dynamic weight storage. ComfyUI tracks a keep_loaded list of models it intends to keep resident - and keeping that entry through the transition preserved the pages the first pass had touched. The observable symptom was that segment 2 entered refinement with less free VRAM than segment 1 had, and it got worse from there. Pass 2 on segment 4 was dying where segment 1 was fine, for no reason visible in the graph.

The fix is the design of this node: retain the pinned host cache so weights don't have to come back off disk, but evict the GPU pages and rematerialise them on demand. That's deterministic, and it's much cheaper than the alternative it was falling back on - spilling activations into Windows' shared VRAM, which is the kind of thing that turns a slow render into an unusable one.

Inputs and outputs

• conditioning (CONDITIONING) - ready for pass 2. In and out.
• latent (LATENT) - the pass-2 latent, post-upscale. In and out.
• stage (STRING, default pass-1/VAE/upscaler -> pass-2) - the log label.
• keep_model (MODEL, optional) - the pass-2 base model. Its tooltip says keep its host cache, clear only pass-1/VAE/upscaler. And the source is careful to note that this is an ordering and host-cache hint, not a request to leave the model resident on the device. That distinction is the whole node.

Outputs: conditioning and latent, both pass-through. Wire them into the second-pass guider and sampler.

Before it evicts anything, the node waits for both pass-2 inputs to exist - hence the two required inputs being pass-throughs rather than decorations. The barrier fires when the data is ready, which is the only moment it can know what it's safe to free.

Placing this in context

It's the middle link of the pack's four-barrier chain: H3PreConditionMemoryBarrier before conditioning, H3ConditionMemoryBarrier after it, this one before pass 2, H3OutputMemoryRelease at the end. Category 沐阳 H3/内部 - in a Director or long-video graph it's already there.

The reason to read about it anyway is that this is the class of bug that makes long video feel unreliable. Nothing is wrong with your model, your prompt, or your settings. Segment 1 works, segment 4 doesn't, and the cause is that a previous stage left residency behind. If you're building your own chained second pass, the lesson generalises: explicitly clear between stages, and do it in a way that keeps host buffers, or you'll pay to re-stage a 33B model from disk every segment.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang

Restart ComfyUI, hard-refresh the browser; category 沐阳 H3/内部. The pack declares no Python dependencies, and this node only reaches into ComfyUI's model_management and model_prefetch internals - which is also a reason to keep ComfyUI reasonably current, since those are private APIs. The pack is tested against v0.33.2 and v0.34.0 structurally, and its own advice after any ComfyUI update is to validate a two-segment render before starting a long job. This barrier is a good reason to take that advice rather than skim it.

For the second pass you'll want a Ref2VA base model without a Turbo LoRA - the Director refuses a Turbo output on the 二采模型 socket. And the README's point stands: final audio comes from pass 1 and only gets seam handling and duration trimming, so a second pass changes the picture, not the sound. See upscaling for the wider two-pass picture.