Mpi From Checkpoint
Un-bundle a checkpoint back into model, clip, VAE
- 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.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| mpi_checkpoint | MPI_CHECKPOINT | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |
| CLIP | CLIP | — |
| VAE | VAE | — |