Clark Air DC-AE VAE Loader
The 1.2 GB codec that turns Sana's dense latents back into pictures
- CLARKAIR_VAE
Sana owes its whole "cheap and fast" reputation to its VAE. It uses a DC-AE - a deep-compression autoencoder that squeezes pixels down 32× on each side while packing them into 32 latent channels. That aggressive compression is what lets a 1.6B transformer generate at 512×512 in well under a second on a consumer card. This node loads that codec, and it's why your workflow has a VAE at all.
On the surface it's a one-trick loader: pick a model, get a CLARKAIR_VAE socket, wire it into ClarkAirVAEDecode. But the surface hides two things worth knowing.
What you're loading
The dropdown offers two names:
mit-han-lab/dc-ae-f32c32-sana-1.1-diffusers- default, the newer Sana 1.1 VAE.mit-han-lab/dc-ae-f32c32-sana-1.0-diffusers- the original Sana 1.0 codec.
For Clark Air Sana 1.6B, leave it on the 1.1 default. The model was trained against this exact codec, and the golden rule of VAEs applies harder here than anywhere (VAE panel): the right VAE is the one the checkpoint was trained with, not the one with the best reputation. The file is ~1.2 GB and downloads itself from Hugging Face on first run, loaded in bf16.
Why a dedicated node
You can't just use ComfyUI's normal VAELoader for this. Sana's VAE is a diffusers-format AutoencoderDC, and the pack's node loads it through the diffusers library directly. It's also Sana-specific: the DC-AE's 32-channel latent is the same format the Sana transformer generates, which is precisely why the standard VAE path (built around 4- and 16-channel autoencoders) can't touch it. That's the entire reason the pack ships its own loader-and-decode pair instead of leaning on the built-ins.
Where it sits in the workflow
ClarkAirVAELoader ── CLARKAIR_VAE ──┐
├─ ClarkAirVAEDecode ── IMAGE ── SaveImage
KSampler ── LATENT ─────────────────┘
The one input you ever touch is vae_name, and you'll touch it once and forget it. The output feeds the vae input of ClarkAirVAEDecode, which does the actual latent-to-pixels work. In the example workflow you can practically ignore this node after wiring it - it's the quiet half of the pair.
Install and gotchas
Same pack as everything here: ComfyUI Manager ("Clark Air Sana") or git clone https://github.com/clark-labs-inc/ComfyUI-ClarkAirSana into custom_nodes, restart. The VAE weights download on the first queue and cache locally, so after that it's offline-friendly.
The traps, in order:
- Swapping in any other VAE - an SDXL or Flux VAE produces garbage here. The 32-channel format is non-negotiable.
- First-run download lag - the ~1.2 GB VAE plus the ~2.1 GB Gemma encoder both come down before your first image appears. It's normal; the console will show it.
- VRAM - the VAE loads at bf16 on the GPU. At 512×512 it's a rounding error next to the transformer, but on an 8 GB card it's part of why you should keep the transformer GPU-resident and skip
--lowvram(that flag trips over GemLite's packed buffers).
There's genuinely nothing clever to configure here. Pick the 1.1, wire it, and let it decode.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| vae_name | COMBO | 2 options: mit-han-lab/dc-ae-f32c32-sana-1.1-diffusers, mit-han-lab/dc-ae-f32c32-sana-1.0-diffusers |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLARKAIR_VAE | CLARKAIR_VAE | — |