Ternary Bonsai 2 27B 对比 Bonsai 27B：两个月，两个基础模型，一个缺失的变体

Ternary Bonsai 2 27B 于 2026 年 9 月 17 日问世，距 Bonsai 27B 在 2026 年 7 月 14 日发布两个月，而两者之间最受关注的对比只是一对数字：第一代保留了其全精度基础模型基准平均值的约 95%，第二代则保留了 98.2%。这读起来像是一次直截了当的世代改进，而它大体上确实如此——但这两个数字衡量的并不是同一件事，因为它们底下的基础模型变了。7 月发布的版本压缩的是 Qwen3.6-27B。9 月发布的版本压缩的是 Qwen3.8-27B。质量提升的一部分归功于压缩配方，另一部分归功于更新的 Qwen3.8-27B，而没有任何已公布的数字将两者区分开来。

两代之间还有第二个差异，它受到的关注少得多，却对某一特定用户群体更重要：第一代 Bonsai 以两种变体推出，第二代则只推出一种。那个让 27B 级模型装进 iPhone 17 Pro 的 3.9 GB 构建版本，在本次发布中没有后继者。如果正是这个占用空间让你一开始对 Bonsai 产生兴趣，那么新一代并不是升级——而是一个无法覆盖你这种情况的不同产品。

第一代实际交付了什么

Bonsai 27B 于 2026 年 7 月 14 日以 Apache 2.0 许可发布，以同一基础模型构建的两个产物形式呈现，而两者之间的分野正是此次发布的用意所在。

• Ternary Bonsai 27B — 采用三值 {−1, 0, +1} 权重，配合 FP16 分组缩放，每权重有效比特数为 1.71，占用空间仅 5.9 GB。这是以质量为先的构建版本，定位于日常笔记本电脑，具备完整的推理、工具调用与智能体能力。

• 1-bit Bonsai 27B — 采用二值 {−1, +1} 权重，并沿用相同的分组缩放，每权重有效 1.125 比特，占用空间为 3.9 GB。这款以占用空间为导向的构建版本，其大小专为适配 iPhone 17 Pro 的内存预算而设计。

两者都具备 262K token 的上下文窗口，都保留了紧凑的 4 位视觉塔，使模型保持多模态，并且都支持使用 DSpark 草稿模型的推测解码。Prism ML 当时的说法是，低位表示是端到端运行的——嵌入、注意力、MLP 和 LM head——没有任何更高精度的回退选项，并且 1 位版本是首个能在手机上运行的 27B 级模型。据报告，1 位变体的吞吐量在 iPhone 17 Pro 上约为每秒 11 个 token，在 Apple M5 Max 上为 87 tok/s，在 RTX 5090 上为 163 tok/s；三值变体在 M5 Max 上据称为 58 tok/s，在 5090 上为 134 tok/s。

质量代价与这些数字一同报告，而非被掩盖。在一个包含 15 项基准测试的思考模式套件上，全精度基础模型得分为 85.0，三值版本为 80.5——约 95%——1 位版本为 76.1，约 90%。性能退化集中在智能体工具调用上，在 1 位版本上从 80.0 降至 66.0，以及视觉方面，从 72.6 降至 59.6。数学和编码在两种变体中都保持得明显更好。

第二代改变了什么

Ternary Bonsai 2 27B 保留了配方，改变了输入。三值表示仍是 {−1, 0, +1}，每 128 个权重一组配一个 FP16 缩放因子，现在打包后每权重 1.76 比特，文件大小为 5.93 GB，支持 262K 上下文，并沿用同样的独立视觉塔——本次发布中为 4-bit 下的 0.63 GB，仅在图像到达时加载。

有两件事确实是新的，而这两件事都被说成是留存数据变动的原因。

第一种是选择性精度。与几乎把所有内容都三值化的七月版本不同，Bonsai 2 以全精度保留了 26,238,464 个参数——占语言模型的 0.0976%，在 bf16 下约 52 MB，集中在线性注意力层的循环状态路径以及归一化权重中。这在字节上是一个小小的让步，而在行为上显然是一个巨大的让步。

