Bonsai 27B：Bonsai 家族中的 27B 模型详解

Bonsai 27B 是 PrismML 的 Bonsai 家族中拥有 270 亿参数的模型，也正是人们在输入“bonsai 27b”时所指的那个模型——但仅凭这个名字并不能让你找到它，因为有三样不同的东西都与它名字相近。Bonsai 27B 是 Qwen3.6-27B 的低比特重建版本，厂商自己的公告将日期标注为 2026 年 7 月 14 日，它以同一模型的两个包的形式发布：1-bit Bonsai 27B 将二值 {−1, +1} 权重存储在约 3.9 GB 中；Ternary Bonsai 27B 则以每权重 1.71 有效比特存储三值 {−1, 0, +1} 权重——厂商宣传数字为 5.9 GB，而实际发布的包为 7.165 GB。它不是 Ternary Bonsai 2 27B——那个基于 Qwen3.8-27B 构建、单独命名的第二代模型；也不是 PrismML 为 Snapdragon AR1 Gen 1 智能眼镜打造的 20 亿参数视觉语言模型。Bonsai 27B 的两个包都具备 262,000 token 的上下文、紧凑的 4 比特视觉塔，以及 Apache 2.0 许可证。这个模型就是 Bonsai 27B；随之而来的抉择是，它的两个包中哪一个适合你的内存预算。

本页面是该型号的参考文档。它并非公告：Bonsai 27B 自 2026 年 7 月起就已可用，如今值得回答的，是读者带着来的那些问题——它究竟是什么、这个名字区分了什么，以及实际运行它的成本是多少。

哪一个是 27B

这里的混淆确实存在，值得优先解决，因为一旦猜错，你就会转向一个拥有20亿参数的模型，或者转向正确模型的错误代际。

• Bonsai——家族名称，也是厂商对它的叫法。单凭它本身，并不能确定你能下载的是哪一个。PrismML 已发布 Bonsai 1.7B、Bonsai 4B、Bonsai 8B、Bonsai 27B 和 Bonsai Image，此外还有 20 亿参数的眼镜模型，以及 2026 年 4 月早些时候面向较小产品线发布的 Ternary Bonsai。搜索这个光秃秃的词，结果会随机落到这一堆里的某一个。

• Bonsai 27B——本页的主题。27B 系列的第一代，源自 Qwen3.6-27B，日期为 2026 年 7 月 14 日。当某个页面提到"Bonsai 27B"，且没有其他限定词、也没有"2"时，它指的就是这个模型，而这也正是应当使用的名称。

• Ternary Bonsai 27B——并不是另一个不同的模型。它是偏重质量的 Bonsai 27B 版本：同一个 27B 模型，相同的架构、相同的基座，只是用三值权重取代了二值权重。该仓库名为 Ternary-Bonsai-27B-gguf，其模型卡与二值版本一样，都将 Qwen3.6-27B 列为基座。这里的“Ternary”是一种权重格式，而非版本。

• Ternary Bonsai 2 27B——一个真正不同的模型。27B 系列的第二代，基于 Qwen3.8-27B 构建，于 2026 年 9 月 17 日发布，参数划分不同，质量宣称也不同。“2”承载了全部区别。

• 1-bit Bonsai 2B —— 同一家族中另一款不同规模的成员：一个面向眼镜级硬件的 20 亿参数视觉语言模型，而非任意精度下的 27B 模型。

所以，如果你来这里是为了弄清这些当中哪个是 27B 模型，答案是：上面第三行和第四行是同一个模型，只是两种权重格式，而第五行则不是。实际使用时：就叫它 Bonsai 27B，并在需要的时候加上 pack。

规格说明，来自模型卡

本节中的每个数字都来自 PrismML 为这两个包发布的模型卡，并且是厂商就其自身模型所作的陈述。如果某个数字是声称而非测量结果，则会将其标注为声称。

• 参数量——总计约 27.3B，而"27B"指的就是这一整体。这个拆分值得了解，因为它解释了内存表现：约 24.8B 分布在 64 个块的语言主干中，约 2.5B 在嵌入层和 LM head 中，约 0.46B 在一个 27 层的视觉塔中。低比特表示是端到端应用的——嵌入层、注意力、MLP 和 LM head——整个语言网络中没有任何更高精度的例外通道。

