Override CLIP Vision Device [LP]

The third of this pack's device-override trio, alongside OverrideCLIPDevice-LP and OverrideVAEDevice-LP. Same idea, different model: this one pins the CLIP Vision encoder - the component that "looks at" a reference image - onto CPU or leaves it on ComfyUI's automatic placement.

Why this one can matter more than the text-CLIP version

CLIP Vision shows up whenever a workflow needs to understand an image rather than just text: IPAdapter-style style transfer, reference-image conditioning in models like Flux Kontext, Redux, and similar multimodal setups. The bigger vision encoders used in these pipelines - some IPAdapter and reference-conditioning setups lean on genuinely large vision backbones - can be a meaningfully bigger chunk of VRAM on their own than a text CLIP model is. And like text CLIP, vision encoding typically happens once, early in the graph, to produce a conditioning signal the rest of the run then uses. If your workflow only touches CLIP Vision briefly at the start but spends the rest of its time on a long sampling pass, forcing it onto CPU for that one encode and freeing the VRAM for sampling can be a proportionally bigger win than doing the same trick for text CLIP.

The inputs and outputs that matter

• device - auto or cpu, default cpu. Dropping this node with defaults immediately forces CLIP Vision off the GPU.
• clip_vision - the CLIP Vision model, wired in from your CLIP Vision loader.
• Output - CLIP_VISION, the same model with its device pinned, wired onward to whatever reference-image-conditioning node consumes it.

How to install it

ComfyUI Manager: search "ComfyUI Level Pixel" or ComfyUI-LevelPixel, install, restart - auto-updates via Manager's "Update ALL." Manual:

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

Restart ComfyUI. No models, no extra dependencies - a thin wrapper over ComfyUI's own device placement, same as its OverrideCLIPDevice-LP and OverrideVAEDevice-LP siblings.

Common issues & troubleshooting

Reference-image encoding got noticeably slower. Expected - you traded CPU-encode latency for freed VRAM elsewhere in the run. If that trade isn't worth it for a given workflow, switch back to auto.

You don't see the VRAM savings you expected. Verify CLIP Vision isn't already living on CPU for other reasons - some low-VRAM ComfyUI launch configurations (like --lowvram) already push auxiliary encoders off the GPU automatically, in which case this node has nothing left to override and you won't see any additional change.

Something else in your workflow also manages device placement. If you're combining this with a multi-GPU pack or another device-override mechanism touching the same CLIP Vision model, you can end up with two systems disagreeing about where it should live. Keep device placement for any one model to a single mechanism per graph - mixing this node with another pack's override on the same model object is the most common way to get inconsistent behavior that's hard to reproduce.