ARTEMIS 與 Gemma 4 12B：套具與大腦不是同一種購買

Google 的 ARTEMIS 與 Gemma 4 12B 並不競爭，而浪費一週最快的方法，就是把它們放進同一張比較表裡，然後選出一個贏家。ARTEMIS 是 Google 在 2026 年 8 月以 Apache 2.0 開源的 Android 自動化框架：它接收一句話，透過 ADB 操作一支真實手機，並回報發生了什麼事。Gemma 4 12B 則是 Google DeepMind 於 2026 年 6 月 3 日發布的稠密 120 億參數開放權重多模態模型——是一個你能在筆電上執行的「大腦」，而不是一個能點擊螢幕的系統。兩者之中，少了另一種東西，其中一個就無法看見、決策或行動；另一個則根本無法拿握裝置。但這個比較值得做，因為它底下的問題，正是每個行動團隊目前都在問的：一個你完全擁有的小型開放模型，能不能做到 Android 自動化？或者你需要在 ARTEMIS 這類框架背後，接上一個託管的前沿模型？這個問題有真正的答案，而它並不是兩家廠商發布貼文所暗示的那個答案。

首先，直白地說，範疇錯誤

ARTEMIS 本身不含任何模型。它自己的徽章寫著「Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL」，而決定你使用哪一個的檔案是 code>config/artemis.jsonc/code>。它是一個控制迴路：一個無障礙優先的定位器、一項在你點擊落下前先清掉彈出視窗的安全檢查、一本會把舊截圖壓縮成視覺摘要的工作階段帳本，以及兩種執行設定檔——Flash 每步約 3–5 秒，Pro 每步約 15–40 秒，並搭配 Planner、Operator 與唯讀的 Checker。它對世界所知的一切，都是透過一個並非它自己撰寫的視覺語言模型得來的。

Gemma 4 12B 是相反型態的物件。它是一個檢查點。它沒有裝置連線、沒有 ADB、沒有無障礙服務，也沒有「點按是可以被執行的事情」這個概念。給它一張螢幕截圖，問它下一步該做什麼，它會回答你——可能答得不錯——但回答就是它能動性的全部範圍。從「模型說在 (540, 1180) 點按」到「手機在 (540, 1180) 點按了」之間的一切，都是 ARTEMIS 的工作，而這占了大部分工夫。

所以，這場對決最誠實的框架並不是 ARTEMIS 對上 Gemma。而是：作為 Android 代理的推理層，一個 12B 開源模型能為你帶來什麼？以及你何時需要付費使用更大型的模型？

Gemma 4 12B 究竟帶來了什麼

對一款中型模型而言，它的規格異常完善，而其中三項特性對任何行動端應用都至關重要。

• 它在輸入層是貨真價實的多模態。輸入的是文字、圖像、音訊與視訊，輸出的是文字。它是首款不需要獨立多模態編碼器的中型 Gemma，也是該系列第一個原生支援音訊輸入的成員——這並非 UI 自動化功能，但如果你的測試情境涉及語音備忘、會出聲的通知，或建立在音訊提示上的無障礙路徑，那它就是貨真價實的功能。

• 這是一顆你握得住的 12B。Artificial Analysis 將它列為總參數 12B、採用 Apache 2.0 授權——沒有營收門檻，沒有研究條款，是一份你可以直接拿來打造產品、不必徵詢任何人的授權——具備 256K 上下文視窗、已啟用推理，實測輸出速度為每秒 109.2 個 token。社群回報指出，權重在 SFP8 下約為 13.4 GB，在 Q4_0 下約 6.7 GB，也就是一台配備 16 GB 記憶體的筆電。

• 它很便宜，但並非同級中最便宜的。Artificial Analysis 將其列為每百萬輸入 token 0.10 美元、每百萬輸出 token 0.30 美元——並在同一個面板中指出，對於規模相近的開放權重模型而言，這屬於偏貴的一端，中位數落在輸入 0.05 美元、輸出 0.15 美元。快取讀取則約為 0.03 美元。