• 上下文——足足 262,000 个 token，没有长上下文变体，也没有缩减上下文的构建版本。该窗口的成本是受控管理的，而不是直接全额付出：主干是混合式的，因此其 64 层中只有 16 层保留完整的注意力缓存，而且该缓存以近乎无损的 4 位形式存储。在完整的 262K 窗口下，正是压缩后的缓存让模型在二值包上控制在约 9.4 GB 以内，在三值包上控制在 12.8 GB 以内。

• 模态——文本和图像，两个包都包含。视觉塔以紧凑的 4 位形式（0.63 GB）提供，并附带一份 BF16 副本（0.93 GB）。视觉也是压缩代价最高的部分，详见下文。

• 权重格式与大小 — 1-bit Bonsai 27B 使用二元 {−1, +1} 权重，并采用 FP16 分组缩放，以 GGUF Q1_0_g128 打包，实际每个权重的有效位数为 1.125 位；交付的文件为 3.803 GB，而卡片将部署占用空间四舍五入为约 3.9 GB。Ternary Bonsai 27B 使用三元 {−1, 0, +1} 权重，并采用相同的分组缩放；一个三元值携带 log₂3 ≈ 1.585 位信息，因此该表示形式的下限约为每个权重 1.71 位，理想情况下合计为 5.9 GB。已发布的三元打包文件大于该理想值，因为当今的内核将每个三元值存储在 2 位槽中——部署时每个权重 2.125 位——而交付的文件为 7.165 GB。PrismML 同时给出这两个数字，而不是只给出更好看的那个，并且二者之间的差距是内核限制，而非建模选择。

• 许可证—— 两个包均采用 Apache 2.0，两个代码仓库及厂商公告中均有说明。这是一种宽松许可证，不限制使用领域；在这一权重规模下，这一点比在大多数情况下都更为重要。

• 基础模型——两者均为 Qwen3.6-27B。这是对他人模型的重新压缩，而非从零开始训练的模型，因此 Bonsai 27B 的能力上限和更新节奏都追随上游的 27B 系列，而非 PrismML 的。

三元关系，仅陈述一次

这两个包是同一个模型，而坦诚的总结是：三值买的是质量，二值买的是占用空间，它们之间的差距比 3.9 GB 与 7.2 GB 的大小差异所暗示的要小。

在 PrismML 自己的 15 项基准测试的思考模式套件上，FP16 Qwen3.6-27B 基线得分为 85.07。Ternary Bonsai 27B 得分为 80.49——保留率为 94.6%，厂商将其四舍五入为约 95%。1-bit Bonsai 27B 得分为 76.11——89.5%，四舍五入为约 90%。因此，注重质量的包挽回了二值包与全精度之间大约一半的差距，同时多占用约 3.3 GB，而二值包才是能装进 12 GB 手机的那一个。同一套件显示，同一基线的 4 位 Q4_K_XL 构建得分为 84.99，即 99.9% 的保留率，占用 17.6 GB——正是这一对比解释了为什么这两种低位宽包会存在，因为它在质量上胜过它们，但在每一个能给模型分配少于 18 GB 的设备上落败。

二进制包性能下降的地方并不均匀，而按类别拆分才是有用的部分。相较于 FP16 基线，它在数学上从 95.33 降至 91.66，在编码上从 88.74 降至 81.88，但在指令遵循上从 78.47 降至 65.74，在智能体及工具调用工作上从 80.00 降至 66.03，在视觉上从 72.61 降至 59.57。如果你的工作负载是算术或代码补全，那么 3.9 GB 几乎等于没有成本。如果它涉及工具调用智能体或图像理解，那么压缩的代价实际上正是在这些地方付出。

模型卡还发布了一个它称为智能密度的衍生指标——每 GB 的聚合分数，经过归一化，使完美分数趋近于无穷大。按该指标，1-bit Bonsai 27B 达到 0.530，Ternary Bonsai 27B 达到 0.400，而同一基线的 2-bit IQ2_XXS 构建为 0.199，4-bit Q4_K_XL 构建为 0.155，FP16 模型为 0.051。该列表中有趣的数字是第一个比较：二值包在聚合质量上以不到一半的占用空间击败了传统的 2-bit 构建，而这正是一句话概括的该系列全部核心论点。

