ltx-2.5-mlx-q8 完全指南如何在 Apple Silicon Mac 上快速跑通 LTX-2.5 文生视频ltx-2.5-mlx-q8 是面向 Apple Silicon Mac 的LTX-2.5 文生视频模型量化版本。它把文生视频流程中最吃内存的文本编码器量化为 int8让整段推理的峰值显存从约 24.8 GB 降到14.6 GB——24 GB 内存的 Mac 第一次可以本地跑通 LTX-2.5 的音频视频联合生成。下面这份指南会讲清楚它是什么、为什么省内存、以及如何一步步跑起来。为什么选 ltx-2.5-mlx-q8 而不是原版LTX-2.5 是一个音视频一体的生成模型48 层 DiT 主干、8 层文本连接器、独立的音频分支音频注意力头 32 个、cross-attention 维度 2048架构细节可见 config.json 和 embedded_config.json。原版bf16在 Mac 上跑 LTX-2.5 有一个绕不过去的坎配置文本编码器体积整段运行峰值内存原版 bf16 编码器23.8 GB约 24.8 GB24 GB/32 GB 机型均超预算ltx-2.5-mlx-q8 int8 编码器13.6 GB14.6 GB / 15.4 GB✅ 关键结论来自项目 README.md 的实测这个 24.8 GB 的峰值是与分辨率无关的地板——256×256×9 的小片段和 512×288×121 的大片段峰值几乎相同说明瓶颈不是解码而是 bf16 文本编码器常驻内存换 int8 编码器 流式加载 DiT两条杠杆缺一不可只换编码器DiT 常驻看不出效果只做流式编码器还是 bf16地板依旧。仓库结构拆解每个文件是干什么的这是一个完整组件树下载即用各组件相互独立、可自由组合文件 / 目录作用gemma4-12b-ltx-v1/⭐ 核心差异所在int8 量化的 Gemma-4 12B 文本编码器3 个分片 safetensors tokenizerconnector.safetensors文本连接器把编码器的 49 个隐状态接入 DiTvae_encoder.safetensors / vae_decoder.safetensors标准视频 VAE 编码器 / 解码器vae_decoder_pruna.safetensorsPrunaAI 的剪枝蒸馏版解码器可选解码约 2 倍速vae_diffusion_decoder.safetensors扩散解码器audio_vae.safetensors / vocoder.safetensors音频 VAE 与声码器负责视频里的声音部分spatial_upscaler_x2_v1_1.safetensors空间 2 倍上采样潜空间内2.0×temporal_upscaler_x2_v1_0.safetensors时间 2 倍上采样即帧数翻倍延长片段duration_head.safetensors时长预测头LICENSE.mdLTX-2.x 社区许可证全文⚠️ 注意本仓库不包含量化 DiT。DiT 是独立的量化轴——你可以自由搭配 int8 编码器 bf16 DiT或 int8 编码器 int8 DiT后者见 mlx-community 的ltx-2.5-mlx-ditq8仓库。三步安装在 Mac 上跑通 LTX-2.5 文生视频第一步获取模型文件模型约 14 GB 量级确保磁盘有 30 GB 以上空闲git clone https://gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx-q8第二步确认你的内存档位24 GB Mac必须使用本仓库的 int8 编码器 流式 DiT峰值约 14.6 GB留有充足余量32 GB Mac同样受益于 int8 编码器峰值约 15.4 GB可尝试更高分辨率。推理入口是 MLX 移植版ltx-2-mlx-swift它在本仓库选择了 int8 文本编码器时会自动从本组件树读取其余组件——这正是整棵树可独立解析的设计目的。第三步可选开启 Pruna 轻量解码器 ⚡️解码是 LTX-2.5 最慢的环节之一。仓库内置的 vae_decoder_pruna.safetensorsPrunaAI 剪枝蒸馏版SHA-256 校验值见 README.md实测效果解码速度约2 倍每片段墙钟时间−15.9%在解码成为瓶颈的 704×512×121 档峰值从 21.1 GB 降到14.5 GB——把一次必须换页的运行拉回预算内。开启方式二选一# 方式一环境变量 export LTX_VAE_DECODERpruna或在LTX2Configuration.vaeDecoderPath中指向该文件。低内存档位compact24、balanced32默认就会选它。int8 量化后画质掉不掉这是新手最关心的问题项目方给出了两组可复现的结论数值保真度决定文本编码器量化质量的指标——连接器在有效 token 位置的输出——int8 版为 0.999820对比 bf16 地板值 0.999879几乎无差。量化配方为 int8、group 64并刻意把embed_tokens排除在量化之外保持 bf16因为它是连接器直接消费的隐状态之一。观感生成画面与 bf16 并非逐位一致条件变了采样轨迹自然不同但在包含人脸特写的盲测 4 组 A/B 中被评为可接受。 也就是说它是另一条同样合格的视频轨迹而不是有损的低画质版。常见问题 FAQQ1我的 Mac 是 16 GB 内存能跑吗不建议。整段运行峰值 14.6 GB 已贴近物理内存上限加上系统占用容易触发内存压缩速度会显著下降。16 GB 机器建议先从更小几何参数低分辨率、短时长试水。Q2只有这个仓库能跑文生视频吗本仓库提供的是组件树权重 配置需要配合 MLX 移植版运行框架如ltx-2-mlx/ ltx-2-mlx-swift调用。仓库内的 config.json 表明模型版本为 2.5.0、模型类型为 AudioVideo调度器为 RectifiedFlowLinearQuadratic 采样器。Q3想要更长、更高清的视频怎么办仓库自带两级上采样器先用 spatial_upscaler_x2_v1_1.safetensors 做空间 2× 放大再用 temporal_upscaler_x2_v1_0.safetensors 做时间 2× 延长组合即可得到 4× 的分辨率与时长增益。Q4许可证有什么限制项目遵循 LTX-2.x 社区许可证LICENSE.md个人研究、学习、非商业用途免费年收入 ≥ 1000 万美元的商业实体用于商业目的需购买付费授权。使用规范快照见 ltx-acceptable-use-policy-snapshot-2026-08-12.pdf商用前请务必通读。写在最后ltx-2.5-mlx-q8 的价值在于降门槛三个字 用 int8 文本编码器把 LTX-2.5 的内存地板从 24.8 GB 打到 14.6 GB让 24 GB 的 Mac 真正用得起音视频一体的文生视频再叠加 Pruna 解码器速度与峰值还能再降一档。对于想在 Mac 上本地体验 LTX-2.5 的新手这是目前内存友好度最高的入口。快速清单git clone拉取本仓库约 14 GB 磁盘占用确认 24 GB 起步的内存档位用 MLX 移植框架加载本组件树可选export LTX_VAE_DECODERpruna开启加速解码写下第一条提示词生成属于你的第一条本地视频 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
