ARTEMIS 對比 LFM2.5-2.6B-Base：無法勝任任務的檢查點，以及需要它來完成的測試框架

Google 的 ARTEMIS 路線圖上有四個項目，而其中恰好有一個需要一個目前顯然還不存在的模型：裝置端輕量級視覺語言模型，用於低延遲、隱私優先的自動化。這類工作的明顯候選者，是尺寸級別落在 LFM2.5-2.6B-Base 附近的東西——Liquid AI 的 26.9 億參數預訓練檢查點，以開放權重發布，具備 131,072 個 token 的上下文，且佔用空間小到足以放進手機。而且，以出廠狀態而言，它也無法填補那個位置；在任何人把這兩者放進比較表之前，箇中原因值得先理解。Google 的 ARTEMIS 是一套自然語言 Android 自動化測試框架，於 2026 年 8 月以 Apache 2.0 開源，透過 ADB 驅動真實手機，並宣稱在 Google Research 的 AndroidWorld 基準測試上達到 99%+ 完成率。LFM2.5-2.6B-Base 則是未經加工的預訓練素材，沒有指令微調、沒有聊天範本，而且——刻意地——沒有已發布的基準測試結果，目標對象是將自行對其進行後訓練的團隊。一個是已完成的軟體，卻帶著未完成的模型問題。另一個是未完成的權重，卻帶著已完成的授權問題。兩者都不能替代彼此，而它們真正交會之處，並不是你會猜到的地方。

LFM2.5-2.6B-Base究竟是什麼

剝去品牌包裝後，它是為裝置端工作精心打造的基礎，其規格讀起來就像有人是為了記憶體頻寬，而不是為了排行榜名次而做最佳化。

• 大小 — bfloat16 格式的 2.69B 參數，裝在單一約 5.39 GB 的分片中，宣傳為「2.6B」。

• 架構 — 混合切分下的 30 層：8 層分組查詢注意力之上疊加 22 個雙閘控短卷積區塊，隱藏寬度 2048，32 個注意力頭對應 8 個 KV 頭，綁定嵌入。與前一代相同的 code>Lfm2ForCausalLM/code> 類別，因此不需要自訂建模程式碼。

• 訓練 — 約 34 兆個詞元，並設有專門的中期訓練階段以進行上下文擴展。

• 詞彙 — 128,000 個詞元，這一代加倍以更妥善處理非拉丁文字。約 2.62 億個參數——大約佔模型的十分之一——位於綁定嵌入中。

• 背景 — 這裡的模型卡與設定不一致，而這點值得留意：文件宣稱有 131,072 個 token，但 code>config.json/code> 將 code>max_position_embeddings/code> 設為 128,000。請以 128K 來規劃，並將超過此數量的任何內容視為未經驗證。

• 語言 — 十六種：英文、阿拉伯文、中文、法文、德文、印地文、印尼文、義大利文、日文、韓文、波蘭文、葡萄牙文、俄文、西班牙文、泰文、越南文。

• 基準測試 — 無。Liquid 並未為基礎檢查點發布任何評估，而模型卡將此遺漏定調為刻意為之：此產物存在的目的是接受後訓練，而非以其原始狀態被衡量。

最後一行正是這次發布的全部重點，也是「X vs LFM2.5-2.6B-Base」這類比較必須謹慎處理的原因。基礎檢查點對任何事物都沒有立場。要它規劃一套 Android 工作流程，它只會以機率方式續寫你的文字，因為它從未被教導要回答。這張卡片僅建議在需要大量微調的情況下使用它：特定語言的助理、受監管垂直領域的特定領域助理、以專有資料進行訓練，或作為蒸餾學生模型。至於任何開箱即用的用途，包括工具呼叫，Liquid 都請你改用經後訓練的 LFM2.5-2.6B。

ARTEMIS 需要模型提供什麼，而這並非基礎檢查點所能提供

ARTEMIS 是一個具有兩種模式的控制迴圈。Flash 是反應式的「觀察並行動」循環，每一步大約 3–5 秒。Pro 則是一個多代理圖，每一步大約 15–40 秒，其中規劃器持有一份持續演進的 Markdown 計畫，操作器配備完整工具集，而唯讀檢查器則在四個層級驗證檢查點，從code>off/code> 到 code>strict/code>。這兩種模式都對底層模型提出同樣的要求：看一張螢幕截圖，從固定的工具集中挑選一個動作，然後在一兩秒內再做一次，重複上百次，而且不會失去脈絡。

