H3 MS Text Encoder Cache

MiniMax H3's text encoder is a Qwen3-VL-32B, which means one of the models in your workflow is roughly the size of a small video model on its own. On 2026 architectures that's normal - the encoder is a second VRAM budget you plan around, not a 200 MB CLIP you forget about. What's less normal is what happens next: the DiT evicts the encoder during sampling, and when you tweak one word of the prompt, ComfyUI has to stage those 15 GB back into VRAM before it can encode.

The pack's own measurement puts that at ~68 seconds, at roughly 263 MB/s. And the insult is that only about ten seconds of it is actual encoder compute. The rest is shuffling weights.

H3 MS Text Encoder Cache takes that from 67 seconds to 12.5, and a re-render of a scene you already encoded to about 0.2 seconds. It's the single biggest quality-of-life win in this pack if you iterate on prompts, which is to say: if you use it at all.

Two caches, one node

A pinned-RAM weight cache keeps the encoder's host weights - NVFP4, AWQ, int8 or bf16 as stored - copied once into CUDA-registered CPU memory, and routes the encoder's modules through a shadow cast that copies each weight from pinned RAM per call instead of letting DynamicVRAM re-stage the whole model. That covers the encoder-compute case: a prompt change now costs the ~10 seconds, not the ~68.

An output cache goes further and skips the encoder entirely. It's an LRU, keyed by the encoder file, the LoRA patch state, layer options, and a content hash of the token/image input - so re-rendering a scene you already encoded is a lookup, not an encode. ComfyUI's own execution cache can't help here: it remembers only the last result per node, so every earlier scene is gone the moment the prompt changes.

Both caches hook the shared cond_stage_model rather than wrapping a clone. That's what makes them survive Select CLIP Device and similar nodes - and it's also the source of the pack's most confusing failure mode, below.

Inputs and output

clip is the H3 text encoder, after Select CLIP Device. The output is a single CLIP that goes into MiniMaxH3ImageToVideo's clip input.

weight_cache (default on) is the pinned copy. The tooltip quotes ~14.6 GB for the NVFP4/AWQ encoder; the README's memory table puts the int8 variant at 25.3 GiB. Check which encoder you actually have before you assume this fits comfortably.

cond_cache_entries (default 64) is the output cache size. Work the arithmetic once: ~12 MB per 768×1344 I2VA scene, so 64 entries is roughly three-quarters of a gigabyte. That's nothing next to the weight cache, and if you iterate across a lot of scenes it's cheap to raise. 0 turns it off.

cache_ram_reserve_gb (default 0) means "only fill the weight cache while at least this much system RAM would still be available." On a 64 GB machine, set it. The README's guidance: 64 GB buys the DiT cache plus the NVFP4 encoder, or the DiT cache alone with the int8 encoder. On 32 GB, turn the weight caches off.

The bypass trap, because it will get you

enabled looks redundant next to the bypass toggle. It isn't, and the author is blunt about it in the tooltip: off removes this node's hook from the shared model. Bypassing or muting the node cannot do that. ComfyUI never calls a bypassed node, so nothing gets the chance to uninstall anything - the hook from the last run stays attached and keeps running with its old settings. You'll see cache log lines from a node that's greyed out, and the obvious conclusion ("the bypass doesn't work") is the wrong one.

Use enabled, or the main menu's Detach all hooks, which is the escape hatch for when you already bypassed it.

Install and first-run behaviour

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

Or ComfyUI Manager, search ComfyUI-H3-MultiStream. Restart; the node appears under advanced/conditioning. No Python dependencies - the pack's pyproject.toml declares none, and every import is either stdlib or something ComfyUI already installs. It needs ComfyUI 0.35.0 or newer.

Filling the cache isn't instant: about 118 seconds on first use with the 27 GB int8 encoder, less with the NVFP4/AWQ one. That happens on the first render after you start ComfyUI, not per prompt - but if your first generation of the day feels oddly slow, this is why.

One more real limitation: the weight cache needs a loader that records a single-file reload factory. The core CLIPLoader does. If you see weight cache DISABLED in the console instead of a fill line, the RAM guard (cache_ram_reserve_gb) refused it - lower the reserve or free some memory.

And the reassuring part, given all that machinery: none of this changes your output. A cache hit returns the same conditioning a fresh encode would. It only changes your clock.