Pipeline Memory Barrier

PipelineMemoryBarrier exists for one very specific pain: the workflow that OOM-kills your process at the start of a new stage, even though the previous model was already offloaded. You know the one - you're running a two-pass WanVideo generation, pass one finishes, pass two loads, and ComfyUI dies before it draws a single frame. This node is a barrier you drop into the graph that forces the CUDA allocator to actually give memory back before the next stage starts.

The name is doing real work here. It's a synchronization point, not a memory saver. You wire a LATENT through it, get the exact same LATENT back, and somewhere in between the node calls ComfyUI's soft_empty_cache(force=True), Python's gc.collect(), and torch.cuda.empty_cache() plus torch.cuda.synchronize() on every visible GPU.

Why does that matter? Because PyTorch's CUDA allocator is lazy in the annoying direction: when a model gets offloaded, the freed blocks don't return to the OS right away - they sit in the allocator's internal cache. So your system reports low free RAM even though the memory is technically free. In long multi-stage pipelines, especially two-pass I2V with ComfyUI-MultiGPU in the mix, that cache is what tips the next stage over into an OOM kill. This node forces the flush that ComfyUI's own offloading sometimes doesn't get around to.

What makes it useful is what it doesn't do: it doesn't unload any model ComfyUI is still tracking, and it doesn't touch your latents. It costs essentially zero compute time. You can drop it anywhere it's harmless.

The inputs that matter

There are only two, and you'll barely touch either:

• latent (LATENT, required) - passed through unchanged. Wire the first pass's sampler output here, then take the output into your second pass sampler. Same trick before VAE decode, so the decoder starts clean.
• log_memory (bool, default true) - when on, it prints GPU allocated/reserved and system RAM before and after the flush to the console. Genuinely handy for confirming the flush worked (you'll see allocated drop to ~0 and RAM go from 66% to 18%). Flip it off for production runs so your console isn't spammed every single step batch.

Placement in a two-pass workflow

[Pass 1 Sampler] → [Pipeline Memory Barrier] → [Pass 2 Sampler]
[Pass 2 Sampler] → [Pipeline Memory Barrier] → [VAE Decode]

Installing it

The easy way: ComfyUI Manager → search Pipeline Memory Barrier → install. Manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/brosequist/ComfyUI-PipelineBarrier

Then restart ComfyUI. That's the whole install - there are no pip dependencies beyond what ComfyUI already ships (psutil is in the base environment).

Where people get burned

The trap is expecting it to fix actual memory pressure. This node reclaims cache, not model memory. If your second stage OOMs because the workflow genuinely needs more VRAM than you have, a flush isn't the fix - that's what offloading, GGUF quantization, and the Wan two-pass low-VRAM workflows are for. The barrier only rescues you when the memory was freed and the allocator just wouldn't admit it.

Also worth knowing: it's a LATENT-only node in practice, even though the pack's Manager listing vaguely claims any wire type. Keep it on the latent path and it does what it says. If you're not hitting OOMs between stages, you don't need it - and you'll know you don't, because this is the rare utility node that's easy to justify deleting from a workflow without breaking anything.