DGX Spark CLIP Loader

Text encoders are the sneaky part of the DGX Spark loading problem. The diffusion model gets all the attention - it's the 20 GB monster that takes forever to load - but the CLIP model is loaded and unloaded by ComfyUI's memory manager on its own schedule, and on the Spark that scheduling is part of why renders feel slow. DGX Spark CLIP Loader fixes the loading side with the same trick as the rest of this pack: fastsafetensors doing zero-copy GPUDirect transfers into unified memory, instead of reading the file through system RAM with up to 2× transient memory usage.

It's a drop-in replacement for ComfyUI's CLIP Loader. Same folder (text_encoders/), same output type (CLIP), same downstream wiring into your CLIP Text Encode nodes. And it comes with one input the stock loader doesn't have, which is where everyone trips.

The type input you must not ignore

The node's clip_name dropdown lists the text encoders in your text_encoders/ folder, but you also have to tell it which architecture the file is: a type selector with nineteen choices - stable_diffusion, stable_cascade, sd3, stable_audio, mochi, ltxv, pixart, cosmos, lumina2, wan, hidream, chroma, ace, omnigen2, qwen_image, hunyuan_image, flux2, ovis, and longcat_image.

This is the one setting a beginner gets wrong, because it fails softly. The code maps your selection onto ComfyUI's CLIPType enum, and if it can't match, it falls back to STABLE_DIFFUSION - so a mismatched type usually doesn't error, it just loads the wrong encoder architecture and you get conditioning that's subtly, annoyingly wrong. If you're running the DGX Spark Qwen Image Edit workflows this pack's author mentions, that's qwen_image. Flux → flux2. SDXL → stable_diffusion. When in doubt, match the type to the model family, not to your vibes.

How it loads

Mechanically it mirrors the pack's Checkpoint Loader: SafeTensorsFileLoader copies the file straight to cuda:0 via GPUDirect, the tensors get the assign=True treatment so nothing duplicates, and the patcher is pinned to cuda:0 so ComfyUI never shuffles the encoder off to CPU. It also runs ComfyUI's convert_old_quants pass on the state dict, which is a nice touch if you're loading older quantized text encoders.

Results land in the same global registry as the other loader nodes, so once a text encoder is loaded, re-running the workflow returns the cached copy - no disk, no re-transfer.

The inputs and output

• clip_name - the text encoder file, from text_encoders/.
• type - the architecture selector above. Get this right.
• device - cuda:0, and the tooltip is explicit: "On DGX Spark, always use cuda:0 (unified memory)." Leave it.

It outputs a single clip socket, which feeds your CLIP Text Encode nodes exactly like the stock loader's output.

Installing it

Search ComfyUI-DGXSparkFastSafetensorsLoaders in ComfyUI Manager, or clone manually:

cd ComfyUI/custom_nodes
git clone https://github.com/redstonewhite/ComfyUI-DGXSparkFastSafetensorsLoaders.git
pip install fastsafetensors   # activate your venv first if applicable

Restart ComfyUI and you'll find the nodes under loaders.

Common issues

• Wrong type, no error. The fallback to stable_diffusion masks mistakes. If your conditioning looks subtly off after switching loaders, re-check the type against the model family first.
• The encoder stays loaded. Like every loader in this pack, CLIP loads outside ComfyUI's memory management, so it lingers in unified memory until you run the pack's Model Unloader or restart. That's by design, but worth knowing when you're juggling several models in one session.
• It's a Spark-only tool. On a normal GPU the stock CLIP Loader is perfectly fast and this is just an extra dependency hunting for a problem.

One aside: this pack is genuinely the best answer I've seen to "my Spark reloads models every single run," but only if you replace all the loaders in a workflow - mix a fast CLIP loader with a stock checkpoint loader and ComfyUI's memory manager starts fighting itself over who owns what.