Perceptron Mk1.5 vs Gemma 4 12B：一個以句子作答，另一個以座標作答

Here is the number that should stop you first: Perceptron Mk1.5 is a model built for video and embodied agents, and its context window is 36,864 tokens. Gemma 4 12B is a 12B open-weights generalist with a 256K window. On the axis most people use to compare vision models — how much footage can I hand it — the smaller, closed, purpose-built model loses by a factor of seven to the downloadable one. That inversion is not a flaw in either product. It tells you what each was actually built to do, and the two jobs are further apart than the shared "multimodal input" line on their spec sheets suggests.

Perceptron Mk1.5 是 Perceptron 於 2026 年 9 月 25 日推出的具身推理模型，為 5 月問世的 Perceptron Mk1 後繼者，可輸入文字、圖像、影片與音訊，並輸出文字以及可供機器解析的幾何資料。Gemma 4 12B 是 Google DeepMind 的 119.6 億參數、免編碼器多模態開放權重模型，於 2026 年 6 月 3 日以 Apache 2.0 授權發布，可輸入文字、圖像、音訊與影片，並輸出文字。兩者都很便宜，兩者都能讀取攝影機影像串流，而只有其中一個能在無須第二階段解析的情況下，直接把邊界框交給你的控制器。在兩者之間做選擇，本質上是在選擇什麼必須被回傳。

每一個被設計來回傳什麼

把兩者並排比較，差異不在於準確度，而在於輸出型態。問 Gemma 4 12B 堆高機在哪裡，你會得到一句話，而在大多數應用中，那句話就是產品——一段描述、一份摘要、對某張照片相關問題的回答。問 Perceptron Mk1.5，除了它的文字敘述之外，你還可以要求一個點、一個邊界框、一個多邊形、一段短片，或一個 <track> 元素，用來承載一項空間觀測，以及它所屬的時間戳記。一段 60 秒的短片回來時，是一連串隨時間變化的位置，而不是對場景的一個平均猜測。

這就是 Mk1.5 存在的全部論據，而且值得精確說明它為何重要。對場景的描述是最終成品。座標則是其他東西的輸入——抓取規劃器、缺陷檢查、帶時間戳的稽核軌跡。如果你的下游程式碼必須閱讀文字敘述並從中推斷位置，你就在兩個模型之間建了一個解析器，而那個解析器現在就是你的失效面。Mk1.5 的賣點在於，幾何資料是帶著型別抵達的。

Gemma 4 12B 的反駁論點並不是它也能做到這件事。而是你可以擁有權重。Apache 2.0、11.96B 參數，以預訓練與指令微調變體發布，能在你掌控的硬體上運行，背後還有已發布的評估卡與第三方索引。這些是不同類型的資產，而且兩者不能互相取代。

這兩者實際上吻合的地方

比「多模態 2026」這個標籤所暗示的還要少，但共同的基础確實存在，而且值得明確指出，因為這通常正是買家檢查清單的起點。

• 輸入模態——兩者都是真正的四模態。Perceptron Mk1.5 接受文字、圖像、影片和音訊（WAV、MP3、FLAC）。Gemma 4 12B 透過單一無編碼器的統一路徑接受文字、圖像、音訊和影片。

• 輸出模態 —— 兩者都不會生成音訊或圖像。兩者都是文字輸出。差別在於，Mk1.5 的文字可以帶有結構化的空間標註，而 Gemma 4 12B 的文字則不行。

• 函式呼叫 — 兩者皆支援。Mk1.5 在聊天完成（chat completions）上提供函式呼叫，並透過 JSON Schema 與正規表達式接受受限回應。Gemma 4 12B 在其指令微調形式中隨附函式呼叫，並具備可設定的思考模式。

• 推理控制 — Mk1.5 將舊有的 vision_config.enable_thinking 布林值改為 reasoning_effort 欄位，可設為 high、medium、low、minimal 或 none，且預設為 high。Gemma 4 12B 提供推理與非推理兩種變體，由於兩者投入的工作量不同，在同一套評測框架下的得分也不同。

• 上下文 —— Mk1.5 為 36,864 個符元，而 Gemma 4 12B 則為 256K。這是清單上最大的差距，下一節將探討此事。

• 權重與授權 — Mk1.5 是封閉的託管模型，附有 SDK，而非可下載的檔案。Gemma 4 12B 採用 Apache 2.0，因此託管價格只是多種選項之一，而非執行它的唯一途徑。

36K 視窗是一項設計決策，而不是不足之處。

