智能眼镜上的 Bonsai：在 Snapdragon AR1 Gen 1 上运行的 2B 1-Bit VLM

决定这项发布究竟适合什么用途的数字，不是 4 倍，也不是 2 倍，而是 1,024——PrismML 于 2026 年 9 月 23 日在 Snapdragon Summit 上装到一副智能眼镜上的模型的上下文长度。这个 1-bit Bonsai 2B 视觉语言模型是一个基于 Bonsai 1.7B 构建的 20 亿参数系统，在搭载 Snapdragon AR1 Gen 1 Platform 的 AI 智能眼镜上本地运行；而 PrismML 主推的数字是内存和速度：LLM 权重为 0.43 GB，而对应的 4-bit 1.7B 模型为 1.66 GB，缩减了 3.83 倍；每秒 15.36 个 token，而后者为 7.44，提升了 2.06 倍。这两个数字都来自厂商自己，都是在 4 GB 测试平台上测得的，也都是与 Qwen 3 1.7B 4-bit 模型对比测得的。它们不是与任何 Bonsai 27B 对比测得的，也不是与任何托管模型对比测得的。把它们当作关于 Bonsai 质量的声明来解读是错误的；把它们当作关于什么能装进眼镜级内存预算的声明来解读才是正确的。

已公布的内容，尽在一处

PrismML的公告——发稿地标注为帕萨迪纳，并与高通的骁龙峰会相呼应——将一款20亿参数的视觉语言模型部署到了AR1 Gen 1眼镜平台上。其架构拆分为一个17亿参数的1比特语言模型加上一个3亿参数的4比特视觉编码器，上下文长度为1,024个token。它构建于PrismML的Bonsai 1.7B之上，因此属于Bonsai家族中体量最小的一端，而非一种全新架构；并且它是使用内部支持1比特算子的QNN SDK，为高通Hexagon NPU编译的。

标题声称，如供应商所述：

• 在某些眼镜形态规格下，可在相同的内存限制内容纳参数量多 4 倍的模型。

• 提供与同一模型在4位精度下大致相当的智能，同时内存占用减少约4倍。

• 以超过2倍的速度生成token。

那三句话就是发布稿本身。内存和速度宣称背后的具体测量数据是 0.43 GB 对 1.66 GB，以及每秒 15.36 个 token 对每秒 7.44 个 token，二者都是在配置了 4 GB 内存的平台上进行的。AR1 Gen 1 本身标称峰值 6 TOPS 和每周期 2,304 MACs——这是平台的数据，而非语言模型推理的数据；公告自己的数字通过单独列出每秒 token 数，已经清楚地区分了这一点。

4x 是一个关于内存的说法，而基线是另一个模型

这一段值得慢下来仔细看，因为“4x”这类数字往往比它出自的那句话传播得更远。PrismML 为眼镜模型发布的每一项对比，都是针对 Qwen 3 1.7B 的 4 位量化——相同的参数量级，相同的任务，不同的量化方式。这是一个合理且有价值的对比：它是眼镜 OEM 实际面对的对比，问题在于 1 位路线能否省回足够的内存，从而值得投入内核层面的工作。它不是与 4 位版本 Bonsai 的对比，也不是与在别处运行的更大 Bonsai 的对比。

公告所附的基准测试脚注同样措辞谨慎。PrismML 于 2026 年 9 月将 Bonsai 1.7B 1-bit LLM 与 Qwen 3 1.7B 4-bit 模型在 BFCL v3、HumanEval+、MMLU Redux、IFEval、IFBench、MuSR、GSM8K 和 GPQA Diamond 上进行了对比评估，所报告的结果是这两种配置“取得了相当的基准测试结果”。是相当，而非更优。公告中没有逐项基准测试得分，也没有任何独立复现——这对于发布周的边缘版本发布来说很正常，也正因如此，在 PrismML 之外的第三方运行这些测试之前，这些数字应当被标注为厂商自报数据。

1,024 个 token 是塑造产品的规格

眼镜上的视觉语言模型与聊天窗口中的视觉语言模型是两种不同的工作负载，而上下文长度正是体现这一差异的地方。在 1,024 个 token 时，模型可以容纳一条简短指令以及摄像头当前看到的内容。它无法容纳对话历史、一份文档，或一长串之前的轮次。这并不是该版本的一个缺陷——正是这一限制才使该版本成为可能，因为 KV 缓存和激活值必须与权重一起放在同样的 4 GB 中，而一个具有 262K token 上下文的 27B 级模型需要多出几个数量级的空间来容纳这些状态。

