Bonsai 2 在任何人宣布它将会登陆之前，就已经登陆了 Ollama

2026年10月17日凌晨某个时候，Ollama开始提供Bonsai 2——一个包含九个标签的库条目，涵盖Ternary Bonsai 2 2B、Ternary Bonsai 2 4B、Ternary Bonsai 2 9B以及Bonsai 2 27B，每个模型都有两种打包形式，外加一个默认别名。Prism ML 对此只字未提。供应商的新闻页面上没有相关文章，10 月 15 日关于这些小模型的公告中也没有只言片语——那篇帖子将 llama.cpp 和 MLX 列为运行时，并将一个托管控制台列为演示，却完全没有提及 Ollama。这个条目就这么存在着，所有九个标签都带有同样几小时前的时间戳，这正是新推送的样子，而不是逐步推出的样子。

所以诚实的划分是这样的。现在就能从注册表和文件中得知的：各个标签、它们的名称、精确的字节大小、内容摘要，以及——由于 Ollama 以 GGUF 格式分发——权重文件内部的架构与元数据字符串。尚未确认的：是谁打包了它们，为什么厂商的公告略去了平台，三值内核是上游存在于 Ollama 自己的引擎中还是以第三方代码内嵌的方式引入，以及厂商给出的任何数字是否能经得起这一路的检验。这些是彼此独立的问题，而本文把它们分开处理。

架子上实际上有什么？

九个标签、四种大小、相同权重的三种打包方式。Ollama 的库页面为每种大小列出了一个默认别名，以及一个 -q2_0 变体，每种大小一个：

• bonsai-2:latest — 3.2 GB，解析为 9B（摘要 c8b5462f8688）

• bonsai-2:2b 和 bonsai-2:2b-q2_0 — 911 MB，摘要同为 de2ccb4e7328

• bonsai-2:4b 和 bonsai-2:4b-q2_0 — 1.6 GB，摘要相同 93edd652c932

• bonsai-2:9b 和 bonsai-2:9b-q2_0 — 3.2 GB，摘要相同：c8b5462f8688

• bonsai-2:27b 和 bonsai-2:27b-q2_0 — 8.3 GB，摘要同为 f3c4f4208659

命名所起的作用比表面看起来更大。每个尺寸两个标签共享一个摘要并不是重复——它是在说明 Ollama 选择了哪种打包方式。拉取 bonsai-2:9b 的清单，模型层是 2.557 GB。那就是 Ternary Bonsai 2 9B 的 Q2_0 文件，在 Hugging Face 上量得为 2.557 GB，精确到字节。PQ2_0 包是 2.417 GB，而 PTQ1_0 包——最小的，1.997 GB——根本不在这里。

这个选择有一个值得直说的后果，因为这种事往往会演变成一条求助帖。在厂商的模型卡上，上游 llama.cpp 只运行三种打包中的一种：Q2_0，“最新的 master，其中包含 Hadamard 激活运行时。”它拒绝PQ2_0 和 PTQ1_0，视其为未知类型，因为它们需要 Prism ML 的 llama.cpp 分支。Ollama 提供自己的引擎。Q2_0 是标准 GGUF 消费端有可能加载的包——而 Q2_0 正是 Ollama 发布的那个包。Ollama 是自行发展出了自己的三值内核，还是路由到某个内置的第三方构建，注册表并不会告诉你。它确实告诉你的是，他们没有发布那个无法加载的文件。

GGUF 元数据告诉你的信息比页面上的更多。

Ollama 的页面会为每个标签报告四项事实：字节大小、“256K”上下文徽章、文本加图像的输入类型，以及相对时间戳。其余一切都在文件内部。读取每个模型层的 GGUF 头部会得到以下内容，而它值得一读有一个特定原因：它是这个故事中唯一不是某人营销说辞的部分。

• general.architecture — 四种规格均为 qwen35

• general.name — Ternary-Bonsai-2-2B、-4B、-9B 在三个小型版本上；27B 层报告通用字符串 Hf，并带有 general.basename = folded

• general.file_type — 四项中均为 41，且 general.quantization_version = 2

• general.size_label — 2B、4B、9B、27B，与标签名称匹配

• 张量数量 — 2B 为 320，4B 为 426，9B 为 427，27B 为 851

