VELVET VICE LTX — FP16 Full VAE Decode

The most frustrating OOM in video generation happens at the very end. You survived the 22B model, you survived sampling, and then the VAE decode of the full temporal sequence tries to allocate one giant image buffer and the machine folds. VelvetViceLTXFP16VAEDecode attacks exactly that: it runs a full, non-tiled VAE decode, but asks ComfyUI to allocate the decoded image buffer directly as FP16 - half the bytes, same math.

How it works

The mechanism is a surgical override. ComfyUI's VAE class has a method vae_output_dtype() that decides the dtype of the decoded output. This node temporarily binds that method on your VAE instance to return torch.float16, calls vae.decode(latent), then restores the original. The decode itself is untouched - same VAE compute dtype, same temporal context, same frame order, same motion. Only the output buffer is FP16.

It also handles the edge cases: nested latent lists get unbound, and a 5D decoded tensor gets reshaped to [frames, height, width, channels] so it flows cleanly into image nodes.

Here's the part that surprises people: if ComfyUI doesn't expose vae_output_dtype(), the node raises a hard error instead of falling back. That's deliberate. Converting the decoded clip to FP16 after the fact would recreate the exact RAM peak this node exists to prevent - a silent FP32 decode followed by a downcast is the bug, not the fix. The error message tells you to update ComfyUI, and that's the right move.

Inputs and outputs

• samples - the LATENT from the sampler.
• vae - the video VAE.
• Output: image, the decoded FP16 frame batch.

Where it sits in the workflow

The Velvet Vice LTX pipeline is built to keep everything half-precision through the back end: FP16 decode → FP16 chunked scale → encode. That chain is exactly why the FP16 decode matters - if you popped a stock VAEDecode in there, the workflow would suddenly allocate a full FP32 clip, and the pack's careful memory budget (pre-decode gate, memory checkpoints, cleanup) would be working against a self-inflicted spike.

Installing it

Ships in VELVET VICE - LTX (velvet-vice-ltx) - 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. But it needs a recent-enough ComfyUI that VAE.vae_output_dtype() exists - the node will tell you if you're behind.

Troubleshooting

• "This ComfyUI build does not expose VAE.vae_output_dtype()" - update ComfyUI. That's not an optional suggestion; there's no fallback path by design.
• "ComfyUI returned a non-FP16 VAE output" - same category; update ComfyUI and rerun. The node refuses to downcast for you.
• Still OOM after decode - the decode is now half the size, but the latent and everything upstream still occupy VRAM. Make sure the Pre-Decode Memory Gate (or the cleanup node) ran before the decode.

One honest note: FP16 output can occasionally show tiny rounding differences versus FP32 on fine gradients. In practice, for video decode this is invisible - and it's a much better trade than the alternative, which is not rendering at all.