Nodes/MiniMax H3 CLIP-Cached/MiniMax H3 CLIP-Cached FL2VA
ComfyUI Node

MiniMax H3 CLIP-Cached FL2VA

Stop reloading the Qwen3-VL encoder on every MiniMax H3 run

By Mu5hr00moO·Created 9 days ago·Updated about 23 hours ago· 8
MiniMax H3 CLIP-Cached FL2VA
  • vae
  • first_frame
  • last_frame
  • positive
  • latent
clip_name
prompt
width1344
height768
length124
cache_modeauto

If you've run MiniMax H3 in ComfyUI, you know the ritual: you hit Queue and stare at the canvas for half a minute while the text/vision encoder loads and conditions, every single time - even when the prompt and start frame haven't changed. The name "CLIP" is a bit of a lie, by the way. MiniMax H3 doesn't use a traditional CLIP; its conditioning comes from a Qwen3-VL text/vision encoder, a multi-gigabyte checkpoint that's brutal to load and run repeatedly. And despite the "Cached" branding, nothing about this node calls an API or needs a key. It's all local, and it's all about one thing: not paying that encoder cost twice for the same conditioning.

MiniMaxH3CLIPCachedFL2VA is the cached sibling of ComfyUI's stock MiniMax H3 Image to Video node (the FL2VA path - prompt plus optional first/last keyframes). You'd reach for it any time you're iterating on a workflow where the text/vision part is the same across runs but you want to change the seed, sampler, or anything that happens after conditioning. If you're a 16 GB card user, this is also a VRAM rescue: on the author's RTX 5080, native conditioning peaks around 15.2 GiB of VRAM and 29 GB of RAM, versus roughly 2.7 GiB and 3.4 GB on a cache hit. That's the difference between fitting and OOMing.

How it works

On a first run with a given prompt and keyframes, the node does a cache MISS: it loads the real Qwen3-VL encoder, runs the encode exactly like the stock node, then unloads it and stores the finished conditioning to disk in the pack's cache folder. The next time you ask for the identical conditioning, it's a HIT: the stored result is restored from disk and the encoder never loads at all. The author's benchmark: ~29.9 s median native conditioning versus ~1.1 s on a hit.

The fine print is what makes it useful rather than a gimmick. A cache entry only changes when Qwen3-VL would see different input. Different prompt text? New entry. Different first_frame or last_frame pixels? New entry. Swapping the encoder checkpoint in models/text_encoders? New entry (identity = filename + size + timestamps). But the seed, sampler, scheduler, steps, and any diffusion/model LoRA applied downstream of conditioning? All free - they reuse the existing entry. That LoRA-in-prompt caveat matters: add a LoRA trigger word to the prompt and the change alone creates a new entry.

Inputs and outputs

The two inputs you'll actually set daily are prompt and length - length is frames at 24 fps snapped up to the model's 17k+5 grid (124 ≈ 5 s; the trained range is roughly 124–362, and longer is untested, so don't expect miracles at 3600). width/height are the generation canvas (defaults 1344×768, multiples of 32). clip_name is a dropdown of encoder checkpoints in models/text_encoders rather than a loaded CLIP object - pick the file and it loads lazily, only on a miss. vae feeds latent construction, which isn't part of the cache and always runs.

Optionally wire first_frame and last_frame images for image-to-video. cache_mode defaults to auto (reuse if identical, else encode and save); refresh deliberately forces a real re-encode and overwrites the matching entry - use it when you've edited the source frames and want to be sure.

Outputs are positive (CONDITIONING) and latent (LATENT), the same shapes the stock node returns, so they plug straight into the rest of the H3 sampler graph.

Installing

The pack needs ComfyUI v0.30.0+ with the native MiniMax H3 nodes (it's developed against v0.34.2), plus a MiniMax H3 text/vision encoder checkpoint in ComfyUI/models/text_encoders - the tested file is qwen3vl_32b_minimax_h3_int8_convrot.safetensors. If stock H3 already works for you, no extra model setup is needed; the only Python dependency is safetensors, which ComfyUI already ships. GGUF encoders are untested.

cd ComfyUI/custom_nodes
git clone https://github.com/Mu5hr00moO/ComfyUI-MiniMaxH3-CLIPCached

Restart ComfyUI and the nodes appear under model/conditioning/minimax/cached. ComfyUI Manager users can just search "MiniMax H3 CLIP-Cached". An example workflow, "MiniMax H3 T2V (CLIP-Cached)", shows up under Workflow → Browse Templates.

Gotchas

First runs will feel identical to stock - that's a MISS, and it's the price of a warm cache. If you're iterating on the prompt, you pay a real encode each change; the payoff is re-rolling seeds and tweaking the sampler for free. The cache has no automatic eviction, so it grows on disk - the pack ships a Cache Manager panel to inspect and delete entries. Also know the MiniMax H3 weights themselves carry a community license that excludes the US, EU, UK and Korea; if you're in one of those regions, the model is the blocker long before the cache is.

Categorymodel/conditioning/minimax/cached

Inputs (9)

NameTypeDefaultDescription
clip_nameCOMBOMiniMax H3 text/vision encoder (Qwen3-VL) checkpoint from models/text_encoders. Loaded lazily -- only on a cache miss.
vaeVAE
promptSTRING
widthINT134432–16384
heightINT76832–16384
lengthINT1245–3600Frame count at 24 fps, snapped up to the model's 17k+5 grid (124 = ~5s; trained range is ~124-362, longer is untested)
first_frameoptIMAGE
last_frameoptIMAGE
cache_modeoptCOMBOautoauto: reuse the cached encode for an identical prompt+first_frame+last_frame+clip_name (checkpoint identity = filename+size+mtime+ctime) if one exists, otherwise encode and save it. refresh: ignore any cached encode, always re-encode and overwrite the cache.

Outputs (2)

NameTypeDescription
positiveCONDITIONING
latentLATENT