Bonsai 2 与 Bonsai 27B：一个你能拉取，另一个则不能

之间最具体的区别Bonsai 2与Bonsai 27B与基准测试毫无关系。2026 年 10 月 17 日，一条覆盖整个 Bonsai 2 系列的 Ollama 库条目上线了——Ternary Bonsai 2 2B、Ternary Bonsai 2 4B、Ternary Bonsai 2 9B以及Bonsai 2 27B——而第一代没有对应的条目。查找bonsai-27b、ternary-bonsai-27b或该注册表上的任何变体名称，都会得到 404。Bonsai 27B，由 Prism ML 于 2026 年 7 月 14 日发布，必须从厂商的 Hugging Face 仓库下载，并针对 Prism ML 的 llama.cpp 分支运行。Bonsai 2 只需一行安装命令。

那种不对称性正是这个选择的全部实际形态，而且很容易被忽略，因为这两个名字看起来像是同一产品线的一次版本升级。它们是两代产品、两个基础型号、两套不同的打包方式，而且——截至本周——还是两种不同的交付机制。接下来要说的是它们之间实际发生了什么变化、较旧的那个在哪些方面仍然胜出，以及唯一一种答案两者皆非的配置。

每一个是什么

两者都是 Q​wen 混合注意力模型的三值压缩。它们都不是新训练的模型——架构、权重和量化感知训练都来自 Q​wen 基础模型，而 Prism ML 的贡献在于三值表示以及消费该表示的核函数。

• 代际 — Bonsai 2（2026 年 9 月，延长至 2026 年 10 月）对比 Bonsai 27B（2026 年 7 月 14 日）

• 27B 规模的基础模型 —— Qwen3.8-27B 与 Qwen3.6-27B 对比

• 该系列的基础模型——Bonsai 2 旗下的 Qwen3.5-2B、-4B、-9B 和 Qwen3.8-27B;第一代旗下的单个 Qwen3.6-27B

• 提供的规模 — 四种（2B、4B、9B、27B）对比一种（27B）

• 在 27B 上有两个运行点——不，只有一个：Bonsai 2 27B 仅提供三值版本，而 Bonsai 27B 同时发布过三值构建和二值构建

• 27B 级别中最小的占用空间 —— Bonsai 2 中的 PTQ1_0 为 5.95 GB，而第一代的 1-bit 版本为 3.9 GB

• 上下文 — 两者均继承自 Qwen 骨干网络的 262,144 个 token

• 许可证 — 两者均为 Apache 2.0

• 交付 — 面向 Bonsai 2 的 Ollama 标签和 Hugging Face；面向 Bonsai 27B 的 Hugging Face 以及 Prism ML 的 llama.cpp 分支

比其他行更能决定部署数量的，是第五行。Bonsai 27B 提供了两种占用内存的方式：约 7.2 GB 的三元构建和 3.9 GB 的二元构建。Bonsai 2 27B 只提供一种——在密集 trit 打包下为 5.95 GB，或在 2 位槽打包下为 7.21 GB 的三元构建——这一代没有二元伴随版本。如果你之前运行的是第一代的 3.9 GB 构建，并期待一个同等对应的后继版本，那么在 27B 上并没有这样的版本。

这一代人实际上买了什么

Prism ML 自己的数字，来自 Prism ML 自己的测试框架，且没有可用的独立复现结果：第一代三值 Bonsai 27B 报告称，其思考模式平均分为 80.49，而其 Qwen3.6-27B FP16 参考模型为 85.07——在 15 项基准测试中保留了 94.6%。Bonsai 2 27B 报告为 84.78，而 Qwen3.8-27B FP16 为 86.32——在 14 项基准测试中达到 98.2%。按绝对值计算，该压缩模型在厂商的评分标准上提升了约 4.3 分。

有两点注意事项必须一并说明，因为标题容易让人得出一种比数据所能支持的更干净利落的解读。第一，基准测试套件并非同一组——一个为15项，另一个为14项——而且基线从 Qwen3.6-27B 换成了 Qwen3.8-27B，后者本身就是一个更强的模型。厂商自己的 27B 模型卡通过在新14项基准套件上重新计算上一个版本来给出一行同口径对比，从而明确了第二点：在那一共同口径下，上一个版本得分为 80.98，Bonsai 2 27B 得分为 84.78。因此，对这一变化的诚实解读是：在相同基准集上大约提升了 3.8 分，其中一部分来自基础模型，另一部分来自三元训练。保留率从 94.6% 升至 98.2%，部分原因是分母发生了变化。

其次，损失的具体形态比总体指标更具信息量。在同一套14项基准测试中，Bonsai 2 27B在持续推理显现之处几乎没有损失：数学96.57对97.06，编码89.42对89.07——持平，略占优势——指令遵循82.66对81.25，领先。知识与推理从85.55降至79.86，视觉从71.36降至66.19。这正是每权重1.72比特表示所应有的特征：推理核心得以保留，事实回忆和图像理解则受到冲击。如果你的工作负载是代码和数学，这种压缩几乎免费。如果是对语料库进行检索式问答，则并非如此。

3.9 GB 这个槽位正是事情变得有趣的地方

这就是两代框架所掩盖的部分。第一代最具特色的产物是二进制构建：一个 3.9 GB 的 27B 模型，在 15 项基准测试平均为 76.11 的情况下，保留了厂商报告的 FP16 的 89.5%。Bonsai 2 没有二进制 27B。但 Bonsai 2 确实有一个 9B：在 dense-trit 打包下为 1.997 GB，在 2-bit-slot 打包下为 2.42 GB——大约是二进制 27B 占用空间的一半，来自更新的世代和更新的基础模型。

