Nodes/ComfyUI-LoaderUtils/Load CLIP Vision (Any)
ComfyUI Node

Load CLIP Vision (Any)

The IP-Adapter/Redux loader with a manual VRAM leash

By lrzjason·Created 8 months ago·Updated 8 months ago· 88
Load CLIP Vision (Any)
  • any
  • CLIP_VISION
clip_name

If you've ever wired up IP-Adapter, Flux Redux, or anything else that says "condition on this reference image," you've used a CLIP vision loader. This node loads that same vision encoder - usually a SigLIP or OpenCLIP model depending on the architecture - which turns a picture into embeddings another node can act on. It doesn't do anything with the image itself; it just produces the encoder that reads it. The "(Any)" part is what's new, and it's a genuinely useful one for this specific node - more on why below.

What it does

The stock version of this node is dead simple, and so is this one: one dropdown, one output. clip_name picks a file from your models/clip_vision folder, and the output is a single CLIP_VISION model - the encoder, not an encoded image. That output feeds a CLIP Vision Encode node downstream, which is where an actual image gets turned into the embedding an IP-Adapter or style model can use.

The one thing that's different: any

Every node in this pack adds one optional input beyond the stock version - any, which accepts literally anything. It's not part of the load; it's a tripwire. ComfyUI's executor runs a node the moment its required inputs are satisfied, and a loader has none coming from elsewhere in the graph, so by default it's free to fire immediately - often dumping every model in your workflow into VRAM before the first sampler step even runs. Wire something into any and the loader waits for whatever feeds that wire to finish first. It's a pure ordering hack: the value passed in is never used, only its arrival time.

This matters more for CLIP vision than for most loaders in the pack. Vision encoders plus IP-Adapter or Redux weights are commonly the thing that pushes a workflow over budget on 6-8GB cards, especially once you're stacking more than one adapter alongside an already-loaded checkpoint. Deferring this load until right before your CLIP Vision Encode node actually needs it - instead of at graph start, alongside everything else - is one of the more useful stagings this whole pack offers.

Installing it

Through ComfyUI Manager: search ComfyUI-LoaderUtils, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/ComfyUI-LoaderUtils

Restart ComfyUI. There's no requirements.txt and nothing extra to install - it's a thin wrapper around ComfyUI's own loader classes, so there's no separate dependency to break. It doesn't bundle any weights either: drop whatever CLIP vision file you'd already be using (SigLIP for Flux Redux, CLIP-ViT-H or CLIP-ViT-bigG for the SD1.5/SDXL IP-Adapter lines) into models/clip_vision and it'll show up in the dropdown after a restart.

Where people get burned

The empty-dropdown problem is the boring one: the file isn't in models/clip_vision, or ComfyUI hasn't been restarted since it landed there.

The real gotcha isn't specific to this pack - it's picking the wrong encoder for whatever consumes it downstream. IP-Adapter and Flux Redux each expect a specific CLIP vision model, and they're not interchangeable: load the wrong one and you either get a shape-mismatch error, or worse, a vision encoder that runs fine and quietly produces garbage conditioning. Check the adapter or style model's own documentation for which vision encoder it wants before you assume this node is broken.

And one honest limitation of the pack as a whole: there's no GGUF-format variant here. If you're running quantized vision or text encoders through ComfyUI-GGUF, this pack's staging trick doesn't extend to those - you'd be looking at that pack's own loader nodes instead, without the any input.

Categoryloaders

Inputs (2)

NameTypeDefaultDescription
clip_nameCOMBO0 options:
anyopt*

Outputs (1)

NameTypeDescription
CLIP_VISIONCLIP_VISION