JR MiniMax H3 Sequential Latent Checkpoint

The JR MiniMax H3 sequential workflow has a simple memory strategy: only one chunk of generation lives on the GPU at a time. But a sampled chunk is still a full video-plus-audio latent sitting in VRAM, and it has to survive long enough to be decoded. JR_H3_SequentialLatentCheckpoint is the node that gets it off the GPU safely - it writes the sampled tensors to disk as one atomic safetensors checkpoint and hands the decode stage a CPU-backed copy. Third node in the chain, and the one that makes the "low memory" promise real.

What it does

After your sampler finishes a chunk, its output lands here. The node validates the chunk_context token from the Driver against the job manifest - if the context is stale or ahead of the manifest, it refuses, because committing out of order would corrupt the sequence. Then it unzips the official H3 AV NestedTensor into its two streams (video [B,24,T,H,W], audio [B,32,2,T]), moves them to CPU, and saves them atomically as latents/chunk_NNNNN.safetensors in the job directory.

"Atomically" is doing real work here: the file is written to a temp name and renamed into place only after a complete write, so a crash mid-save never leaves a half-written checkpoint the next chunk would read. Each checkpoint carries job_id, chunk_index and generation_token in its metadata, which is how recovery knows exactly where you are.

The output is deliberately boring

What comes out is a latent that is a CPU-backed official H3 AV NestedTensor, plus the same chunk_context (preserved for the commit node) and a status string saying where the file landed. That CPU latent flows into VAE Decode; decode runs on the tensor and can pull it back to GPU as needed, but the giant sample no longer parks in VRAM between the sampler and the decoder. No pickle is involved, and no tensor is ever serialized into workflow JSON - the disk checkpoint is the persistence layer, and the workflow stays a small, shareable graph.

Sampler -> JR_H3_SequentialLatentCheckpoint -> VAE Decode -> JR_H3_SequentialVideoOutput
             |-> writes latents/chunk_00000.safetensors (atomic)
             |-> chunk_context passes through to the output node

If the chunk was already committed (say you re-ran the prompt after a crash), the node notices the manifest has moved past it and skips the write rather than double-saving.

Installing it

This is the same JR MiniMax H3 pack (Goldlionren/ComfyUI_JR_MiniMaxH3Node) as the rest of the chain. ComfyUI Manager → search "JR MiniMax H3", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Goldlionren/ComfyUI_JR_MiniMaxH3Node.git
<ComfyUI-Python> -m pip install -r .\ComfyUI_JR_MiniMaxH3Node\requirements.txt

Same Python as ComfyUI, as always with this pack. Beyond ComfyUI's own stack it needs imageio-ffmpeg>=0.5; the safetensors writer is already in your ComfyUI environment. Restart ComfyUI after installing.

Troubleshooting

The errors this node throws are all about sequence integrity, and they read like a custody chain: "chunk_context is ahead of the manifest and cannot be committed" means you're trying to checkpoint a chunk the output node already advanced past - you're likely running an older prompt against a newer manifest, so load the current workflow or bump run_id for a fresh job. "chunk_context generation token does not match" means the manifest moved on; same fix. And if you ever see the saved .safetensors file and wonder whether you can load it with a generic Load Latent node - you can, and it's the recovery path: each checkpoint is a complete, self-describing chunk. That's the design, not an accident.