资讯详情

把ltx-2.5-mlx的62.4GB显存占用砍掉35%:DiT驱逐与文本编码器int8量化双技详解

📅 2026/10/18 8:08:56 | 华诺云谱 👁 阅读
把ltx-2.5-mlx的62.4GB显存占用砍掉35%:DiT驱逐与文本编码器int8量化双技详解
人工智能基础模型大模型媒体生成本地部署视频【免费下载链接】ltx-2.5-mlx项目地址https://ai.gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx点击查看免费下载ltx-2.5-mlx是 Lightricks 22B 音视频联合生成模型LTX-2.5的 MLX 格式转换版专为 Apple Silicon 打造支持文生视频、图生视频与音画联合生成。但它默认配置的峰值内存占用高达62.4 GB直接把不少 Mac 用户挡在门外。好消息是官方实测出两个几乎零损失的显存优化手段——DiT 驱逐eviction与文本编码器 int8 量化最高可以把 62.4 GB 的占用直接砍掉 35%。这篇文章用最直白的方式把这两个优化的原理、实测数字和注意事项一次讲清楚。一、为什么默认要 62.4 GB先看懂三大内存大头 LTX-2.5 采用按组件拆分split components的权重布局各组件文件与规模如下数据来自 README.md权重文件角色参数量备注transformer-distilled.safetensors蒸馏版联合音画 DiT8 步固定、CFG122B生成主力transformer-dev.safetensors完整版dev联合音画 DiT22B二选一使用gemma4-12b-ltx-v1/Lightricks 调优的 Gemma-4-unified 文本编码器12B显存大头vae_encoder.safetensors / vae_decoder.safetensors视频 VAE编码/解码726M—vae_diffusion_decoder.safetensorsDiffVAE 一步 x0 视频解码器417M—audio_vae.safetensors / vocoder.safetensors音频 VAE BigVGAN v2 BWE182M—connector.safetensors文本嵌入连接器 聚合投影——spatial_upscaler_x2_v1_1.safetensors×2 空间 latent 上采样器498M—temporal_upscaler_x2_v1_0.safetensors×2 时间 latent 上采样器131M—duration_head.safetensors提示词→时长预测头1.9M—内存结构的关键事实在 128 GB Apple Silicon 统一内存上实测448×320×9 帧、bf16DiT 本体bf16 下常驻约37.98 GB是硬性地板文本编码器才是惊喜gemma4-12b-ltx-v1/是未量化的bf16 12B磁盘 23.8 GB、常驻约24.4 GB——比 LTX-2.3 时代 4-bit Gemma-3约 7 GB大了三倍多照搬 2.3 的经验会严重低估 2.5 的占用默认调度下文本编码器与 DiT同时驻留峰值即62.40 GB。⚠️ 模型为 48 层音视频联合 DiTconfig.json 中num_layers: 48、model_type: AudioVideo音频/视频双路注意力并行这是它比纯视频模型更吃内存的根源之一。二、技巧一DiT 驱逐——不花钱的调度的魔法 效果一览来源README.md 内存小节调度方式峰值占用默认文本编码器与 DiT 共驻62.40 GB编码阶段前后将 DiT 驱逐40.66 GB一次调度改动直接−21.74 GB−34.8%这就是标题里砍掉 35%的来源。为什么 DiT 驱逐是免费午餐生成流程里文本编码和扩散去噪是两个不重叠的阶段编码阶段文本编码器gemma4-12b-ltx-v1 连接器connector.safetensors工作此时 DiT 完全用不到去噪阶段DiT 迭代 8 步蒸馏版生成 latent此时文本编码器已完成使命。DiT 驱逐就是在阶段切换的间隙把 22B 的 DiT 从内存中卸载、需要时再载入。它本质是调度优化不是精度妥协✅ 输出逐位一致bit-identical✅ 耗时只在运行间噪声范围内波动✅ Swift 消费端ltx-2-mlx-swift默认开启。换句话说如果你的运行框架支持该选项优先开它无任何代价。三、技巧二文本编码器 int8 量化——再省 10 GB肉眼不可辨 ️DiT 驱逐解决了 34.8%剩下的空间从 24.4 GB 的 bf16 文本编码器身上挤。推荐配方官方实测数值保真档int8 量化group size 64embed_tokens保持 bf16 不量化原因见下文避坑编码器常驻24.42 GB → 14.20 GB端到端峰值62.40 GB → 52.18 GB。质量到底损失了多少官方给了两组数据结论是可忽略指标数值含义有效 token 余弦相似度int8 vs 参考0.999820高于 bf16 基线下限 0.999879 的容忍带属数值保真盲测 A/B6 对样本操作者盲评3 平局、2:1、全部非常接近感知中立而int4 被明确拒绝同一指标只有0.996728。README 还特别提醒市面上一些第三方 MLX 包直接附带 4-bit 版本编码器且无任何公开质量数据自建量化时请勿盲目跟进。⚠️ 自己动手量化时两个必踩的坑默认命令会把embed_tokens也量化掉。mlx_lm.convert -q的默认行为如此而embed_tokens既是 hidden state 00也是全部 48 层的输入必须排除mixed_*配方更差该编码器启用tie_word_embeddings: true见 gemma4-12b-ltx-v1/config.json 第 130 行混合配方会把嵌入表压到 3 bit质量进一步劣化。 本仓库不发布量化版权重量化配方在消费端仓库ltx-2-mlx的ltx-2.5分支中需要自行执行转换。四、双技叠加优化路线怎么选两个杠杆可以叠加README 原文Two levers, and they stack方案峰值占用相对默认质量影响默认共驻62.40 GB—基线仅 DiT 驱逐40.66 GB−34.8%输出逐位一致仅文本编码器 int852.18 GB−16.4%数值保真、感知中立驱逐 int8 叠加可进一步压低—两者叠加选型建议内存 ≥ 64 GB默认配置直接跑或用蒸馏版 transformer-distilled.safetensors8 步、CFG1流程更短内存 48~56 GB先确认调度端已启用 DiT 驱逐40.66 GB 即可跑通 448×320 级别分辨率需要更大分辨率时再叠加 int8追求极限容量驱逐 int8 全上并关注下方第四节的可选解码器。五、附赠低内存机型的解码器替换 PrunaVAED 如果你的瓶颈在解码阶段例如 24 GB 档位的 M5 ProREADME 提供了一个可选的剪枝蒸馏解码器 vae_decoder_pruna.safetensorsPrunaAI PrunaVAED 的 MLX 转换版解码约快 2×解码激活峰值显著下降实测 704×512×121 档位下峰值21.1 → 14.5 GB把超预算换页的运行拉回预算内Swift 端可用环境变量LTX_VAE_DECODERpruna或LTX2Configuration.vaeDecoderPath启用代价是解码结果近但不逐位属可接受范围。更多细节见 README.md 对应小节。六、快速上手一条命令跑起来 拉取消费端仓库权重即本仓库mlx-community/ltx-2.5-mlxgit clone -b ltx-2.5 https://gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx # 消费端 ltx-2-mlx 需另行 clone 后 uv sync生成一条 768×512、121 帧的蒸馏版视频uv run ltx-2-mlx generate \ --model mlx-community/ltx-2.5-mlx \ --distilled \ --prompt a red fox standing in deep snow, closeup wildlife photography, golden hour \ -H 512 -W 768 -f 121 --frame-rate 24 -o fox.mp4完整用法与 Swift API 示例见 README.md Usage 小节。七、文件资料与延伸阅读 资料路径项目总览组件表、内存数据、量化配方要点README.md内存实测两技详解README.md#L91-L117流水线 transformer 配置config.json、embedded_config.json文本编码器配置48 层、tied embeddings 证据gemma4-12b-ltx-v1/config.json许可证与可接受使用政策快照LICENSE.md、ltx-acceptable-use-policy-snapshot-2026-08-12.pdf⚖️使用提醒权重为 LTX-2.5 衍生模型遵循LTX-2.x Community License。年营收 ≥ 1000 万美元的商业实体使用前须向 Lightricks 购买授权机器生成内容需按许可附件 A 披露。使用即接受条款详情读 LICENSE.md。总结面对 ltx-2.5-mlx 的 62.4 GB 峰值占用——先开DiT 驱逐−34.8%零质量损失、Swift 端默认开启再按需做文本编码器 int8 量化group 64、保留 bf16embed_tokens端到端 52.18 GB、感知中立。两步叠加多数 Apple Silicon 机型都能把这条 22B 音视频生成流水线真正跑起来。赞分享人工智能基础模型大模型媒体生成本地部署视频【免费下载链接】ltx-2.5-mlx项目地址https://ai.gitcode.com/hf_mirrors/mlx-community/ltx-2.5-mlx点击查看免费下载相关推荐如何在64GB Mac上流畅运行LTX-2.5文生视频ltx-2.5-mlx-ditq8的int8量化显存减半完全指南如何在64GB Mac上流畅运行LTX 2.5文生视频ltx 2.5 mlx ditq8的int8量化显存减半完全指南 想在 64GB 统一内存的 Mac 上8GB 显存玩家的极限LTX-2.5 的 INT8 量化 低显存模式实测清单8GB 显存玩家的极限LTX 2.5 的 INT8 量化 低显存模式实测清单 220 亿参数、一次前向就要吃掉几十 GB 权重的扩散 Transforme大模型媒体生成视频音频多模态为什么Qwen-Image-2.1-FP8能把显存砍半FP8/INT8量化原理与LPIPS质量损失详解为什么Qwen Image 2.1 FP8能把显存砍半FP8/INT8量化原理与LPIPS质量损失详解 Qwen Image 2.1 FP8 是 Unslot人工智能大模型基础模型媒体生成模型量化Qwen创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
📝

华诺云谱内容团队

资深建站顾问 · 行业研究员

10年+企业数字化服务经验,专注智能建站、SEO优化与品牌营销,持续输出建站技巧、行业洞察与营销干货,已帮助5000+企业实现数字化增长。

你可能需要的服务

订阅华诺云谱资讯周报

每周一封,精选建站技巧、SEO与营销干货,直达邮箱。已有 8,000+ 企业主订阅,助你少走弯路。

↑