Nodes/ComfyUi-MpiNodes/Mpi From Checkpoint
ComfyUI Node

Mpi From Checkpoint

Un-bundle a checkpoint back into model, clip, VAE

By MadPonyInteractive·Created 11 months ago·Updated 5 days ago· 3
Mpi From Checkpoint
  • mpi_checkpoint
  • MODEL
  • CLIP
  • VAE

ComfyUI normally gives you a checkpoint as three separate outputs - MODEL, CLIP, VAE - straight from the loader. So why would anyone bundle them back together and then unbundle them again? Because once you're routing a checkpoint around (switching between them, holding a "current model" in one wire), carrying three loose wires everywhere gets old fast. This pack's answer is the MPI_CHECKPOINT wire type, and MpiFromCheckpoint is the node that turns that bundle back into the three sockets every sampler and encoder actually wants.

How it works

One input, mpi_checkpoint, which must come from a node that emits that type - the pack's MpiToCheckpoint is the bundler (it takes model, clip and VAE and combines them). MpiFromCheckpoint does the exact inverse: it takes the bundle and unpacks it into MODEL, CLIP and VAE outputs, in that order.

Mechanically it's the simplest node in the pack - the bundle is just a list under the hood, and this node splats it back out. There are no widgets, nothing to configure, and it can't fail in interesting ways: if the wire carries a valid checkpoint bundle, you get three valid outputs.

Why you'd bother

The pattern it enables is "one checkpoint wire, many uses." A workflow that lets you switch the active model with a single selection - say an MpiAnySwitch or a prompt-driven picker - can route entire checkpoints around as bundles, then unbundle once at the point of use. That's far cleaner than switching model/clip/vae three at a time and risking one of the three getting out of sync. It's the same "bundle for transport, unbundle at the destination" idea as the pack's MpiPacker/MpiUnpacker and MpiBox/MpiFromBox, just specialised for checkpoint triples.

It also pairs with the pack's style and LoRA routing: pick a checkpoint bundle and a LoRA bundle, apply both, unbundle, sample. The checkpoint itself never needs to be re-derived mid-graph.

Where people get burned

The main confusion is expecting it to load a checkpoint. It doesn't - it can't, it takes a bundle, not a filename. If you wire a string path into it, nothing happens; the path goes into a checkpoint loader first. Also, the bundle's three pieces are only as good as what was bundled: unbundling gives you back exactly the model/clip/vae that went in, so there's no magic recovery if one of them was already stale upstream.

Install

From the MadPonyInteractive/ComfyUi-MpiNodes pack. ComfyUI Manager → search ComfyUi-MpiNodes (publisher mad-pony-interactive), install, restart. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes

then restart. Zero dependencies, no model files - it's a tuple unpack in node form. The pack is AGPL-3.0 (≤ 1.2.6 MIT) and is the node library behind the author's Cubric Vision app.

The verdict

Standing alone it's useless; standing next to MpiToCheckpoint it's the reason you can treat "which checkpoint is active" as a single decision instead of three. If you never bundle checkpoints, skip it. If you're building model-switching or routing workflows, it's the release valve that turns a bundle back into something you can actually sample with.

CategoryMpiNodes/Logic

Inputs (1)

NameTypeDefaultDescription
mpi_checkpointMPI_CHECKPOINT

Outputs (3)

NameTypeDescription
MODELMODEL
CLIPCLIP
VAEVAE