智慧眼鏡上的 Bonsai：運行於 Snapdragon AR1 Gen 1 的 2B 1 位元 VLM

決定這項發表實際上適合什麼的數字，不是 4x，也不是 2x。而是 1,024——PrismML 於 2026 年 9 月 23 日在 Snapdragon Summit 上放進一副智慧眼鏡的模型，其上下文長度。1 位元 Bonsai 2B 視覺語言模型，是以 Bonsai 1.7B 為基礎打造的 20 億參數系統，在搭載 Snapdragon AR1 Gen 1 Platform 的 AI 智慧眼鏡上本機執行，而 PrismML 主打的數據是記憶體與速度：LLM 權重 0.43 GB，對比對應 4 位元 1.7B 模型的 1.66 GB，減少 3.83x；每秒 15.36 個 token，對比 7.44，提升 2.06x。這兩項數字都出自廠商本身，都是在 4 GB 測試平台上測得，且都是與 Qwen 3 1.7B 4 位元模型相比測得。它們並非與任何 Bonsai 27B 相比測得，也不是與任何代管方案相比測得。把它們解讀成關於 Bonsai 品質的宣稱會是個錯誤；把它們解讀成關於眼鏡等級記憶體預算能容納什麼的宣稱，才是正確的。

宣布了什麼，都在一處。

PrismML 的公告——發稿地為帕薩迪納，與 Qualcomm 的 Snapdragon Summit 相連結——將一個 20 億參數的視覺語言模型放上 AR1 Gen 1 眼鏡平台。其拆分為一個 1.7B 的 1 位元語言模型，加上一個 0.3B 的 4 位元視覺編碼器，上下文長度為 1,024 個 token。它建構在 PrismML 的 Bonsai 1.7B 之上，因此是 Bonsai 家族中較小型的一端，而非全新架構；並且它是使用支援 1 位元核心的內部 QNN SDK，為 Qualcomm Hexagon NPU 編譯而成。

該標題所稱，如供應商所述：

• 在某些眼鏡外型規格下，可在相同的記憶體限制內，容納參數多達 4 倍的模型。

• 提供與同模型在 4 位元精度下大致相當的智能，同時使用約少 4 倍的記憶體。

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

那三句話就是這份新聞稿。記憶體與速度宣稱背後的具體量測數據，是 0.43 GB 對 1.66 GB，以及每秒 15.36 對 7.44 個 token；這兩項數據都是在配置 4 GB 記憶體的平台上所得。AR1 Gen 1 本身所引用的峰值為 6 TOPS 與每週期 2,304 MACs——這是平台的數字，而非語言模型推論的數字；這項區別，發表內容本身的數字已透過另外列出每秒 token 數而清楚表明。

4x 是記憶體方面的宣稱，而基準是不同模型

這一段值得放慢腳步細看，因為「4x」這類數字，往往會傳播得比它原本出處的那句話更遠。PrismML 針對眼鏡模型發布的每一項比較，都是對照 Qwen 3 1.7B 的 4 位元量化——相同的參數級別、相同的任務，只是不同的量化方式。這是合理且有用的比較：這正是眼鏡 OEM 實際會面對的比較，問題在於 1 位元路徑能否換回足夠的記憶體，值得為此投入核心（kernel）開發工作。這不是與 Bonsai 的 4 位元版本相比，也不是與在其他地方執行的更大 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 個詞元時，模型可以容納一段簡短指令，再加上相機當下所看到的內容。它無法容納對話歷史、一份文件，或一長串先前的往來輪次。這並不是這次發布的缺陷——而是讓這次發布得以實現的限制條件，因為 KV 快取與激活值必須和權重一起存放在同樣的 4 GB 之中，而一個具備 262K 詞元上下文的 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-bit 之間的取捨具體可見，而非只是概括帶過。在同一條 NPU 路徑上提供更大的上下文視窗；這是狀態記憶體的問題，而非權重問題，因此是兩者中較難的一項。以及對 1-bit 1.7B LLM 與其 4-bit 對應版本進行獨立評估，因為本次發布中的每一項數字目前都來自打造它的那一方。

在那之前，準確的摘要既狹窄又實用：一個 20 億參數的多模態模型，如今能在眼鏡級裝置上運行，語言權重僅 0.43 GB，速度約為 4 位元等效版本的兩倍，記憶體約為其四分之一，且上下文預算為 1,024 個 token。這對裝置端推論而言是真正的一步，對模型能力而言則是一小步，而這兩者並非同一種主張。