VAELoaderMultiGPU

The VAE is small compared to a UNet or a big text encoder, but it still has to sit somewhere, and its one job - turning a finished latent back into pixels (or a source image into a latent, on the encode side) - briefly spikes memory when it runs. VAELoaderMultiGPU is the device-aware twin of core VAELoader: same vae_name file picker, plus a device dropdown so that memory spike doesn't have to happen on your compute card.

Why offload the VAE specifically

Not every workflow even needs an explicit VAE anymore - modern checkpoints increasingly bake their own in. But plenty still call for one: SD 1.5's classic 840k fix for washed-out color, SDXL's dedicated fp16 VAE, or a targeted swap to correct a specific model's decoder behavior (Qwen-Image's is one the community has flagged for over-smoothing). Whenever you are loading one explicitly, it's worth knowing it only runs at the very start or very end of a generation - not on every diffusion step the way the UNet does. That makes it one of the cheapest, lowest-risk things in your whole graph to move off your compute GPU: one PCIe round-trip per run, and the rest of the time that memory is free.

The inputs and outputs that matter

• vae_name - whatever's in your models/vae folder. The dropdown reflects what's actually installed there, so don't be alarmed if a fresh setup shows only a built-in placeholder entry until you drop real VAE files in.
• device (default cpu) - where the VAE lives.
• Output: VAE, into your VAEDecode / VAEEncode nodes, or wherever a checkpoint loader's VAE output normally plugs in.

How to install it

ComfyUI Manager: search ComfyUI-MultiGPU, install, restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/pollockjj/ComfyUI-MultiGPU

then restart. No extra dependencies, no model downloads tied to the node itself.

Common issues & troubleshooting

Empty or thin vae_name dropdown. That's a models-folder issue, not a MultiGPU bug - add VAE files to models/vae and restart or refresh.

"On cpu" doesn't mean "doing nothing." A VAE pinned to cpu still runs its decode/encode math there, which is noticeably slower than on a GPU for large latents or high resolutions. If VAE decode time becomes a visible chunk of your total generation time - heavy img2img batching is where this shows up first - that's the signal to give it a real GPU rather than leaving it on cpu by default.

Wrong VAE for the checkpoint. Loading an SD 1.5 VAE against an SDXL model (or vice versa) produces bad colors and artifacts no matter which device it's sitting on - that's a compatibility problem this node's device setting can't fix. Match the VAE to the model family first, then worry about placement.