HFRemoteVAE(Decode Only)

Let's get the scary part out of the way: the name is a bit of a lie. HFRemoteVAE does not call a paid API and needs no key. It posts your raw latent bytes to a free Hugging Face-hosted decode endpoint, gets pixels back, and your machine never loads a VAE into VRAM at all. That's the whole trick.

Every image you generate ends in a VAE decode - the step that turns the small latent tensor into the image you actually look at. Normally that's a local model eating a few hundred MB of VRAM and a couple of seconds. This node (displayed in ComfyUI as "HFRemoteVAE(Decode Only)") makes that step somebody else's problem. If you're VRAM-starved, if you don't want to download the VAE file for the model you're running, or if you're decoding video whose VAE is heavier than any image VAE you've touched, this is genuinely useful. It's the same idea as running your sampler on a remote endpoint, except the VAE is the only part that leaves your machine.

How it works

You get exactly one meaningful input: VAE_type, a dropdown with four choices - Flux, SDXL, SD, HunyuanVideo. Pick the architecture you generated with, and the node hands you a vae output, a VAE object that slots into any node expecting one, like VAEDecode or VAEDecodeTiled. Your existing workflow doesn't change; you just swap the loader.

Under the hood (from the pack source) it does something neat: it computes height and width from the latent dimensions × 8 - the VAE's downscale factor - and POSTs the tensor as raw binary bytes to a hardcoded per-model endpoint on Hugging Face's hosted inference. The server decodes and returns a tensor, which gets postprocessed with a standard image processor (or a video processor for HunyuanVideo) and handed back as a normal VAE decode. It even skips the usual latent scaling step, because ComfyUI already hands nodes latents in the model's native scale. All of this is invisible to you - the node behaves like any other VAE.

The input that matters

Honestly, it's one field. VAE_type is the only thing you'll ever touch, and the only failure mode it has is choosing the wrong architecture - a Flux VAE on SDXL latents gives you noise or flat colour, not a subtly wrong image, because each architecture has its own incompatible autoencoder (channel counts differ from 4 on SD/SDXL to 16 on Flux and HunyuanVideo). Pick the one that matches what you sampled and you're done.

Installing it

Boring, in a good way. ComfyUI Manager → search "HFRemoteVae" → install, or drop it in manually:

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

Then restart ComfyUI. The requirements.txt is literally diffusers, which ComfyUI already ships, and the code imports only stock requests, Pillow, and torch. No model downloads, no weights, no dependencies to fight with. That's rare for a Kijai pack, and it's because there's nothing local to load.

The honest caveats

Reach for this when you know why. The top reaction on r/comfyui when remote VAE decoding landed was basically "c'mon, the VAE is never the thing eating your VRAM - T5 is." Fair. For SD and SDXL the local VAE is small, so the win is modest. It pays off when you're chasing the last few hundred MB, when you want to skip downloading a video VAE, or when you're on a GPU that chokes on tiled decode. And two real costs: these are free public endpoints with no SLA, so expect occasional slowness or rate limits (and someday they may just go away), and every decode ships your latent bytes to a Hugging Face server - fine for most people, a non-starter if you're generating sensitive stuff. If a decode fails, it's the network or the endpoint, not your config. Want to skip the VAE socket entirely and feed a LATENT straight in? That's the sibling node, HFRemoteVAEDecode.