Perceptron Mk1.5 vs LFM2.5-2.6B-Base：租用感知能力，還是擁有檢查點並自行完成？

這兩個模型都鎖定你可以單手拿起的硬體。Perceptron Mk1.5 是為具身代理設計的感知模型，其供應商表示它會落實在無人機、四足機器人、智慧眼鏡與手機上。LFM2.5-2.6B-Base 是 Liquid AI 明確為裝置端部署打造的 2.69B 開放權重檢查點——小到能在低於 2.5GB 記憶體中執行。那個共同的硬體企圖是她們唯一的共同點，而這對任何按規格表比較它們的人來說是個陷阱。Perceptron Mk1.5 是完成品，按 token 租用：輸入文字、圖像、影片與音訊，輸出文字以及機器可讀的幾何資訊，自 2026 年 9 月 25 日起上線。LFM2.5-2.6B-Base 則是原始預訓練基礎模型，沒有指令微調、沒有聊天模板，也沒有基準測試宣稱——一個釋出給其他人完成的檢查點。其中一個今天就能回答問題；另一個則是未來某個能夠回答問題的模型所用的原料。

只有在您為階段命名時，比較才會有效。

把一個已上線服務的 API 拿來跟一個基礎檢查點並列，並不是一對一的較量；若假裝它們可以這樣比，就會產生一張荒謬的表格，其中一方每一列都「勝出」，因為它已由其供應商完成，而另一方則尚未開始。真正有用的問題是：你目前處於哪個工作階段。

Liquid AI 將 LFM2.5 系列以一整組檢查點的形式發布，而 base 是其中的第一個。其模型卡列出橫跨 30 層、總計 2.69B 參數——22 個雙閘控短卷積區塊與 8 個分組查詢注意力區塊——以約 34 兆個 token 訓練而成，具備 128,000 個 token 的詞彙表、131,072 個 token 的上下文長度，並支援 16 種語言，包括英文、中文、日文、韓文與阿拉伯文。它僅支援文字，是純粹的因果語言模型，別無其他，而 Liquid 自家的建議相當直白：這個檢查點適用於需要大量微調的任務，例如特定語言或特定領域的助理、以專有資料進行訓練，或實驗新穎的後訓練方法。讓它成為承載該系列已公布分數的工具呼叫型代理的，是 Liquid 的四階段後訓練流程，而 base 並不包含這部分。

Perceptron Mk1.5 位於那條弧線的另一端。Perceptron 已經完成後訓練，決定了輸出格式並為結果定價——每百萬輸入 token 為 $0.15、每百萬輸出 token 為 $1.50，快取輸入則為 $0.0375。它的規格具體的方式，是基礎檢查點所沒有的：36,864-token 上下文、8,192-token 最大輸出、四種輸入模態、一個 reasoning_effort 控制項，預設為高，在聊天補全上進行函式呼叫，以及透過 JSON Schema 和 regex 的受限回應。

同時關注這兩者的原因在於，總持有成本的走向恰好相反。Mk1.5 每 token 所費不貲，但起步免費。LFM2.5-2.6B-Base 在邊際上免費，卻在對基礎檢查點唯一重要的貨幣上昂貴——你的工程時間。

逐個維度地，並讓角色保持分明。

• 它是什麼 — Perceptron Mk1.5 是一套託管的感知 API，具備結構化空間輸出。LFM2.5-2.6B-Base 則是一款可下載的 2.69B 預訓練因果語言模型。

• 輸入 — Mk1.5 接受文字、圖像、影片與音訊（WAV、MP3、FLAC）。LFM2.5-2.6B-Base 接受文字，且僅限文字。

• 輸出 — Mk1.5 會返回文字，以及可選的點、方框、多邊形、剪輯片段和帶時間戳的 <track> 元素，或受 JSON Schema 約束的回應。基礎模型會返回下一個詞元的詞元機率，而且沒有經過任何調校來讓這變得有用。

• 獨立使用 — Mk1.5 在你拿到金鑰的當天就能運作。LFM2.5-2.6B-Base 就任何產品意義而言都無法回答問題；它需要微調，而且通常還需要聊天模板，才能成為你會出貨的模型。

• 上下文 — Mk1.5 為 36,864 個 token，基礎版本則為 131,072 個。裝置端檢查點所容納的文字量，幾乎是提供服務的感知模型所容納任何內容的四倍。

• 資源佔用 — Mk1.5 在 Perceptron 運行它的地方運行，而其已發表的延遲成果是在單張 H100 上完成。基礎版本旨在能在筆記型電腦、手機或邊緣運算盒上以低於 2.5GB 的資源運行。

• 證據 — 每一項 Mk1.5 能力數據都是 Perceptron 自己的，而且沒有針對它的獨立指標。基礎版本完全沒有基準測試方面的宣稱：Liquid 公布的是後訓練 LFM2.5-2.6B 的分數，而不是這個檢查點。

• 授權條款 — Mk1.5 是封閉的，按 token 租用。LFM2.5-2.6B-Base 以 LFM Open License v1.0 發布，權重可供下載並保留。

權重路徑，誠實計算成本

如果 LFM2.5-2.6B-Base 的吸引力在於權重免費，那麼這句話誠實的版本是：權重是整個專案中最便宜的部分。在專有資料上進行微調，意味著需要一個資料集、一次訓練運行、一套評估框架來告訴你微調是否奏效，以及一條服務路徑——Transformers、vLLM 或 SGLang，或是 Liquid 分別為 CPU、跨平台與 Apple Silicon 部署所發布的 GGUF、ONNX 與 MLX 版本之一。這些都不算稀奇，而且在 2.69B 的規模下，它能裝進 70B 微調根本碰不到的硬體。但基礎檢查點只是起點，而時程風險完全落在這筆交易中你這一側。

