RemoteCLIP Client

Some machines are short on VRAM and long on everything else. Text encoders - the CLIP models that turn your prompt into conditioning - are comparatively small but they still hog memory, and if your GPU is already groaning under a Wan or Flux sampler, offloading the encoding step to a second box is real headroom. RemoteCLIP Client (class RemoteClipClient) is the side of that deal that lives in your main workflow: it connects to a RemoteCLIP Server running elsewhere, and hands you four CLIP and four VAE outputs that behave like local models.

Mechanically it's a proxy. Point it at a server with worker_ip (default 127.0.0.1) and port (default 8181), and it builds lightweight stand-ins - RemoteCLIPProxy and RemoteVAEProxy - for each of the four CLIP and four VAE slots. When a downstream node calls tokenize or encode on one of these proxies, the work doesn't happen locally: the prompt text and any kwargs get serialized and sent over a TCP socket to the server, which runs the real CLIP encode and ships the conditioning tensor back. From the graph's point of view, you just have a CLIP. From your GPU's point of view, that step never touched it.

The inputs that matter

• worker_ip - the address of the machine running the RemoteCLIP Server. Defaults to localhost, which is pointless unless you're testing - the whole point is pointing it at another box on your network.
• port - must match the server's listen_port (default 8181).
• refesh (boolean) - the odd one. It's a manual "force re-acquire" switch: the tooltip says to toggle it when you change the remote CLIP, because the client otherwise caches the remote model reference. Flip it and back to pick up server-side changes without restarting.

Outputs: CLIP_1 through CLIP_4 and VAE_1 through VAE_4 - up to eight models, all proxied. Wire them into your normal CLIP Text Encode and VAE Decode nodes and carry on.

Realistic expectations

This is not a one-click miracle. You need the server side running (that's the companion RemoteClipServer node, loaded with the actual CLIPs and VAEs on the remote machine), the two must agree on a port, and your machines need to reach each other on the network. The client doesn't do any model loading of its own - it only works if the server has the models wired in. Expect a small latency cost per encode (serialization + socket round-trip), which is fine for batch workflows and annoying for interactive poking. Also note the security posture: this is a plain TCP protocol with no authentication. Keep it on trusted networks only; exposing it to the internet is an open door into your compute.

Installing it

This node is in lhaoyun6/ComfyUI-lhyNodes. Install via ComfyUI Manager by searching for lhyNodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/lihaoyun6/ComfyUI-lhyNodes.git
python -m pip install -r ComfyUI-lhyNodes/requirements.txt

Restart ComfyUI after. The pack's shared requirements (ultralytics, opencv-python, numpy, yarl) are installed by that one command; no model downloads - the models live on the server box, not here.

If you've got a second machine and a big-prompt workflow, splitting the encoder off can be the difference between "barely fits" and "runs comfortably." It's a niche tool with a specific job, and when that job is yours, it's a lifesaver.