一個 14MB 的檔案，比你手機裡一張照片還小，可以聽懂「把客廳燈調到 30」然後真的去調。但它在自己的主力評測榜上，只排第三。
一句話結論：Needle 2 是 45M 參數、14MB 的端側工具呼叫模型，Mobile Actions 主榜 63.7 分只排第三，但函式名準確率 98.3％ 全場最高——選端側模型要看分項，不是看總分。
Cactus Compute 這兩天放出 Needle 2，中文圈的轉述幾乎清一色停在「14MB」這個數字上。我把官方那份評測表整個看完之後，覺得最值得講的反而不是體積，是它輸掉的那幾欄，還有它為什麼輸了還是能被 Pebble 放進出貨的產品裡。
這篇拆三件事：它到底做得到什麼、那張評測表該怎麼讀、以及你手上的裝置該不該用它。截至 2026 年 8 月的官方公開數據。
Needle 2 到底是什麼？
它是一個只做一件事的模型：把人講的話，翻譯成一個函式呼叫。
你先告訴它有哪些工具可以用（開燈、播音樂、傳訊息，各自有什麼參數），然後丟一句人話進去，它吐回一段 JSON，說明該叫哪個函式、參數填什麼。沒有聊天，沒有寫作，沒有解釋世界。官方的說法很直接：開一盞燈不需要前沿模型。
| 項目 | Needle 2 |
|---|---|
| 參數量 | 45M（前一代 Needle 是 26M） |
| 檔案大小 | 14MB，單一二進位檔 |
| 執行時記憶體 | 約 28MB 上限（不隨對話長度增加） |
| 量化 | CQ2-bit，訓練階段就內建，非事後壓縮 |
| 授權 | Apache 2.0 |
| 速度 | Raspberry Pi 5 解碼 500+ tok/s；平價手機 300–700 tok/s |
| 跑得動的硬體 | ARM64／x86-64／ARMv7／RISC-V／WebAssembly，含 ESP32-P4 這類微控制器 |
| 能做 | 工具呼叫、裝置操作、結構化抽取 |
| 不能做 | 對話、寫作、任何需要世界知識的事 |
那個 28MB 的記憶體上限值得多講一句。它用 256 token 的滑動視窗，工具宣告被釘死在快取裡不會被擠掉，所以聊多久記憶體都是那個數。對雲端模型來說這是限制，對一塊只有幾十 MB RAM 的板子來說，「不會漲」比「上限多少」重要得多。
為什麼它在主榜只排第三，我還說值得看？
先把難看的數字放上來。Google Mobile Actions 是這類模型的主力評測，961 題，計分方式是嚴格逐項比對：函式名、呼叫順序、每一個參數值，錯一個就算錯。
| 模型 | 總分 | 函式名準確率 | 非空回應率 |
|---|---|---|---|
| LFM2.5 230M（f16） | 69.1 | 93.0 | 98.9 |
| FunctionGemma 270M（f16） | 64.0 | 87.3 | 98.9 |
| Needle 2（CQ2-bit） | 63.7 | 98.3 | 99.4 |
| Apple FM（裝置端） | 57.6 | 94.2 | 95.5 |
第三名，跟第二名差 0.3 分，跟第一名差 5.4 分。如果你只看第一欄，故事就是「14MB 打不贏 230M」，收工。
但第二欄那個 98.3 才是我停下來的地方。它比第一名高 5.3 個百分點，而且是全場唯一一個進 98 的。
「函式名準確率」為什麼比總分重要？
因為這兩種錯，後果完全不同。
總分算的是「整題全對」。挑對了函式但某個參數差一點——你說「調到 30」它填了 35——這題算你錯。函式名準確率算的是「有沒有挑對要做哪件事」。
把燈調到 35 而不是 30，使用者皺一下眉。把「關燈」聽成「開暖氣」，那是另一種等級的事故。
在一個會動的實體裝置上，這兩件事不該被算進同一個平均分。參數偏差是可以再問一次、可以用滑桿修正的；叫錯函式是不可逆的動作。Needle 2 明顯是照著後者去優化的——它在「挑哪個」上做到接近滿分，在「填多準」上認了。
這個取捨在另外兩張表上更明顯。Seal-Tools 這組評測的特點是候選工具清單很長、而且多半要連續呼叫好幾個函式：
域外那一欄的差距最說明問題：28.7 對 17.0，Needle 2 領先 11.7 分，接近對手的 1.7 倍。這欄測的是遇到沒見過的工具還認不認得出來——對一個要裝進各家硬體、每家工具清單都不一樣的模型來說，這是最貼近真實部署的一題。
它靠的是一個叫 tool retrieval 的機制：宣告超過五個工具時，每一輪先用內建的檢索頭把清單收窄到最相關的五個，再把解碼文法限死在這五個裡面。沒被選中的工具不是「比較不可能」，是根本叫不到。
那它到底輸在哪裡？
輸在 BFCL v4，而且是包尾。這是最通用的那張函式呼叫評測，3,641 題：
42.6，最後一名。官方自己把原因寫出來了：Needle 的訓練資料是消費裝置動作——智慧家庭、手機、穿戴、電視、車——BFCL 裡的企業級 API 和 Java／JavaScript SDK 完全不在那個分布裡。Python 簡單呼叫這一列它 61.2，跟大它六倍、專門為此訓練的 FunctionGemma 只差 1.1 分；差距全部集中在它沒學過的地方。
我認為官方把這張表放出來這件事本身值得記一筆。他們大可以只貼 Seal-Tools。願意把自己包尾的那張一起貼，還附一段說明為什麼，這在模型發布裡不算常見。
省下來的算力有多少？（互動試算）
官方公布了每個 token 的實際算力消耗。體積小不等於省電，真正決定電池的是每 token 要動多少乘加運算，以及要從快閃記憶體讀多少位元組。下面這個試算機用官方那組數字，算你的用量一天差多少：
用預設值試一次：每天 200 次呼叫、每次 120 token，Needle 2 跟 Apple FM 之間差 85 倍。這個倍數不會因為裝置變快而消失，它是架構決定的。官方對這段的說法是，在裝置晶片上，從快閃或 DRAM 搬一個位元組的代價，比做一次乘加高好幾個數量級——所以真正要省的是「每 token 讀多少位元組」，而不只是參數量。
它是怎麼把 45M 塞進 14MB 的？
靠一個叫 Simple Attention Network 的架構，加上 2-bit 量化。後者是重點：一般做法是先訓練好再壓縮，小模型這樣搞通常會壞掉。Needle 2 從預訓練開始就對著 2-bit 訓練，權重、激活、KV 快取一起。官方的講法是「你部署的那個 2-bit 模型，就是當初被訓練的那個模型」。
幾個設計取捨，我覺得比參數量本身有意思：
- 用 Hadamard 變換取代 FFN：把小模型裡最吃權重讀取的那層換成一個固定矩陣加學到的對角線，幾乎不佔參數。
- 世界知識搬出網路本體：改放進雜湊 n-gram 表，每個 token 只讀幾列。它 45M 參數裡有 8M 是這種「用查的、不用算的」記憶。
- 文法先於運算：因為解碼文法事先知道哪些 token 合法，引擎在結構性 token 上可以跳過最多 98％ 的詞彙表投影。
- 訓練量小得多：Needle 2 預訓練 1,150 億 token、後訓練 380 億。對照組 LFM2.5-230M 預訓練用了 19 兆 token，大約 120 倍，兩者評測互有勝負。
這條路線跟我們之前寫過的 LFM2.5-2.6B 和 VibeThinker 3B 是同一個大方向的不同刻度，另一頭則是 Qwen3.8-Max 的 2.4 兆參數——同一個月裡，兩端都在拉開。
怎麼在十分鐘內自己試一次？
不用 GPU，不用註冊，Mac 或 PC 都可以。
- 裝套件：終端機執行
pip install cactus-needle。權重會自動下載，總共 14MB，不用等。 - 宣告一個工具：用
@needle.tool裝飾一個 Python 函式。函式簽名提供參數型別，docstring 就是工具描述——官方明講，把描述寫好是這裡的全部功夫。 - 丟一句人話進去：
agent.run("what's it like in Lagos right now?")，它會挑函式、執行、把結果餵回去、給你最後答案。 - 看回傳的 confidence：每次回應都帶一個信心分數。設一個門檻，高於它就執行，低於就重問或轉給雲端模型。
- 試一句不相關的：問它天氣以外的事，它會回一個空呼叫
[]。這是設計，不是失敗——它沒有自由文字的退路，寧可拒答也不亂猜。
想收窄輸出範圍的話，用 needle.Field 可以把數值範圍、正則、長度、陣列元素數直接編進解碼文法。設了 gt=0, le=10000，它就吐不出範圍外的數字——不是「不太可能」，是文法上不允許。做轉帳、控溫這種有實際後果的動作時，這比事後驗證可靠。
官方網站上也有一個瀏覽器內的 sandbox，直接用 WebAssembly 跑，連裝都不用裝。
什麼情況下不該用 Needle 2？
比它能做什麼更重要。照官方數據，這幾種情況你應該直接跳過：
如果你的場景在上面找不到，或者你要的是一個會聊天的助手，smolagents 這類接雲端模型的 agent 框架、或者 LFM2.5 那個級距的端側模型都更合適。工具沒有好壞，只有配不配。
有人已經拿它出貨了嗎？
有一個。Pebble 把它放進 Index 01 的 app 裡，本機跑。創辦人 Eric Migicovsky 的說法是，那隻戒指沒有螢幕，所以你講一句話，動作就必須發生，有沒有網路都一樣。
這個案例比任何評測分數都能說明它的定位。一個沒有螢幕的裝置，沒辦法顯示「抱歉我不太確定」，也沒辦法等你重講一次。它需要的不是最高的平均分，是最高的「有沒有挑對那件事」，加上一個誠實的信心分數告訴它什麼時候該閉嘴。
我怎麼看這件事
老實說，我對「14MB」這個數字本身沒那麼興奮。真正讓我把整份文件讀完的是那個信心機制的設計：它的信心分數取兩個訊號的較小值——一個事後校準的評分頭，加上呼叫 token 的解碼機率——兩個都同意才算數。官方對這個設計的描述是，這樣做的失敗模式是「往上呈報」，不是「執行錯誤」。
這一年多來大部分模型發布都在比同一件事：分數更高、上下文更長、參數更多。Needle 2 挑的是另一個問題——在一個只有 28MB、沒有網路、而且動作會直接影響現實世界的地方，怎麼樣讓「不確定」變成一個可以被程式處理的狀態。
它不見得是同級最強的那個。BFCL 那張表寫得很清楚。但如果你正在做一個會動的東西，這個取捨方向可能比多五分總分更值錢。
至於那份評測表的讀法，倒是可以帶走用在別的地方：下次看到一個模型的排名，先問它的評分方式跟你的失敗成本對不對得上。總分是給榜單看的，分項才是給你自己看的。
常見問題
Needle 2 免費嗎？可以商用嗎？
模型是 Apache 2.0，免費且可商用，權重和訓練程式都公開。要注意的是 Cactus Engine（他們那套推論引擎）走的是另一份可取得原始碼的授權，跟模型本身不同，商用前值得先看清楚你用到的是哪一塊。
Needle 2 跟 Needle 1 差在哪？
Needle 1 是 2026 年 5 月發布的 26M 參數模型，從 Gemini 蒸餾出來，做單次函式呼叫。Needle 2 是 45M，加了工具檢索、信心評分、結構化抽取和多輪對話，並且改成單一二進位檔發布，不用另外裝執行環境。
14MB 真的能在微控制器上跑嗎？
官方點名 ESP32-P4（配 32MB PSRAM）這類有外接記憶體的型號，並提到有人回報在 ESP32-S3 上以大約 11MB 跑起來。引擎可以單執行緒編譯給裸機環境，也有給 Cortex-M4／M7／M55 的靜態函式庫。純內建記憶體、幾百 KB 的那種 MCU 還是不行。
它比 Apple 的裝置端模型好用嗎？
看場景。Mobile Actions 上 Needle 2 的 63.7 高過 Apple FM 的 57.6，BFCL 總分則是 Apple FM 的 61.7 高過 Needle 2 的 42.6。Apple FM 約 3B 參數，是通用模型；Needle 2 只做工具呼叫，體積小約 70 倍、每 token 算力少約 85 倍。要通用能力選前者，要塞進便宜硬體選後者。
可以用自己的工具重新訓練嗎？
可以，而且這是官方推薦的用法。45M 小到可以在自己的 Mac 或 PC 上微調，官方說幾分鐘到幾小時就能跑完，之後匯出成 .cact 檔照樣部署。他們的說法是，每個產品都有自己的工具詞彙，與其用通用助理，不如訓練一個只認得你那套裝置的版本。
延伸閱讀：Meta Muse Glimmer 與 OpenAI 的開源分層｜744B 模型塞進 25GB 舊電腦的 colibrì｜用家裡 WiFi 做感測的開源 RuView｜為什麼 AI 畫的圖一看就知道是 AI 畫的
資料來源：Cactus Compute 官方 Needle 2 頁面｜Hugging Face 模型卡｜GitHub｜Simple Attention Network 論文（arXiv:2607.18363）
本文所有規格與評測數字取自 Cactus Compute 官方公開文件，截至 2026 年 8 月 13 日。評測分數為官方自行公布，第三方尚未獨立複現。本文為技術資訊整理，不構成任何投資建議。
發表迴響