ltx-2.5-mlx-q8 内存优化实战：int8 文本编码器 + DiT 流式加载，峰值压到 14.6GB 的完整方案-北京尧图网络

ltx-2.5-mlx-q8 内存优化实战int8 文本编码器 DiT 流式加载峰值压到 14.6GB 的完整方案ltx-2.5-mlx-q8是面向 Apple SiliconMLX的LTX-2.5 文生视频内存优化组件全集用int8 量化文本编码器搭配DiT 流式加载把整次生成的内存峰值从约 24.8 GB 压到14.6 GB让 24 GB / 32 GB 统一内存的 Mac 也能完整跑通 LTX-2.5 音视频生成。这个仓库与官方 MLX 基础版的唯一差异就是文本编码器从 bf16 换成了 int8 量化版13.6 GB vs 23.8 GB其余组件与基础版逐字节一致只是在这里重复了一份以便独立解析。一、为什么难跑24.8 GB 的几何无关地板LTX-2.5 的 DiT 是一个 48 层的音视频AudioVideoTransformer配置见 config.json 和 embedded_config.json。在 DiT 流式加载的前提下实测发现峰值内存由一个与分辨率/帧数无关的约 24.8 GB 地板决定——两个相差很大的片段256×256×9 和 512×288×121峰值相差不到 0.01 GB。如果是解码decode占主导峰值会随分辨率变化实测不随几何尺寸变化说明地板来自bf16 文本编码器常驻显存。而 24.8 GB 直接超出了 24 GB 和 32 GB 机器的预算。二、两个杠杆int8 文本编码器 DiT 流式加载杠杆 1Gemma-4 int8 文本编码器一次省 10.2 GB文本编码器是 Gemma-4 12Bgemma4-12b-ltx-v1约 119 亿参数、总量 13.6 GB分片与索引见 gemma4-12b-ltx-v1/model.safetensors.index.json量化方案为int8、group 64、affine 模式写在 gemma4-12b-ltx-v1/config.json 中。量化配方里有一个关键细节embed_tokens被刻意排除保持 bf16。因为它的输出hidden state 00是 connector 直接消费的 49 个状态之一、也是全部 48 层的输入源量化它会让该状态单独漂移。杠杆 2DiT 流式加载必做但不在本仓库⚠️ 本仓库不包含量化版 DiT。DiT 是独立的一条轴量化 DiT 在另一个仓库mlx-community/ltx-2.5-mlx-ditq8而流式加载按块加载/换入换出权重是运行时策略。两者都可以与 int8 编码器自由混搭——int8 编码器配 bf16 或 int8 DiT 都行。为什么单独哪个都不行组合结果只换 int8 编码器、DiT 常驻峰值仍由 DiT 主导编码器省了个寂寞只流式加载、编码器仍是 bf1624.8 GB 地板依旧int8 编码器 DiT 流式加载峰值 14.6 GB / 15.4 GB24 GB、32 GB 机器全部达标✅实测数据DiT 流式加载下片段规格峰值内存256×256×914.6 GB512×288×12115.4 GB三、14.6GB 实战文件清单与要点完整组件清单文件作用gemma4-12b-ltx-v1/int8 文本编码器3 个 safetensors 分片 tokenizerconfig.json / embedded_config.jsonDiT 模型与 RectifiedFlowScheduler 调度器配置vae_encoder.safetensors / vae_decoder.safetensors视频 VAE 编解码器vae_diffusion_decoder.safetensors扩散式 VAE 解码器可选路线vae_decoder_pruna.safetensors可选Pruna 精简解码器解码约快 2 倍audio_vae.safetensors / vocoder.safetensors音频 VAE 与声码器LTX-2.5 支持音视频联合生成connector.safetensors / duration_head.safetensors文本条件连接器、时长预测头spatial_upscaler_x2_v1_1.safetensors / temporal_upscaler_x2_v1_0.safetensors空间 / 时间 2 倍上采样器多阶段分辨率与帧数扩展如需获取完整组件集git clone https://gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx-q8如何确认 int8 量化生效看配置文件gemma4-12b-ltx-v1/config.json 中bits: 8、group_size: 64、mode: affine看状态指纹connector 消费的 49 个状态中state 00 严格等于 1.000000说明embed_tokens确实保住了 bf16看文件体积编码器从 23.8 GB 降到 13.6 GB。可选加速Pruna 精简 VAE 解码器vae_decoder_pruna.safetensors 是一个经过剪枝蒸馏微调的解码器解码速度约快 2 倍解码阶段激活峰值明显更小。在 704×512×121 这种解码成为瓶颈的场景峰值从21.1 GB 降到 14.5 GB把原本超预算的运行拉回预算内。运行时通过LTX2Configuration.vaeDecoderPath或环境变量LTX_VAE_DECODERpruna选用在低内存档位compact24、balanced32上它就是默认解码器。四、量化之后画质掉多少连接器输出有效 token 位置相似度 0.999820对照 bf16 自身下限 0.999879——几乎贴着精度天花板⚠️ 别用整数组余弦相似度评估短提示词下 1024 个位置里大多是所有编码器臂完全相同的学习寄存器会把整数组指标稀释 3–30 倍输出视频会移动但不是变差int8 输出与 bf16 不逐位相同均值 −0.1421/σ 0.4253 vs −0.1274/0.4222编码器变了、条件变了、轨迹自然不同是一条同样有效的新视频。团队在 704×512 与 512×288 两套几何下做了盲评 4 对 A/B含面部特写判定可接受。五、许可与合规提示项目遵循LTX-2 Community License见 LICENSE.md 及 ltx-acceptable-use-policy-snapshot-2026-08-12.pdf。它继承 Lightricks LTX-2.5 的条款包含附件 A 的收入门槛与非竞争条款§3 允许再分发但必须原样传递这些条件。商用前请务必通读。总结把 LTX-2.5 装进 24 GB Mac 的关键只有一句话两个杠杆必须同时上——文本编码器换 int8本仓库gemma4-12b-ltx-v1省 10.2 GBDiT 流式加载运行时策略去掉常驻瓶颈有余量再叠 Pruna 解码器解码快 2 倍、激活峰值更低。三者叠加峰值 14.6 GB画质盲评通过——小内存 Mac 跑 LTX-2.5 音视频生成从此从不可能变成开箱即用。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

ltx-2.5-mlx-q8 内存优化实战：int8 文本编码器 + DiT 流式加载，峰值压到 14.6GB 的完整方案

相关推荐

深入 ltx-2.5-mlx-q8 量化配方：int8 group 64 完整拆解，embed_tokens 为何必须保持 bf16

【完全免费】游戏解包三步上手：完整提取贴图/音频/模型资源

【独家整理】仿宋_GB2312 字体下载与安装完整指南（Windows / macOS）

更多资讯

5G毫米波与室内电波传播仿真技术解析

STM32F103上运行GRBL：CNC脱机控制器设计与实现

高频电磁场仿真在5G与室内信号优化中的应用解析

Go 敏感词过滤实战：DFA/Trie 匹配与 AC 自动机选型

华为昇腾AI算子库CANN ops-nn架构解析与性能优化

通用型物联网平台架构设计与关键技术解析

今日更新

AI智能体开发实战：从技术原理到商业落地

OpenShell 完全定制指南：从安装到深度配置，打造高效 Windows 开始菜单

Superpowers技能体系全解析：从Skills引入到安装的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？