ModelPack Checkpoint
Load a Checkpoint Straight Out of an OCI Registry
- MODEL
- CLIP
- VAE
Every ComfyUI tutorial has the same middle step: download the file, drop it in models/checkpoints, refresh, and hope the loader sees it. That step is where the support threads come from - Flux weights in the wrong folder, a "Load Diffusion Model" node that still shows nothing, extra_model_paths.yaml that half works. ModelPack Checkpoint skips it. You give it an OCI reference - the same kind of pointer docker pull eats - and it fetches, validates, and loads the checkpoint for you.
What it's actually doing
The pack pulls weights stored as CNCF ModelPack artifacts: model weights bundled for an OCI registry, with a manifest and a config the client can verify. The pulling is done by modelpack-client, and the node then calls comfy.sd.load_checkpoint_guess_config - literally the function behind core's Load Checkpoint node.
That matters if you're wary of custom loaders: this isn't a new loading engine or a fork of ComfyUI's model code. It's the loader you already trust, with the file arriving from a registry instead of your Downloads folder.
Inputs and outputs that matter
Two fields, both plain text - not dropdowns, which is the honest downgrade versus core's file browser. You type the filename.
reference- the OCI reference, likeregistry.example.com/models/my-checkpoint:v1. Leave it empty and the node switches to local mode.file- does two different jobs. With areferenceset it's the path inside the artifact, e.g.weights/clip_l.safetensors; withreferenceempty it's a filename from yourmodels/checkpointsfolder. That's what lets one node point at either a local or a remote checkpoint.
At least one of the two has to be filled, or it stops with a clear complaint.
The outputs are the core checkpoint triple: MODEL, CLIP, VAE. Wire MODEL into your sampler, CLIP into CLIP Text Encode, VAE into VAE Decode. If your graph currently starts at Load Checkpoint, this is a drop-in swap.
Where it's the wrong node: if the artifact holds only a diffusion model, guess_config can't invent the text encoder and VAE, and those two outputs come back empty. Point it at a bare UNet and you'll find that out at the sampler. That's the case the pack's separate Diffusion Model, CLIP and VAE nodes exist for.
Installing it
ComfyUI Manager is the short path - search ComfyUI ModelPack (published under the id cerussite). Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/SiLeader/ComfyUI-ModelPack comfyui-modelpack
python -m pip install -r comfyui-modelpack/requirements.txt
Then restart ComfyUI. The nodes show up under ModelPack and ModelPack/loaders.
Get the interpreter right: that pip install has to go into the Python that runs ComfyUI - on the Windows portable build, python_embedded\python.exe, not whatever pip your PATH finds. Otherwise the dependency is light: modelpack-client plus oras, jsonschema and zstandard. No torch, no CUDA extension, no compile step. Python 3.10+ and ComfyUI 0.22.0+ are the real floors.
The part nobody documents: when it re-downloads
Downloads land in ComfyUI/models/modelpack/checkpoints/<hash>/, where the hash is the first 24 characters of the SHA-256 of the reference string. Three consequences worth internalizing:
- A digest reference (
...@sha256:…) is pulled once and then reused forever without contacting the registry. This is the one to ship in a shared workflow: reproducible, and it keeps working offline. - A tag reference (
:v1) is pulled again on first use after each ComfyUI start, so a tag that moved upstream is picked up - and if the registry can't be reached, it logs a warning and uses the copy you already have. Restarting offline won't break your workflow. - Because the hash keys on the reference string and not the content,
:v1and:latestpointing at identical bytes are two copies and two downloads. Deleting themodels/modelpack/checkpoints/…folder is how you reclaim the disk.
Private registries use credentials you've already saved with docker login in ~/.docker/config.json. There's no credential UI, so if the pull 401s, that's where to look.
When it goes wrong
The most useful failure here is the least scary: leave file blank on a multi-weight artifact and the node lists every weight path it found - the artifact's inventory, and usually faster than digging through a registry UI. Typos in the in-artifact path get the same list. It also ignores files outside the download directory and anything that isn't an extension ComfyUI's loader accepts, so an artifact's own README won't confuse it.
The one to actually watch for is mode confusion: leave reference empty with a file you haven't downloaded, and you get a file-not-found rather than a pull. Same two fields, two different jobs.
Honest verdict: this is infrastructure, not a workflow upgrade. If you're a solo user with 200 GB in models/checkpoints and CivitAI open in another tab, the pull is a download either way and you've gained nothing. It earns its keep when a workflow needs to be self-describing (pin the digest, get exactly those bytes), when your weights live in a registry you control and you want fine-tunes versioned like software, or when a 30 GB fetch should be one line in a runbook instead of a URL and folder instructions.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| reference | STRING | OCI reference, e.g. registry.example.com/models/foo:v1. Leave empty to select a local file. | |
| file | STRING | Path within the artifact if it has multiple weights, or local ComfyUI model filename. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |
| VAE | VAE | — |