训练时量化 vs 事后量化：拆解 Bonsai 2 的三值内核，1.58-bit 路线凭什么保住 98% 性能

训练时量化 vs 事后量化：拆解 Bonsai 2 的三值内核，1.58-bit 路线凭什么保住 98% 性能

【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit

2026 年 9 月，PrismML 发布 Bonsai 2 27B——一个把 Qwen3.8-27B 的 54GB FP16 权重压缩到 5.9GB、综合基准平均分保留 98.2% 的三值（Ternary）推理模型。这个数字本身已经很有冲击力，但真正值得研究的，是它和过去两年"低比特量化"叙事的分道扬镳：传统路线在 4-bit 以下普遍崩溃——同一基座用 IQ2_XXS 压到 9.4GB，分数从 86.32 跌到 72.59；而 Bonsai 2 用更小的体积拿到 84.78。差别不在压缩率，而在权重被约束到低比特域的时机。本文从本地仓库的配置、编解码与运行时源码出发，逐层拆解三值内核的存储设计与推理路径，并梳理其白皮书背后的 1-bit 硬件路线图，说明 1.58-bit 路线为什么能在 4-bit 以下保持推理、编程与智能体能力不塌方。

训练时约束 vs 事后量化：同样的比特数，不同的失效方式

要理解 Bonsai 2 的"98.2%"，先得看清对照组是怎么失败的。主流的低比特部署是"事后量化"：模型先在 FP16 下完整训练，再用 GPTQ、AWQ 或 GGUF 的 IQ 系列做校准和压缩。这套流程的问题在于，权重分布是为高精度表示学习出来的，压缩器在推理前用一小段校准数据把它"投影"到低比特域，损失一旦发生就不可逆。更隐蔽的问题是标签与实际位宽脱节——README.md 明确指出，社区广泛使用的 Qwen3.8-27B "2-bit" 构建真实位宽是 2.8 bits/weight，体积 9.4GB。

Bonsai 2 走的是另一条路：权重在训练阶段就被约束到三值域，嵌入、注意力投影、MLP 投影、LM Head 全部端到端三值化，且"没有藏在低比特标签背后的高精度逃生舱"（README.md Highlights 一节的原话）。社区对这一路线的定性也很一致——"训练阶段即约束权重为低比特格式，而非传统事后量化，显著降低信息损失"。

仓库本身提供了可验证的证据链：

• config.json 声明model_type: prism_hadamard_qwen35，量化配置为{"bits": 2, "group_size": 128, "mode": "affine"}；
• hadamard.json 列出全部被折叠（folded）的投影权重清单，共 402 个模块；
• reload-validation.json 记录reload_logits_exact: true、checked_logits: 248320、packed_modules: 402——序列化往返后 logits 逐位一致，说明压缩不是"近似存储"，而是确定的表示。

效果差异在基准表里非常刺眼（README.md Benchmarks 一节，EvalScope + vLLM 同机同测、thinking mode）：

注意最后一行：Bonsai 2 的体积只有 IQ2_XXS 的三分之二不到，平均分却高出 12 分以上；离 UD-Q4_K_XL 只差 0.4 分，而体积是它的三分之一。更关键的是失效方式的差异。传统低比特的退化是选择性的：IQ2_XXS 在 MMLU-Redux 还能拿 88.93，到了 AIME26 只剩 57.5、LiveCodeBench 只剩 56.4——短链知识问答看起来没坏，一进入需要持续推理链的场景就崩。Bonsai 2 恰好在这两个"思维密集"基准上守住 95.83 与 90.07。README 还披露，同样的坍塌模式在上一代 Bonsai 对 Gemma-4-31B 的报告中复现过，说明这是压缩方法的属性，而非某个基座的问题。这正是"训练时约束"的回报：分布从一开始就适配离散域，推理链的中间状态不因突变的量化误差而漂移。

三值权重 {-1, 0, +1} 与共享缩放因子：1.585 比特的信息论账

三值权重的信息论下限是 log₂3 ≈ 1.585 bits/weight——这正是 BitNet b1.58 命名与 Bonsai 路线同源的数学根源。Bonsai 2 在此基础上加了一层分组共享缩放：每 128 个权重共享一个 FP16 scale。于是有效存储成本为：

1.585（三值码）+ 16/128（scale 摊销）= 1.71 bits/weight；计入少量保留高精度的张量后，全模型 1.72 bits/weight，相对 FP16 约 9.3 倍压缩。

这个账在 README.md 的 Weight Representation 一节有完整表述，也解释了为什么一个"三值"模型会被社区媒体标注成 1.76、1.71、2-bit 等多种说法——它们分别对应含 scale 摊销的理想值、GGUF 打包的 1.75，以及 MLX 容器实际落盘的 2.25。

真正值得展开的是容器层的位宽差异。runtime/codec.py 展示了两种 GGUF 打包到 MLX affine 格式的无损转码逻辑：

