DGX Spark Checkpoint Loader

If you own a DGX Spark, you already know the weird contradiction: 128 GB of unified memory means you can hold models that would make a 5090 choke, and yet the first render still hangs for 20+ seconds while a checkpoint drags off the disk. ComfyUI's normal Load Checkpoint works fine on the Spark, but it loads the slow way - the Hugging Face safetensors path reads the whole file through system RAM, and on this hardware that can transiently use up to 2× the model's size in RAM just to hand it to the GPU.

DGX Spark Checkpoint Loader is a drop-in replacement that skips most of that. It's part of the ComfyUI-DGXSparkFastSafetensorsLoaders pack from redstonewhite, a fork-and-extension of Phaserblast's earlier DGX Spark loader (Apache 2.0, credit in the README). Where the official loader has one node, this pack gives you four plus an unloader, and the Checkpoint Loader is the one you'd use to swap in for a full model + CLIP + VAE load.

How it loads

Under the hood it uses the fastsafetensors library from NVIDIA's foundation-model-stack. Instead of reading tensors into CPU RAM and then copying them to the GPU, it does a zero-copy GPUDirect transfer straight from storage into the Spark's unified memory. The weights never take a scenic detour through system RAM, which is where the double-buffer and the lag come from.

Then it hands the tensors to ComfyUI's own checkpoint-splitting code (load_state_dict_guess_config) - the same logic the normal Load Checkpoint uses - so model, CLIP, and VAE come apart exactly as you'd expect. A couple of tweaks make it behave on the Spark: loading uses assign=True so weights aren't duplicated, and the patcher's load and offload devices are both pinned to cuda:0 so ComfyUI never tries to move the weights back out of unified memory.

Loaded checkpoints go into a global registry keyed by filename. Re-run the workflow and the node returns the already-loaded model instead of touching the disk - the author reports ~5s total load times in Qwen Image Edit workflows. The flip side: because these loaders sit outside ComfyUI's memory management, ComfyUI will not free them for you. That's what the pack's DGX Spark Model Unloader node is for.

The two inputs that matter

• ckpt_name - the checkpoint to load, picked from your checkpoints/ folder. Same dropdown, same files as the normal loader.
• device - locked to cuda:0, and you should leave it that way. On the Spark's unified-memory architecture there's exactly one device, and the tooltip on the CLIP variant spells it out: always use cuda:0.

That's it. No scale factor, no clip skip, no vae name - the checkpoint already bundles all three.

Wiring the outputs

The node outputs model, clip, and vae, and they plug into the same sockets the standard Load Checkpoint feeds: model into your sampler or refiner chain, clip into the text encoders for your positive/negative prompts, vae into VAE Decode. If you're porting an existing workflow, swap the loader and leave every downstream wire alone.

Installing it

Via ComfyUI Manager, search for ComfyUI-DGXSparkFastSafetensorsLoaders. Or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/redstonewhite/ComfyUI-DGXSparkFastSafetensorsLoaders.git

Then install the one real dependency (activate your venv first if you use one):

pip install fastsafetensors

Restart ComfyUI. The nodes appear under the loaders category. There are no model downloads - it reads whatever is already in your checkpoints/ folder.

Common issues

• The model never frees up. By design. Run the pack's Model Unloader (or restart) when you want the memory back - the README is blunt that memory is not managed by ComfyUI.
• First run is still the slow run. The registry only caches after a model has been loaded once, and the node's IS_CHANGED returns NaN until that happens, so the initial load pays full price. Subsequent runs are where the speedup lives.
• Quantized checkpoints. The README says this fork supports quantized models where Phaserblast's original didn't, but flags it as "should support" - if a GGUF/quantized load fails, file an issue.
• Older versions doubled memory on every loader except the plain Safetensors Loader. That's listed as fixed in the current README, so if you're seeing weird RAM spikes, make sure you're not running an old clone.

One honest caveat: this is a Spark-only tool. On a normal GPU it solves a problem you don't have - the standard loader is already fast there, and fastsafetensors is just an extra dependency.