Bonsai 对比 Bonsai 27B：同一个家族名称，参数量却是十六倍

任何按名称选购这个家族产品的人都会买错型号，原因在于，光秃秃的“Bonsai”这个名字并不是一个型号。它是一个家族；而截至本周，这个家族包含一个可在智能眼镜上运行的 20 亿参数视觉语言模型，以及一个可在手机、笔记本电脑或台式机上运行的 270 亿参数模型。第一个是 2026 年 9 月 23 日发布的 1-bit Bonsai 2B 视觉语言模型——一个 1.7B 的 1 比特语言模型加上一个 0.3B 的 4 比特视觉编码器，1,024 词元上下文，基于 Bonsai 1.7B 构建。第二个是 Bonsai 27B，于 2026 年 7 月 14 日以 Apache 2.0 许可发布，基于 Qwen3.6-27B 构建，具有 262,000 词元上下文，并可选 5.9 GB 的三值构建版本或 3.9 GB 的二值构建版本。它们共享一个名称、一个厂商、一种压缩理念，除此之外几乎再无共同之处。十六倍的参数量，二百五十六倍的上下文，以及两种完全不同的设备。

这个页面是为那些搜索了其中之一、结果却落到另一个上的人准备的。

命名问题，直白地说

PrismML 的模型菜单目前列出了 Bonsai 2 27B、Bonsai 27B、Bonsai 8B、Bonsai 4B、Bonsai 1.7B 和 Bonsai Image。眼镜发布公告在 Bonsai 1.7B 系列的基础上新增了一个 20 亿参数的视觉语言模型。因此，单说“Bonsai”可能指至少四种参数级别和两代模型中的任意一个，而尺寸后缀是唯一能区分它们的东西。这不是对命名方式的批评——这是模型家族的常态——但这确实意味着，家族名称本身并不包含关于你正在下载什么的信息。

有用的划分不在于代际，而在于设备类别。27B 产品线中的一切都假定你有 4 GB 到 8 GB 的内存可以分配给语言模型，并且愿意花掉它。1.7B 产品线中的一切都假定你只有几百兆字节，不会更多。仅仅这一个事实，就在任何基准测试之前决定了这个家族中哪一半与你相关。

每一个到底是什么

• 参数 — 眼镜模型中包含一个 1.7B 的 1 比特 LLM 加一个 0.3B 的 4 比特视觉编码器，而 Bonsai 27B 中则是源自 Qwen3.6-27B 的 27B 级模型。

• 上下文——眼镜模型上为 1,024 个 token，而 Bonsai 27B 则拥有完整的 262,000 token 上下文。

• 语言模型权重 — 1-bit 1.7B 为 0.43 GB，而三值 Bonsai 27B 为 5.9 GB，其 1-bit 版本为 3.9 GB。

• 表示形式 — 两者均采用二值 {−1, +1} 权重并配合 FP16 分组缩放，这正是该系列赖以构建的 1 比特方案；Bonsai 27B 还额外提供三值 {−1, 0, +1} 构建，每权重有效位数为 1.71 比特。

• 目标芯片——Snapdragon AR1 Gen 1 眼镜平台上的 Qualcomm Hexagon NPU，通过支持 1 位内核的 QNN SDK 编译，对比通过 MLX 的 Apple 芯片和通过 CUDA 的 NVIDIA，用于 Bonsai 27B。

• 解码吞吐量——在 4 GB 的 AR1 Gen 1 测试平台上，眼镜模型达到每秒 15.36 个 token，相比之下 iPhone 17 Pro 约为每秒 11 个 token，Apple M5 Max 为 87 个，而 RTX 5090 上的 1-bit Bonsai 27B 则为 163 个。

这些数字全部来自厂商，而且这两组数据是在不同硬件上、对照不同基线测得的，因此它们描述的是两款不同的产品，而不是同一条曲线上的两个点。

Bonsai 27B 在哪些方面胜出，而且差距悬殊

上下文是第一位的，而余量并非细枝末节。262,000 token 的窗口能容纳一个代码库、一份长文档、一份转录稿，或一次正在运行的智能体会话，而且还绰绰有余。1,024 token 的窗口只能容纳一条简短指令和一张图像。如果你的工作负载涉及阅读任何超过一页的内容，那么 Bonsai 27B 是两者中唯一一个还能胜任这项工作的；而在眼镜模型上，再怎么巧妙地进行提示也无法弥合这一差距，因为限制在于为键值状态保留的内存，而不是权重的大小。