• PQ2_0：每 128 权重块占 34 字节，2 字节 FP16 scale + 32 字节 2-bit 槽位，对应 2.13 bits/weight；
• PTQ1_0：每块 28 字节，三值码按 3 进制密集打包（代码里(remainder * 3) >> 8的三值拆包循环），贴近信息论下限 1.75 bits/weight，但解包需要算术运算；
• MLX 容器：每块存 scale 和 bias 两个 FP16（config.json 的 affine 模式），落到 2.25 bits/weight。README 解释了关键设计——三值水平{-s, 0, +s}用scale = s, bias = -s就能精确重现，codec 转码时biases = -scales一行即是证据；bias 不携带新信息，纯粹是容器格式的代价。

存储总账在 README.md Memory Requirement 表：FP16 54GB → Ternary 理想 5.8GB → PTQ1_0 5.95GB → PQ2_0 7.21GB → MLX 2-bit 7.67GB。本仓库落盘 8.60GB 则含 0.92GB 的 FP16 视觉塔（语言模型与视觉塔同包分发，视觉塔不做旋转、不量化，原样透传）。

光有存储格式还不够，三值模型真正的工程难点在运行时如何直接消费压缩权重。runtime/runtime.py 的Packed模块给出了答案：前向传播中，非嵌入层先对激活施加fwht（块长为 1024 的归一化 Walsh–Hadamard 变换，乘上 hadamard.json 里那份固定 ±1 符号向量），再直接调用mx.quantized_matmul（group_size=128, bits=2）——权重永远不会被展开回 FP16；嵌入层则走mx.dequantize后施加逆变换。这印证了 README 的核心卖点："packed weights are consumed directly, never expanded back to FP16"。

Hadamard 旋转是整套设计的隐藏主角：每 128/1024 块用正交旋转打散权重能量分布，使三值化误差在块内均匀化。旋转被离线折叠进存储权重（hadamard.json 的weight_names清单、sign_widths: [5120, 6144, 17408]），因此不增加任何存储与权重搬运开销；运行时只需对激活做对称变换。折叠旋转以元数据形式声明，加载器要么执行匹配变换、要么拒绝加载——普通 MLX 加载器会跳过激活变换和逆嵌入查找，"返回错误输出而不是报错"，这正是 PACK-RUNTIME.md 反复强调必须使用包内runtime/的原因。

白皮书路线图：从软件内核到 1-bit 原生硬件

Bonsai 2 的技术路线与 Microsoft BitNet b1.58 一脉相承，白皮书与社区分析将其未来拆成两个阶段。

第一阶段是软件内核的"贴地飞行"。GGUF 版本以 PTQ1_0（5.95GB）和 PQ2_0（7.21GB）两种打包交付 llama.cpp 定制内核，实测吞吐（README.md Cross-Platform Throughput）：RTX 5090 上 PQ2_0 解码 129.9 tok/s、单 token 1.95 J，H100 上 113.9 tok/s，而 Apple M5 Pro 笔记本以 28.1 tok/s 交互式运行一个 27B 模型——FP16 基线 54GB 在这台机器上根本装不进去，所以"能跑起来"本身就是有意义的结论。两种打包是真实的权衡而非严格序贯：PTQ1_0 每步少搬 17% 权重数据，但密集三值的解包算术让它在 Ada 系与 L4（内存受限）上占优，在 Hopper/Blackwell（指令吞吐受限）上反而落后。能效侧同样有据可查：M5 Pro 解码时 GPU 轨仅 27.5W，对比 NVIDIA 显卡 300–455W 的板级功耗。

第二阶段是硬件原生化。社区情报显示，llama.cpp 主线已支持 1-bit（Q1_0）格式，但 Ternary 仍需定制后端；白皮书亦将"在每种目标硬件上把 footprint 优势还原成延迟优势"列为活跃工程目标（README Limitations 一节）。与之呼应的是生态侧的真实落地：高通联手 PrismML 将 1-bit Bonsai 用于 AI 眼镜的离线识图问答，iPhone 17 Pro 的 12GB 内存可原生运行 Bonsai 27B——AnythingLLM 创始人对后者的评价是"这才是 AI 真正的 DeepSeek 时刻"。这些信号指向的终局是原生 1-bit 内存计算硬件：当三值/二值权重不再依赖通用算子的解包开销，而是由 bit-serial 存算一体结构直接消费时，27B 级推理的功耗与延迟还会再降一个量级。Bonsai 2 在软件层已经把"表示即 1.58-bit"这件事做扎实了——剩下的，是等硬件来认领。

小结

训练时量化与事后量化的分野，本质是"分布适配"与"分布逼近"的分野。Bonsai 2 用 1.72 bits/weight 的三值表示 + 共享 FP16 缩放 + 折叠 Hadamard 旋转，换来 98.2% 的基准保留率，并首次证明 4-bit 以下的推理链可以不坍塌。而 runtime/runtime.py、runtime/codec.py、hadamard.json 这些源码告诉我们：这不是靠"更聪明地牺牲"，而是靠"更早地约束"。当 1-bit 硬件落地，这条路线积累的表示与内核经验，就是端侧智能密度竞赛的起跑线。

【免费下载链接】Ternary-Bonsai-2-27B-mlx-2bit项目地址: https://ai.gitcode.com/hf_mirrors/prism-ml/Ternary-Bonsai-2-27B-mlx-2bit