Load Remote VAE

What this node is for

Load Remote VAE is a VAE loader that doesn't load anything. You point it at another ComfyUI on your LAN, it hands you a VAE object, and every decode and encode you do with that object actually executes on that other machine's GPU. Your card never holds the VAE weights and never pays the decode spike.

Why would you bother? Because VAE decode is not the cheap afterthought people assume. For stills it usually is - a few hundred MB of weights and a spike that tiled decode flattens. For video latents it is not: you're decoding a batch of 80+ frames at once, and whether that costs more VRAM than the diffusion pass is a real argument among people running video models. It depends on the architecture, but it's a spike either way, and it lands at the end of a long job. The honest pitch is narrower: the diffusion model has the card pinned and there's a second GPU in the house doing nothing. Same reason the pack's Load Remote CLIP exists - and that's the one more people actually need, since a 24B text encoder is a bigger permanent resident than any VAE. This node is the other half of the same trick. (Earlier attempts pushed VAE decode to cloud servers; this is the boring LAN version - no account, no key, your hardware.)

How it works

The pack runs two halves. The server is any ComfyUI with the pack installed and "Serve models to other machines" on: it lists its models/vae folder and runs VAE operations on those files. When you hit Connect, the client asks for that list plus an info record about the VAE you picked - latent channels, upscale ratios, dtype - and builds a stand-in object that quacks like comfy.sd.VAE.

That stand-in is why your workflow keeps working: wire it into VAE Decode, VAE Encode or the tiled variants and it ships the latent over HTTP, then returns pixels. Nodes that do latent math read those ratios straight off it.

Two things from the source rather than the README: latents going out are small, pixels coming back are the bulk of the traffic, so decoded frames cross the wire in fp16. Encode is the mirror image - you upload full-res frames, which is why the server may need --max-upload-size raised.

Anything the stand-in doesn't implement fails loudly: nodes that want the VAE weights, or call vae.to(...), get a plain "this node needs the VAE weights locally" error.

The two fields

server_url is the whole setup: http://192.168.1.50:8188, or the magic string local to use the models this same instance already serves, no network involved. Leave it blank and the node falls back to the "Default server URL" setting.

vae_name is a dropdown that starts with one placeholder, (connect to list). You don't type a filename - the node auto-connects shortly after it appears, fills the list from the server's models/vae folder, and the button under the widgets becomes a status line: Connected · 14 VAEs, Unreachable, or Not on server: wan_2.1_vae.safetensors.

One output, VAE - same type as the stock loader, so it drops in anywhere a local VAE would.

Install

Two machines, one command each. ComfyUI Manager will find it as Remote Models, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Mr-Quin/ComfyUI-RemoteModels

Restart ComfyUI. There are no pip dependencies - the project declares none. The pack must be on both machines, same version; mismatched protocols are refused outright.

On the server: start ComfyUI with --listen, open port 8188, put the VAE files in its models/vae, and turn on Settings → Remote Models → Serve models to other machines. Off means every request gets a 403.

# server, when you'll be encoding long video
python main.py --listen --max-upload-size 4096

Where people get burned

• "Unreachable" is almost always --listen missing on the server, or the firewall. "Server not serving" means the toggle is off. "Version mismatch" means update both.
• First decode after a pause is slow. The server unloads idle models after 10 minutes by default. On a dedicated box, set that to 0.
• Don't generate on the server while you're using it. Remote requests queue behind its own prompts, and the pack gives up waiting after ten minutes with a 503.
• Big decodes have a ceiling. The client refuses any single response over 1 GB - roughly 80 frames of 1080p at fp16, so long clips can trip it.

And the one nobody says out loud: no authentication, plain HTTP, and the serve switch is not access control. Anything that can reach the port can flip settings. Keep it on the LAN.

Should you reach for it

Got a second machine with a GPU? Then yes - this is the cleanest way to spend it. One GPU? local mode is only good for testing the plumbing, and for stills, VAE Decode (Tiled) gets you the same fix with zero network. Try that first.