VELVET VICE LTX — Prompt-First Model Gate

The worst-case ComfyUI scheduling scenario is two big models competing for the same VRAM. The Velvet Vice LTX workflow has exactly that problem built in: its non-manual prompt modes load an LLM through Ollama on the same machine that must then hold a 22B LTX model, two VAEs, and a text encoder. VelvetViceLTXLazyModelGate is the discipline that makes that workable - it enforces prompt-first execution, keeping the LTX render inputs lazy until the prompt has been generated, released, and verified.

How it works

The node takes six inputs: prompt plus model, clip, audio_vae, custom_width, and custom_height. The trick is in the schema - the five render inputs are declared lazy, so ComfyUI doesn't resolve them (and doesn't load the models behind them) until the gate says go.

It works in two phases. ComfyUI first calls check_lazy_status, which reports which of those inputs are still None. While they're unresolved - i.e., while the prompt pipeline and Ollama are still doing their job - it starts the pack's render memory monitor (using the optional memory_policy for sampling interval and warning thresholds) and logs a snapshot, so the system knows the render session is live but not yet at full weight. Only when the prompt is final and the LLM has been released does the gate call release_render_inputs, which passes everything through and prints "Prompt-first gate completed. LTX render inputs may load now."

The result: the 22B model isn't sitting in VRAM while Ollama is still rewriting your prompt. The KB's LLM-in-ComfyUI material calls this the core principle of good multi-model nodes - "automatic unload/reload rather than holding both resident" - and this gate is exactly that, expressed as graph ordering.

Inputs and outputs

• prompt - the final prompt STRING (from the Ollama Release Barrier / Prompt Director).
• model, clip, audio_vae - the LTX render inputs, lazy.
• custom_width, custom_height - render dimensions, lazy too (so they can be decided by the prompt pipeline's duration/geometry planning).
• memory_policy (optional) - a VELVET_VICE_MEMORY_POLICY object from elsewhere in the pack, controlling monitor interval and RAM warning/critical percentages.
• Outputs: all six inputs passed through unchanged - prompt, model, clip, audio_vae, custom_width, custom_height.

Where it sits

In the graph, the model/CLIP/VAE loaders feed their outputs into this gate, and the gate feeds the sampler. The prompt path (Director → Release Barrier → Final Prompt Preview) feeds the prompt input. Wire it that way and the dependency graph itself enforces the ordering - ComfyUI physically cannot load the heavy models until the prompt is ready, because they're behind a lazy gate.

Installing it

Part of VELVET VICE - LTX (velvet-vice-ltx) via ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Velvet-Vice/velvet-vice-ltx

Restart and hard-refresh with Ctrl+F5. No pip deps. It needs a ComfyUI that supports lazy inputs - if the node complains or behaves like a normal passthrough, update ComfyUI.

Troubleshooting

• The gate doesn't seem to delay anything - check that the heavy inputs actually feed through the gate (not around it) and that your ComfyUI supports lazy inputs.
• "monitor started" then no report - the monitor only produces its summary when stopped by a cleanup node. Wire a final cleanup after the encode to collect it.
• Render inputs load anyway - a direct wire from a loader to the sampler bypasses the gate; the lazy mechanism only helps if the gate is on the path.

It's invisible plumbing - you'll never think about it when it works - but it's the difference between a workflow that fits on a 24 GB card and one that OOMs before sampling starts.