Recover-LoRA：4-bit 压缩掉的精度，Edge0 怎么找回来

Recover-LoRA：4-bit 压缩掉的精度，Edge0 怎么找回来

【免费下载链接】Edge0-35B-A3B-preview项目地址: https://ai.gitcode.com/hf_mirrors/Edge0/Edge0-35B-A3B-preview

把 35B 参数的 MoE 模型塞进 3 GiB 内存跑起来，靠的是两条路：4-bit 量化把权重体积压到四分之一，SSD 流式加载把不激活的专家留在磁盘上。但量化从来不免费——16 个离散档位装不下 fp16 里连续分布的权重值，误差一定会进来。Edge0 开源预览模型 Edge0-35B-A3B-preview 给出的答案是 Recover-LoRA：冻结 int4 基座，用一份在"学生路径"上蒸馏出来的 LoRA 适配器，把量化压掉的精度补回来，最终五个公开基准平均只比 fp16 原版低 3.9 分。本文结合仓库源码与配套论文，拆解这条恢复链路到底补回了什么、怎么补，以及它对端侧量化技术路线意味着什么。

一、4-bit 压掉的是什么：先从配置文件说起

打开仓库根目录的 config.json，量化方案直接写在quantization字段里：主权重4-bit、group_size=64、affine 模式——即每 64 个元素为一组，共享一组 scale 与 zero-point。再看 model.safetensors.index.json，每个线性层都落盘为weight、scales、biases三份张量，这正是分组仿射量化在存储层面的形态：整数权重 + 每组浮点缩放参数，推理时反量化回浮点参与计算。

这套配置里有两个细节值得单独拎出来：

• 40 层、256 专家、每 token 激活 4 个（K=4），稀疏度决定了活跃权重远小于总参数量，这是 SSD 卸载能成立的前提；
• 全部 40 层的mlp.gate与mlp.shared_expert_gate被单独覆盖为8-bit。gate 是 MoE 的路由器，负责决定"把这一 token 交给哪几个专家"；shared_expert_gate 控制共享专家的门控。它们的体量在模型中占比极小，却决定了计算的分发方向——Edge0 宁可让它们多占一倍比特，也不允许路由决策被 4-bit 的粗粒度拖累。

那 4-bit 为什么必然损失精度？两个机制叠加：其一，量化本质是舍入——fp16 里连续分布的权重值只能落到 16 个离散档位上，这一步不可逆地引入舍入误差；其二，affine 分组量化对分布 outlier 极度敏感——一组 64 个元素中只要出现少量远大于均值的离群值，该组的 scale 就会被拉宽，其余元素被压缩到更窄的有效区间，有效精度进一步缩水。对稠密模型，这种误差还只污染单层输出；对 MoE，误差会被放大：量化后的专家输出与 fp16 专家输出存在系统性偏差，逐层传播、在长链推理中累积，甚至会让后续层的路由"选错专家"。于是 Edge0 面对的是双重损失源——int4 对专家计算的精度侵蚀，加上由此引发的路由偏移。这也解释了为什么单纯"换更好的量化算法"治标不治本：误差已经进入计算路径，必须有人把它补回来。

二、Recover-LoRA：在"学生路径"上蒸馏回精度

Recover-LoRA 的思路可以浓缩为一句话：既然 4-bit 的误差无法避免，就让模型学会用自己的方式弥补它。结合配套论文《The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction》与仓库文件，机制分三步：

第一步：冻结 int4 基座。量化后的基座权重只读，不被微调改写。这保住了量化的全部内存收益——基座仍是 4-bit 的约 19 GB 规模，而恢复用的 lora_edge0_35b.safetensors 与 prerouter_edge0_35b.safetensors 只是挂在基座旁的小体量适配器，与 4 个基座分片（model-00001-of-00004.safetensors 等）一起构成一个完整的可加载模型目录。

第二步：在 student 路径上蒸馏。论文原文给出了准确定义："an unmerged recovery LoRA, trained on the student path, pays back the quality lost to int4 quantization and routing replacement"。所谓 student 路径，就是端侧真实运行的完整链路——int4 专家计算 + prerouter 路由替换。LoRA 以 fp16 teacher（即基座 Qwen3.6-35B-A3B）的输出为监督信号，在这条整体降级的路径上端到端训练。因此它补偿的不仅是量化舍入误差，还包括路由替换引入的偏差——这正是第一节说的双重损失源，一次性对齐。