架构字符串才是耐人寻味的那一处。qwen35 是 Qwen3.5 的混合注意力主干，它从产物本身印证了模型卡以文字所描述的内容：小的那三个是 Qwen3.5-2B、-4B 和 -9B，架构未变，只是替换了权重。它还暴露出厂商自家发布说明所掩盖的一处命名接缝。10 月 15 日的帖子称这些新模型“基于 Qwen3.5”。而 27B 完全是另一个基座——9 月 17 日发布的 Qwen3.8-27B。四种尺寸，一个家族名，两个基座模型。你读到的任何关于“Bonsai 2”行为的说法，只要是在 27B 上测得的，就不能自动下推到 9B，而 GGUF 头部正是你能看出缘由的地方。

27B 的元数据也明显不如其余几个整洁：general.name = Hf，general.basename = folded，general.version = v5，还多了一个那三个小模型没有的采样键。这就是转换流水线的中间输出在未经最终重命名步骤就被推送出去时的样子。这不是缺陷——张量还是那些张量——但它是一个指纹，表明 27B 这个标签走的是与那三个小模型不同的路径。

Ollama 数字并不代表什么

大多数关于模型库列表的报道正是在这里出错，所以值得放慢速度细看。Ollama 页面上标注的字节大小是容器大小，而且对每一种规格而言，它们都大于其中包含的模型文件。2B 标签显示为 911 MB，而对应的模型层为 0.547 GB，视觉投影器为 0.365 GB。27B 标签显示为 8.3 GB，而对应的模型层为 7.626 GB，投影器为 0.629 GB。再加上许可证和参数数据块，账就对上了：Ollama 报出的是整个被拉取的产物，连视觉塔也算在内。

这意味着，Ollama 页面上 9B 模型的 3.2 GB，无法与厂商对同一模型给出的“2GB”数值直接比较；这一差距也不是需要报告的不一致——它是对两种不同事物的两种不同测量结果。Prism ML 的 0.43 GB / 0.95 GB / 2 GB 仅是语言模型本身。视觉塔会被卸载，只有在实际收到图像时才加载，因此纯文本部署永远不必为它承担开销，但一次 ollama pull 却会。如果你依据厂商的数字来为设备做容量规划，随后又从 Ollama 拉取，那么在运行任何东西之前，你就会超出预算 0.5 到 1 GB。

同样的谨慎也适用于"256K"这个标注。其底层上下文是 262,144 个 token，继承自 Qwen3.5 主干——在 9B 上是 24 层线性注意力层和 8 层全注意力层——而 Ollama 的标注在显示时把它向下取整了。该上下文是真实存在的，而且是继承而来的，并非 Ollama 添加的东西。未页面{{2}}未{{/2}}在任何地方说明长上下文要付出多少内存代价，而在一个部分层带有全注意力缓存的混合注意力模型上，这可不是一个小数目。Ollama 页面上没有任何内容告诉你，262K 在你打算运行它的地方是否真的放得下。

这是谁打包的，这重要吗？

未解答，并且应标记为未解答，而不是猜测。有三种可能：Prism ML 推送了它，Ollama 作为其自身目录工作的一部分从供应商的公开 GGUF 仓库拉取了它，或者是第三方做的。注册表无法告诉你究竟是哪一种。

能够核查的是这件产物的来源，而它对得上。Ollama 自己的模型描述写着“来自 Prism ML 的 Bonsai 2 是一个专为三值权重（−1、0 或 +1）打造的视觉模型系列：体积约为标准 4 位模型的一半，质量却接近全精度”，并给出了厂商的 Hugging Face 组织、Bonsai 2 27B 白皮书以及 Apache 2.0 的链接。嵌入四份尺寸清单中每一份的许可证数据块，都是逐字照搬的 Apache 2.0 文本。2B、4B 和 9B 的参数数据块内容为 {"presence_penalty":1,"temperature":1,"top_k":20,"top_p":0.95}——这正是厂商推荐的思考模式采样配方（出自模型卡），并且像 27B 模型卡所说的那样，GGUF 文件确实省略了 min_p。这不是谁凭空猜出来的；这是一次真正读过模型卡的转换。

