• 人工智能
• 大模型
• 模型量化
• 本地部署
• 代码模型

flint-oQ5e 是 Recursive 开源 40B MoE 大模型 Flint 面向 Apple Silicon 的oQ5e 量化权重，磁盘占用仅 28.1 GB（约 5.65 bpw）。本文从开发者视角，带你拆解这个仓库中的safetensors 权重分片布局、config.json里的量化参数与 imatrix 校准报告，看懂 5 bit 与 8 bit 混合精度到底是怎么分配的 🔬。

一、先看全貌：这是一个什么样的权重包

在动手翻文件之前，先建立三个关键印象：

• 🧩体量：40B 总参数、每 token 激活约 2.5B；bf16 原始体积 79.6 GB，量化后28.1 GB
• ⚡结构：49 层 = 2 个稠密层 + 47 个 MoE 层；每层 256 个路由专家（top-6）+ 1 个共享专家；35 层滑动窗口注意力（513 tokens）+ 14 层全注意力，支持262k 上下文
• 🎯量化方案：oMLX 的oQ5e—— 数据驱动的混合精度，路由专家 5 bit，其余"每个 token 都要读"的部分 8 bit，并用 imatrix 校准裁剪范围

官方对比数据（摘自 README.md）：相对 bf16 平均 KL 仅 0.089、困惑度 14.38 vs 14.30，top-1 一致率 86.2%；短上下文生成约 103 tok/s，峰值内存 28.2–29.7 GB。

二、仓库文件清单：每个文件是干什么的

三、safetensors 布局：1798 个张量如何切进 6 个分片

打开 model.safetensors.index.json，metadata.total_size为28092673321字节，与 README 宣称的 28.1 GB 完全吻合。weight_map共登记1798 个张量，每个张量都指向它所在的分片文件。

3.1 张量后缀的"四件套"规律

按后缀统计全部张量，规律非常清晰：

注意scales+biases数量一致且正好 486：这就是 MLXaffine 量化的标志——被量化的线性层同时保存weight / scales / biases三元组。例如：

language_model.model.layers.10.mlp.switch_mlp.gate_proj.weight # 5-bit pack 权重 language_model.model.layers.10.mlp.switch_mlp.gate_proj.scales # 每 64 个元素一组 language_model.model.layers.10.mlp.switch_mlp.gate_proj.biases # 零点对齐

未被量化的部分（input_layernorm.weight、k_norm、q_norm、expert_bias、softmax_offset、路由器mlp.gate.weight等）则只存一个weight，保持原始精度。

3.2 分片切法：为什么第 1 片特别大

统计各分片承载的张量数：片 1 有 1381 个，片 2～5 各约 93 个，片 6 有 44 个。原因是片 1 装的是"公共部分"——embed_tokens、lm_head、前 10 层（0–9）的全部张量；而 MoE 层的专家权重在 MLX 中是融合存储的：256 个专家的三组投影合并为switch_mlp.gate_proj / up_proj / down_proj三个大张量，所以每个 MoE 层只占约 93 个张量条目，片 2 起按 8 层一片切，片 6 收尾 42–48 层。

命名统一带language_model.前缀，因为权重是按 mlx-vlm 的模型类量化的；oMLX 与 mlx-vlm ≥ 0.7.10 可原样加载，而 mlx-lm 自带的flint模型期望无前缀名称。

四、量化参数全解：config.json 的 quantization 字段

config.json 的quantization块是理解 oQ5e 的核心，结构为"默认值 + 逐张量覆盖"：

"quantization": { "group_size": 64, "bits": 5, "mode": "affine", "language_model.model.layers.5.mlp.shared_expert.down_proj": { "bits": 8, ... } }

把全部覆盖条目按类型归类后，混合精度的分配一目了然：

也就是说，约 22 GB 的体积贡献自 5-bit 路由专家，其余"每 token 都要读"的注意力、共享专家、稠密层、词表层全部 8 bit——这正是 oQ 系列"数据驱动分配位数"的设计：量化分配器在 bf16 权重上逐层测量敏感度，而不是粗暴地全局降位。

README 还透露了一个实验结论：oQ4e上曾尝试把 group_size 提到 128，省了 1.2 GB，但平均 KL 从 0.222 恶化到 0.263 且没有更快，所以本仓库全部沿用 64（共享专家因 8-bit 精度冗余更大，用 128 也无妨）。

五、imatrix 校准报告：量化前的"体检单"

oQ5e尾缀里的e= imatrix pass。oq_imatrix_report.json 记录了这次校准的完整过程：

• 校准集：oqe_code_multilingual，请求 128 条样本、单条 512 token；自适应机制在第二轮补齐到256 条后判定覆盖充分（oq_imatrix_report.json）
• 覆盖检查：共安装 532 个采集模块（390 个Linear+ 141 个SwitchLinear）；47 层 × 3 投影 × 256 专家 =36096 个专家全部被激活到，active_ratio: 1.0，最冷门专家也被路由了 2 次以上
• 敏感度地图：sensitivity_map给出每层的敏感度数值（oq_imatrix_report.json），第 0 层最高（约 0.0496），第 47 层几乎为零（1.46e-06）——层与层之间的敏感度差距超过 4 个数量级，这解释了为什么"逐层分配位数"远比"一刀切"重要

imatrix 的作用只是按激活重要性挑选每个 group 的裁剪范围（clipping range），并不改变谁拿 5 bit、谁拿 8 bit 的分配。

六、模型结构关键参数速查

从 config.json 提炼的速查表：

采样参数见 generation_config.json：temperature 1.0、top_p 0.95、top_k 20、do_sample true。官方建议困难问题给足 32k 输出预算（推理与答案共享该预算），并在多轮对话中保留返回的 reasoning 内容。

七、如何加载这份权重

输出为标准 MLX affine 量化，无需自定义 kernel。推荐 oMLX（自带融合 MoE decode 路径，约 16% 加速）：

hf download mlx-community/flint-oQ5e omlx serve

或 mlx-vlm（≥ 0.7.10）：

pip install -U "mlx-vlm>=0.7.10"

八、常见问题

Q：bpw 5.65 是怎么来的？28,092,673,321 字节 ÷ 400 亿参数 ≈ 5.65 bit/参数——5-bit 专家占了大头，8-bit 部分拉高了均值。

Q：为什么分片 1 有 1381 个张量，其他片只有 93 个？片 1 还装了embed_tokens、lm_head和第 0–9 层；MoE 层专家被融合成 3 个大张量，条目数天然少。

Q：能在 mlx-lm 里直接跑吗？可以，但需要去掉language_model.前缀；oMLX / mlx-vlm 则原样加载。

Q：这份量化会掉点吗？README 的保真度表显示平均 KL 0.089、真实 top token 无可测损失，属于"有内存就选它"的近无损档位。

• 人工智能
• 大模型
• 模型量化
• 本地部署
• 代码模型