TAEHV: a tiny autoencoder for previewing video diffusion models

What the tiny encoder replaces

TAEHV is a Tiny AutoEncoder for Hunyuan Video and similar video models. The readme states the trade directly: it can encode and decode latents into videos more cheaply in time and memory than the full-size video VAEs, at the cost of slightly lower quality.

The comparison table in the readme puts numbers on both halves of that trade, measured in fp16 on a GH200. Decoding 61 frames of 512 by 320 video takes roughly two to three seconds with the full Hunyuan VAE and roughly half a second with TAEHV. Peak memory for the same job is about six to nine gigabytes for the full VAE and under half a gigabyte for TAEHV.

That is the shape of the tool. A video diffusion pipeline produces latents, and the VAE is what turns those latents back into pixels. In a full model, the VAE is a large convolutional and transformer stack that dominates the memory budget and adds seconds of latency to every preview. TAEHV is a deliberately small reimplementation that trades fidelity for responsiveness, and it is aimed at the part of the workflow where you are looking at frames rather than delivering them.

The readme is clear about the intended use: TAEHV is fast and well-suited for live previewing or interactive video. There is a profiling notebook in the examples directory with the details of the comparison, and a simpler text-to-image demo notebook alongside it.

The licence is MIT, the package is named taehv at version 0.1.0, and the author is Ollin Boer Bohan. The project is classified as Development Status 4 - Beta and Intended Audience Science/Research, and it requires Python 3.8 or newer with torch and tqdm as its only dependencies.

One weight file per model, and how the architecture is chosen

The repository root is the weight file repository, and the readme explains that TAEHV picks the matching architecture based on the checkpoint filename. The root listing shows the files: taehv.pth for Hunyuan Video 1, taeh3.pth for MiniMax H3, taehv1_5.pth and taehv1_5_super.pth for Hunyuan Video 1.5, taew2_1.pth for Wan 2.1, taew2_2.pth and taew2_2_super.pth for Wan 2.2, taeltx_2.pth for LTX-2, taeltx2_3.pth for LTX-2.3 and 2.5, taeos1_3.pth for Open-Sora 1.3, and taecvx.pth for CogVideoX.

The super variants are a consistent pattern: they give higher-quality output at the cost of slightly more compute.

There are two cases where the weight choice is not obvious, and both are documented rather than left to guesswork. Wan 2.2 14B uses the taew2_1 weights, because Wan 2.2 14B still uses the older Wan 2.1 VAE. Qwen Image also uses the taew2_1 weights, since Qwen Image uses the Wan 2.1 VAE encoder.

The LTX case has a wrinkle of its own. The standard TAE decoder for LTX 2.3 and 2.5 produces blurry outputs, which the readme documents with a link to an issue thread, and the author trained a larger, less-blurry taeltx2_3_wide variant for it. Those weights live on a dated branch of the repository rather than on the main branch, and the readme points at ComfyUI-bleh, which has previewing code compatible with that variant.

Mochi 1 and SVD are handled by separate repositories, TAEM1 and TAESDV, because they use different architectures.

If you rename a checkpoint file, the automatic filename matching breaks, and the readme gives the fix: pass the original name explicitly.

TAEHV("my_renamed_weights.pth", arch_name="taeh3")

The main .pth files live in the repository root and converted .safetensors files are in a safetensors subdirectory. TAEHV loads either format, although the safetensors files require the optional safetensors package.

Where it is available, and the packaging details

TAEHV has been integrated into a set of tools, and the readme credits each one.

In ComfyUI it is in main, thanks to a pull request from Kijai. It is also reachable through the ComfyUI-WanVideoWrapper and VideoHelperSuite nodes, credited to Kijai and AustinMroz, and through the ComfyUI-Bleh nodes by blepping. The MiniMax H3 weights are described as currently supported in ComfyUI nightly, in ComfyUI-KJNodes and in ComfyUI-bleh.

Outside ComfyUI, it is in stable-diffusion.cpp through a pull request from stduhpf, in SDNext through vladmandic, and in the Wan2.1 Self-Forcing demo through Guande He and Xun Huang.

The Python packaging is deliberately minimal. The build backend is setuptools with setuptools 64 or newer, and the project is a single module rather than a package, declared as py-modules = ["taehv"]. That means the whole implementation is one file, taehv.py at the repository root, and the only console script is a thin wrapper on its main function.

[project.scripts]
taehv = "taehv:main"

The runtime dependencies are torch and tqdm, and the single optional extra is safetensors, which is the package needed to load the converted checkpoint format.

