为什么 24.8GB 是 LTX-2.5 的隐形内存门槛？ltx-2.5-mlx-q8 的 int8 编码器破局实录

为什么 24.8GB 是 LTX-2.5 的隐形内存门槛？ltx-2.5-mlx-q8 的 int8 编码器破局实录

跑过本地视频生成模型的同学可能都遇到过这种情况：显存（统一内存）明明还有一截没满，程序却直接报内存不足。ltx-2.5-mlx-q8 这个项目就是冲着这个痛点来的——它是 LTX-2.5 文生视频（text-to-video）模型的完整 MLX 组件树，与官方基础版唯一的区别，是把 Gemma-4 文本编码器量化成了int8（13.6 GB 对比 bf16 的 23.8 GB），从而把整机峰值内存从 24.8 GB 一路拉到 14.6 GB 左右。

这篇实录就来拆解：那个 24.8 GB 的"隐形门槛"到底是怎么形成的，int8 编码器又如何把它撬开的。📉

LTX-2.5 的内存由谁决定：先看组件结构

LTX-2.5 是一个音视频生成模型（见 config.json 中的model_type: AudioVideo，48 层 Transformer），一次完整推理涉及多个大部件：

模型架构细节（如AVTransformer3DModel、音视频交叉注意力、RectifiedFlow 调度器）定义在 embedded_config.json 中。

需要特别说明：⚠️本仓库不包含量化版 DiT（扩散 Transformer 主干）。DiT 是独立的量化轴（另有ltx-2.5-mlx-ditq8项目），int8 编码器可以与 bf16 或 int8 的 DiT 自由组合。

24.8 GB 隐形门槛：一个与分辨率无关的内存地板

在开启 DiT 流式加载（streaming）之后，LTX-2.5 的峰值内存本该由"解码阶段"决定——而解码开销理应随分辨率增长。但实测结果反常：

• 生成256×256×9的小片段，峰值 ≈24.8 GB
• 生成512×288×121的大片段，峰值依然在 0.01 GB 之内贴着 24.8 GB

如果是解码瓶颈，峰值必然随几何尺寸（分辨率×帧数）放大；而它纹丝不动，说明峰值被一个与画面无关的固定开销钉死了——正是那块 bf16 文本编码器（23.8 GB）。加上少量激活开销，24.8 GB 就成了地板价。

这个数字的残酷之处在于：它同时超出了 24 GB 和 32 GB 机器的安全预算。24 GB 的 Mac 直接被拒之门外，32 GB 的机器也只能贴着悬崖跳舞。🪂

int8 编码器配方：group 64 量化，但故意保留一个模块

破局方案就是把这块地板换薄。查看 gemma4-12b-ltx-v1/config.json 的量化配置：

"quantization": { "group_size": 64, "bits": 8, "mode": "affine" }

关键细节：

• int8 + group 64 + affine 仿射量化，编码器从 23.8 GB 压到13.6 GB，瘦身超过一半；
• embed_tokens（词嵌入层）被刻意排除在量化之外，保留 bf16。原因很微妙：第 00 号隐状态本身就是embedTokens(ids) · embedScale，它既是 49 个状态中 connector 直接消费的一个，也是全部 48 层网络的输入。量化它会单独扰动这个状态——量化组正是用state 00 == 1.000000精确相等作为"它没被量化"的指纹来验证的。

这是典型的"量化不是无脑全量"案例：省内存和省内存的代价要逐层权衡。

破局效果：峰值降到 14.6 GB，但两个杠杆必须同时拉

换上 int8 编码器后，两种规格片段的整机峰值分别降到14.6 GB / 15.4 GB——24 GB 机器正式入场。

但这里有一个容易被忽略的结论，官方文档特别强调：两个杠杆单独使用都无效⚠️

也就是说：常驻内存时瓶颈是 DiT，编码器怎么瘦都没用；流式加载后瓶颈才轮到位，地板才暴露出来。优化内存这件事，永远是"木桶最短的那块板"在说话。

量化后画质掉了多少：看对指标，别看整段余弦

对文本编码器这种"条件信号发生器"，官方给出的保真度指标是connector 输出在有效 token 位置上的余弦相似度：

• int8 版本：0.999820
• bf16 的理论下限：0.999879

差距几乎可以忽略。这里还埋了一个避坑点：不要拿整段数组的余弦相似度来评判文本编码器量化。因为短提示词时，1024 个位置中绝大多数是各版本完全相同的"learned registers"，会把真实差异稀释 3～30 倍——一次故意注入错误的对照组，整段余弦高达 0.994316，但有效 token 上只有 0.829329。用错指标，可能把"被污染"的编码器当成合格品。🕵️

另一个诚实的声明：输出视频确实变了（均值/标准差从 −0.1274/0.4222 变为 −0.1421/0.4253）。编码器一变，条件信号就变，生成轨迹自然不同——它是"另一段同样有效的视频"，而不是 bf16 的近似拷贝。团队在 704×512 与 512×288 两档几何下做了盲测 4 组 A/B 对比（含人脸特写），判定可接受；也因此，用 SSIM/PSNR 逐像素对比两个版本是范畴错误。

可选加码：Pruna 精简 VAE 解码器再省 6.6 GB

仓库还带了一份 vae_decoder_pruna.safetensors——PrunaAI 的剪枝蒸馏版视频 VAE 解码器（690,025,680 字节，SHA-256891ec5f0680acea9acbdd651c9756a26c5d3298480224356cf5ea86071846f79可校验完整性）。

它的收益在"解码是瓶颈"的高分辨率场景最明显：

• 解码速度约2 倍，单片段墙钟时间 −15.9%；
• 在 704×512×121 这种解码受限的规格下，峰值从21.1 GB 压到 14.5 GB，把一次"超预算触发换页"的运行变成预算内的运行；
• Swift 端可通过LTX2Configuration.vaeDecoderPath或环境变量LTX_VAE_DECODER=pruna选用，在 low tiers（compact24、balanced32）下已是默认解码器。

由于 int8 编码器是出厂低配档的默认选择，这个文件才同时托管在本仓库，保证组件树可以独立解析。

上手路径：24 GB 机器跑 LTX-2.5 的正确姿势

1. 获取仓库（只读使用）：

git clone https://gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx-q8

2. 用 int8 编码器 + DiT 流式加载的组合（前面说过，缺一不可）；
3. 低内存档位（如 compact24）下，Pruna 解码器默认启用，无需额外配置；
4. 若还想再压 DiT，可单独搭配ltx-2.5-mlx-ditq8的 int8 DiT——两条轴互相独立，随意组合。

📦许可提醒：本项目基于 Lightricks LTX-2.5 衍化，采用 LTX-2 Community License（见 LICENSE.md 及可接受使用政策快照 ltx-acceptable-use-policy-snapshot-2026-08-12.pdf），包含附件 A 的收入门槛与竞业条款，分发时需原样传递这些条款。商用前请务必细读。

小结

LTX-2.5 的 24.8 GB 内存门槛，本质是bf16 文本编码器这块与分辨率无关的固定地板——它让 24 GB/32 GB 机器在流式加载后依然无路可走。ltx-2.5-mlx-q8 的答案是：int8（group 64、affine）量化编码器并精确保护embed_tokens，配合 DiT 流式加载，把峰值压到 14.6 GB，且保真度贴近 bf16 理论下限。对想在 Mac 上本地跑音视频生成的朋友，这大概是目前最完整的"低内存破局"参考样本。🎬