9B 比 1-bit 的 27B 更好吗？厂商没有报告任何能回答这个问题的数字，你也不应自行构造一个。这两个模型是在不同的测试套件上评估的——小型 Bonsai 2 模型涉及六大技能领域的 19 项基准，第一代 27B 则为 15 项——且对照的是不同的基线；小型模型的发布报告给出的是相对于各自全精度 Qwen3.5 对应版本的类别保留率，而不是一个可与 27B 的 76.11 相比较的单一绝对平均值。确实存在的比较都是按基准逐项进行的，而且结果指向两个方向。按照厂商给出的数字，9B 在 BFCLv3 上得分为 71.81，在 Tau2Bench 上为 73.02，而二值化 27B 在 BFCL v3 上录得 74.41——差距小到足以被测试套件的差异吞没。

可以不过度引申地说出的结论更窄，但仍然有用：那个27B二进制模型曾经独自占据的占用空间级别，如今有了来自下一代更便宜的入局者，而且两者足够接近，任何人都不应仅凭厂商表格在它们之间做选择。这正说明应在你自己的提示词上进行测量，而不是轻信某个数字。这也是本次比较中唯一一个答案确实不是标题中两个模型之一的地方。

运行它们：数字与隐情

吞吐量数据由厂商实测得出，且并非在同一台机器上测得，因此应将其视为数量级参考，而非排名依据。

• Bonsai 2 27B 在 Apple M5 Max 上——在较早的旋转前构建版本中约为 47 tok/s，尚待在当前技术栈上重新测量

• Bonsai 2 27B 在 M5 Pro 上——采用 2-bit 槽打包时达到 28.1 tok/s，GPU 供电轨功耗约为 27.5 W

• RTX 5090 上的 Bonsai 2 27B — 在 2-bit 槽位打包下达到 129.9 tok/s，在稠密 trit 打包下为 120.5

• 第一代 ternary Bonsai 27B 在 M5 Max 上——44.0 tok/s；在 H100 上为 98.0 tok/s，配合其 DSpark 草稿器可提升至约 131.8

• 在 iPhone 17 Pro Max 上的第一代二值 Bonsai 27B——约 11 tok/s，受热限制

问题在于打包方式，而且它对两代产品的影响如出一辙。两代的三值内核都不在上游 llama.cpp 中。第一代需要为每个文件使用 Prism ML 分支版本。Bonsai 2 提供了同一套权重的三种打包形式，而上游 llama.cpp 只能运行其中一种——最近 master 中的 Q2_0——同时将更小的 PTQ1_0 和更快的 PQ2_0 作为未知类型拒绝。因此，最接近理论值每权重 1.72 比特的 dense-trit 打包，恰恰也是需要分支构建的那一种。

这值得停下来仔细想想，因为它解释了 Ollama 列表。Bonsai 2 的 Ollama 标签提供的是 Q2_0：9B 标签的模型层测得为 2.557 GB，与 Hugging Face 上的 Q2_0 文件大小逐字节相同，而最小的 PTQ1_0 包则完全不在注册表中。无论那个列表是什么，它都不是通往最小产物的路径。这里权衡的是便利性和占用空间，除非你查看文件大小，否则这种权衡是看不见的。

到达其中任何一个

如果你在使用 Ollama，那选择已经替你做好了：Bonsai 2，四种尺寸，ollama pull bonsai-2:27b 或 :9b，包含视觉投影器在内，磁盘占用分别约为 8.3 GB 和 3.2 GB。如果你需要 dense-trit 打包、推测解码草稿模型，或第一代中的任何东西，那就得从 Hugging Face 下载并自行构建分支版本，而厂商的演示仓库是这条路径经过测试的参考。

路由层在这里真正能帮上忙的地方，其实在问题的另一面。你无法将请求路由到这两者中的任何一个——它们是本地权重，而 OrcaRouter 目前并不提供任何规模的 Bonsai。OrcaRouter 给你的是对比基准：一个 API 统一接入 200 多个托管模型、零加价，按提供商标价原样透传，并支持提供商之间的自动故障转移。对大多数团队来说，合理的顺序是：先通过托管模型确定某项任务实际需要什么水平，再判断 2 GB、3.9 GB 还是 6 GB 的本地模型能否达到这一标准——而不是凭一个留存率百分比去猜。

具体是哪一个？

• 你想要 27B 规模下的最新一代三值（ternary）模型，并且只需一条命令即可安装——通过 Ollama 使用 Bonsai 2 27B，接受 Q2_0 打包格式以及更大的磁盘占用。

• 你想要尽可能最小的 27B 级产物，或者你依赖 DSpark 起草器——来自 Hugging Face 的第一代 Bonsai 27B，采用分叉构建版本。Bonsai 2 中没有任何东西能在 27B 上取代它。

• 你一直在运行 3.9 GB 的二进制构建版本，并且需要让这个占用体积保持不变——不要以为 Bonsai 2 一定有后继者。要么继续用下去，要么用你自己的提示词实测 Bonsai 2 9B；它的体积只有一半，还新了一代，而厂商尚未发布能一锤定音的对比结果。

• 你需要从同一个运行时获得四种尺寸等级——只有 Bonsai 2 这一代才能做到。

有一件事值得关注，它会简化这一切：一个ptq1_0标签出现在 Ollama 的列表上。那将意味着 dense-trit 内核已经进入 Ollama 发布的引擎，对最小的包来说分叉需求消失了，而便利性与占用空间之间的取舍也不再是取舍。

这一切都并非假设：像本次这样的发布背后那些有据可查的 AI 故障与智能体事件，均收录于 OrcaRouter AI 事件档案库中，其中每条记录都附有自己的来源、严重程度、置信度评级和存疑标记。