Nodes/VELVET VICE — LTX/VELVET VICE LTX — Pre-Decode Memory Gate
ComfyUI Node

VELVET VICE LTX — Pre-Decode Memory Gate

Free the sampling model before the VAE decode eats the card

By Velvet-Vice·Created 25 days ago·Updated 10 days ago· 2
VELVET VICE LTX — Pre-Decode Memory Gate
  • video_latent
  • audio_latent
  • video_latent
  • audio_latent
release_sampling_modelstrue

ComfyUI's graph executes one node after another, and it's perfectly happy to hold your 22B sampling model in VRAM while the next node - a VAE decode that wants a huge chunk of the card for a full-resolution clip - starts allocating. That's how you die on the finish line. VelvetViceLTXPreDecodeMemoryGate is the "please empty your pockets before the flight" moment: it waits until both final latents are ready, then releases the tracked sampling models and GPU caches before the VAE decode runs.

What it does

Inputs are video_latent and audio_latent - the two final latents out of the LTX sampler (LTX-2/2.3 renders video and audio as separate latent streams). The node holds them, calls the pack's unload_sampling_models_before_decode() routine, and passes both latents through unchanged. Nothing about the data changes; the timing does. By the time the decode starts, the sampling model that produced those latents has been freed, which is exactly the headroom the decode needs.

There's a release_sampling_models toggle (default on). Turn it off and the node becomes a pure passthrough - useful if you're debugging memory and want to isolate whether the unload is what fixed your OOM.

Like the other lifecycle nodes in this pack, it has IS_CHANGED returning NaN, meaning it always executes on every run rather than being cached as "already done" - important for a node whose whole job is to run once per render at the right moment.

Why this matters for LTX specifically

LTX packs a lot of resident weight: a 22B diffusion model, video and audio VAEs, a Gemma text encoder. On a 24 GB card there's no room for both the sampler and a full-sequence VAE decode at once. The standard solution is offloading and patience; this node's solution is ordering - do the memory-hungry thing only after the memory-hungry thing before it has been thrown away. It's the same philosophy as the pack's interrupt cleanup and final cleanup nodes: the workflow treats VRAM as a budget to be managed at boundaries, not something you hope fits.

Inputs and outputs

  • video_latent - the LATENT out of the video sampler.
  • audio_latent - the LATENT out of the audio path.
  • release_sampling_models - boolean, default true.
  • Outputs: video_latent, audio_latent, passed through. Wire them to the VAE decode(s).

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 the pack's memory-lifecycle service (bundled) and a recent ComfyUI.

Troubleshooting

  • Still OOM after the gate - check that the gate actually runs before the decode in graph order (ComfyUI executes by dependency, so wire the latents through the gate). If the decode is downstream of the gate, the unload happened; your remaining spike is the decode itself, and that's what the FP16 VAE Decode node is for.
  • Want to see the effect? Turn release_sampling_models off for a run and watch the console peak jump - that's the node earning its keep.
  • No visible logs - the unload prints only a short line; run the pack's memory checkpoints around the decode if you want a before/after reading.

It's a ten-second-to-understand node with a real job: it's the reason the workflow can render 20-second LTX clips on cards that would otherwise OOM at the final decode.

CategoryVELVET VICE/LTX

Inputs (3)

NameTypeDefaultDescription
video_latentLATENT
audio_latentLATENT
release_sampling_modelsBOOLEANtrue

Outputs (2)

NameTypeDescription
video_latentLATENT
audio_latentLATENT