LightVAE：为 Wan 和 H3 加速视频 VAE 解码的 ComfyUI 方案

来自项目仓库：Wan2.1 VAE 与 Turbo-VAED、Flash-VAED 及 LightVAE 的对比。

LightVAE 的作用

视频 VAE 解码占视频生成运行成本的很大一部分：每次都需要将一个 latent 片段重新转换为数百帧。LightVAE 让解码器的任务保持不变，只缩小执行该任务的网络：

• LightVAE-Pro 在原始解码器深度上使用时序低秩卷积，因此重建保真度接近原始版本。
• LightVAE-Lite 在此基础上加入块剪枝，以略低的保真度换取更高的速度。
• 原始 latent 接口。 Wan 模型保留自身未压缩的编码器，因此现有工作流只需替换解码端。MiniMax-H3 则同时获得一个剪枝解码器和一个独立的 Lite 编码器。

论文中的表 1：解码器吞吐量与重建 PSNR 的对比。

解码速度

作者在 ComfyUI 中使用 H200 测得，分辨率 768 x 1344，批处理大小 1，Wan 为 125 帧、H3 为 124 帧，预热一次并取三次运行的中位数：

该测量仅覆盖 GPU 同步的 VAE.decode，因此它是解码加速，而非完整生成的加速。LightVAE 不会降低 diffusion 模型或文本编码器的内存开销。

如何选择 checkpoint

Wan2.2 14B 使用 Wan2.1 VAE（16 个 latent 通道），而 5B 模型使用 Wan2.2 VAE（48 个通道），因此这一选择并非随意挑选。所有配置中，Wan 编码器和 H3 音频 VAE 均保持不变。

在 ComfyUI 中使用

python comfyui/install.py --comfy-root /path/to/ComfyUI 会将适配器复制到 ComfyUI/custom_nodes/ComfyUI-LightVAE/，而 *-comfy.safetensors 权重则放入 ComfyUI/models/vae/LightVAE/。此节点为 Load LightVAE (TLR)，关键在于这些打包好的导出权重替换的是正常的 Load VAE，而不是标准的 VAELoader 路径：

1. 保留原始 Load VAE 节点，并将其连接到 LightVAE 的 base_vae。
2. 为你的骨干模型选择 Pro 或 Lite 解码器，并保持 encoder = none（Wan），或选择两个 H3 Lite 文件。
3. 将 LightVAE 的 VAE 输出连接到工作流中的编码和解码节点。

对于 Wan，只有解码端发生变化，引用条件仍使用原始编码器。对于 H3，可选的 Lite 编码器会同时替换引用编码路径和解码，该配置下无需原始视频 VAE。将两项选择都设为 none 可完全恢复原始 VAE。

该仓库为此节点提供了六个扁平工作流，它们除 ComfyUI 核心之外无需任何其他内容：

全部六个工作流也在工作流目录中。

硬件支持

LightVAE 并不局限于 Hopper。在 NVIDIA BF16 配合 Triton 时，它使用融合内核；在没有可用的 Triton 编译器时，或在其他 PyTorch 设备上，TLR 卷积保持因式分解形式并通过 PyTorch 回退路径运行，同时还有一条用于调试的 CPU FP32 路径。H3 路径使用 PyTorch 卷积和注意力，而非 Wan 的 Triton 内核，作者指出未测试的 GPU 系列不保证速度。此节点已在 Python 3.11 下针对 ComfyUI e8665ca 验证，并在 1344x768、362 帧、24 FPS 下验证了完整的 H3 生成。

可用性

权重：lightx2v/LightVAE，位于 Hugging Face。代码、基准测试和工作流：ModelTC/LightVAE，位于 GitHub。