PrismML 昨天发布了 Ternary Bonsai 2 27B。这家从 Caltech 出来的团队拿到过 Khosla Ventures、Cerberus 和 Google 的支持，方向只有一个：压缩神经网络而不牺牲推理能力。
这次的结果值得认真看一下，因为它把本地部署的门槛推到了一个新的位置。
一、先看这组数字
| 项目 | 数值 |
|---|---|
| 基座 | Qwen3.8 27B |
| 权重量化 | 三值（负一、零、正一）+ FP16 分组缩放 |
| 平均位宽 | 1.76 比特每权重 |
| 模型体积 | 5.9GB |
| 上下文窗口 | 262K token |
| 模态 | 文本 + 图像 |
| 聚合基准 | 83.9（全精度版 85.4） |
| 能力保留率 | 98.2% |
| 推理吞吐 | RTX 5090 上 143 tokens/s；M5 Max 上 46.8 tokens/s |
| 能效 | RTX 4090 上 0.714 毫瓦时每 token |
| 授权 | Apache 2.0 |
对照上一代 Ternary Bonsai 27B，保留率从 95% 提升到 98% 以上。这个变化看起来不大，但它是这次发布最实质的进步——在低比特这个方向上，最后几个百分点通常是最贵的。
二、三值量化到底省了什么
每权重只有负一、零、正一三种取值，理论上区分三种状态只需要以 2 为底 3 的对数，约 1.585 比特。1.76 比特是算上分组缩放系数和未量化部分之后的实际平均值。
这里有一个常被忽略的要点：三值的收益不止来自压缩率。
- 存储侧：27B 参数乘 1.76 比特约等于 5.9GB。对照全精度 FP16 的约 54GB（27B 乘 2 字节），相差约 9.2 倍，和官方说的「超过 9 倍」吻合。
- 计算侧：当权重只有三种取值时，矩阵乘法中的乘法退化成加减法和条件累加。这是吞吐提升的另一半来源，也是三值路线相比传统量化最本质的区别——传统量化降低的是访存压力，三值同时降低了算术强度。
代价也很明确：三种取值能表达的数值分辨率极低，必须靠分组缩放系数来补偿动态范围。分组粒度越细，缩放系数开销越大、实际位宽越高；粒度越粗，精度损失越明显。1.76 这个数字反映的就是团队在这个折中点上的选择。
三、横向对比：三值 vs 传统量化
| 路线 | 典型位宽 | 27B 体积量级 | 相对全精度的典型代价 |
|---|---|---|---|
| FP16 全精度 | 16 | 约 54GB | 基准 |
| GGUF Q4_K_M | 约 4.5 | 约 15GB | 困惑度退化约 1% 到 2% |
| AWQ 4 比特 | 4 | 约 14GB | 与 Q4_K_M 相当，质量略好 |
| 三值 / 1.58 比特路线 | 约 1.6 到 1.8 | 约 6GB | 本模型报告 98.2% 保留 |
传统量化和三值量化有一个根本区别：前者是训练后量化，后者是端到端应用低比特表示。
训练后量化的逻辑是：模型已经训好了，现在把权重映射到一个更粗的网格上，误差只能靠标定数据事后补偿。而三值路线让模型在被压到三值表示的过程中参与适配——权重表示形式是训练流程的一部分，不是事后套上去的壳。
这解释了为什么三值能做到 98.2% 的保留率，而常见 4 比特方案通常有 1% 到 2% 的困惑度退化。位宽更低但代价更小，靠的不是压缩技巧，而是把低比特变成训练时的约束。
需要说明的是，这条路线的先行者是 BitNet b1.58，它同样使用三值权重，并报告过在 3B 规模上匹配 FP16 LLaMA 的表现，同时实现约 2.71 倍推理加速、3.55 倍内存占用下降和 71.4% 的能耗降低。Bonsai 2 的意义在于把这条路线上推到了 27B 级别，并且是通用模型而非研究原型。
四、分项成绩里最值得看的三个格子
聚合分 83.9 对 85.4 的对比容易被 98.2% 这个数字一带而过。真正要看的是分项：
| 能力 | Bonsai 2 27B | Qwen3.8 27B | 差距 |
|---|---|---|---|
| 智能体与工具调用 | 77.57 | 79.74 | -2.17 |
| 编码 | 81.58 | 82.17 | -0.59 |
| 指令遵循 | 82.66 | 81.25 | +1.41 |
| 知识与推理 | 83.95 | 86.66 | -2.71 |
| 数学 | 96.57 | 97.06 | -0.49 |
| 视觉 | 78.59 | 81.64 | -3.05 |
三个格子值得单独说。
第一，编码只掉 0.59 分。 包含 HumanEval+、LiveCodeBench v6、MBPP+、BigCodeBench 在内的编码套件几乎无损。编码是压缩最敏感的领域之一——代码生成对数值扰动的容忍度远低于闲聊，一个 token 错就是语法错。能保住这项，说明三值表示对结构化推理的损害有限。
第二，指令遵循反而涨了 1.41 分。 从 81.25 升到 82.66，这很反直觉。可能的解释是 IFBench 和 IFEval 更侧重格式约束与条件遵循，而三值化带来的轻微分布平滑恰好让模型在严格格式任务上更稳定。无论原因是什么，它至少说明量化不必然意味着全面单调退化。
第三，视觉掉了 3.05 分，是相对损失最大的一项。 从 81.64 掉到 78.59。多模态任务的中间张量形状更复杂、信息通路更长，低位宽在这里的代价更明显。官方宣传里说 Bonsai 2 提升了视觉能力（相比 Qwen3.6 27B 的 79.82 确实涨了），但和全精度基座比仍有可见的差距。
还有一个必须指出的口径问题：数学类基准 96.57 这个分数会系统性拉高聚合均值。 数学套件（AIME 2026、AIME 2025、GSM8K、MATH-500）本身就在 94 到 97 区间，任何模型的聚合总分都会被它抬起来。所以真实的能力损失应该按分项读，而不是按 98.2% 这个单一数字读——知识推理和视觉上的实际损失，比 98.2% 听起来要大。
五、吞吐与能效：本地部署的真实门槛
143 tokens/s（RTX 5090）和 46.8 tokens/s（M5 Max）这两个数字，比压缩率更决定体验。
对编码 agent 来说，这个吞吐意味着编辑与调试循环可以保持交互感——本地模型的瓶颈历来不是「答得对」，而是「等得久」，一旦延迟超过某个阈值，你就会忍不住切回云端。
能效数字更值得注意：RTX 4090 上每 token 耗电 0.714 毫瓦时，比全精度运行的 8B 模型还低约 40%。
这个对比很有说明力：一个 27B 的三值模型，单 token 能耗低于一个 8B 的全精度模型。这意味着笔记本上的常驻助手不再需要频繁唤醒云端——能耗决定了本地推理能不能真正「一直开着」，而这正是本地部署相对云端最核心的价值主张。
六、生态：领先但需要自己动手
目前的支持路径有两条：NVIDIA GPU 走 CUDA，Apple 设备（Mac、iPhone、iPad）走 MLX，两条路径都依赖自定义低比特 kernel。
这是关键限制。你不能像下载一个 GGUF 文件那样，在 Ollama 或者 LM Studio 里点一下就跑起来。自定义 kernel 意味着硬件适配、编译环境和推理框架都需要自己处理，社区微调生态和量化流程的复现方案也还需要时间。
权重是 Apache 2.0 授权，商业使用没有法律障碍。但**「权重可用」和「生态可用」是两件不同的事**，现阶段它更接近一个性能领先、需要动手能力的选项。
七、谁该换，谁不该换
值得考虑的场景：
- 显存紧张的设备：单张 8GB 卡或统一内存的 Mac 上想跑 27B 级能力，5.9GB 加 262K 上下文缓存仍然放得下；
- 需要长时间常驻的助手：能耗优势在笔记本上直接转化为可用时长；
- 编码 agent 循环：编码分项几乎无损，而这类任务对退化最敏感；
- 隐私敏感的高频任务：本地处理、仅对少数难任务选择性上云，这是混合编排最实际的形态。
暂时不必换的场景：
- 多模态工作流重度依赖：视觉分项损失最大，如果你的产品核心是图像理解，全精度基座或云端模型仍更稳；
- 需要成熟工具链：如果你的部署依赖现成的推理客户端和社区量化版本，GGUF 生态的成熟度短期内无法被替代；
- 追求绝对上限：三值的定位是「在受限预算内交付最多有用智能」，不是「超越全精度模型」。
一句话总结这次的发布：它把「27B 级能力需要多大显存」这个问题的答案，从 54GB 改成了 5.9GB，而且保留了 98.2%。 真正需要你自己判断的是，剩下的那 1.8% 具体落在哪几个分项上——以及你的场景是否正好依赖那几项。