H3 MS VAE Cache

Most node articles have to talk you into something. This one gets to do the opposite, because the pack's README is refreshingly honest about H3 MS VAE Cache: it's not in the recommended wiring, and in the author's reference workflow at 192 frames it did nothing, because nothing was evicting the VAE between scenes.

So here's the deal. It's a pinned-RAM weight cache for a VAE - the same idea as the text-encoder cache, at a much smaller scale. It's worth knowing it exists, and worth knowing when it applies. It is not worth adding to every workflow because a node appeared in the pack.

What it does

It copies the VAE's host weights into CUDA-registered pinned CPU memory once, for the life of the ComfyUI process, and routes the VAE's modules through the pack's shadow cast so each weight copy comes from pinned RAM rather than being re-staged by ComfyUI's memory manager.

The numbers here are small. The H3 video VAE is 2.95 GB in its int8 form and the audio VAE is 0.56 GB - about 3.5 GiB for both, or 5.4 GiB if you're running an fp16 video VAE. That's a rounding error next to the DiT's ~18.5 GB. The cost of not caching is around 22 seconds per scene for encode, decode and audio combined, whenever DynamicVRAM has evicted the VAEs to make room during sampling.

So: 3.5 GB of RAM to avoid a 22-second hit - but only in workflows where that hit actually happens. At 192 frames in the reference setup, it didn't.

Where I'd actually use it

Two cases. First, scenes with mixed VAEs - the video VAE and the audio VAE - where the two keep displacing each other. Second, a box where VRAM is genuinely tight and ComfyUI is being aggressive about evicting. Everywhere else, leave it out and spend the RAM on the DiT or text-encoder cache instead.

If you're the kind of person who adds nodes because they look useful: don't. The author measured it and said so, which is rarer than it should be.

Inputs and output

vae is the video or audio VAE. The output is a VAE, so it passes straight through to VAE Decode or MiniMaxH3ImageToVideo's vae input.

weight_cache (default on) is the pinned copy.

cache_ram_reserve_gb (default 0) means "only fill while at least this much RAM would remain available." Same semantics as everywhere else in this pack - if you're near your RAM ceiling, set a reserve, or the fill gets refused and you'll see weight cache DISABLED in the console.

And enabled (default on) deserves its own sentence, because it's the trap that runs through this whole pack. Off removes the hook. Bypassing the node does not. These cache nodes replace methods on the shared first_stage_model, which ComfyUI caches across prompts - so a bypassed cache node leaves its hook attached and keeps behaving as it did on the last prompt that actually ran it. Use the toggle, or the Detach all hooks command in the H3 MultiStream menu, or the detach_hooks switch on H3 MS Release Resources.

Placement matters more than the settings

Put it immediately after Select VAE Device. That isn't stylistic. Select VAE Device shallow-copies the VAE and swaps in a retargeted patcher's model, so the hook has to land on the first_stage_model the VAE actually decodes with. Wire it before that node and you've cached an object that isn't the one doing the work - you'll get no benefit and no error either, which is the worst combination.

Install

Ships with the pack. ComfyUI Manager, search ComfyUI-H3-MultiStream, or:

cd ComfyUI/custom_nodes
git clone https://github.com/martonsagi/Comfy-H3-MultiStream ComfyUI-H3-MultiStream

Restart, and it's under advanced/latent. No Python dependencies to install - the pack's dependency list is empty and it requires ComfyUI 0.35.0 or newer. Nothing here changes your output; a cached VAE weight is the same weight.