Mpi Load Latent
Pick up a stage-1 latent and keep the run going
- samples
- loaded
Two-stage sampling - generate a latent, stop, then continue from that exact latent later - is the backbone of the hi-res fix and long video work. Core ComfyUI's Load Latent can do it for plain tensors, but it breaks on the packed audio+video latents that MiniMax H3 produces, and its filename dropdown can't see files written this session. Mpi Load Latent is the pack's answer: it loads a latent written by Mpi Save Latent, rebuilds packed H3 pairs, and uses a plain text filename field so there's no UI refresh dance.
The interface is one input, filename - a plain STRING, default mpi_stage1, with no dropdown. The tooltip tells you where it looks: the engine's input/ folder first (where a host app stages a latent from a previous run), then <output>/latents/<filename>.latent, and an absolute path is used as-is. That search order is the "continue a previous run" pattern: the first stage's save lands where the second stage's load can find it.
Two outputs come out. samples is the LATENT, ready to feed a sampler for stage two. loaded is a BOOLEAN - and this is the behavior that makes the node safe in a live graph: if the file is missing, the latent output is blocked (downstream doesn't run) and loaded is false, so the other branch can generate it instead. That's a genuinely useful design for a workflow that can either continue from a cached latent or regenerate from scratch, because the missing-file case becomes a routing decision, not a crash.
Under the hood there are two details worth knowing. First, IS_CHANGED is keyed on file mtime + size rather than a content hash - the author's comment notes an H3 latent is hundreds of MB and hashing it every graph validation would cost more than the load. So if you write a file and load it in the same session, the change detection actually works (mtime moves). Second, it rebuilds the packed audio+video pair that H3 latents are, which is precisely the thing core's loader can't handle - a NestedTensor pair that has no .contiguous() and crashes core. If you're on plain SD/SDXL, that's irrelevant to you; if you're on H3, it's the difference between a working two-stage workflow and a wall of AttributeError.
The natural partner is Mpi Save Latent (this pack), and the one-node version is Mpi Stage Latents, which does the save/gate/load handshake in a single node. If you're driving a host app, the plain-text filename and the loaded boolean are what let a tool compile a two-stage run from one workflow file.
Installing is the pack's standard no-drama deal: ComfyUI Manager → search "ComfyUi-MpiNodes" → install → restart, or
cd ComfyUI/custom_nodes
git clone https://github.com/MadPonyInteractive/ComfyUi-MpiNodes
No dependencies, no models. Part of the Mad Pony Interactive utility pack (the engine behind Cubric Vision), written by people who clearly hit H3's packed latents hard enough to ship a whole two-stage system around them.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| filename | STRING | mpi_stage1 | Read from the engine <input>/ folder if the file is there, else <output>/latents/<filename>.latent. An absolute path is used as-is. A plain text field, not a dropdown, so a file written this session needs no UI refresh. |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| samples | LATENT | — |
| loaded | BOOLEAN | — |