所以，对已交付产品的诚实描述是：一个完全在设备上运行的、能力不错的短上下文助手。眼镜类任务——识别这个、读取那个、翻译我面前的标牌、回答关于我正在看什么的问题——都能容纳在 1,024 个 token 内。任何需要记住最近十分钟的事情则不行，而且无论多少 1-bit 压缩都改变不了这一点，因为限制在于状态，而不是权重。

边缘生态系统应该从中汲取什么

这次公告中真正全新的工程工作并不在模型本身，而在于内核路径：一个 1 位 LLM 通过支持 1 位内核的 QNN SDK 编译到 Hexagon NPU 上。低位宽权重已经能在 CPU 和 GPU 上运行有一段时间了，PrismML 自家的 Bonsai 27B 发布也已在 Apple silicon 和 NVIDIA 硬件上证明了这一点。而把二值权重内核放到移动端 NPU 上则是另一个问题，因为加速器的数据通路、打包格式和调度都必须适配一种根本不是浮点类型的表示。

如果这条路径能泛化到这一个模型之外——而 SDK 的表述表明 PrismML 有意如此——那么有趣的后果就是，1-bit 系列不再只是笔记本电脑和手机的故事，而会成为始终在线设备的故事。公告中的 4 GB 平台是当前的上限。任何能在质量固定的情况下降低权重占用的做法，都会提高可容纳在该上限之下的模型规模。

端侧这一说法值得一点提醒

在一副眼镜上实现完全本地的多模态推理是一个很强的说法，因此有必要区分哪些是已演示的内容，哪些是隐含推论。AR1 Gen 1 是一个为持续感知和音频打造的眼镜平台；高通自己对端侧语言模型的表述总体上是混合式的，即设备处理其所能处理的部分，并将其余部分交给配对的手机或云端。高通首次公开展示的端侧小型语言模型演示，是与 AR1+ Gen 1 平台相关，而不是 AR1 Gen 1。这两点都不与 PrismML 的公告相矛盾——公告称该模型在 AR1 Gen 1 上本地运行，而厂商自己的吞吐量和内存数据也与小型模型正好能做到这一点相一致——但它们确实意味着，基于此构建的实际产品几乎肯定会是一个带升级路径的本地层级，而不是一个从不与任何其他设备通信的设备。

无论如何，这都是正确的架构。一个 1,024 token 的本地模型非常擅长处理能放进 1,024 token 的请求，而对于放不进去的请求则无法回答。

升级路径应位于何处

对于基于这样一个版本进行构建的人来说，设计问题不在于眼镜端模型好不好——而在于它无法处理的请求会怎样。如果在应用代码里回答这个问题，就会变成一堆特殊情况，每次端侧模型的大小或上下文发生变化时都得重写。如果作为路由策略来回答，它就变成一条规则：超出本地层级上下文预算的请求，或需要本地层级所不具备的工具或推理能力的请求，升级到托管模型。这正是 OrcaRouter 存在的意义——一个端点前置 200 多个托管模型，具备故障转移，并且该策略在配置中表达，而不是在客户端中。Bonsai 本身在这里并不经过路由；它是你在自己硬件上运行的下载项。路由层所覆盖的是它上方的边界，而这条边界正是眼镜部署将耗费大部分工程时间的地方。

接下来看什么

要让这份发布从一则公告蜕变为一个平台，需要三件事。其一，在“对比结果”那一行背后给出按基准分项的明细，让与 4 位版本的取舍清晰可见，而不是只给一句概括。其二，在同一条 NPU 路径上实现更大的上下文窗口——这属于状态内存问题，而非权重问题，因此是两者中更难的一个。其三，对 1 位 1.7B LLM 与其 4 位对应版本进行独立评测，因为本次发布中的每一个数字目前都出自构建它的一方之手。

在那之前，准确的总结范围狭窄但有用：一个 20 亿参数的多模态模型如今能在眼镜级设备上运行，语言权重只有 0.43 GB，在 1,024 个 token 的上下文预算下，速度约为 4 比特等效方案的 2 倍，内存约为其四分之一。这对端侧推理来说是真正的一步，对模型能力来说则是一小步，而这两者并不是同一种主张。