第三步：不合并（unmerged）。适配器以增量形式在推理时动态叠加，不写回基座。这意味着同一份只读的 4-bit 基座可以同时挂多套适配器，服务不同任务、不同语言或不同客户，无需为每一套适配重新量化一份基座——README.md 明确把它列为批量服务的核心卖点："one read-only base serves many LoRA adapter sets without re-quantization"。

把第一节的 8-bit gate 设计放回这个体系里，精度保护的层次就很完整了：路由决策用更高位宽先保住，专家计算误差交给蒸馏 LoRA 补偿，prerouter（prerouter_edge0_35b.safetensors）提前一个 token 预测下一层路由，让 SSD 读盘与计算重叠——精度和速度的问题被分而治之。

三、只掉 3.9 分：五个基准的实测账本

机制说得通，还要数据说话。README.md 的 Quality 一节用 OpenCompass 在完全相同的设置与参数下，对比了 edge0 流水线（int4 + 适配器）与 fp16 基座，满分 100：

平均差距 3.9 分。逐项看分布很有意思：掉分最多的是 AIME 2026（-6.1），数学推理对误差最敏感——推理链越长，量化误差累积越明显，符合预期；掉分最少的是 GPQA-Diamond（-2.0），单步知识判断受量化影响最小；指令遵循 IFBench（-3.8）与代码生成 HumanEval（-4.2）居中。

作为参照系，未经恢复补偿的裸 4-bit 模型在同类基准上的退化通常显著大于这个量级。用这 3.9 分换来的，是 4-bit 的体积与实打实的端侧性能：Mac mini M4 Pro（24 GB）实测解码 14.9–17.7 tok/s、prefill 冷/热 113/140 tok/s、峰值活跃内存仅 2.9 GiB；社区在 iPhone 上的复测也验证了 6.4 tok/s、约 4 GB 内存的组合。可以说，"3 GiB 内存跑 35B 且质量不掉档"在这个模型上第一次同时成立——质量由 Recover-LoRA 兜底，内存与速度由 SSD 卸载与 prerouter 兜底。

四、对端侧量化路线的影响

Recover-LoRA 的意义不止于这一个模型。它把端侧部署的范式从"量化即终点"推进到"量化 + 蒸馏补偿"，并留下三个可复制的结论：

其一，4-bit 从"凑合能跑"变成"质量可用"。此前端侧 4-bit 模型给人的普遍印象是"能跑但明显变笨"。Recover-LoRA 用一套可复现的蒸馏流程把退化压进个位数，让 4-bit 有理由成为端侧首选位宽——相比 8-bit 体积减半，意味着相同内存预算下模型规模可以翻倍。

其二，模型发布格式的"三件套化"。这个仓库本身就是范式样本：int4 基座分片 + lora_edge0_35b.safetensors + prerouter_edge0_35b.safetensors，三者共存、由 edge0 自动加载。模型发布不再是"一个权重文件"，而是一套"基座 + 恢复层 + 调度层"的组合——基座只读共享，恢复与调度按需叠加，天然支持多适配器复用。

其三，内存、速度、质量三个角被同时补齐。SSD 专家流式加载解决内存墙，prerouter 预测路由隐藏存储延迟（解码吞吐最高提升 59%，且增益随存储延迟、模型规模与 K 值增大），Recover-LoRA 解决精度损失。三者互为前提：没有 Recover-LoRA，SSD 卸载省下的内存只会换来一个"变笨的模型"，毫无意义。

边界同样要讲清楚：这是 preview 版本，README.md 如实列出了局限——agent 能力（工具调用、多步规划、长程自主）尚未优化，将在正式版大幅加强；MLX 后端目前只面向 Apple Silicon；长上下文会显著增长 KV cache，3 GiB 峰值内存以短上下文为前提。这些局限不削弱 Recover-LoRA 本身的通用价值：当算力与内存都不够时，"冻结量化基座 + 蒸馏适配器补偿"比硬扛 fp16 更聪明，而这条路径对任何因量化受损的端侧模型都成立——4-bit 不再是终点，而是补偿链路的起点。

【免费下载链接】Edge0-35B-A3B-preview项目地址: https://ai.gitcode.com/hf_mirrors/Edge0/Edge0-35B-A3B-preview