那是一項要求很高的任務——在僵固的結構描述下遵循指令、具備有依據的視覺理解，以及長時程的連貫性——而這正是一組基礎檢查點（base checkpoint）未曾被賦予的技能。ARTEMIS 自己測試過的後端是託管模型：Gemini、Claude、GPT-4o、Qwen-VL。它們每一個都針對工具使用做過指令微調，而且每一個都很大。

所以差距不在於規模。一個 2.6B 的後訓練模型就能撐起工具呼叫迴圈——Liquid 自家後訓練的同系列模型宣稱，在其所有指令遵循評估以及幾乎所有工具使用評估上都優於 Gemma 4 E2B-it 和 E4B-it，不過那些都是廠商自行回報的數字，未經獨立驗證。差距在於 基礎檢查點完全沒有套用那些訓練，因此根本無法直接放進評估框架裡。

許可證是更明顯的差異

這裡才是真正決定勝負的地方，而這正是大多數比較會略過的部分。

• ARTEMIS — Apache 2.0。可商業使用、可 fork、可內嵌於產品中出貨，沒有任何營收條件。唯一的義務是保留聲明並註明你的變更；而這項義務，連專案本身都必須在 2026 年 9 月公開補救——在 Minitap 指控 ARTEMIS 的 229 個檔案中有 228 個與其自家 Apache-2.0 的 code>mobile-use/code> 專案相符，且作者姓名已遭強制推送（force-push）抹除之後。該儲存庫如今已帶有一行 Minitap 的致謝聲明。

• LFM2.5-2.6B-Base — LFM Open License，這是自訂授權條款，而非 Apache 或 MIT。年營收低於 1,000 萬美元時，授予的權利範圍廣泛、永久且免權利金。達到或超過此門檻時，該授權完全不涵蓋商業使用，你必須聯絡 Liquid。對任何以此為基礎進行開發的人來說，重要細節是：衍生作品會繼承相同條款。你進行後訓練所得的檢查點並非你完全擁有的新事物——它會延續此以營收為條件的授權，並對合格的非營利組織設有例外條款。

把那兩項事實並排放在一起看，決策會因你是誰而翻轉。一家資金充裕、想推出手機端代理的公司，手上有一套可自由使用的 Apache-2.0 測試框架（harness），以及一個可能完全無法用於商業用途的檢查點（checkpoint）。個人開發者或未達門檻的新創公司則兩者兼得，授權條款不過是個附註。兩家廠商都稱不上不合理——Liquid 是家保護自家商業層級的公司，Google 則是把測試工具開源——但「開放權重」和「開放權重」並不是同一種許可，而只比較參數量的對照，不會告訴你手上拿到的究竟是哪一種。

這個家族，因為基礎檢查點是進入它的錯誤入口

如果目標是裝置端的 Android 代理，有三個同系列成員比基礎版更重要，而 ARTEMIS 路線圖真正需要的那一個，並不是最顯而易見的那一個。

• LFM2.5-2.6B — 經後訓練的代理型同系列模型。廠商回報的吞吐量在手機級硬體上約為每秒 30 個 token，在 Ryzen AI Max+ 395 上為 113，在 Apple M5 Max 上為 220，且執行時佔用不到 2.5 GB。

• LFM2.5-VL-3B — 視覺語言邊緣模型，建構於相同基礎模型上，搭載 SigLIP2 400M NaFlex 編碼器；根據廠商回報，其在 RefCOCO 上的 grounding precision@1 從 57.1 提升至 87.9，且根據 Liquid 的說法，在螢幕上 UI 元素的表現勝過規模大得多的 Gemma 模型，並與 4.7B Qwen 3.5 的差距在 0.7% 以內。未經證實，但它是這個系列中唯一能看見螢幕的成員。

• LFM2.5-230M — 擷取與分類層級，明確不建議用於推理密集型工作。