基準測試的整體情況就是中型模型常見的那種一團亂，值得仔細說明，因為各家追蹤網站上的數字彼此並不一致。Artificial Analysis 給這個推理組態的 Intelligence Index 分數為 14，在同類 142 個開放權重模型中排名第 21——這是個體面的中段位置，距離前沿還差得遠。Google 自家的定位是，12B 幾乎能與更大的 Gemma 4 26B-A4B 匹敵，並在推理、科學與文件任務上勝過上一代的 Gemma 3 27B。第三方彙整網站給它的成績大約是 LiveCodeBench v6 的 72%、MMLU-Pro 的 77.2%，而 GPQA Diamond 則落在 66% 到 79% 之間，取決於你看的是哪個追蹤網站、哪一種組態。對一個 12B 模型來說，這些都是體面的數字。但它們同樣是未經審計、自行回報的彙總數據；當四個網站相差達十三個百分點時，你該把握的是這個區間，而不是單一數字。

ARTEMIS 所帶來的是什麼，以一段話說明，因為它並非此處的主題

ARTEMIS 補足了模型所欠缺的一切：一個動態優先的定位器，當無障礙元素索引存在時便使用它們，不存在時則退回視覺與座標，這意味著不必維護 XPath，也不會有 ID 在 Compose 或 Flutter 介面上失效。它帶來了一道安全網，能攔截你的點擊原本即將落在其上的系統彈出視窗；具備四種等級、從 code>off/code> 到 code>strict/code> 的檢查點驗證；自動崩潰堆疊；關鍵影格截圖與診斷報告；網頁主控台；供 pytest 與 CI 使用的 Python SDK；以及——這正是它傳播得如此迅速的原因——一個原生 MCP 伺服器，把整套功能以五項工具的形式開放給 Antigravity、Claude Code、Codex 及任何其他支援 MCP 的助理。它宣稱在 Google Research 的 AndroidWorld 基準測試上達成 99% 以上的完成率，截至 2026 年 9 月 11 日，這使它在公開排行榜上達到 99.1%，而人類表現為 80%。該數字為自我呈報，且排行榜不會驗證提交內容，因此請將其視為強而有力的廠商宣稱，而非經過稽核的結果。

這兩者真正重疊的唯一地方

存在一種真實的架構，讓小型 Gemma 獨力完成整份工作，而它值得一看，因為它揭示了雲端模型實際上在為哪些東西付費。一個名為 Orion 的開源 Android 代理框架完全在裝置端運行：MediaProjection 擷取螢幕畫面，一個量化的 Gemma-4-E4B-it 透過 LiteRT-LM 在 Qualcomm Hexagon NPU 上執行，負責選擇下一個動作，而 Android Accessibility Service 則派送點擊操作。沒有雲端 API，沒有按 token 計費的帳單，而且螢幕畫面從不離開手機。它已在 Galaxy S25 Ultra 上通過驗證，且根據其自身的描述，只有在配備 Hexagon NPU 的硬體上才有意義——該模型需要約 3 GB 的儲存空間，而該框架鎖定 arm64 上的 QNN HTP v79。

那就是當今小型模型 Android 代理的樣貌，而請留意要達到那裡得付出什麼代價。模型經過量化並映射到 NPU。動作空間是像素，因為僅靠螢幕截圖的模型無法解讀「元素索引 12」。整體設計是垂直堆疊——模型、執行環境、晶片、框架——這就是為什麼它是一個框架，而不是能直接套進你測試套件的現成方案。Gemma 4 12B 的參數量約為該堆疊中 E4B 的三倍，而且並未以可在手機上執行的格式發布；一個四位元量化的 12B 是工作站或服務端點，而不是常駐 NPU 的模型。

各自真正勝出之處

• 規模化成本 — 自行託管的 Gemma 4 12B 完全沒有按 token 計價的費用，而 ARTEMIS 每跑一次，每一個步驟都得呼叫一次視覺模型。以每晚執行的 500 項測試迴歸套件來說，這種差距累積的速度遠比任何基準測試的落差都快。