一個具身模型擁有 36,864 個 token 的視窗，聽起來像是個錯誤，直到你看到 Perceptron 同時打造了什麼。Mk1.5 接受 asset_idx 欄位，因此單一請求可以參照多張圖片或影片，並分別指涉每一個。它將每個項目的音訊上限設為 16,384 個 token——Perceptron 的文件指出，以每分鐘約 750 個 token 計算，這大約相當於 21.8 分鐘的語音。而視窗之所以能維持這麼小，是因為任務範圍狹窄：在畫面中尋找並追蹤特定事物、針對它們作答、停止。

那是與 Gemma 4 12B 不同形態的工作。256K 視窗是用來容納一份文件、一個程式碼儲存庫，或一段長對話，並在其中進行整體推理。Mk1.5 的視窗是為單一感知任務加上結構化答案所編列的預算，而 Perceptron 是依據那項任務、而非排行榜來決定它的大小。這項差異真正造成影響的時刻，就是你的任務是「看完這整段 40 分鐘的檢查影片，並告訴我一切」的時候——36K 視窗無法同時容納逐字稿、畫面影格和答案，而 Gemma 4 12B 的視窗加上它的長脈絡回想分數，才是處理那類任務的誠實工具。

那筆取捨的另一半是速度。Perceptron 指出，在單張 H100 上、以三次執行的中位數計算，端到端最高可快 4.7 倍，但要留意，4.7 倍是三次測量中最好的一次，並非典型情況：聊天回答從 5.2 秒縮短到 1.1 秒，圖像問答從 1.7 秒降到 0.51 秒（約 3.3 倍），而 60 秒影片在八路併發下從 19 秒降到 9.1 秒（約 2.1 倍）。在具身代理實際執行的影片工作負載上，實際的倍數大約是兩倍。

這些之中有一個已經被其他人測量過了

這是這場對決中最純粹的不對稱，而且差距毫不接近。

Gemma 4 12B 有一份供應商評估卡與一份第三方指數。這張卡列載供應商回報的數字——MMLU Pro 77.2、GPQA Diamond 78.8、MMMU Pro 69.1、LiveCodeBench v6 72.0、AIME 2026 不使用工具 77.5、Tau2 三次執行平均 69.0——以及一個誠實的弱點：MRCR v2 8-needle 在 128k 的表現為 43.4，這是在假設 256K 視窗在遠端表現相同之前該先看的那一列。在此之上還有一項獨立量測：Artificial Analysis 將 Gemma 4 12B 的 Intelligence Index 評為 14，在同級 142 個模型中排名第 22，輸出速度為每秒 113.7 個 token——速度在 142 個中排名第 20——定價為每百萬 token 輸入 $0.10、輸出 $0.30。

Perceptron Mk1.5 完全沒有這類東西。Mk1.5 和 Mk1 都沒有 Artificial Analysis 的索引條目，也沒有競技場評分，因此這款模型所有現存的能力數據，全都是販售它的公司自己產出的。那組數據具體而不含糊，值得一讀：在自我中心視角的 hand_box 上為 0.9433，而 Gemini 3.1 Pro 為 0.4467，Perceptron 自家測試中最佳的 Gemini 則為 0.6179；EgoSchema 為 80.40，同一競爭對手為 81.20，在廣泛理解基準上落後 0.80 分，卻宣稱在 EgoSchema-hard 子集上以 63.75 取得 12% 的優勢；Molmo2-Track 上中心 F1 為 0.647、點 HOTA 為 0.628；音訊方面則是 DailyOmni 74.67、AVHBench 80.56。這些數字呈現的模式——在細粒度幾何上具決定性優勢，在一般影片理解上大致持平或略為落後——前後一致，也與產品敘事相符。但廠商對自家模型所做的基準測試只是一種宣稱，而本文中的這兩款模型，並不是以同等性質的證據來描述。

那張表裡有一列特別值得提出警告。Perceptron 的追蹤比較把 Qwen3-VL-8B 列為 0.180 中心 F1，數據取自該模型自己的論文，卻與其自家模型的實測數字並排，還把它與 Qwen3.5-27B 的 0.530 與 0.476 配對，而兩者來自不同的檢查點與評估設定。在一整欄實測數字之中放進一個論文數字，並不是同基準的比較列，而這正是那種被引用時往往不帶出處的資料。反向來看，同樣的告誡也適用於 LiveVQA-W 上啟用工具的 56.0 Mk1.5 貼文——那個數字來自四樣本多數投票，而拿來與它相比的 Gemini 3.8 Flash 搭配搜尋接地所得的 53.2 則不是，而四樣本多數投票雖是正當技術，卻會讓分數相對於單次貪婪推論顯得偏優。

計算實際工作負載的成本

