沐阳 H3 · 读取一采检查点(内部)
Load the checkpoint instead of re-sampling it
- samples
Two-pass video is expensive for a dumb reason. You generate the whole thing at low resolution, then upscale and refine it - and the moment you want to change a refine setting, you re-run pass 1. The latents you just spent twenty minutes producing get thrown away because they only existed in VRAM and a decode.
H3Pass1CheckpointLoad is one half of the fix, and the more useful half. It reads a saved pass-1 latent back off disk and hands it straight to the second pass, so you can iterate on the refine without paying for generation again.
What it loads
Three inputs:
filename_prefix(STRING, defaultvideo/H3_长视频) - the same prefix the save node used. This is not a file path so much as a key; the loader resolves it, so keep the prefix consistent between the save and the load or you'll get a not-found error telling you to check exactly that.segment_index(INT, 1-9999, default 1) - long jobs are per-segment, and this reads one.expected_frames(INT, default 125) - what the segment is supposed to be. This is a guard, not a suggestion: a checkpoint whose saved frame count disagrees gets rejected rather than fed into a refine pass at the wrong length.
Output: samples (LATENT), the full H3 audio+video latent. Wire it into the second pass exactly where you'd wire the sampler output of pass 1.
The mechanisms underneath
The file is a .safetensors written under ComfyUI/output, named with the prefix plus _一采检查点_第NN段.h3pass1. It carries the video latent, the audio latent, a format version, the segment index and the frame count - the last three being what the loader verifies. It loads on CPU and refuses anything with a version it doesn't recognise, which is the right kind of paranoia for a binary cache format.
There are two things this node does that a naive loader wouldn't, and both matter in practice.
It re-reads when the file changes. Its change detection stats the path and hashes size plus modification time, so re-saving segment 3 gives you a cache miss and the new file gets loaded. If you're iterating - save, refine, tweak, save again - that's the behaviour you need, and its absence would have you debugging phantom caching.
It uses safetensors directly rather than ComfyUI's generic save path. The source is explicit about why: the generic saver collects prompt metadata and can block on the global output-save path, and an internal pass-through node that's supposed to be fast shouldn't wait behind a PNG queue.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/civilcoco/ComfyUI-MiniMaxH3-Myang
Restart ComfyUI and hard-refresh; category 沐阳 H3/内部. No Python packages beyond the ComfyUI environment - the pack declares no dependencies, and safetensors is already there.
You still need the real stack: H3 diffusion model, Qwen text encoder, video VAE, audio VAE. For the second pass specifically, the pack's advice is a Ref2VA base model without a Turbo LoRA - the Director refuses a Turbo output on the 二采模型 socket.
Where this actually pays off
Upscale-path experimentation. The README lists three second-pass modes and, within them, pixel/VAE projection, neural 3D latent and NVIDIA RTX VSR as paths. Comparing neural 3D at fp16 against fp32, or a temporal chunk of 0 against 16, involves regenerating the same pass-1 latents every single time unless you checkpoint them. With a checkpoint it's a pure second-pass run, which is a fraction of the cost.
Same story for the denoise sweep that every second pass eventually needs. Where 0.25 adds detail and 0.5 changes the scene is a per-shot question, and it's the kind of thing you learn by trying four values on the same pass-1 result. That's only possible if pass 1 is a file.
One limit worth stating: this only helps at the segment granularity the save node writes. There's no partial resume inside a segment, and it doesn't help you skip the audio decode - the checkpoint carries the audio latent too, and re-decoding it is part of the second pass's job. If you want to understand why the latent path beats a decode-re-encode round trip for quality, upscaling covers the trade in general terms; the pack's own second-pass design follows it.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| filename_prefix | STRING | video/H3_长视频 | — |
| segment_index | INT | 11–9999 | — |
| expected_frames | INT | 1251–100000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| samples | LATENT | — |