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

First, the thing that's probably confusing you: after installing this pack, ⚡ CUDA Zero-Copy VRAM Pin (Anti-Eviction) shows up twice in the add-node menu, both under sampling/sol_engine, both with the same name and the same ports. Nothing is broken. The pack registers the same class under two keys:

NODE_CLASS_MAPPINGS = {
    "CineFluxZeroCopyVRAMPin": CineFluxZeroCopyVRAMPin,
    "ZeroCopyVRAMPin": CineFluxZeroCopyVRAMPin,   # same object
}

ZeroCopyVRAMPin is the "clean non-namespaced alias for general community usage," per the source comment. The CineFlux-prefixed name is the one the author's own CineFlux/Sol-Engine pipeline uses. Grab either - identical behaviour, identical inputs. The only real difference is what gets written into your workflow JSON, and the pack's own example file uses ZeroCopyVRAMPin.

What the node does

ComfyUI evicts models to host RAM when it needs room - typically so the VAE decoder can allocate. For a 20GB-class DiT in a multi-shot pipeline that means a full reload over PCIe at the start of every shot, and GPU-to-CPU shuffling is exactly the "not worth it" slowdown everyone complains about in VRAM threads. This node makes the model refuse to leave.

enable_pinning flags the model patcher, and the pack patches ComfyUI's LoadedModel.model_unload to ignore unload requests for anything flagged. tune_allocator sets PyTorch's caching allocator to expandable_segments: True, which reduces fragmentation across long runs. Neither one moves weights to the GPU - it stops the GPU copy from being thrown away.

The inputs are just those two booleans plus model; the sole output is model, wired into your sampler's model input. UNETLoader → ⚡ VRAM Pin → KSampler is the whole pattern.

Install

Manager → search ComfyUI-ZeroCopy-Continuity, or:

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

Then restart. Nothing else to fetch - the pack declares no dependencies beyond the torch you already run, and there are no model downloads. (The README's clone line still says latentforge/ instead of latentforge-dev/; the URL above is the one that resolves.)

Because both keys exist, a workflow you download might contain either name. Both resolve to the same class, so a graph built with CineFluxZeroCopyVRAMPin opens fine on your machine and vice versa - this is also why the alias exists: the author could ship prettier node names later without every shared workflow breaking.

Honest caveats

ComfyUI has its own version of this. --disable-smart-memory and --highvram already tell ComfyUI to be much less eager about unloading, and --disable-smart-memory turns up all over troubleshooting threads for this exact problem. If you're already launching with it, expect a marginal gain here, not a 35× one. Measure two consecutive shots before and after; it takes five minutes and settles it.

Pinning turns "slow" into "out of memory." With no eviction, the VAE decode has to fit alongside the resident model. On a card that just barely held the model by shuffling, this node will OOM instead. It's a 24GB-and-up tool in practice, which is what the README's hardware framing implies.

It only holds the id and the flag. Pinning is a Python attribute on that patcher instance, so reloading the model in a fresh graph means routing it through the node again. (The flag is also set on the root model object, so patcher clones inherit it - that's why LoRA patches downstream don't break the pin.)

Watch the startup log. The eviction hook is installed at import time, not when you place the node, and it patches a ComfyUI internal that can move between releases. The pack logs Installed ComfyUI LoadedModel anti-eviction hook on success; if that line is missing after a ComfyUI update, nothing is being pinned no matter what the node says.

Worth being straight about the pack's provenance too: it ships from a homelab ("LatentForge", credited to an autonomous AI agent called Antigravity), it has essentially no footprint in the community corpus - searches for the pack and its node names come back empty - and the README's benchmark table comes from a single RTX 5090. The code is short and readable, though, and if you're going to pin a 20GB model you should read the ~100 lines that do it.