能力排在第二位。据报道，Bonsai 27B 的三值版本在包含 15 项基准测试的 thinking 模式套件中，保留了其全精度基线约 95% 的能力，其 1 位版本则约为 90%，其中损失最大的是视觉与工具使用方面。这些是厂商在其自家测试套件上给出的数据，而且它们与一个 20 亿参数的模型仍不是同一回事——该模型唯一公布的质量声明是，它在与 4 位 Qwen 3 1.7B 对比时取得了“可比的基准测试结果”。眼镜模型并没有被其制造商拿去与 27B 模型比较，因为这种比较不会有意义。

生态系统是第三点。Bonsai 27B 以 GGUF、MLX 和 AWQ 打包形式发布，并配有文档化的运行时，因此你可以在自己已有的硬件上运行它。眼镜模型则存在于高通 NPU 工具链之中。

在 2B 胜出之处，而这正是全部意义所在

0.43 GB 的语言模型能装进 5.9 GB 模型去不了的地方，而眼镜平台就是其中之一。这就是全部论点，而且它比规格对比听起来更有力，因为所讨论的设备别无选择：一副只有 4 GB 共享平台内存的眼镜，无论哪种构建都无法承载 Bonsai 27B；而手机要承载三值构建，就不得不放弃手机的大部分用途。

还有第二个不那么受关注的胜利：1-bit 表示在这一设备类别上并非妥协，而是使其成为可能的关键技巧。PrismML 自己的说法是，1-bit 路径能提供大致相当于同一模型在 4-bit 精度下的智能，同时仅使用约四分之一的内存，并以两倍以上的速度生成 token。对于每一毫瓦和每一兆字节都要争夺的常开设备而言，这种权衡本身就是产品。

所以，这两个模型并不构成竞争关系。2B 是在没有别处可运行时运行的那个。27B 则是在有别处可运行时运行的那个。

层级边界才是真正的决策

几乎没有人是在这两者之间做选择。现实中的部署方案是两者兼有：设备上跑一个小型常驻模型，处理适合 1,024 个 token 以内的请求；而在这之后还有一个更大的模型，应对其余所有情况。一旦接受了这种形态，工程问题就不再是“选哪个 Bonsai”，而是“分界线划在哪里，以及由谁来执行这条线”。

如果这条线在应用代码中强制执行，它就会变成一个分支，每当设备端模型更改上下文长度或能力时都必须重写——而根据过去三个月的证据，这大约是每月一次。如果作为路由策略强制执行，它就变成一条关于上下文预算和所需能力的规则，而本地层级也依然是一个层级，而不会变成贯穿整个客户端、被默认写死的假设。这正是 OrcaRouter 所运作的层面：一个端点，位于 200 多个托管模型之前，具备故障转移和以配置形式表达的升级策略。两个 Bonsai 都不在这里路由——它们都是你在自己硬件上运行的下载模型——所以诚实的表述是：路由层覆盖的是本地层级之上的那一层，而面对一个 1,024 token 的本地模型，大多数流量都会落在那一层。

如果你必须选一个

• 你正在为眼镜、可穿戴设备或任何始终开启的设备进行构建——1-bit Bonsai 2B 视觉语言模型是这里唯一的选择，而 1,024 token 的上下文是你围绕其构建、而非与之对抗的设计约束。

• 你是在为手机打造——3.9 GB 的 1-bit Bonsai 27B 是该系列中能够适配 iPhone 级内存预算的最大模型，而且它能为你带来眼镜模型无法企及的 262K 上下文。

• 您正在为笔记本电脑或台式机进行构建——在三元 Bonsai 27B 构建是家族中以质量为导向的选择，而 1 位构建换来的是速度而非能力。

• 你正在构建的是一个混合体——先定升级规则，再定模型。模型可以换；而边界一旦落进客户端，就换不动了。

值得关注的是，让这款眼镜得以发布的那条 NPU 路线能否向上延伸。如果移动端加速器上的 1-bit 内核具备可推广性，那么 1.7B 这条产品线就会继续做大，在手机上跑 27B 模型的理由也会更充分。在那之前，这个家族的两半仍会按设备类别清晰划分，这使得选择比共用的名称所暗示的更为简单。