• 隱私 — 在你自己的硬體上執行 Gemma 4 12B 時，螢幕截圖永遠不會被傳送到任何地方；ARTEMIS 的無障礙輔助工具明確地僅在本機運作，不會傳送任何資料，但它每處理一張螢幕截圖時所發出的模型呼叫，會送到你所設定的任何服務供應商。

• 真實應用程式上的任務可靠性 —— ARTEMIS 以大幅差距勝出，因為它是一套具備安全網、檢查點驗證與復原機制的測試框架。再優異的模型也無法取代這一點。

• 音訊與長篇文件——Gemma 4 12B，技術規格表上列有原生音訊輸入，以及 256K 符元的上下文視窗。ARTEMIS 對這兩者都沒有任何意見。

• 首次通過測試所需時間——ARTEMIS，遙遙領先。複製（Clone）code>./start.sh/code>，連接一台已啟用 USB 偵錯的裝置，等待第一個任務安裝無障礙輔助工具。用一個裸檢查點打造同等成果，是耗時數個月的專案，而上面那個 Orion 範例，就是該專案完成後呈現的樣貌。

• 自由修改推理層 — Gemma 4 12B 是 Apache 2.0 授權的權重，你可以針對自己的 UI 詞彙進行微調。ARTEMIS 是 Apache 2.0 程式碼，但推理則取決於你的模型所在之處。

這個配對目前實際可取得的版本

清楚說明你本週能部署什麼。ARTEMIS 經測試的後端清單是 Gemini、Claude、GPT-4o 和 Qwen-VL——Gemma 4 12B 並不在其中，而且沒有已發表的評估顯示 Gemma 4 12B 能驅動 ARTEMIS 工作階段。設定檔接受模型端點，所以這種搭配是看似合理而非已獲證實；如果你嘗試，你是在做原創工作，而不是照著文件走。值得直說：ARTEMIS 的路線圖上有一項「裝置端輕量級 VLM」，而填補它的模型不會是 12B。

Gemma 4 12B 也不在我們的目錄中——我們路由的是其他 Gemma 4 規格，Gemma 4 26B-A4B 和 Gemma 4 31B，而不是 12B，所以如果那正是你想要的檢查點，你得從供應商自家的散布管道和常見的第三方主機取得。路由式目錄的用途在於這個問題的另一半：如果你的計畫是在託管的視覺模型上跑 ARTEMIS，那個模型是一項成本，會隨著每次執行的每一步而增加，而真正有用的槓桿不是標價，而是快取價格。一次 Pro 執行會在每一步重新讀取不斷增長的上下文，因此快取讀取便宜的模型，對整體計算的影響遠大於全新輸入便宜的模型。這也是為什麼供應商容錯移轉應該放在設定裡，而不是記在你的事故日誌中——一次長時間的 Android 工作階段會把它的上下文保存在單一端點上，而供應商在第 74 步出個小狀況，就會讓你賠掉整次執行。

哪一個是你的下一步？

如果你有行動應用程式和回歸測試套件，你要的是 ARTEMIS，而 Gemma 4 12B 並不是它任何一部分的替代品——它頂多是你之後可能換進來、沒有文件記錄、用你自己時間處理的引擎。如果你正在打造一個必須在沒有網路、且不需按次計費的手機上運行的產品，你要的是小型模型，而 Gemma 4 12B 對你實際擁有的硬體規格來說可能太大；在你假設 12B 能裝得下之前，先看看 Orion 如何在 NPU 上運用 4B 等級的 Gemma。

這兩個決定只在一處產生衝突，而且那是成本問題，不是能力問題：你每天願意買多少次視覺呼叫？誠實地回答這個問題——數數你的測試、數數你的步驟、數數你的夜間執行——要在託管模型上架一套測試框架，還是自架一整套技術堆疊，這個選擇會自己浮現。

的用途路由目錄是這個問題的另一半：如果你的計畫是在託管視覺模型上使用 ARTEMIS，那個模型就是一項會隨著每次執行的每一步而擴增的費用項目