HF Diffusers load AutoencoderKL (VAE)

Let's get the awkward part out first: for most workflows that use this pack, you should not be reaching for this node. HFDLoadPipeline loads its own VAE and hands it to you as its second output. This "HF Diffusers load AutoencoderKL" node exists for the two cases where the pipeline's own VAE isn't good enough - you want a different VAE, or you want the VAE on a different device or dtype than everything else. It's the pack's escape hatch, not its default path.

That's also why it's the pack's most-searched node despite being optional: the author's "exploded" example workflows (the LongCat Image one especially) load every component separately, and people who drag those into ComfyUI meet this node first and go "wait, what is this?".

What it actually does

It loads a HuggingFace diffusers autoencoder from a model repo on the Hub. The defaults tell the story:

• autoencoder_class - AutoencoderKL, but you can type the name of any autoencoder class in the diffusers namespace. That's the pack's whole philosophy: everything is a string you can replace.
• pretrained_model_name_or_path - the HF repo id, defaulting to stabilityai/stable-diffusion-xl-base-1.0.
• subfolder - "vae", because diffusers-format repos keep the VAE in a vae/ subfolder.
• device - default / auto / cpu (plus cuda options if it detects a GPU). default means "move it to your first CUDA device with .to()"; auto hands the placement to device_map.
• dtype - default, float32, float16, bfloat16, bitsandbytes_8bit, bitsandbytes_4bit.

One thing worth knowing before it bites you: "default" dtype actually resolves to bfloat16 under the hood (the util always sets a torch_dtype, and that's the fallback). If you're on a card with weak bf16 support and getting garbage, set the dtype explicitly instead of trusting the label.

The kwargs box is JSON text for anything the node doesn't expose - the author's answer to "but what about this parameter?" is always "put it in kwargs".

Wiring it up

The output is a single HFD_AUTOENCODERKL. It plugs into three places:

• HFDLoadPipeline's optional vae input, overriding the pipeline's built-in VAE;
• HFDVAEEncode, to push a real image into latent space;
• HFDVAEDecode, to turn latents back into an image.

So the two workflows where this earns its keep: you want a VAE that the model's repo doesn't ship (the "swap the VAE to fix washed-out colors" tradition from the SD 1.5 days), or you want to quantize the VAE to 8-bit while the pipeline runs at full precision. Both are legit, and both are exactly what this node is for.

Install

Install via ComfyUI Manager (search ComfyUI-HF-Diffusers) or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/Yahweasel/ComfyUI-HF-Diffusers

Then restart ComfyUI. The pack's requirements.txt pins diffusers~=0.36.0; it also expects transformers and torch, which ComfyUI already ships.

Where people get burned

• It downloads on first run. Repos land in the HuggingFace cache (~/.cache/huggingface), not in ComfyUI/models/. First load of a big VAE pulls hundreds of MB and looks frozen. It isn't.
• Channel mismatch. A VAE from one architecture used on another model's latents produces noise or flat color, not a subtly wrong image. If your output looks like static, the VAE doesn't match the model.
• You don't need it. Remember: the pipeline exports its own VAE. If you just want to generate, skip this node entirely.