☁️BizyAir Load CLIP Vision

This node doesn't do anything visible on its own - it loads an image-understanding encoder that other nodes need as an input. Anything that reads a reference photo and turns it into an embedding an IP-Adapter-style node can act on (this pack's BizyAir IPAdapterAdvanced has an optional clip_vision slot that wants exactly this) needs a CLIP vision tower feeding it first. This is that loader, running on BizyAir's cloud rather than pulling a multi-GB checkpoint onto your own disk.

What it does

One setting: clip_name, a three-way choice that tells a real story about what this loader is meant to support. models/CLIP-ViT-H-14-laion2B-s32B-b79K.safetensors is the standard OpenCLIP vision tower most IP-Adapter Plus and FaceID setups expect - if you're not sure which one you need, this is the default assumption. kolors/pytorch_model.bin is specific to Kolors workflows (BizyAir ships a full Kolors integration, credited in its own changelog to MinusZoneAI's ComfyUI-Kolors-MZ work) and won't do anything useful outside that context. sigclip_vision_patch14_384.safetensors is a SigLIP vision variant - a newer vision-language encoder family some IP-Adapter and identity-preservation setups have started expecting instead of the older OpenCLIP tower.

Output is CLIP_VISION - notably not a BIZYAIR_-prefixed type, unlike most of this pack's other loaders. That's worth knowing because it means this specific output plugs cleanly into BizyAir IPAdapterAdvanced's clip_vision optional input, which is also typed plain CLIP_VISION.

Installing it

ComfyUI Manager: search BizyAir, install, restart. Manual:

cd ComfyUI/custom_nodes && git clone https://github.com/siliconflow/BizyAir.git

Restart afterward. No model file lands on your disk - the whole point of routing this through BizyAir instead of ComfyUI's stock CLIPVisionLoader is that the checkpoint lives and runs on their infrastructure, not yours. A BizyAir account with an API key configured is required before this or any other node in the pack executes.

Where people get burned

Loading the wrong vision tower for the IP-Adapter checkpoint you're actually using. CLIP vision encoders and IP-Adapter weights are trained as matched pairs - feed an IP-Adapter checkpoint a vision encoder it wasn't trained against and you don't get an error, you get subtly wrong or noisy results that are easy to misdiagnose as a bad weight or prompt problem instead of a mismatched encoder.

Reaching for this when you don't actually need it. This loader only matters if a downstream node has an explicit clip_vision input to fill - plenty of BizyAir workflows (the InstantID or ReActor lines, for instance) don't touch CLIP vision at all, so don't add this node reflexively to every graph.

Confusing this with a general-purpose image encoder. It's specifically the vision-tower half of IP-Adapter/Kolors-style conditioning - not a captioner, not a classifier, and not useful on its own outside a graph that has something downstream to consume its output.