Nodes/ComfyUI-Qwen2.5-VL-7B-OPENVINO/🔍 Qwen2.5-VL Clip Encoder (单图特征)
ComfyUI Node

🔍 Qwen2.5-VL Clip Encoder (单图特征)

A fake CLIP that turns an image into conditioning

By blackmeat1225·Created 5 months ago·Updated 5 months ago· 3
🔍 Qwen2.5-VL Clip Encoder (单图特征)
  • image
  • CONDITIONING
model_pathhelenai/Qwen2.5-VL-7B-Instruct-ov-int4
deviceCPU

The name promises a CLIP encoder. It is not one. It's the vision tower of Qwen2.5-VL pretending to be a CLIP encoder, and it's the pack's attempt at a poor-man's IP-Adapter: image in, a CONDITIONING out that you're supposed to be able to feed a KSampler, no LoRA, no training. The display name even says what it actually is - "单图特征," single-image features. Take the marketing with a grain of salt and you've got a fun toy for extracting image embeddings on hardware that can't run the real thing.

How it works

Every node in blackmeat1225's ComfyUI-Qwen2.5-VL-7B-OPENVINO pack shares one model - helenai/Qwen2.5-VL-7B-Instruct-ov-int4, auto-downloaded on first use. This node is different from the description nodes in one important way: it doesn't load the full language model. It reads just openvino_vision_embeddings_model.xml from that folder - the vision tower alone - compiles it through OpenVINO, runs your image through it, mean-pools the features over the spatial dimensions, and wraps the resulting vector as a ComfyUI conditioning: [[tensor, {}]]. That's the exact format a sampler expects, which is the trick - it looks like a legit conditioning even though no text was encoded.

The image gets resized to the model's input size (typically 224×224) before inference, so this is genuinely lightweight - no autoregressive generation, just one forward pass. On the Intel CPU/iGPU hardware this pack targets, that's the difference between "usable" and "go make tea."

The honest caveat

This is where I'd pump the brakes. Real conditioning comes from a text encoder whose output dimensionality matches the UNet/DiT's cross-attention. This node outputs whatever dimension Qwen's vision tower happens to use - the code doesn't remap it to anything. Feed it straight into a standard SD/SDXL sampler and you can easily hit a dimension mismatch or produce garbage, because nothing guarantees the cross-attention layers line up. It's not a bug in the node; it's the fundamental limitation of swapping a vision embedding for text conditioning.

Where it can work: as a reference-feature source in a custom graph where you control the mapping, or as a cheap way to test whether image features from Qwen's tower are useful to you at all before committing to a real IP-Adapter setup. Treat every output as experimental.

Inputs and output

  • image - any IMAGE tensor. Resized to the model input size internally.
  • model_path / device - shared with the pack. Default to the auto-downloaded repo id and CPU; "GPU" is Intel iGPU.

The single CONDITIONING output is the pooled feature vector. There's also a Dual Clip Encoder (two images → positive + negative conditioning) in the source, but it's not registered in this pack's __init__.py, so you won't find it in your node list - don't go hunting for it.

Install & issues

ComfyUI Manager (search ComfyUI-Qwen2.5-VL-7B-OPENVINO) or clone https://github.com/blackmeat1225/ComfyUI-Qwen2.5-VL-7B-OPENVINO into custom_nodes/, then pip install openvino-genai pillow in a fresh venv - no requirements.txt ships in the repo, so this is the whole install. First run downloads the model (multi-GB).

This node raises instead of swallowing errors: if the model folder is missing openvino_vision_embeddings_model.xml you'll get a clear FileNotFoundError in the console. That's the most common failure - a custom model_path pointing at a folder that only has part of the model.

CategoryQwen2.5-VL

Inputs (3)

NameTypeDefaultDescription
imageIMAGE
model_pathSTRINGhelenai/Qwen2.5-VL-7B-Instruct-ov-int4
deviceCOMBOCPU2 options: CPU, GPU

Outputs (1)

NameTypeDescription
CONDITIONINGCONDITIONING