Save MiniMax H3 AV Latent Cache

There's a class of ComfyUI node that never generates anything and still saves people whole afternoons. This is one: it takes the latent that just came out of the sampler, writes it to a safetensors file, and passes it straight through so nothing downstream notices.

MiniMax-H3 is where this matters most. Its latent is a nested video+audio pair, and the denoise pass over that token sequence is the single most expensive thing in the workflow. Cache it once and you can re-decode with a different VAE, decode on a different machine, or decode tomorrow, without touching the sampler again.

What it writes

The node expects the H3 latent to be ComfyUI's nested two-stream tensor. It unbinds the pair, detaches both streams to CPU, and writes them under the keys video and audio, with metadata={"format": "minimax_h3_av_latent_v1"}. That metadata isn't decoration - it's how a file identifies itself as the right kind of thing later, and it's the format LoadMiniMaxH3AVLatentCache validates against.

The write is atomic: the tensors go to a temp file named after the target (.minimax_h3_av.safetensors.tmp-<pid>) and are then renamed into place. If ComfyUI dies mid-save you get no file rather than half a file, which is the difference between a confusing error and a corrupt cache you'll debug twice.

Inputs and outputs

• samples - the LATENT from your sampler. Required.
• cache_path - string, default /tmp/minimax_h3_av.safetensors. Point it somewhere you'll still have tomorrow, and give each project its own file; the default is shared scratch.

The output is a single samples socket that is the input latent, unchanged. That makes the node safe to drop inline: sampler → save → decoders, no rewiring, and the graph still produces a video on the first run while also leaving a cache behind. Parent directories are created for you, and the resolved path is reported back to the UI so you can see where it landed.

That pass-through is also why the node is an output node: it has a side effect, it produces no new data, and it can sit at the end of a graph with nothing after it.

The workflow it's built for

The pack's own benchmark harness splits denoising from decoding on purpose. One graph runs the sampler and ends in this node; a second graph starts with the loader, feeds both VAEs, builds a video, and saves it. That structure is what lets the team compare four samplers with matched prompts and seeds and then decode everything under identical conditions - the kind of controlled comparison that a single end-to-end graph makes impossible.

You don't need to be benchmarking for it to pay off, though. If you generate four variations of a prompt and only like one, you can decode just that one. If the clip renders but the audio is off, you re-decode instead of re-denoising. If you're dialling in an upscaler on the video side, you keep one cached latent and iterate.

Installing

The pack installs as a unit through ComfyUI Manager (Registry publisher zechengtang, node ID comfyui-spark-h3), or from a release ZIP with the installer:

cd /path/to/ComfyUI/custom_nodes
unzip /path/to/ComfyUI-Spark-H3-<version>-linux-x86_64-sm86-cu130.zip
/path/to/ComfyUI/.venv/bin/python ComfyUI-Spark-H3/install.py

git clone https://github.com/zechengtang/Spark-H3 into custom_nodes also works for this node - it has no CUDA backend of its own, it's pure safetensors I/O - but the Spark attention nodes in the same pack do, and they want the matching comfy-kitchen wheel. Targeted at ComfyUI 0.38.x/0.39.x on Linux or Windows x86_64, CUDA 13.0, SM86/SM89/SM120. Model weights are a separate download from Comfy-Org/MiniMax-H3.

When it breaks

expected a MiniMax-H3 nested video+audio latent - you fed it something that isn't H3's two-stream latent. A plain image-model latent, or a single-stream latent from another video model, will hit this every time. It's a hard type check, not a heuristic, so the error is trustworthy.

You saved a file and the loader rejects it. Check the keys: the loader wants exactly video and audio and nothing else. If you post-processed or re-saved the latents with another tool, don't - the round trip is meant to stay inside this pair of nodes.

Disk. H3 latents are full-video-grid tensors in BF16. A handful of cached 14-second clips is a real amount of gigabytes, so clean the directory out occasionally rather than assuming it's tiny.

One caveat before you build a whole workflow around caching: the cache is only as good as the model state that produced it. Change the checkpoint, the LoRA, the sigma shift, or the sampler and the cached latent is now a stale artifact of the old configuration - re-denoise rather than reusing it, or you'll be comparing things that aren't the same run.