LingBot VAE Decode

Every video generation ends the same way: you've got a latent tensor that is technically a video but looks like noise, and you need pixels. LingBotVAEDecode is the pack's bridge between the two - it takes the LINGBOT_LATENTS from any LingBot sampler and the LINGBOT_MODEL handle, runs the model's VAE decoder over the whole clip, and hands back frames as a normal IMAGE tensor you can preview, save, or post-process.

If you've used ComfyUI's stock VAE Decode, the shape of this is familiar - but note it's not interchangeable with it. This node takes the pack's custom latent type and the model handle (not a separate VAE loader node), because the pack loads the LingBot VAE itself and keeps it resident on the GPU. There is no standalone "LingBot VAE Loader"; the VAE rides along inside the model handle from LingBotModelLoader. So the wiring is always: Model Loader → Sampler → this node, all sharing the same model handle.

What comes out

frames is an IMAGE tensor shaped [T, H, W, 3] - one frame per video time step, in normal RGB float space clamped to 0–1. The node verifies it decoded a single video (batch size 1) and that the shape is sane before handing it on. From there it's standard ComfyUI territory: wire frames into a VideoHelperSuite VHS_VideoCombine for an MP4, into a preview node, or into the pack's optional post-processing branches (RIFE interpolation, FlashVSR upscaling - controlled by LingBotPostProcessSettings and selected by LingBotLazyImageSwitch).

Decode is the pack's "Stage 4/5" in the workflow progress narration, and it reports the frame count when done ("Complete · 61 frames ready"), which doubles as a sanity check that your 4n+1 math was right.

How it works (and why it cares about VRAM)

The decode uses the VAE the loader parked on the GPU (AutoencoderKLWan from the model directory, kept in bf16) and calls the pipeline's _decode_latents routine. The one thing that bites people: the VAE must still be on CUDA when this runs. The pack's whole memory design rotates the transformer and Qwen through a small card, but the VAE is deliberately kept GPU-resident the entire time. If something evicted it - a too-aggressive --lowvram setup, another custom node grabbing VRAM, a manual cache clear mid-graph - you'll get the explicit "LingBot VAE is on CPU at decode time" error, because a bf16 VAE decode off the GPU would be both slow and wrong. The fix is usually to not fight the pack's memory model: it's tuned for 16 GB.

Install

Ships with the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/ALX-CODE/lingbot-video-1.3b-fp8
pip install -r requirements.txt   # with ComfyUI's python

or ComfyUI Manager → search "LingBot" → restart. It needs the model's vae folder present in the model directory (part of the robbyant/lingbot-video-dense-1.3b download) and a successful model load. For actual MP4 output you'll also want ComfyUI-VideoHelperSuite installed - the published workflows require it, and without it your frames are stuck as a latent preview.

Gotchas

• "Expected one LingBot video, got batch size N" - you decoded something that isn't a single-clip latent batch. Recheck what you wired in; this node handles one video at a time.
• Frames come out in RGB 0–1; if you're compositing with nodes that expect something else (e.g. a particular preview format), do the conversion downstream rather than patching this node.
• Decode happens on GPU, so it's a VRAM spike after sampling - if you're right at the edge, that's normal and usually fine because the transformer has already been moved back to CPU by the sampler's finally block.
• If your output looks washed or wrong, it's almost never this node - it's faithfully decoding what the sampler produced. Check the prompt side (LingBotPromptPreview) and your CFG/shift first.