價目表上的差距，比產品本身的差距還小。Perceptron Mk1.5 每百萬個輸入 token 收費 0.15 美元，每百萬個輸出收費 1.50 美元，快取輸入則為 0.0375 美元——正好是標準輸入費率的四分之一，而且每個快取 token 比 Gemma 4 12B 的 0.10 美元標準輸入還便宜。Gemma 4 12B 在測量它的第三方測試框架上標價為 0.10 美元與 0.30 美元，而且它採用 Apache 2.0 授權，所以如果你有硬體，自行架設便能完全省去邊際成本。

有兩件事讓直接比較變得複雜，而且它們指向相反的方向。首先，Mk1.5 的 reasoning_effort 預設為 high，這表示你沒有設定的每一次呼叫，都是在採用模型所提供最昂貴的推理路徑；降到 medium 或 low 只是一行變更，卻會直接影響帳單，而且是這個版本中最便宜的實驗。其次，Gemma 4 12B 讓你完全關閉思考步驟，這會同時改變帳單與延遲，而在像是幀級分類這種固定任務上，非推理的一次執行往往是正確的選擇。

用真實情境來算一下：一條視覺管線每天處理 40,000 個影格，每個影格約有一千個影像輸入 token。那相當於每天 4,000 萬個輸入 token。以 Mk1.5 的 $0.15 輸入費率，加上在相同場景重複出現時使用快取影格，你每天的輸入成本只有低個位數美元——無論以什麼標準來看都很便宜。Gemma 4 12B 的 $0.10 輸入價又更便宜，若自行託管，邊際成本更是零。這兩個模型都不貴。這裡的決定不是預算問題，而是你是否需要座標、256K 視窗，或兩者都要。

無需第二次整合即可呼叫兩者

執行這項比較的實際障礙不在於價格——而在於 Perceptron Mk1.5 與 Gemma 4 12B 並不在同一份目錄中。目前 OrcaRouter 上也未提供兩者的路由：我們供應的 Gemma 4 項目是 31B Instruct 與 26B-A4B 變體，而 Mk1.5 完全沒有路由，因此最誠實的指引是透過廠商自家的 API 於 api.perceptron.inc——pip install "perceptron>=0.4.0"，並將金鑰放入 PERCEPTRON_API_KEY——來取得 Mk1.5，而 Gemma 4 12B 則可透過第三方主機，或自行部署 Apache-2.0 權重來取得。

在這種情況下，路由層真正的作用，在於那個你還沒做出的決定。如果 Mk1.5 的結構化輸出是你的應用程式所需要的，而 Gemma 4 12B 的上下文視窗是你的另一個工作負載所需要的，那就是兩個整合、兩個故障域；把它們放在一個 OpenAI 相容端點之後，並搭配自動容錯移轉，意味著任一方供應商出點小狀況時，會降級成備援，而不是讓工作失敗，而且路由規則可以把幾何運算工作和長上下文工作送到不同模型，而你的應用程式無須知道哪個是哪個。當供應商調整費率表時，直通式路由器會依供應商的標價計費，每個 token 不額外加收費用，因此變更會在同一天生效，而不是等到你下一個帳單週期。路由 DSL 也是你用來安排比較的方式——把一部分真實流量分給每個模型，以你自己的資料框架來衡量，而不是用基準測試論戰。

你真正想要哪一個？

如果答案必須是機器可讀的，就採用 Perceptron Mk1.5。如果你是在驅動某個東西，或在記錄位置與時間才是重點的資料，再多的額外上下文視窗都無法取代一組具型別的座標，而在這組合中，Mk1.5 是唯一能產出座標的模型。請睜大眼睛注意三件事：36,864 個權杖的預算、高 推理預設值，以及附加在它身上的每一個能力數字都是供應商自己的說法。

要解決這個問題，最便宜的方法就是把一部分真實流量導向兩者，並用自己的資料框架來衡量；兩者都位於同一個 OpenAI 相容端點之後（該端點位於 OrcaRouter 上），而這正是讓並排測試只需一行設定、而非第二次整合的原因。

如果你需要容納大量素材、需要權重，或需要向不把廠商基準測試當信仰的人證明這個選擇，就選 Gemma 4 12B。它有獨立的指數、公開的評測卡、Apache 2.0 授權，以及大上七倍的視窗——而且它會描述一個場景，而不是去量測它。最後那一句就是整個決策的關鍵。這些模型中，有一個是你能擁有並稽核的通用型模型；另一個則是你因為它能回傳幾何數據而租用的專精型模型，而這個專精型模型視窗較小、又沒有第三方評分，這並不矛盾。那就是一個專門打造的工具從外面看起來的樣子。