★ FEATURED ARTICLE ltx-2.5-mlx-q8 速度优化Pruna 剪枝 VAE 解码器如何让视频解码提速 2 倍compact24 档实测在 Apple Silicon 上跑 LTX-2.5 视频生成VAE 解码往往是最耗时的环节。ltx-2.5-mlx-q8 仓库内置了一份Pruna 剪枝 VAE 解码器vae_decoder_pruna.safetensors可近乎无感替换原装解码器。本文带你弄懂它是什么、实测收益有多大、以及如何在 compact24 档下最快启用。先认识 ltx-2.5-mlx-q8Apple 芯片上的 LTX-2.5 全套组件这是一个面向 MLX 运行时的 LTX-2.5文本生成视频 音频完整组件树与基础版相比唯一的区别是 Gemma-4 文本编码器被量化为 int813.6 GB 对比 23.8 GB其余文件逐字节一致。仓库内主要文件如下文件作用大小LFS 记录gemma4-12b-ltx-v1/int8 量化文本编码器3 分片约 13.6 GBconnector.safetensors文本特征连接器8 层 Transformer约 6.3 GBvae_decoder.safetensors标准视频 VAE 解码器814,349,515 Bvae_decoder_pruna.safetensorsPruna 剪枝解码器本文主角690,025,680 Bvae_encoder.safetensors视频 VAE 编码器约 638 MBvae_diffusion_decoder.safetensors、audio_vae.safetensors、vocoder.safetensors潜扩散解码器 / 音频 VAE / 声码器—spatial_upscaler_x2_v1_1.safetensors、temporal_upscaler_x2_v1_0.safetensors2 倍空间 / 时间上采样器— 注意本仓库不含量化 DiT。DiT 是独立的量化维度int8 编码器与 bf16 / int8 DiT 可以自由组合详见 README.md 的 “Why it exists” 一节。为什么 VAE 解码是提速的关键LTX-2.5 的出片流程可以概括为文本编码器 → DiT潜空间去噪→ VAE 解码器把潜变量还原成像素帧。前两步有流式加载等手段可优化而解码阶段是实打实把全部空间/时间维度展开成像素的“重活”——帧数、分辨率越高解码占比越大。换句话说谁能让解码变快、变省内存谁就拿到了整条流水线的最大红利。Pruna 剪枝 VAE 解码器它和原装到底差在哪vae_decoder_pruna.safetensors来自 PrunaAI 发布的PrunaVAED一个经过剪枝 蒸馏微调的 LTX-2 视频 VAE 解码器可作为原装解码器的“即插即用”替代品。仓库于 2026-07-31 将其从 diffusers 布局转换为本仓库使用的ltx-core扁平解码器格式转换只做键名映射 PyTorch→MLX 卷积转置不改动任何张量数值。几个值得留意的工程细节均来自 README.md 说明不是单纯的“砍通道”其中两个块携带原装解码器没有的通道适配器 ResBlockconv_in512→384 与 384→256附带仿射norm3。MLX 解码器会从权重自动推导每个层宽、并在检测到适配器时自动启用因此无需改代码。潜空间完全不动编码器、潜变量格式、逐通道统计量都保持原装——也就是说上游生成流程一行代码都不用改只换解码端。一份文件通吃两代视频 VAE 在 LTX-2.3 与 LTX-2.5 之间逐字节相同所以该文件同时服务两个版本。完整性可校验文件 690,025,680 字节SHA-256 为891ec5f0680acea9acbdd651c9756a26c5d3298480224356cf5ea86071846f79。对比原装 vae_decoder.safetensors814,349,515 B剪枝版体积直接少了约 15%——而收益远不止参数变少这么简单。compact24 档实测解码约 2× 提速峰值内存 21.1 GB → 14.5 GB官方在24 GB M5 Pro上、compact24档位测试单号 AB-R-0561ltx-2-mlx-swift给出了两组关键数据场景指标原装解码器Pruna 剪枝解码器compact24 档自身包络每条 clip 墙钟耗时基线−15.9%峰值不变解码构成瓶颈的 704×512×121峰值内存21.1 GB超预算触发换页14.5 GB预算内一句话理解在“解码绑死总耗时”的高分辨率场景剪枝解码器不仅把解码速度提升到约2 倍还把峰值激活显存从 21.1 GB 压到 14.5 GB——直接让一次原本超预算、需要 swap 的运行回到预算之内。对于 24 GB 机型的用户这是“跑得动 / 跑得顺”的差别。配合仓库本身的 int8 文本编码器整程峰值 14.6 / 15.4 GB小内存机器上的“双杠杆”组合也就完整了编码器降基线内存 Pruna 解码器降解码峰值README 特别强调两者必须同时生效缺一不可。如何启用一个环境变量即可切换解码器Swift 移植版提供了两种选择方式任选其一环境变量LTX_VAE_DECODERpruna配置项LTX2Configuration.vaeDecoderPath指向剪枝解码器文件而且在 compact24、balanced32 等低档位中Swift 移植版已把 Pruna 解码器设为默认解码器——也就是说按官方低档配置出片时你其实已经在享受这份提速了。模型文件本身建议通过 Hugging Face 工具链如hf命令行拉取后放入工作目录解码器路径与 vae_encoder.safetensors 同级。兼容性与许可须知许可PrunaVAED 以 LTX-2 许可证发布本仓库中的转换副本按 LICENSE.md 的 LTX-2 Community License 一并分发README 对应章节即为修改声明协议 §3.3镜像与格式转换不改变、不放宽任何条款。质量预期解码结果是“近乎相同但非逐位一致”的视频属于同等有效的另一种输出官方通过盲测 A/B 判定可接受。模型整体受 LTX-2 社区许可约束含营收门槛条款商用前请先阅读 LICENSE.md 与 ltx-acceptable-use-policy-snapshot-2026-08-12.pdf。总结Pruna 剪枝 VAE 解码器是 ltx-2.5-mlx-q8 里最“立竿见影”的提速件解码约2×提速、解码激活峰值显著下降。compact24 档实测墙钟−15.9%704×512×121 解码瓶颈场景峰值内存21.1 → 14.5 GB超预算变预算内。启用零门槛LTX_VAE_DECODERpruna或直接走LTX2Configuration.vaeDecoderPath低档位默认即启用。潜空间格式与编码器保持不变上游流程零改动且 LTX-2.3 / 2.5 通用。如果你的 Mac 是 24 GB 档且经常出 512×288 以上的高分辨率视频这个剪枝解码器基本是“必开”的默认项。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