在這場對決中，對基礎檢查點而言，令人不安的結論是哪一個：ARTEMIS 的路線圖項目是一項 視覺需求，基礎檢查點是純文字的，而填補這個位置的家族成員，是已經同時套用視覺編碼器與後訓練的 VL 變體。基礎檢查點在 Android 自動化堆疊中的角色並不是驅動手機，而是成為最終實際負責驅動手機的那個小型模型底下的原始材料。

在它們真正交會之處：那個還沒有人打造出來的飛輪

這裡有一個真正成立、而非只是修辭的關聯，而且它的方向與慣常相反。ARTEMIS 最被低估的功能不是代理，而是它產生的副產品。每次執行都會擷取當機堆疊、關鍵影格螢幕截圖、一份記錄壓縮後步驟的工作階段帳本，以及一份診斷報告；而 Pro 會在動作失敗時開啟一筆「執行事件」，並將其保留在脈絡中，直到之後某次成功執行將其結案。那正是一座標註語料庫，精確對應 UI 代理感知出錯的那些時刻。

將這點與一個用途完全在於後訓練的檢查點搭配起來，就會得到一個顯而易見的迴圈：在託管模型上跑這套測試框架，蒐集它在你的應用程式上卡殼的軌跡，然後正對著那些訊框微調一個 2.6B 模型。這正是 Liquid 自家模型卡所援引、用來作為釋出基礎檢查點之正當理由的那類專有資料集——「用自己的資料訓練」——而以營收為門檻的授權則意味著，這是一條對門檻以下的團隊說得通、對門檻以上的團隊則需要談一談的路徑。

為了明確說明那個想法的地位：沒有人發表過這個迴圈，兩家供應商都沒有建議它，也沒有證據顯示任何一方測試過它。這是一項提案，不是一項結果，應該被當作提案來解讀。但這是唯一一種框架，能讓這兩個人工製品成為協作者，而不是範疇錯誤。

如果你做到微調這一步，比較基準就是問題的另一半。LFM2.5-2.6B-Base 不在我們的目錄裡——任何 LFM2.5 變體都不在——所以那個檢查點來自 Liquid 自家的發佈管道以及常見的第三方主機。路由式目錄真正發揮價值之處，在於用同一把金鑰、同一份帳單，讓你的微調成果與它在工具使用上必須擊敗的模型一較高下，並具備容錯移轉，這樣某個供應商的一個糟糕下午，就不會變成你評估工作的一個糟糕下午。當這整件事的重點，就是你打算據以行動的一對一對決時，這確實是很有用的東西。

所以哪一個是你的問題？

如果你有一個 Android 應用程式，而你想在本季讓它自動接受測試，你要的就是 ARTEMIS，而 LFM2.5-2.6B-Base 並不是解答的一部分——你會讓 ARTEMIS 對上託管的視覺模型來執行，按步計費，而關於裝置端 VLM 的路線圖項目終究會到來，並解決一個你還沒衡量過的成本問題。

如果你正在打造一款必須在沒有網路的手機上運行的產品，你會想走小型模型路線，而 LFM2.5-2.6B-Base 是那個專案的起點，而不是其解決方案的任何一部分：你會對它進行後訓練，你會在你寫下第一份訓練腳本之前，對照你的營收預測來閱讀 LFM Open License，而如果你的代理需要看到螢幕，你最終會改用 VL 變體。

最不該做的，就是把這兩者並排放，宣稱那個測試框架能力更強，然後就此打住。有用的比較，是兩個完整堆疊之間的比較——託管模型加上測試框架，對上微調過的小型模型加上你自己打造的框架——而其中只有一個在公開基準測試上有已公布的成功率，這件事的價值，恰恰等同於另一個完全沒有雲端帳單這件事。

路由式模型目錄真正展現價值之處，在於拿你的微調模型去和它在工具使用上必須擊敗的模型做基準測試，只需一把金鑰、一張帳單，並具備容錯移轉，讓某家供應商的一個糟糕午後，不會變成你評估作業的糟糕午後。

LFM2.5-2.6B-Base 不在我們的目錄中——LFM2.5 的任何變體都不在——因此該檢查點來自 Liquid 自家的發佈以及常見的第三方主機。