这两个包之间的完整直接对比，以及各自的数字从何而来，都列在本博客的 Bonsai vs Bonsai 27B 页面上，旁边还有共享同一家族名称的 20 亿参数模型。

随这个模型而来的一个问题，值得一个只讲事实的回答，仅此而已。这些包是同一底层模型的低位编码，而非重新训练的变体，各仓库也没有在它们旁边发布任何单独调优或未经审查的检查点——唯一提供的全精度产物，是同一组权重的解包 FP16 转换，其发布目的是让你能在标准工具中将压缩包与其自身基线进行对比。

权重和许可证，来自各仓库

Bonsai 27B 的权重已在 Hugging Face 上以 prism-ml 组织的名义发布，而文件列表是此次发布中最具体的信息。该二进制包的仓库中包含模型本体，大小为 3.803 GB；作为对比，同一模型的 FP16 GGUF 为 53.808 GB；一个 DSpark 推测解码草稿模型，4 位版本为 1.787 GB，BF16 版本为 7.292 GB；以及视觉塔，分别为 0.931 GB 和 0.629 GB。该三值仓库自带一个 7.165 GB 的包，另有一个 7.585 GB 的打包版本，后者采用 group-64 而非 group-128，且与上游兼容，但并非最优；此外还有相同的草稿模型和视觉文件。两个仓库均采用 Apache 2.0 许可，且均将 Qwen3.6-27B 列为基础模型。

那份清单可以推出两点。第一，53.808 GB 对 3.803 GB，正是模型卡开头主打的 14.2 倍比例，而且这是可核查的，不是凭空断言——全精度文件就在那里。第二，这次发布比模型本身更重：如果再把草稿模型和视觉塔也算进去，也就是多模态路径所需的部分，那你就是在 3.9 GB 的模型之上再加约 2.4 GB。3.9 GB 这个招牌数字指的是语言权重，而不是部署整体。

下载量是注重质量的包唯一领先的地方：截至 2026 年 10 月，三元 GGUF 仓库的下载量已超过 59 万次，而二进制包仅略高于 40 万次，同时两者的 MLX 容器各自都超过了一百万。这种分布表明，该模型大多运行在 Apple 硬件上，而非服务器上，并且下载它的人是在为额外五个百分点的留存率买单，而不是追求尽可能小的文件——这大致正是厂商设计这两款方案的本意。

运行它

如今你能获得的是每个包中四种工件，而你需要哪一种取决于你的运行时，而非质量。

• 适用于 llama.cpp 的 GGUF—— 主要路径，也是低比特内核为之编写的那一个。两个包都是面向 CUDA、Metal 和 CPU 的 llama.cpp 构建，但 1 比特和三值内核位于 PrismML 自己的分支而非上游，因此原版 llama.cpp 目前还无法正确加载它们。group-64 三值打包正是为需要上游兼容性、并愿意接受 7.585 GB 而不是 7.165 GB 来获得它的情况而存在。

• 适用于 Apple 芯片的 MLX — 分别提供独立发布的容器：二进制包为 5.129 GB，三值包为 8.491 GB。请注意，MLX 二进制容器比 GGUF 二进制包更大，这属于容器开销上的差异，而非不同的模型。

• 面向服务器框架的 AWQ 4-bit —— 为每个模型提供一个 4-bit 构建版本，面向那些需要 AWQ checkpoint 的推理服务框架，分为九个分片，总计 18.70 GB，并附带多 GPU 部署方案。这不是低比特产物；它还是同一个模型，只是采用了在机架上才说得通的精度，而代价是牺牲掉该模型存在的全部理由。

• 未打包的 FP16 safetensors——完整的约 54 GB 模型，采用 Hugging Face 标准格式，明确面向尚不原生支持 1 位权重的框架发布。厂商表示，一旦低位宽内核进入上游，该产物就会被淘汰。