这令人安心，却仍然没有告诉你真正决定你体验的那件事：三值内核是否在你正在运行的引擎中。诚实的立场是，成功拉取只能证明该文件是格式良好的 GGUF，仅此而已。在基于它进行构建之前，请在你自己的硬件上验证。

供应商的声明，以及已核实的内容

这个系列模型的每一项质量指标数值都来自 Prism ML，跑在 Prism ML 自己的评测框架上，而且没有任何一项经过独立复现。在这个阶段这很正常，应该明说，而不是暗示。10 月 15 日的文章报告了小型模型在六个技能领域的 19 项基准测试，并给出了相对全精度 Qwen3.5 基线的保留率：

• 2B — 智能体 95.5%，数学 107.8%，指令遵循 121.5%，编程 115.0%，知识 82.9%，视觉 89.0%

• 4B — 90.0% / 99.3% / 106.0% / 100.7% / 90.9% / 91.3%

• 9B — 92.4% / 98.2% / 100.0% / 100.1% / 93.0% / 92.5%

其中若干项超过 100%，这既不是笔误，也不是舍入造成的假象——它意味着三值模型在该类别上的得分高于它所源自的全精度模型。2B 的指令遵循达到 121.5%，是最突出的例子。应以它应得的怀疑态度看待这一点：一个压缩模型在厂商选定的基准上击败自己的基线，这至少同样是在说明训练和评测框架的情况，而不只是表征本身；而且小模型类别的分数比 27B 的要嘈杂得多。27B 的数字在整体形态上更为保守，也更可信——84.78 对 FP16 的 86.32，在 14 个思维模式基准上保持 98.2% 的留存率，其中数学为 96.57 对 97.06，编程水平为 89.42 对 89.07，而损失集中在知识/推理和视觉方面。当一个模型家族在 1.7 比特表示下损失能力时，那正是你会预测到的特征分布。

小型模型文章里那个不是基准测试的说法，才是最值得认真对待的：9B“在标准指令遵循和日常数学任务上使用的 token 大约少 40%”。这是一个关于冗长程度、而非能力的主张，而且这种事你花一个下午用自己的提示词就能验证。它还和厂商自家模型卡上的一条警告相互牵连——思考模式在一道微不足道的问题上就能烧掉 3,000 多个 token，所以至少要把输出 token 设为 8,192，并且不要在开启思考模式时使用贪心解码，因为它可能会卡在推理里出不来。一个冗长程度低了 40%、却仍然需要 8,192 token 预算的模型，是在告诉你：它在某个特定地方很啰嗦。

这让你处于什么境地

如果你已经在运行 Ollama，并且想在没有数据中心 GPU 的笔记本电脑上尝试 27B 级别的模型，那么这四个标签就是目前存在的最短路径：一次拉取，无需 fork，无需构建内核。如果你需要实际最小的打包，或者厂商为 4B 和 9B 附带的投机解码草稿模型，Ollama 的列表里并没有它们——那是一次 Hugging Face 下载和 Prism ML llama.cpp 构建，而且自 10 月 15 日起就一直如此。

另一件值得了解的事是，本地并非消费低位模型的唯一方式，而且它也不总是正确的那一种。OrcaRouter 将一个 API 置于 200 多个托管模型的前端，且 0% 加价——按供应商标价原样传递——并支持供应商之间的自动故障转移，因此你可以在真实工作负载上评估某个模型，再决定它是否值得在你的笔记本电脑上占有一席之地。目前 Bonsai 2 的任何规格都未通过 OrcaRouter 提供服务，本文也并未声称并非如此：该系列是一个你自己下载运行的模型，并且在供应商发布端点之前，它会一直如此。路由层为你换来的是这一决策的另一半——你将用来与之比较的那些托管模型，全都位于同一个密钥之后，而当单个模型不够用时，还可以使用模型融合与路由 DSL。

值得关注的事项，按其可能改变局面的程度排序：某个 Ollama 标签多出一个 ptq1_0同级项——这意味着 dense-trit 内核已进入上游；厂商发帖承认该平台——这将回答来源问题；以及对 9B 或 27B 的任何独立基准测试——这是唯一能让留存率数据脱离厂商报告那一栏的东西。在上述任何一项落地之前，该上架条目只是一种交付机制，而不是一个新模型——而它所交付的模型自 10 月 15 日起就已公开。

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