⚡ CUDA Zero-Copy VRAM Pin (Anti-Eviction)

If you're chaining shots with a big diffusion transformer - a 14B Wan, HunyuanVideo, or something in the MiniMax H3 weight class - you've already met the tax. ComfyUI's memory manager decides it needs VRAM for the VAE decode, unloads your model to system RAM, and the next shot starts by dragging 15–20GB back across the PCIe bus. The community consensus on why that hurts is blunt: GPU bandwidth is roughly 11x the PCIe bus, so shuffling memory back and forth "is so huge that it makes it usually not worth it."

CineFluxZeroCopyVRAMPin is one pack's answer to that: mark a model patcher as non-evictable, and ComfyUI stops asking it to leave.

How it actually works

Two things happen, and neither of them moves a single weight onto your GPU. The node assumes ComfyUI already put the model where it belongs; it just refuses to let it go.

First, enable_pinning sets a _is_zero_copy_pinned attribute on the model patcher you pass in (and on the underlying root model, so clones of the patcher inherit the flag). Second, the pack installs a monkeypatch over ComfyUI's LoadedModel.model_unload - ComfyUI's own eviction call - and that patched version returns early for anything carrying the flag. Eviction request comes in, gets swallowed, weights stay resident.

Third, tune_allocator sets PyTorch's caching allocator to expandable_segments: True, which lets segments grow virtually instead of being freed and re-requested. That's aimed at the fragmentation you get after a few dozen shot changes, not at model size - it will not make a model that doesn't fit suddenly fit.

One detail worth knowing before you wire anything: the manager is a module-level singleton, so the allocator tweak and the eviction hook are installed the moment ComfyUI imports the pack. The node's booleans just re-apply them. Look for Installed ComfyUI LoadedModel anti-eviction hook in the console at startup - that line is your proof it's live.

The inputs, and the one output

• model - the MODEL from your loader (or a LoRA chain, whatever your sampler is consuming).
• enable_pinning (default on) - the flag. Turn it off and the node actively clears the flag instead, which is how you unpin.
• tune_allocator (default on) - the expandable_segments call. Harmless, but if you want to isolate whether a memory change helped or hurt, this is the knob to flip.

There's exactly one output, model, and it goes straight into your KSampler (or SamplerCustomAdvanced) model input. It's a passthrough with a side effect, so the graph shape is boring on purpose: UNETLoader → ⚡ VRAM Pin → KSampler.

Install

ComfyUI Manager → search ComfyUI-ZeroCopy-Continuity → install → restart. Or:

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

No model downloads, no extra pip packages - pyproject.toml declares only torch>=2.1.0, which you already have. Note the README's git URL says latentforge/ while the actual repo is latentforge-dev/; use the one above or you'll get a 404.

Where people get burned

Pinning a model that barely fits converts a slow success into an instant OOM. This is the big one. ComfyUI's normal behaviour - unload, squeeze, reload - is annoying but it finishes. A pinned model ignores the unload, so the OOM lands in the VAE decode instead. On a 16GB card with an 18GB fp8 DiT, leave this node out.

You may already own this feature. ComfyUI ships --disable-smart-memory (and --highvram), which is the supported way to stop aggressive unloading; the flag shows up in troubleshooting threads constantly for exactly this class of problem. If you already launch with it, the pin is mostly buying you the allocator tuning, and you should A/B before crediting the node.

The patch rides on ComfyUI internals. It hooks a comfy.model_management class that ComfyUI is free to rearrange. The pack's install is wrapped in a try/except that logs a warning and carries on, so after a ComfyUI update the failure mode is silence: the node still runs, nothing is pinned. No startup log line, no pinning.

The README's benchmark table is one machine. It's a single RTX 5090 / Ryzen 9950X run, not a spec sheet - the mechanism (no unload, no reload) is real, but treat "35.5× faster" as that author's homelab number and time your own first two shots.

And yes, you'll find this node listed twice in the menu under sampling/sol_engine. The CineFlux-prefixed class and a clean ZeroCopyVRAMPin alias map to the same object - either works, same behaviour. More on that in the alias article.