你換來的是掌控權。16 語言分詞器與 131K 脈絡長度，意味著針對特定領域的微調不必和預訓練爭奪空間。低於 2.5GB 的占用空間，代表部署目標是裝置而非資料中心，而這正是這個系列存在的全部意義。而 LFM Open License 讓你得以保有成果——一個競爭對手無法從你能使用的同一個 API 租用的專精模型。

在你押注這條血統之前，有一項值得知道的第三方證據，以及一個缺口。Liquid 後訓練過的 LFM2.5-2.6B 確實有一項獨立評測：Artificial Analysis 將其列在 Intelligence Index 8，在同級 49 個模型中排名第 9。基礎檢查點則沒有——它沒有專屬頁面，這對預訓練基礎模型來說很正常，值得直白說明，而非把它當成定論。後訓練模型的指數告訴你的是：這條流程從這個起點、在指數區間的小規模端能產出什麼，而不是你的微調會產出什麼。

API 路線，以及「裝置端」對託管模型而言代表什麼

Perceptron Mk1.5 的部署情況比其目標清單所暗示的更複雜，值得精確說明。廠商的公告將無人機、四足機器人、智慧眼鏡和手機列為部署目標。模型本身是從 api.perceptron.inc以 API 金鑰保護的方式提供服務，而 Perceptron 公布的延遲證據，是在單張 H100 上三次執行的中位數。單張 H100 並不是無人機。務實的解讀是，Mk1.5 是為具備網路連線或搭配運算盒的機器人提供感知層，而不是在機體內部執行的模型——任何打算以它為核心規劃離線裝置的人，都應在設計硬體前驗證這項假設。

如果網路假設成立，API 路由能換來的，正是基礎檢查點無論出多少錢都給不了的東西：座標。Mk1.5 的 <track> 輸出帶有空間觀測值及其時間戳，因此一段剪輯傳回來的是隨時間變化的物件位置，而不是對場景的描述。再加上 asset_idx 欄位，讓單一請求能分別指定多張圖片或多段影片，請求形狀就與控制迴路相符了——參考幀進、幾何出，模型與實際驅動物件的程式碼之間沒有任何解析階段。

這些成本就是已經列出的那些：36,864 個 token 的上下文、每項目 16,384 個 token 的音訊上限——Perceptron 的文件指出，以每分鐘約 750 個 token 計算，這大約是 21.8 分鐘——以及 reasoning_effort 的預設值為 high，它會針對你未設定的每一次呼叫，以最昂貴的推理路徑計費，還有一組由販售該模型的公司所提出的基準測試宣稱。手部追蹤的那個數字，正是值得用你自己的影片來檢驗的：在 egocentric hand_box 上達到 0.9433，相較於 Perceptron 自家測試中 Gemini 3.1 Pro 的 0.4467，是很大的差距，而供應商評估中的大差距，正是值得重現的那種。

兩者都不在我們的型錄上，而這改變了決定。

Perceptron Mk1.5 與 LFM2.5-2.6B-Base 目前都沒有在 OrcaRouter 上進行路由。Mk1.5 完全沒有路由，因此若要存取它，只能透過供應商自家的 API——pip install "perceptron>=0.4.0" 以及 PERCEPTRON_API_KEY——而 Liquid AI 在我們的目錄中沒有任何大小的模型，因此這個基礎檢查點是從 Liquid 的 Hugging Face 下載，而非透過 API 呼叫。

這件事的重要性不如聽起來那麼大，因為這兩者並不是可互換的端點，再怎麼爭論價格也改變不了這一點。路由層在這裡能貢獻的，是決策中仍懸而未決的那一部分。如果你在 Mk1.5 上打造感知服務，又在微調過的 LFM2.5-2.6B-Base 上打造文字專用模型，你就是在跑兩套整合、面對兩種故障模式；在它們前面放一個 OpenAI 相容的閘道，就能把任一邊的供應商事故變成備援切換，而不是工作失敗，而路由規則可以把視覺流量和文字流量導向不同模型，應用程式完全不必知道哪個是哪個。一個涵蓋200 多個模型、供應商定價以 0% 加成原樣傳遞的 API，就是這種做法的體現：供應商調價當天就反映出來，而不是等到你下次續約時才發生——不過就這兩個模型而言，在今天，這個閘道還只是規劃時要考慮的事，而不是現成的捷徑。

你應該做什麼，以及你應該衡量什麼

如果你的任務是「在這個畫面中找出這個物件，並回報它位在哪裡」，那就先租用 Mk1.5，在把正式生產路徑押上去之前，用你自己的影片測試 hand-box 這個說法。為網路連線這項假設編列預算，刻意設定 reasoning_effort，而不是直接接受 high，並把 36,864 詞元的視窗當成它本來就是的硬性限制來看待。結構化輸出才是產品本身，而如果你的下游程式碼不必經過解析階段就能消費一個座標，那就是在大多數視覺管線悄悄流失準確度的地方，實實在在省下的一筆成本。

如果你的任務是「我需要一個用別人沒有的資料微調過的 2.6B 模型，並在沒有 GPU 的某處運行」，那就下載 LFM2.5-2.6B-Base，並在開始前誠實估算微調的代價。檢查點是免費的，但工程不是；而這個系列自身的教訓——後訓練過的兄弟模型在獨立指標上得分 8——提醒我們，基礎模型與完成品之間的落差，才是真正工作所在。這兩者都不是錯的答案。它們是不同的交易，唯一真正的錯誤，是把一個你必須完成的基礎模型，當成它已經是產品。

兩個模型、兩套整合與兩種失效模式，這樣的情況比表面上更糟。在 OrcaRouter 上，你可以設定自動容錯移轉，讓任一側的供應商事故降級為備援，而不是工作失敗。