• 大模型
• 基础模型
• 模型量化
• 模型压缩
• 本地部署
• 人工智能

BTL-4-OptiQ-4bit-REAP-18B 是一个基于 MLX 框架的 MoE 大模型精简版：先用OptiQ 混合精度量化把父模型压到 4bit，再用REAP 专家剪枝砍掉一半路由专家，最终从 34.7B 参数/20.6GB 瘦身到18.3B 参数/11.5GB，运行时内存仅需约 14.5GB，可在 Apple Silicon 上流畅本地推理。下面用一篇技术白皮书带你完整复盘这套"量化+剪枝"流水线是怎么落地的。

一、核心数据一览：瘦身效果有多猛

先看这张对比表（来源：README.md），这是理解整个项目价值的锚点：

一句话总结：它变小了，但没有变慢——因为每个 token 依旧只激活 8 个专家，计算量不变，只是存储的"专家库"从 256 个缩小到 128 个。

二、血统溯源：badtheorylabs/BTL-4 到 18B 精简版

这个模型经历了两个阶段的"减肥"：

1. 第一代：OptiQ 量化。基座模型是badtheorylabs/BTL-4（一个 Qwen3.5-MoE 架构的多模态 MoE 模型，详见 optiq/metadata.json 中的base_model字段），先被 OptiQ 量化成 4bit 版本（即父模型 BTL-4-OptiQ-4bit）。
2. 第二代：REAP 专家剪枝。在量化版之上，用optiq prune-experts命令做专家剪枝，得到本仓库的 18B 版本。

两个阶段都没有动权重数值：保留下来的专家是从父量化模型逐位（bit-for-bit）拷贝的，不解量化、不重量化、不合并、不重训练。这意味着剪枝引入的误差只来自"删了谁"，而不来自数值精度损失。

三、OptiQ 量化方案：4bit 为主、8bit 兜底

很多人以为"4bit 量化"就是所有权重一刀切压到 4bit，实际上 OptiQ 用的是混合精度量化，策略更聪明。打开 optiq/metadata.json 可以看到关键配置：

• method:optiq_mixed_precision
• default_bits: 4，group_size: 64
• layers_per_bit_width:4bit 层 113 个，8bit 层 399 个，共 512 个量化层

也就是说：对精度敏感的层（如嵌入层、注意力投影、路由器 gate）保留 8bit，对"扛压"的专家 MLP 层压到 4bit，兼顾体积与质量。逐层的比特分配方案都记录在 config.json 的quantization字段里，可以逐层查证。

另外还有一个容易被忽略的细节：kv_config.json 里定义了KV Cache 量化方案——每隔几层的 KV 缓存也按 4bit/8bit 混合压缩（group_size 同样为 64），这是长上下文场景下省显存的关键，让 262K 上下文（max_position_embeddings: 262144）在 14.5GB 内存下成为可能。

四、REAP 剪枝原理：如何砍掉 50% 专家还保持质量

MoE 模型每层挂着 256 个路由专家，但每次推理只激活 top-8。大量专家在真实流量中"出镜率"极低，这就是剪枝空间所在。

4.1 怎么决定"删谁"

本项目采用REAP（REAP the Experts，ICLR 2026）排序规则：

专家得分 = 路由权重 × 专家输出范数，在该专家实际服务过的 token 上取条件均值（conditional mean）

直觉理解：一个专家"被调度得多"且"输出信号强"，得分就高，优先保留；反之淘汰。值得注意的是，optiq_metadata.json中记录"ranking": "conditional"——这个规则并非拍脑袋选的，而是拿"条件均值"与"普通均值"两个候选方案分别对未剪枝模型打分，选出了胜出的条件均值方案。

4.2 剪枝配置全记录

所有剪枝参数都完整记录在 optiq_metadata.json 中，可审计、可复现：

• method:reap，retention_target: 0.5（保留 50%）
• experts_per_layer: 每层均匀保留128/256（uniform_retention: true）
• calibration: optiq 六领域校准数据混合，仅8 个样本，seed: 42
• min_expert_coverage: 0.953125（专家覆盖率下限，防止某层"断供"）
• retained_experts: 逐层列出了保留的 128 个专家原始编号清单——想复核第 N 层删了谁，直接查这份清单即可

专家库体积的账也算得很清楚：expert_bytes_before约 19.6GB →expert_bytes_after约 9.8GB，正好减半，与磁盘总容量 20.6GB → 11.5GB 的降幅吻合。

五、质量验证：KL 散度 0.114 说明了什么

剪枝最让人担心的就是"越剪越傻"。本项目在 README.md 中披露了两个层面的证据：

1）本 checkpoint 实测：KL 散度 0.114。剪枝模型与未剪枝父模型的输出分布 KL 散度仅为 0.114——作为参照，剪枝后明显劣化的 checkpoint 该值会超过 1.0。0.114 处于"人工审阅几乎无法区分生成质量"的安全区间。

2）同配方参考基准（诚实标注：本 checkpoint 未单独跑基准）。同一套 50% 保留率的配方在架构相同的 Qwen3.6-35B-A3B-OptiQ-4bit-REAP-19B 上端到端验证过：

结论很清晰：损失集中在 MMLU 类知识广度，而程序化能力（数学、指令遵循、代码）基本无损甚至略升。对日常对话、写作、编程场景，这是相当划算的取舍。

六、快速上手：两条命令跑起来

得益于 MLX 生态，部署极简：

pip install mlx-optiq optiq serve --model mlx-community/BTL-4-OptiQ-4bit-REAP-18B

也可以用 mlx_lm 直接加载生成（完整示例见 README.md 的 "Use it" 章节）。生成行为由 generation_config.json 定义：temperature: 1.0、top_k: 20、top_p: 0.95采样策略，对话格式由 chat_template.jinja 驱动。

七、文件资料导读：每个文件在干什么

八、写在最后：这套流程能复制到你的模型吗

可以。整条流水线只有三个核心动作：OptiQ 混合精度量化 → REAP 条件均值排序剪枝 → KL 散度验收，且全程在量化域内完成（不需要 BF16 父模型参与，不需要重训练）。如果你的场景里也有"MoE 大模型跑不动"的痛点，这套 50% 专家保留 + 4bit 主导的配方，配合 README.md 中公开的验收标准（KL < 1.0、程序能力不回退），就是一个可以直接抄作业的完整方案。

• 大模型
• 基础模型
• 模型量化
• 模型压缩
• 本地部署
• 人工智能