Load Remote CLIP

If you've run LTX-2 or a big Flux build on a mid-size card, you know the exact pain this pack exists for. Modern text encoders are enormous - LTX-2's Gemma 3 12B alone is around 22GB in fp16 - and ComfyUI keeps loading and unloading them to make room for the main model. On a 16GB card that means every prompt edit triggers a full reload and re-encode, and the wait gets old fast. The author built this pack after exactly that: his machine was constantly evicting CLIP to fit the diffusion model.

Load Remote CLIP is the client half of that solution. Your main machine runs the workflow with this node where a normal CLIP would go, and it talks over the network to a second machine - a gaming laptop, an old Mac, anything with a GPU - that holds the text encoder. Your generation GPU stays focused on the heavy lifting.

How it works

The node hands your graph a proxy object that speaks the same interface a local CLIP does: encode_from_tokens, scheduled encoding, even generate for LLM-style encoders. Rather than running the model, it ships the prompt over a plain TCP socket to the Sender, which does the actual encoding and sends the embeddings back. Only embeddings cross the wire - a few kilobytes, and the author's own measurements put round trips around 20–30ms on a reasonable network. The model itself never leaves the Sender's disk, so nothing big moves.

The inputs that matter

Two are required:

• worker_ip - the Sender's IP. Defaults to 127.0.0.1, which is right when both halves run on one machine; for a real second box, use its LAN address.
• port - must match the Sender's listen_port (default 8181).

The optional pair is worth knowing:

• auth_token - a shared secret that must match the Sender's, or requests are rejected. Leave blank when the Sender has none. It can also be set via the REMOTE_CLIP_TOKEN environment variable.
• transport_precision - auto (default) sends fp16 over the network to save bandwidth but keeps full precision when the worker is on localhost, where bandwidth doesn't matter. fp16 always halves, fp32 never downcasts. On a slow link, fp16 is the difference between snappy and sluggish; the precision loss is negligible for most work.

The single output is a CLIP - wire it to your text encode, conditioning, or prompt-enhancement node exactly like a locally loaded model. One rule to keep in mind: Sender and Loader must run the same plugin version. A mismatch is rejected with a clear protocol error rather than silently producing wrong output.

Install

The pack goes on both machines, even though each only uses half of it:

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

Then restart ComfyUI on both. In ComfyUI Manager you can search "ComfyUI-RemoteCLIPLoader" instead. Dependencies are light - just torch and numpy, which a normal ComfyUI install already has. No model downloads here; the Sender holds the models.

Gotchas

• This is cross-machine, not cross-GPU. Asked whether it could load CLIP onto a second GPU inside one box, the author said no - look at the MultiGPU nodes for that.
• Traffic is unencrypted. Fine on your own LAN; over the internet, tunnel it through SSH or a VPN or don't bother.
• The Sender binds to all interfaces by default, so anyone on your network who finds the port can use your model. Set a token if that's a concern.

Where people get burned: pointing worker_ip at the wrong address (you get a bare connection refusal, not a friendly error), setting the token on one side only, and expecting text generation to be fast - autoregressive generation is bound by the Sender's hardware, not the network.