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

深入 ltx-2.5-mlx-q8 量化配方int8 group 64 完整拆解embed_tokens 为何必须保持 bf16如果你想在 24 GB 甚至 16 GB 内存的 Apple Silicon 上跑 LTX-2.5 文生视频ltx-2.5-mlx-q8是目前最实用的一站。它的量化配方只有两句话int8、group 64并且刻意把embed_tokens排除在量化之外、保持 bf16。这一组合把 Gemma-4 文本编码器从 23.8 GB 压到 13.6 GB直接把整机峰值内存从「24/32 GB 都超预算」拉回 14.6 GB 左右。本文用仓库里的真实文件把这个配方逐项拆开。项目说明基座Lightricks/LTX-2.5与 bf16 原版唯一差异是文本编码器量化对象gemma4-12b-ltx-v1文本编码器119 亿参数量化方案int8、group_size 64、affine 模式关键例外embed_tokens保持 bf16体积13.6 GBbf16 版 23.8 GB许可证LTX-2 Community License见 LICENSE.md一、为什么量化对「小内存机器」是刚需而不是锦上添花先看一个反直觉的测量结论在 DiT 使用流式streaming加载的情况下LTX-2.5 的峰值内存由一个与视频几何尺寸基本无关的 ~24.8 GB 下限决定——实测 256×256×9 和 512×288×121 两段视频峰值内存相差不到 0.01 GB。上图示意bf16 编码器构成一条与分辨率无关的内存「地板线」int8 编码器把地板从 24.8 GB 降到约 14.6 GB。这条地板线就是bf16 文本编码器本身如果是「解码瓶颈」峰值会随几何尺寸增长而它不增长。于是24 GB 机器超预算 ❌32 GB 机器也超预算 ❌换上 int8 编码器后峰值14.6 GB / 15.4 GB✅更关键的是 README.md 里的一句话两个杠杆缺一不可。常驻内存受 DiT 约束编码器量化在不开流式加载时完全「看不见」而只开流式、不换编码器地板线依然超预算。二、配方拆解int8 group 64 到底做了什么2.1 量化参数写在哪个文件里打开 gemma4-12b-ltx-v1/config.json配方一目了然quantization_config: { group_size: 64, bits: 8, mode: affine }三个参数分别意味着参数值含义bits8权重值用 int81 字节存储group_size64每 64 个权重为一组共享一组缩放参数modeaffine每组同时带**缩放scale和偏置bias**两个参数2.2 量化张量长什么样在 MLX 的 affine 量化里一个线性层的权重会被存成三元组。以 48 层中的第 0 层的q_proj为例gemma4-12b-ltx-v1/model.safetensors.index.json 里能找到这三个键language_model.model.layers.0.self_attn.q_proj.weight # int8 权重 language_model.model.layers.0.self_attn.q_proj.scales # 每 64 个元素一个 scale language_model.model.layers.0.self_attn.q_proj.biases # 每 64 个元素一个 bias反量化时执行w q * scale bias逐组。group 64 的意义权重分布在整张矩阵上差异很大组越小、每组能拟合的局部范围越准精度损失越低代价是 scale/bias 的元数据变多。64 是 MLX 生态里 int8 的常用折中值。2.3 哪些层被量化、哪些没有逐条核对权重索引全模型共1655 个张量规律非常干净类别数量存储格式量化线性投影每层 q/k/v/o gate/up/down 共 7 个 × 48 层48 × 7 328个.weight各配一套.scales.biasesint8 值 bf16 缩放元数据各层 RMSNorm 权重全局model.norm48 × 13 1bf16 原样layer_scalar逐层标量48bf16 原样language_model.model.embed_tokens.weight1bf16 原样⭐其中embed_tokens是词表 262144 × 隐层 3840 的查表矩阵bf16 下独占2.01 GB——它是全模型里最大的单个非量化块也是本文的戏眼。2.4 13.6 GB 是怎么来的算给你看索引文件 model.safetensors.index.json 的 metadata 写着total_size: 13595999840≈13.6 GB、total_parameters: 11907350272。拆开验证组成字节数int8 权重值11,554,789,504 个值≈ 11.55 GB词嵌入embed_tokensbf16262144 × 3840≈ 2.01 GBscales biases 元数据各 90,048 个组 × bf16 × 2 字段 × 48 层≈ 43.6 MB全部 Norm 权重 48 个layer_scalarbf16≈ 1.2 MB合计≈ 13.6 GB✅对照 bf16 原版 23.8 GB328 个线性从 bf16≈10.76 GB换成 int8元数据≈4.30 GB省下约6.46 GB再加上词嵌入等其余部分整体从 23.8 GB →13.6 GB数字完全吻合。三、为什么 embed_tokens 必须保持 bf16这是整个配方里最值得细看的一个决策。README 给出的依据README.md可以翻译成三层理由1它是整条链路的「第 0 环」。在 LTX-2.5 里文本编码器输出的隐藏状态一共 49 个每层一个。其中state 00 的定义就是embedTokens(ids) · embedScale——它有两个双重身份是connector 直接消费的 49 个状态之一connector 结构见 embedded_config.jsonconnector_num_layers: 8、connector_num_learnable_registers: 128它把编码器输出接成 DiT 的 cross-attention 条件是全部 48 层 transformer 的输入——后面每一层的残差都叠在它上面。量化它意味着这个「地基」状态会单独发生偏移且误差会一路传播进所有 48 层和 connector没有机会被后续层「修正」。2它是一张纯查表量化收益极低、风险极高。embed_tokens是一次索引取行操作每个 token 只取自己对应的那一行向量。int8 group 64 的误差对「连续计算的矩阵乘」影响有限但对「直接当作后续计算起点」的向量却是实打实的位移。花 2.01 GB 的 bf16 保住它换来的是一条干净的地基。3state 00 1.000000是它的指纹。README 提到一个漂亮的验证方法如果 embed_tokens 保持 bf16那么量化版与 bf16 版对比时state 00 的相似度应当精确等于 1.000000因为该状态的计算路径上没有任何量化操作。一旦它不是 1说明配方被污染了。这是量化验证里「一处指纹、全局安心」的典型设计。顺带一提配置里tie_word_embeddings: trueconfig.json且索引中没有独立的lm_head——权重索引中唯一的大块非量化张量就是embed_tokens与配方描述一一对应。四、保真度怎么验证别看整数组余弦量化文本编码器的验收仓库给了三个层层递进的证据① 连接器输出相似度决定性指标。在valid token 位置上int8 版读数为0.999820bf16 版的理论下限floor是0.999879——几乎贴着地板。② 为什么不能看「整数组余弦」。短提示词下1024 个位置里大部分是 learned registers可学习寄存器它们在所有编码器版本间都完全相同会把整数组相似度「稀释」330 倍。README 里的实证一个被刻意污染deliberately-poisoned的对照组整数组余弦能拿 0.994316但真实 token 位置上只有0.829329。整数组好看 ≠ 真的没坏。③ 盲测 A/B 感知评估。必须接受一个事实样本画面会移动。输出与 bf16 版不逐位相同均值 −0.1421/σ 0.4253 vs −0.1274/0.4222——因为换了编码器条件变了扩散轨迹必然不同它是一条「不同但同样有效」的视频。因此团队在 704×512 与 512×288 两种几何下做了4 对盲测 A/B含面部特写提示词结论是可接受而拿 SSIM/PSNR 去对比两版画面属于「范畴错误」category error。五、组合玩法与使用提示编码器与 DiT 是两条独立的量化轴。本仓库不含量化 DiT见 README.mdDiT 的 int8 版本在mlx-community/ltx-2.5-mlx-ditq8。int8 编码器可以随意搭配 bf16 或 int8 DiT。PrunaVAED 可选瘦身解码器。仓库附带 vae_decoder_pruna.safetensors解码速度约 2 倍、解码激活峰值显著更小在 704×512×121 的解码瓶颈场景下峰值从 21.1 GB 降到 14.5 GB。配套配置文件DiT 结构见 config.json48 层、cross_attention_dim 4096完整管线嵌入配置见 embedded_config.json。许可证提醒基于 Lightricks LTX-2.5 的衍生模型沿用其条款含 Attachment A 收入门槛与竞业限制再分发须按 §3 传播条款。详见 LICENSE.md。六、写在最后ltx-2.5-mlx-q8的配方值得新手记住三点量化要选准对象——328 个线性投影全部 int8 group 64省出 6.5 GB量化要会「留一手」——embed_tokens作为第 0 环状态和全部 48 层的输入保持 bf16 是整条链路的地基state 00 1.000000就是它的保真指纹验证要看对位置——只在 valid token 上量相似度整数组余弦会被 learned registers 稀释出假象。23.8 GB → 13.6 GB峰值内存 24.8 GB → 14.6 GB这套「int8 group 64 embed_tokens 保 bf16」的组合拳正是小内存 Apple Silicon 跑起 LTX-2.5 文生视频的关键。创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

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

相关推荐

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

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

Pot-Desktop 3分钟装好：划词与截图OCR一次跑通

更多资讯

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 成本测算与选型避坑（附配置）

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