第二种是旋转后的权重基。权重矩阵在按块大小 1,024 进行分块 Walsh–Hadamard 旋转后存储，运行时对激活施加相匹配的变换，其依据的理论是：将离群值分散到各个坐标上，能让三级近似的损失更小。它不增加额外存储，因为旋转已被折叠进权重中，但它确实位于计算路径上。

接下来还有一项根本算不上技术的改动：基础模型。Qwen3.8-27B 是一种混合注意力设计——约 75% 线性注意力、25% 全注意力——而其前代并非如此。Prism ML 公布的各类别得分显示了这一举措换来了什么。Bonsai 2 的指令遵循得分为 82.66，而第一代所压缩的基础模型 Qwen3.6-27B 为 74.53。推理与知识得分为 83.95，旧基础模型为 84.71；编程得分为 81.58，旧基础模型为 82.57。新基础模型在指令遵循上大幅领先，却在另外两个类别上略微落后，而正是这种画像，使得跨代保留率百分比单看并无用处。

为什么这两个留存数据不可比较

95% 和 98.2% 看起来像是同一标尺上的两个读数。但它们并非如此，原因有三，而在得出该配方提升了 3.2 个百分点的结论之前，这三点值得厘清。

• 分母不同。第一代的 95% 是在包含 15 个基准的测试套件上、与 Qwen3.6-27B 对比测得的。第二代的 98.2% 则来自包含 20 个基准的测试套件、与 Qwen3.8-27B 对比。不同的测试套件，不同的基线，不同的难度组合。

• 基线各自独立地发生了变化。保留率提升的一部分原因在于压缩模型变得更擅长压缩，另一部分原因则是基础模型的变化恰好对三值权重更友好。目前尚无公开发表的研究能区分这两部分贡献。

• 保留率是相对的，因此在一个类别中，它可能上升，而绝对能力却在下降。一个保留了较弱父模型 99% 能力的模型，仍可能落后于一个保留了更强父模型 96% 能力的模型。

绝对对比比相对对比更有信息量，而在此基础上，整个脉络也更清晰。Bonsai 2 的综合得分 83.9 高于全精度 Qwen3.6-27B 在较早测试集上取得的 83.6——这意味着这个压缩后的继任者如今已领先于它在一代之前所取代的未压缩模型。第一代三值版本在自己的测试集上得分为 80.5。这两个数字都出自 Prism ML，且测试集并不相同，所以应关注排序，而不是小数点后的数值。

那个没有回来的变体

这是对比中能改变购买决策、而非仅停留在基准图表上的部分。

没有 1-bit Bonsai 2。9 月发布的版本提供的是三值构建，有两种打包——PTQ1_0 为每权重 1.76 比特、5.93 GB，PQ2_0 为每权重 2.16 比特、7.25 GB——另外还有一个适用于 Apple Silicon 的 MLX 容器。不存在 3.9 GB 的二值变体，也没有相关发布公告。当前报道中出现的 3.9 GB 手机级数字仍指 7 月的模型。

实际后果很直接。如果你的目标设备是 iPhone 或 iPad，或是任何无法容纳 5.9 GB 语言模型加 0.63 GB 视觉塔再加上下文预算的设备，那么第一代 1-bit 版本仍是该系列中唯一的选择，而且在 1-bit 的 Bonsai 2 出现之前，它会一直如此。升级三值路径并不会升级那条路径。任何人只要读到“Bonsai 2 更好”就重新下载到手机上，就会发现该文件根本放不下。

如果你使用的是笔记本电脑或台式机，那么这笔账就反过来了：没有理由运行 7 月的三值构建，因为 9 月的那个在同等质量下体积更小、在真正重要的基准测试中表现更好，并且具有相同的 262K 上下文。

速度方面，各代产品确实很难排名

吞吐量是这次比较中这样一个部分：诚实的回答是，已公布的数据并不支持得出明确的排名，而这一点值得直说，而不是挑选讨喜的一组数字。

