为什么 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 文本编码器量化成了int813.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: AudioVideo48 层 Transformer一次完整推理涉及多个大部件部件文件大小作用文本编码器int8 版gemma4-12b-ltx-v1/≈13.6 GB把提示词编码成视频生成的条件信号Connector 模块connector.safetensors≈6.3 GB文本条件到 Transformer 的衔接空间上采样器spatial_upscaler_x2_v1_1.safetensors≈0.93 GB分辨率 2 倍上采样VAE 扩散解码器vae_diffusion_decoder.safetensors≈0.78 GB潜空间解码为画面VAE 解码器vae_decoder.safetensors≈0.76 GB标准解码器Pruna 精简解码器vae_decoder_pruna.safetensors≈0.64 GB可选解码约 2 倍速时间上采样器temporal_upscaler_x2_v1_0.safetensors≈0.24 GB时长 2 倍上采样音频 VAE / 声码器audio_vae.safetensors、vocoder.safetensors≈0.35 GB生成同步音频时长预测头duration_head.safetensors≈4 MB预估片段时长模型架构细节如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 机器正式入场。但这里有一个容易被忽略的结论官方文档特别强调两个杠杆单独使用都无效⚠️组合结果只用 int8 编码器DiT 常驻峰值由 DiT 主导编码器瘦身完全不可见只做 DiT 流式加载编码器仍 bf1624.8 GB 地板原封不动int8 编码器 DiT 流式加载✅ 峰值 14.6 GB / 15.4 GB也就是说常驻内存时瓶颈是 DiT编码器怎么瘦都没用流式加载后瓶颈才轮到位地板才暴露出来。优化内存这件事永远是木桶最短的那块板在说话。量化后画质掉了多少看对指标别看整段余弦对文本编码器这种条件信号发生器官方给出的保真度指标是connector 输出在有效 token 位置上的余弦相似度int8 版本0.999820bf16 的理论下限0.999879差距几乎可以忽略。这里还埋了一个避坑点不要拿整段数组的余弦相似度来评判文本编码器量化。因为短提示词时1024 个位置中绝大多数是各版本完全相同的learned registers会把真实差异稀释 330 倍——一次故意注入错误的对照组整段余弦高达 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_DECODERpruna选用在 low tierscompact24、balanced32下已是默认解码器。由于 int8 编码器是出厂低配档的默认选择这个文件才同时托管在本仓库保证组件树可以独立解析。上手路径24 GB 机器跑 LTX-2.5 的正确姿势获取仓库只读使用git clone https://gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx-q8用 int8 编码器 DiT 流式加载的组合前面说过缺一不可低内存档位如 compact24下Pruna 解码器默认启用无需额外配置若还想再压 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 的答案是int8group 64、affine量化编码器并精确保护embed_tokens配合 DiT 流式加载把峰值压到 14.6 GB且保真度贴近 bf16 理论下限。对想在 Mac 上本地跑音视频生成的朋友这大概是目前最完整的低内存破局参考样本。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考