VAE Decode (Remote)

The name is slightly a lie: "remote" VAE decode doesn't mean you need an account, a key, or a cloud budget. You swap your normal VAE Decode for this one node, hit run, and your latents get shipped to a HuggingFace-hosted VAE that does the decoding and sends the finished image back. No key, no signup, nothing to configure.

So when do you actually want that? Decoding isn't usually the bottleneck on a big image card - but it is a real tax on video. HunyuanVideo's VAE decode of a long clip is a heavy chunk of VRAM and time on top of an already-heavy model, and on a small-GPU box it's often the step that finally OOMs. Same story for very large Flux images. Offloading decode is the same trick as running the T5 encoder or a controlnet remotely - ComfyUI's graph doesn't care where a stage runs, only what shows up on the wire. This node is the author's minimal experiment in exactly that hybrid-inference pattern, and the README is honest about the scope: it only covers Flux and HunyuanVideo, because those are the VAEs that pay off remotely. SD1.5 and SDXL decode fast enough on local hardware that sending it over the wire would just be slower.

How it actually works

Read the source (nodes.py - it's about 100 lines, no diffusers, no heavy deps) and the mechanism is plain: it takes the packed latent tensor, serializes it as raw tensor bytes via safetensors' _tobytes, and POSTs it to a hardcoded HuggingFace inference endpoint with a few parameters (do_scaling: false, output_type: "pt", plus your latent shape and dtype). The endpoint decodes, returns a binary tensor, and the node reshapes it back, denormalizes from [-1,1] to [0,1], and flips it to the NHWC layout ComfyUI expects. For HunyuanVideo it does the same per-frame and stacks them. Latent height/width are multiplied by the 8× VAE scale factor before shipping.

That also tells you the honest downside: the node is a shared public endpoint, not your private API. Your latents leave your machine (a privacy flag if you generate anything sensitive), the endpoint is one instance that can slow down when it's busy, and there's zero SLA. The hardcoded URLs live in the source - if HuggingFace ever retires that demo endpoint, the node breaks until someone updates it. This is a March 2025 single-release hobby pack, not infrastructure.

The inputs that matter

Only two, and you'll touch one of them:

• samples (LATENT) - wire in whatever you'd normally feed a VAE Decode.
• vae_type - Flux or HunyuanVideo. This is the important one: it selects which remote VAE handles your latents, so it must match what you sampled from. Feed Flux latents into the HunyuanVideo endpoint and you get garbage back.

The output is a single images (IMAGE) tensor - for Flux, a normal image batch; for video, a batch of frames you then run through your usual combine-frames-to-video path (this node won't make the mp4 for you).

Installing it

Two options, both boring and reliable:

# via ComfyUI Manager: search "ComfyUI-RemoteVAE" and install
# or manually:
cd ComfyUI/custom_nodes
git clone https://github.com/Visionatrix/ComfyUI-RemoteVAE

Restart ComfyUI. There are no model downloads and no new heavy dependencies - the requirements.txt is just torch, pillow, numpy, safetensors, requests, every one of which ComfyUI already ships. The VAE itself lives on HuggingFace's servers, which is the whole point.

Where people get burned

• Wrong VAE type is the classic. The node can't read your model's mind; if you forget to set vae_type correctly, it sends well-formed latents to the wrong decoder and you get a confident mess instead of an error.
• It only works with Flux and HunyuanVideo. Using it with an SD1.5/SDXL/SD3 workflow isn't "unsupported with a warning" - the remote VAE won't know what to do with those latents. Just don't.
• No internet, no decode. Everything else in your workflow can be offline; this one can't.
• Video frames come out as an IMAGE batch, not a video. Beginner trip: you'll stare at a wall of frames and wonder where your clip went.

It's a niche node for a specific pain - small-GPU HunyuanVideo work and very large Flux output - and that's fine. If you have a 24 GB card and never hit decode memory pressure, you don't need it, and you should ignore it. But when decode is the step that's killing you, a two-input swap is the cheapest fix you'll find.