在二进制包上测得的解码吞吐量，根据模型卡自身的表格，在 M5 Max 上为每秒 66.4 个 token，M5 Pro 上为 44.2，M4 Pro 上为 26.0，H100 上为 104.8；预填充则分别为每秒 874、421、133 和 2,755 个 token。公告页面引用的峰值更高——M5 Max 上最高可达每秒 87 个 token，RTX 5090 上可达 163——那是厂商自身的最佳配置结果，而非表格中的数值。应将这两组数据视为不同的测量条件，而非相互矛盾，并且两者都视为厂商报告值。峰值内存同样来自该模型卡：在二进制包上，4K 上下文为 5.2 GB，10K 为 5.6 GB，100K 为 11.6 GB；在三元包上则分别为 8.4、8.7 和 14.7 GB——但需注意，这些数字早于 4 位 KV 缓存，而正是后者将完整的 262K 窗口降至个位数 GB。

DSpark 起草器是可选的，在启用它之前值得了解，因为它不会改变输出：它是一个六层的块并行 Transformer，以从五个均匀间隔的目标层中提取的隐藏状态为条件，在服务精度下会增加约 0.5 GB，并且它对照目标模型进行验证，而不是自行采样。这就是为什么供应商可以宣称在 CUDA 上实现 1.37 倍加速，而不影响质量指标。它在 Apple silicon 上默认未启用。

本地模型在哪里跑到路的尽头，才是有意思的工程问题，而且这是一个路由问题，而不是模型问题。笔记本电脑上一枚 3.9 GB 的模型只能处理装得进其上下文的东西；其余一切都得有处可去，而那个去处就是 API 背后的托管模型。OrcaRouter 就是这一层——一个端点统辖 200 多个托管模型，对提供商标价 0% 加价，跨提供商自动故障转移，以及从本地层级向托管层级的升级规则以配置形式表达，而非手工拼装。它是本地模型之上的一层，而不是它的替代品。

对比索引

Bonsai 27B 属于一个系列，其中每个相邻成员回答不同的问题，而这些页面则分别承接每一个问题——此处不再对其中任何一个重新论证。

• Bonsai 与 Bonsai 27B 对比——一边是 20 亿参数的眼镜端模型，一边是它：参数量是前者的十六倍，上下文长度是前者的二百五十六倍；以及为什么这个家族名称并不能说明你下载的究竟是什么。这个页面在本站是一篇博客文章，而非托管模型——在这个家族里，这一区别值得分清楚。

• Bonsai 27B 对阵 Qwen3.8-27B——本模型与它所不采用的更新基座之间的正面交锋。本批次中有一个专门页面载有这项对比，而由于这两个模型名称相似、又仅相隔一代，它值得作为独立内容来阅读，而不是作为本规格说明的延伸。

• Bonsai 与 Ternary Bonsai 2 27B 对比——代际跃升，以及这两次发布用两把不同的尺子来衡量其质量：一个报告的是对基线的保持，另一个则是比较性主张。

• Ternary Bonsai 2 27B —— 独立成篇的第二代，基于 Qwen3.8-27B，面向那些已经决定想要更新款而非此款的读者。

什么尚未确定

本页面上的每一个质量指标都来自 PrismML，是在 PrismML 自有的 15 项基准测试套件上测得的，公司外部没有任何人发表过对它的复现。这是关于 Bonsai 27B 的已知信息中最大的一个空白：其压缩性能主张异常具体，也异常可核查，但至今仍未经第三方核查。厂商还明确表示，智能体编程——长周期、多文件、运行并修复的工作流——并不是本次发布的一个重点目标，而为此调优的一个变体是路线图上的下一项，这与上文类别拆分中工具调用和指令遵循方面的损失是一致的。在出现独立评估之前，留存率数字和密度排名都应被理解为厂商的立场，而不是已经确立的结果。

已经确定的事情更小也更有用：权重已经存在，大小可以对照文件列表进行核对，许可证是 Apache 2.0，而两个包相差约 3.3 GB，换来的是大约五个点的保留质量。这足以在它们之间做出选择。哪一个适合你，取决于你的工作负载看起来更像算术还是更像工具调用，而上面的类别数字是今天做出这一决定时可获得的最佳证据。