第二代在批大小为 1、排除视觉塔情况下的标准化测量结果为：在 PQ2_0 打包下，RTX 5090 上解码速度为 142.5 tok/s，Apple M5 Max 上为 46.8 tok/s，M5 Pro 上为 27.7 tok/s，M4 Pro 上为 18.0 tok/s。第一代为其三值版本标称的是 RTX 5090 上 134 tok/s、M5 Max 上 58 tok/s。5090 的数字小幅朝着预期方向变化。M5 Max 的数字则朝反方向变化——从 58 降到 46.8——这可不是两个月的代际进步该有的样子。

有两个注意事项使它不足以构成一项发现：各版本之间的测量基准并不相同，而且新机型至少有一个已公布的 M5 Max 数据被归因于一个早于旋转优化的构建版本。但它值得作为一个悬而未决的问题被标记出来，因为能够解释这一现象的机制就写在发布说明里：旋转基在批大小为 1 时，把一次变换放到了每一次投影的关键路径上，而 Apple Silicon 上的解码正是受此影响最严重的场景。换来质量提升的技术，代价可能是解码吞吐量，而在统一内存硬件上，这种取舍最为尖锐。

MLX 容器为 Apple 用户带来了另一层麻烦。它是一种仿射 2 位格式，其块为每 128 个权重同时存储一个缩放因子和一个偏置，但三值权重只需要缩放因子，因此偏置纯属累赘——每 128 个权重对应的块占用 36 字节而非 34 字节，打包后的比特率落在每权重 2.25 位，实测文件大小为 8.005 GiB。它是一个承载相同数值的不同容器，而且正是演示环境默认下载的那个包。

运行任一代

两代模型都受制于同一个运行约束，这个模型的任何版本都未能摆脱它：两者都无法在原版 llama.cpp 上运行。该架构的三值内核只存在于 Prism ML 自己的分支中，原版 llama.cpp 会把当前的打包格式视为未知而拒绝，而且——更糟的是——它会毫无怨言地加载较旧的三值格式并生成看似流畅的垃圾输出，因为它不会应用权重所假定的旋转。MLX 构建带有 Metal 和 CPU 内核，但没有 CUDA 路径。无论你选择哪一代，运行时问题的答案都在于 Prism ML 自己的发行版，或在于已采用其内核的某个运行时，而不是整个 ggml 生态。

在这样一项决策中，OrcaRouter 所处的位置要高一层。两代 Bonsai 都不托管在这里——它们是下载到你自己的硬件上运行的。路由层真正有用的地方在于边界：那些不该由你的本地模型来应答的请求。在路由配置中一次性定义升级策略，而不是写进应用代码，这样本地服务的层级就能把长上下文、重度视觉或其他超出范围的请求上交给托管模型，而不是让它们直接失败；同时无论你碰巧装的是哪一代 Bonsai，这套回退机制都能继续生效。本地层级和托管层级随后都位于同一个密钥之后，而当下一个 Bonsai 世代到来、层级边界再次变动时，策略只存在于一个地方。

这个该怎么办

• 如果你在笔记本电脑或台式机上运行 7 月的 ternary 版本，请改用 Ternary Bonsai 2 27B。它是在大致相同资源占用下更出色的模型，而且它胜出的那些类目分数，正是对智能体任务和指令遵循工作至关重要的分数。

• 如果你在手机上运行的是 7 月的 1 位构建——就继续用。它没有后继版本，而且 5.93 GB 的三值构建并不能直接替代 3.9 GB 的版本。

• 如果你是第一次评估该系列——先确定尺寸规格，再确定世代。你需要的型号决定了你该选购哪个版本，而这一顺序与人们通常描述此次升级的方式正好相反。

• 如果你正依据基准测试来做选择——请把 95% 和 98.2% 视为两种不同的测量结果，而不是同一条线上的两个点，并且在针对 9 月模型的独立评估出现之前，把这两者中的每一个数字都当作厂商自己提供的数据。那项评估才是值得关注的东西，因为它是第一个能够在共同基础上比较这两代模型的评估。