Load Model

Here's the boring sentence that's actually the whole point: when ComfyUI loads a diffusion model normally, it reads the safetensors into CPU memory and then copies every tensor again into freshly-created model parameters. For a 14B model that's tens of gigabytes of pointless traffic. This node keeps ComfyUI's loader but, when it safely can, lets the model adopt the tensors it already loaded instead of duplicating them.

That's the honest pitch. It is a load-faster node, not a load-different-model node.

What it actually loads

Only files from the diffusion_models folder - the bare UNet/diT weights you use with WAN, Flux, Qwen-Image and friends. Not checkpoints. If your models live in ComfyUI/models/checkpoints, this node's dropdown will be empty and that's not a bug. Newer base models ship as separate diffusion model + text encoder + VAE, and this is the loader for that middle piece.

How the fast path works

Three conditions have to line up before you get the zero-copy behaviour:

1. weight_dtype is left on default (no dtype conversion requested),
2. the file is .safetensors or .sft,
3. the model's load device and offload device are the same device - meaning the weights are staying resident on the GPU rather than being split across GPU and system RAM.

When all three hold, the loader reads the file directly onto the target device and hands ownership of those tensors to the model. When any of them fails, it quietly falls through to ComfyUI's standard state-dict path and behaves exactly like the core node. There's no toggle and no warning - you either get the fast path by configuration or you don't.

The explicit float8 choices are straightforward and use ComfyUI's own conversion machinery:

• fp8_e4m3fn - cast weights to 8-bit float, the usual "big model, small VRAM" move.
• fp8_e4m3fn_fast - same dtype plus ComfyUI's fp8_optimizations flag, which is the setting people actually want when they're chasing speed on Ada or newer.
• fp8_e5m2 - the wider-range variant; rarely the right pick for diffusion weights, but it's there.

Picking any of these turns the fast path off by design, because converting weights means touching them.

One output: MODEL. Wire it into your sampler or guider like any other loader.

The unadvertised feature: logs

The pack logs the load in detail - [Load Model] BEGIN load_torch_file path=... device=... with which device it chose, then END ... elapsed=Ns keys=N plus process RSS and CUDA allocated/reserved, then construction progress from 10% to 89% as it builds layers.

If you've ever stared at a frozen progress bar wondering whether a 22GB model is loading or wedged, that's genuinely useful. If you don't care, it's console noise on every run.

Install

Manager → search Link Comfy Nodes → install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/Mister-Link/link-comfy-nodes
cd link-comfy-nodes
pip install -r requirements.txt

The requirements are the pack's, not this node's - pytorch_lightning, mambapy, numba, scikit-learn, and CLIP installed from a git URL. This node itself needs nothing beyond torch and ComfyUI internals, but the pack imports all of its nodes eagerly at startup, so a missing dependency anywhere in it breaks the loader too.

Where people get burned

Empty model list. You put the weights in checkpoints. Move them to diffusion_models (or add a path via extra_model_paths.yaml) and restart.

FP8 silently running slow or erroring. FP8 matmul is an Ada/Hopper-and-later feature. On older cards you can often still store fp8 weights, but you won't get the speed and occasionally you get dtype errors. If a model misbehaves the moment you pick fp8_e4m3fn_fast, drop to default and confirm the model was fine all along.

It doesn't replace your other loaders. You still need the CLIP/text-encoder node and the VAE Load node. This is one third of a modern loader stack, and forgetting which third is a classic hour lost.

Comparing it against core and seeing nothing. If ComfyUI is offloading part of your model to system RAM, condition 3 fails and you're on the standard path - same speed as always. The zero-copy win is a big-model-fits-entirely scenario. Worth measuring with the log lines rather than assuming.

And the pack-level caveat, straight from its README: the author changes node behaviour without warning and there's no community documentation behind it. Pin a commit or accept that an update can move things.