💾 CUDA Zero-Copy Latent Store

ZeroCopyLatentStore is the short name for CineFluxZeroCopyLatentStore - the pack registers both keys against the same class, one with the author's CineFlux namespace and one as a "clean non-namespaced alias for general community usage." Same two inputs, same one output, same entry under latent/cineflux (listed twice; it's the same node, grab either).

It's a passthrough. samples in, samples out, unchanged; the reason it exists is that on the way through it keeps a reference to that latent in a buffer that outlives the prompt run.

Why you'd want that

Long clips in ComfyUI are made by chaining, and the usual chain is lossy: decode clip 1, take the last frame, feed it to the next I2V pass. That's the workflow people have been using to squeeze 30 seconds out of 5-second models since Wan 2.1 - and it's the one that accumulates softness and colour drift over a dozen cuts, because every step goes latent → pixels → latent again.

This node is a piece of the fix. It parks the previous shot's final latent in GPU memory, so a ZeroCopyLatentHandoff node in the next shot can pull the exact ending latent and use it as the opening keyframe with no VAE anywhere in the loop. Whether that's a big win for you depends on how many cuts you're doing: at two shots you'll barely notice, at twenty you'll notice.

Inputs, output, and the one string that matters

buffer_tag is the whole API surface a beginner needs. It defaults to shot_continuity on both this node and the hand-off node, so leaving both alone means they match. Change one, change the other. A mismatch is completely silent - the hand-off logs nothing, finds an empty slot, and falls back to encoding your still image like a normal keyframe.

The trade-off of tagging: the buffer is a dict keyed by that string, so the same tag on a fresh run replaces what was there. That's usually what you want (a sequence marching forward), but it also means there's no history - you can't hand off from shot 3 after you've rendered shot 6 with the same tag. Different sequences want different tags.

Output is samples, a LATENT to feed your decode node. Nothing downstream changes: KSampler → 💾 Latent Store → VAEDecode.

Install

Manager → ComfyUI-ZeroCopy-Continuity → install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/latentforge-dev/ComfyUI-ZeroCopy-Continuity

That's the whole install: no downloaded models, no pip packages past the torch ComfyUI already ships. The README's git clone line uses a stale latentforge/ org - latentforge-dev/ is the real one.

The things that bite

One prompt at a time. ComfyUI's scheduler doesn't know your two shots are related; the hand-off node has no edge back to the store, so queuing both at once runs them in whatever order the graph resolves and the second one cold-starts. Render shot 1, then shot 2.

Restart wipes it. The buffer is a singleton in the ComfyUI server process, nothing more. Restart the server or reload custom nodes and your continuity state is gone - that's also the only way to clear it, since no node calls the buffer's clear() method.

It holds VRAM for the session. The stored latent is a detached reference, not a copy, so it's cheap - but it stays allocated, and repeated runs with many tags accumulate. If a long session gets tighter on VRAM than a fresh start, this is a suspect.

Video latents only, in practice. A 4D image latent stores fine and reads back as nothing: the hand-off requires a 5-dimensional video tensor and quietly falls back otherwise.

Check the console once. Failures inside the store are caught and logged rather than raised - your graph keeps rendering, so the only signal that nothing got stored is a log line.