TAESD: a distilled Stable Diffusion VAE for previews and cheap decoding

Same latent API, a fraction of the compute

TAESD is a very tiny autoencoder which uses the same latent API as Stable Diffusion's VAE, and the README says it can decode Stable Diffusion latents into full-size images at nearly zero cost.

The structure of what is in the repository is worth noting because it is unusual for a machine learning project. Alongside the README, the images/ directory and the examples/, the top level holds the weights themselves as.pth files, and there are seven pairs of them: taesd, taesdxl, taesd3, taef1, taef2, taeqi2_1 and taesana, each with an encoder and a decoder file. TAESD's original weights are in this repository, and the other variants are published on Hugging Face in safetensors format under the taesd, taesdxl, taesd3, taef1, taef2 and taeqi2_1 names.

So this is a weights repository with a small piece of code, taesd.py, rather than a package with a large checkpoint to download. The difference matters for the intended use, which is a preview that starts instantly.

The compatibility list is the other thing to take in. TAESD works with SD1 and SD2 based models using the taesd weights, with SDXL based models using the taesdxl weights, and with SD3 based models using the taesd3 weights.

The project is MIT licensed, the primary language is Python, and the last push to the main branch was on 2026-10-16, with no GitHub releases. The topics attach the project to Stable Diffusion, automatic1111, ComfyUI and Diffusers.

Which weights to use for which model

The question of which file to download is the one that trips people up, because the mapping is by model family and there are now a good number of them.

For FLUX.1 you use the taef1 weights. For HiDream and Z-Image, which use the same VAE as FLUX.1, you also want the taef1 weights. For FLUX.2, FLUX.3 and MOSS-Image you use the taef2 weights. For Qwen Image, which uses the Wan 2.1 VAE, the README points at the TAEW2.1 project for which video models it supports. For Qwen Image 2.1 you use the taeqi2_1 weights. And for Sana, with the dc-ae-f32c32-sana-1.0 checkpoint, you use the taesana weights.

Behind that table is a general rule worth extracting. The autoencoder is tied to the latent space, so you need the variant whose encoder and decoder were trained against the same VAE as your model. Two models that share a VAE share a TAESD variant, which is why HiDream and Z-Image, both on the FLUX.1 VAE, get the same files.

The weights also come in pairs, an encoder and a decoder, and the decoder is the one most people want. The encoder exists for the standalone VAE use case, where you want to encode a real image into latents as well as decode them.

The README also points at several non-SD models having support too, and the Diffusers documentation has a page for the tiny autoencoder, so the formats are stable enough to be a documented integration rather than a script.

How it is used inside the tools people already have

The integrations are the strongest evidence of what this is for, because each one uses TAESD in a different way.

In A1111, the stable-diffusion-webui, it is available as a previewer, thanks to a pull request from Sakura-Luna, and you enable it in Settings then Live Previews. It is also available as an encoder and decoder there, thanks to Kohaku-Blueleaf, through the Settings then VAE panel.

In vladmandic's automatic, a fork of the same web UI, it is available too.

In ComfyUI it is available as a previewer, thanks to space-nuko, following the instructions under How to show high-quality previews, and then you launch ComfyUI with the --preview-method taesd flag. It is also available as a standalone VAE, where you download both taesd_encoder.pth and taesd_decoder.pth into models/vae_approx, add a Load VAE node and set vae_name to taesd.

And in Diffusers, TAESD is available in safetensors format, with the model pages listed for each variant.

The split across these integrations is instructive. As a previewer it is called on every intermediate latent, so a cheap decode matters more than a good one. As a standalone VAE it is doing real work in the pipeline, so the encoder and decoder both matter. The same weights serve both, which is why they are published as separate files rather than a single blob.

Why the scaling conventions trip up users

There is one implementation detail in the README that will silently produce wrong results if you miss it.

TAESD uses different scaling conventions than the official VAE. TAESD expects image values to be in [0, 1] instead of [-1, 1], and TAESD's scale_factor for latents is 1 instead of some long decimal.

That is the difference between a decode that looks slightly wrong and a decode that looks like static, and it is easy to miss because the shape of the output is still correct. The shapes are given in the README as well: the original and decoded images are of shape 3xHxW with values in approximately [0, 1], and the latents are of shape 4x(H/8)x(W/8) with values in approximately [-3, 3]. You can clip and quantize TAESD latents into 8-bit PNGs without much loss of quality, and TAESD latents should look pretty much like Stable Diffusion latents, which is the property that lets them be dropped into a pipeline in place of the real thing.

There are two example notebooks for this. One is Encoding_and_Decoding.ipynb, which shows how to use TAESD for encoding and decoding. The other is Previewing_During_Image_Generation.ipynb, a minimal example that adds TAESD previewing to the Diffusers implementation of SD2.1, and that one is the case the project was built for.

The reasoning behind the preview use case is stated plainly. Since TAESD is very fast, you can use it to watch Stable Diffusion's image generation progress in real time, and since TAESD includes a tiny latent encoder you can use it as a cheap standalone VAE whenever the official VAE is inconvenient, like during real-time interactive image generation or when applying image-space loss functions to latent-space models. The README even suggests running TAESD on a dedicated tiny NPU for maximum efficiency.

What it gives up, and the video caveat

The limitations section is direct about the trade, and it is the first thing to read if you are considering this for final output.

If you want to decode detailed, high-quality images, and do not care how long it takes, you should just use the original SD VAE decoder, or possibly OpenAI's Consistency Decoder. TAESD is very tiny and trying to work very quickly, so it tends to fudge fine details. The summary is that TAESD trades a modest loss in quality for a substantial gain in speed and convenience.

That framing is what makes the project coherent. A distilled autoencoder is not trying to be a better VAE, it is trying to be a cheap one, and the situations where cheap is worth it are the ones where the image is a preview, an intermediate, or the input to a loss function.

For video the answer is yes with a caveat. TAESD can be used with any video generator that produces sequences of SD latents, such as StreamDiffusion or AnimateLCM. Because TAESD generates new details for each frame independently, the results will flicker a bit, but it should still work.

The flicker is worth understanding rather than accepting. The detail is invented per frame with no consistency between frames, so a static region can shimmer. That is why the author trained dedicated Tiny AutoEncoders for the specific video generators instead of relying on the general one: TAEHV for Hunyuan Video, Hunyuan Video 1.5, Wan 2.1, Wan 2.2, Qwen Image, CogVideoX, Open-Sora 1.3 and LTX-2, TAESDV for SD1, SD2 and SVD, and TAEM1 for Mochi 1.

Editorial conclusion

Adopt TAESD when you need to see a Stable Diffusion generation while it happens, or a cheap standalone VAE where the official one is inconvenient, because the distilled encoder and decoder run the same latent API and cost a fraction of the compute. Do not adopt it to produce final images, because the README is clear that it fudges fine details and that you should use the original SD VAE decoder when quality matters more than time. Before you download a variant, check the weight family matches your model, since SD1 and SD2 use the taesd weights, SDXL uses taesdxl, SD3 uses taesd3, FLUX.1 and HiDream use taef1 and FLUX.2 and FLUX.3 use taef2, and each has a separate encoder and decoder file.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. madebyollin/taesd on GitHub
4. README