The examples directory is extensive and shows the intended workflows. There are per-model text-to-image demos for CogVideoX, Hunyuan Video 1.5, Wan 2.1 and Wan 2.2, LTX-2 and LTX 2.3, plus dedicated encoding and decoding notebooks, a streaming demo for Hunyuan Video 1.5, the profiling notebook behind the comparison table, and a Diffusers integration notebook. There are also sample latents and decoded videos included, such as test_latents_wan.pth and test_latents_cogvideox.pth, which are useful for testing a decode path without running a full generation.

The Diffusers conventions that trip people up

Using TAEHV with Diffusers requires a small amount of wrapper code, and the readme gives an example notebook for it. More useful is the list of conventions to keep in mind when writing new code that involves both.

The first is the value range. TAEHV stores image values in the range 0 to 1, whereas Diffusers uses minus 1 to 1. This is the classic off-by-one-and-a-half mistake, and it shows up as washed-out or clipped output rather than as an error, which is exactly the kind of bug that costs an afternoon.

The second is the tensor layout. TAEHV stores videos in NTCHW dimension order, with time first and then channel. Diffusers uses a different ordering, and if you feed tensors in the expected order without transposing, you get a video that decodes but looks wrong: the frames are shuffled, the aspect ratio is off, or the colour channels are scrambled.

Both of these are the kind of convention that is documented once and then rediscovered by every new user of a model, and having them in the readme is one of the more useful parts of it.

The readme also invites people to extend the coverage. If another open video model would benefit from a TAEHV version, the ask is to file an issue, and failing that, to try training your own, with a link to a training example notebook in the author's separate seraena repository.

That invitation is worth taking seriously as a signal about how the project works. The weights are the substance, they are produced by training, and the maintainer is asking for help in producing more of them.

Where TAEHV is the wrong choice

The first limitation is quality, and the readme does not bury it. TAEHV is fast and well-suited for live previewing or interactive video, but it does not yet match the quality of the full-size VAEs. Detailed quality comparisons against the full-size VAEs are published as the MoViRec dataset on Hugging Face, with a speed versus quality chart, and the honest summary is that TAEHV sits at the fast end of that curve.

That means a final render through TAEHV will look worse than the same latent decoded by the real VAE. For a deliverable, that gap matters. The workflow TAEHV is designed for is generate, preview quickly, iterate, and then decode the version you keep with the full VAE.

The second limitation is model coverage. TAEHV covers Hunyuan Video 1 and 1.5, MiniMax H3, Wan 2.1 and 2.2, Qwen Image, CogVideoX, Open-Sora 1.3, and LTX-2 through 2.5. Mochi 1 and SVD need separate repositories because their architectures differ, and any model released after the last weight file was trained has no encoder at all.

The third is the mismatch risk of the weight mapping. Two documented cases already exist where the obvious weight file is not the right one, because a model reused a different VAE: Wan 2.2 14B and Qwen Image both use the Wan 2.1 encoder. This is a class of error that will recur as models are retrained against different VAEs, and the filename-based architecture selection cannot detect it. If a preview looks subtly wrong, suspect the weight mapping before you suspect the model.

The fourth is the packaging. The package version is 0.1.0, the project is marked Beta, and the repository publishes no GitHub releases, so there is no version history to consult and no release notes to read. The last push was on 2026-08-31, and the code lives in a single module file, which is fast to read and fast to break.

The fifth is the ecosystem dependency. The strongest integration path is ComfyUI, and the ComfyUI path itself depends on other projects, in particular the ComfyUI-WanVideoWrapper and VideoHelperSuite nodes, the blerpping ComfyUI-bleh nodes, and the author-hosted Hugging Face weights for MiniMax H3. A tool that supports TAEHV has to track those, and a user assembling a pipeline has to assemble them too.

Editorial conclusion

TAEHV fits an artist or tool author who needs to see a video model's output while iterating, since decoding 61 frames of 512 by 320 video takes about half a second and stays under half a gigabyte of peak memory where the full Hunyuan VAE takes two to three seconds and six to nine gigabytes, and it works across ComfyUI, stable-diffusion.cpp, SDNext and the Diffusers ecosystem through a small wrapper. It is the wrong choice for a final render, since the readme says plainly that TAEHV does not match the quality of the full-size VAEs, and it is the wrong choice if you need a model whose VAE it does not cover, such as Mochi 1 or SVD, which have separate repositories. Before adopting it, load the matching weights file for your model, read the Diffusers conventions section on the value range and tensor layout, and note that the last push was on 2026-08-31 with the package at version 0.1.0 and no GitHub releases published.

Frequently asked questions

Official sources

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