DiffusionGemma Advertisement Memory Barrier

DiffusionGemmaAdvertisementMemoryBarrier is the node you slot between two expensive stages when the second one would otherwise OOM - and it's notable mostly for what it deliberately isn't. It isn't a third-party cleanup pack with its own dependency tree. It's a single, self-contained pass-through that calls ComfyUI's own model-management functions to release loaded models and clear VRAM before the next high-memory stage of an advertisement render. The pack ships it so the governed ad workflow gets a memory boundary without inheriting someone else's cleanup-node pack.

Here's the whole mechanism. You feed it value - a wildcard * socket, so it accepts anything: an image batch, a conditioning object, whatever needs to survive the boundary - and it hands that same value back out of value untouched. What changes is what happens between in and out, controlled by the policy enum. The default, "Unload models + clear CUDA cache", calls ComfyUI's unload_all_models(), does a soft cache empty plus garbage collection, then a hard torch.cuda.empty_cache() if CUDA is present. "Unload models + soft cache" skips the hard CUDA flush. "Passthrough (no release)" does literally nothing except return your value. Every path also emits memory_status, a STRING that tells you what actually got released - the pack wants the cleanup to be observable, not assumed.

Where this lives in the wider graph makes the "why" click. The advertisement workflow chains MiniMax Music 3 (soundtrack generation), the DiffusionGemma Director (the LLM that authors the prompt), and MiniMax H3 (the video model) in sequence. Each of those stages wants a lot of VRAM, and ComfyUI doesn't always unload a model the moment its branch is done. A memory barrier between stages is the standard fix - the difference here is that this pack built its own rather than depending on the usual community cleanup nodes, which keeps the whole 22-node advertisement surface self-contained. In practice the README records the runtime-proven result: two 15-second H3 lanes plus Music 3 and finishing executed end to end, and the barrier is part of why that fit.

The only real control that matters to you is policy, and the honest advice is: leave it on the default unless you have a reason. "Passthrough" is there for diagnosis - run once with it to confirm a hang or OOM is genuinely memory-related rather than a bug in your graph. If you're seeing CUDA out-of-memory errors at the transition into H3 sampling and this node is sitting in the graph, the first thing to check is that its policy didn't get switched off somewhere.

Install is the pack install, nothing extra: ComfyUI Manager search "DiffusionGemma Prompt Builder", or git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder into custom_nodes and restart. One gotcha that surprises people about the full ad workflow rather than this node: it wants ComfyUI 0.33.1+, and the DiffusionGemma Director plus H3 models are heavy local downloads - this node is cheap, the graph around it is not. And because it passes your value through unchanged, don't expect it to fix a graph that's already over budget at a single stage; it's a boundary tool, not a memory shrinker.