沐阳 H3 · 段间显存屏障（内部）

This one produces nothing you'll ever look at. Its outputs are your images and audio handed straight back, and if you only ever use the pack's Director you'll never see it at all - it's a node in the expanded graph, the one that appears when a long video gets unrolled into one sampling chain per segment.

Its whole reason to exist: H3 is a 33B model with native audio, and a long video is a chain of passes where every segment wants a Ref2VA pass-2 model on top of the pass-1 model. Without a hard boundary between segments you're asking the GPU to hold the finished segment's high-resolution residency while the next segment's conditioning and sampling machinery spins up. On a 16GB or 24GB card, that's where long renders die.

What happens when it fires

Three things, in one function.

It compacts the latents. Feed it detail_latent and pass1_latent and it keeps only the last few latent steps of each - the H3 video latent is [B,C,T,H,W], and the number of steps is derived from context_length - detaches that tail to CPU, and returns it as detail_context and pass1_context. The full AV latent in the log line gets squeezed from tens of megabytes to a small CPU tail. The pack deliberately no longer truncates the incoming latent dict in place, which is a nicely instructive bug: doing so let the cache evict the finished segment's decoded pixels, re-run VAE decode on a truncated latent, and assemble a 141-frame film out of a 226+119-frame render. So the full latent stays intact and only the returned tail is compacted.

It actually frees the GPU. Prefetch queues get cleaned, cast buffers reset, a GC pass runs, and every dynamic model's GPU pages are dropped - but their host staging buffers are kept. That's the crucial distinction: a normal full unload truncates the RAM cache too, so segment two has to re-stage multi-gigabyte weights from disk and can hit a Windows WDDM residency spike doing it. It also keeps the pass-1 model you name in keep_model entirely, so you only lose the VAE, text encoder and upscaler residency you're done with.

It creates a real dependency edge. The returned h3 output goes into the next segment's prepare signal. That's the design: with the bundle flowing through, segment N+1 physically cannot start sampling before this cleanup finished. Same trick as threading a context object down a graph - one lightweight object that orders execution.

Inputs and outputs

Required: images, audio (pure pass-through) and stage, which is just a free-text label the expansion fills in for the log ("第N段 二采/高分辨率解码 -> 第N+1段 一采"). Optional, and all of it matters:

• keep_model - the pass-1 model the next segment will reuse; only its host cache survives.
• detail_latent / pass1_latent - the latents to compact.
• context_length - enum of 22, 5, 39, 56. The expansion passes the overlap it actually used, so these two numbers must agree with your long-video context setting.
• h3 - the pass-through bundle.

Outputs: images, audio, h3, detail_context, pass1_context.

One implementation detail worth knowing when you're staring at a graph that won't reuse caches: its IS_CHANGED returns NaN, so it runs every single execution, never cached. For a cleanup barrier that's exactly right, and it also means nothing behind it gets to skip.

When you'd actually touch it

Honestly, rarely - it's marked internal because the long-video expansion inserts exactly one of them between adjacent refined segments (none after the last one). The cases where it's yours:

• You're building your own expansion and want a hard segment boundary.
• You removed it from an expanded graph to save VRAM and everything got worse.
• You're feeding it latents from somewhere else and get 承接 22 帧无法从 N 个 latent step 提取 - that means context_length doesn't map exactly onto an H3 temporal phase, and the fix is picking one of the four legal values, not a round number.

Two rules from the pack that this node lives or dies by: resolution must stay constant between segments when continuity uses temporal latents, and don't stack cache nodes on top of a long chain. Turbo's built-in speed-cache mounts are disabled upstream for the same reason this barrier exists - opaque cache state and the H3 attention/memory patch chain don't compose.

Install is the same as the rest of the pack: ComfyUI Manager, or clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang into custom_nodes and restart. No extra Python packages - the pack declares none.