Intern-Decision-0.8B 對上 Gemma 4 12B：評分頭迎戰多模態通才

看出 Intern-Decision-0.8B 是什麼——以及不是什麼——最省成本的方式，就是把它和 Gemma 4 12B 並列，然後發現這項比較幾乎完全是在談每個模型如何處理自己的輸出層。Gemma 4 12B 是 DeepMind 的 119.5 億參數無編碼器多模態模型，於 2026 年 6 月 3 日以 Apache 2.0 授權發布，屬於生成式通用模型：你給它文字、圖像、音訊或影片，它就會寫出答案。Intern-Decision-0.8B 則由 InternLM 於 2026 年 9 月 26 日悄悄上傳到 Hugging Face，沒有任何公告；它是對小得多的 Qwen3.5-0.8B 進行微調而成的模型，完全不產生文字——它接收一個狀態、一份具名問題的綱要，以及最多八張圖片，並在單次前向傳遞後，為每個問題回傳一組校準過的機率分布。一個負責撰寫，另一個負責評分。以下所述的一切都由此而來。

這使得把兩者框定為一場競賽顯得奇怪，而且值得在規格列之前直言：這兩者並非替代品，任何在它們之間做選擇的人，都已經把問題陳述錯了。Gemma 4 12B 回答的是「回應應該是什麼」。Intern-Decision-0.8B 回答的是「這是十六個選項中的哪一個，以及你有多有信心」——而且是在沒有解碼器迴圈的情況下回答，這正是延遲與成本差異的來源。因此，有用的比較在於你會如何把兩者各自接入同一個工作流程，而不是哪一個勝出。

最大的單一差異在於帳單的輸出側。

Gemma 4 12B 的計費方式與任何生成式模型無異：輸入 token 與輸出 token，兩者皆計。當你要求它產生結構化 JSON 時，那些 token 每一個都會被生成、取樣與計費，而你的結構描述越長、巢狀層級越多，token 的數量就越多。這並非對該模型的批評——解碼器就是這麼運作的——但這正是決策頭存在的目的所要去除的那個計費項目。Intern-Decision-0.8B 沒有輸出 token。它的說明卡明確說明了原因：推論路徑從不呼叫 generate()/，而是在預先渲染好的骨架中，讀取每個 <decision>/ 佔位符緊接之前位置的 logit，並僅對該欄位所允許的候選符號進行 softmax。名為 output_tokens/ 的使用量計數器所計算的是被評分的欄位，而不是文字。

這種效應會隨著規模擴大而複合累積。一條用 Gemma 4 12B 標註一萬筆紀錄的管線，得為一萬份 JSON 文件付費；同一條管線改用 Intern-Decision-0.8B，就只需為提示付費，其他都不用。絕對數字是否龐大，完全取決於你的資料量和結構定義，任何有每 token 預算的人都能在十分鐘內用試算表算出來。但方向無可爭議，而這正是小型決策模型這個類別之所以會出現的原因。

延遲，以及為何參數落差會造成誤導

• 吞吐量模型 — Intern-Decision-0.8B：單次前向傳遞，沒有解碼迴圈。Gemma 4 12B：自迴歸生成，一次一個詞元。

• 實測延遲 — Intern-Decision-0.8B：在單張 RTX 4090 上透過本機 Hugging Face 路徑，平均 33.98 ms／p95 37.50 ms，根據 InternLM 自身的量測。Gemma 4 12B：不存在可比的單次傳遞數據，因為沒有可供量測的單次傳遞。

• 佔用空間 — Intern-Decision-0.8B：約 1.73 GB 的儲存庫儲存空間，852,985,920 個參數，分散於 1.50 GB 的語言分片、176 MB 的視覺分片與 25 MB 的投影器。Gemma 4 12B：Google 的發布資料指出其需要 16 GB 的 VRAM 或統一記憶體。

• 輸出確定性 — Intern-Decision-0.8B：對候選 logits 取 argmax，因此相同輸入每次都會產生相同標籤。Gemma 4 12B：除非將 temperature 固定為零，否則會進行取樣；而且即使如此，標籤也會以你必須解析的文字形式送達。

這兩個模型之間 14 倍的參數量差距，並不會在決策任務上轉化為任何接近 14 倍的執行時間差距，因為兩者所做的工作性質不同。Intern-Decision-0.8B 把它的唯一一次運算用在讀取提示詞上——狀態、結構描述、選項說明——然後就結束了。Gemma 4 12B 花同樣的工夫讀完提示詞後，還要在此之上逐一補上答案的每一個詞元。對於一個含有描述性選項標籤的十六欄位結構描述而言，生成階段並不是可以忽略的零星誤差；它占了實際耗時的大部分。InternLM 自家的表格無意間說明了這一點：其 2B 的同系列模型平均為 33.28 毫秒，比 0.8B 的 33.98 毫秒還略快一些。當提示詞處理占據主導地位時，參數量就不再是那個可施力的槓桿了。img src="2.png">

而 Gemma 4 12B 根本就是另一個類別

若把規格表只停留在決策任務的框架下，那會是不誠實的，因為在該框架之外，Gemma 4 12B 不僅僅是領先——它根本是在玩另一種運動。

Intern-Decision-0.8B 接受文字以及最多八張圖像，而這就是它全部的輸入介面。其預設輸入上限為 8,192 個 token，超出時會被拒絕而非截斷，這遠低於其設定所宣稱的 262,144 最大位置嵌入——真正決定實用視窗的是這個上限，而非架構。Gemma 4 12B 透過無編碼器設計原生接收文字、圖像、音訊與視訊，將原始圖像區塊與波形直接投影到嵌入空間，具備 256K 上下文視窗，並輸出文字。Google 公布的評測卡給出分數：MMLU Pro 77.2%、AIME 2026（未使用工具）77.5%、LiveCodeBench v6 72.0%、GPQA Diamond 78.8%、MMMU Pro 69.1%、MATH-Vision 79.7%。那些是 Google 自家評測卡上的廠商數據，而與 Intern-Decision-0.8B 的表格不同，它們背後已有一年的第三方使用經驗，因為 Gemma 4 在推出首日就已進入一個生態系——LM Studio、Ollama、llama.cpp、MLX、vLLM、SGLang、Unsloth。

這些發布看起來也毫不相似，而這種對比很具啟發性。Gemma 4 12B 在登場當天就有發布部落格、arXiv 上的技術報告、五個模型的家族頁面、評估卡，以及下載連結。Intern-Decision-0.8B 則只有一張模型卡，其中的 GitHub URL 會回傳 404，還有一個會回傳 401 的 demo Space，而且它是在兩個同樣未附文件的更大同類模型出現後四十秒內現身。其中一個是產品。另一個則是有人決定丟上網路的檢查點。

兩者都是 Apache 2.0，而那可不是一列微不足道的共用資料列。

兩者真正交會的唯一一個面向就是授權，而這值得用一整段來說明，因為商業使用者的決策正是在這裡出現變化。兩者都是 Apache 2.0。Gemma 4 12B 是依循託管於 Google 的 Gemma 4 授權條款發布，模型卡將其標示為 Apache 2.0；Intern-Decision-0.8B 則在 Apache-2.0 之外，還附上第二個 LICENSE-QWEN/ 檔案，這對一個衍生自 Qwen 權重的模型而言是正確的處理方式，也顯示 InternLM 連一個它並未對外宣布的版本都把文書作業做足了。

這使兩者都與 Liquid AI 的 LFM2 系列有所不同，其 LFM Open License v1.0 將商業權利取決於您的法律實體維持在年營收 1,000 萬美元門檻以下——這是比較各種選項的決策模型在假定「開放權重」到處都代表同一件事之前，應該先閱讀的一項實際限制。如果您的使用情境屬於商業用途，且您的營收超過那條界線，Apache 2.0 與 LFM 授權便不能互換，而 Gemma 4B 與 Intern-Decision-0.8B 帶有這項限制。

Intern-Decision-0.8B 數字的誠實帳本

Intern-Decision-0.8B 的每一項效能數據都是由廠商自行報告，且未經重現。這不是形式上的問題——這就是目前證據的實際狀態，也應該決定這張表格該有多少份量。InternLM 自行挑選基準測試、自行挑選比較對象、自行執行評估並公布結果，而任何公開排行榜上都不存在獨立的執行結果。以 Artificial Analysis 查詢該模型，結果一無所獲。img src="3.png">

附上那個標籤後，結果的樣貌仍具參考價值。0.8B 在 TypeSafe 的 Typed Decision 基準上拿到 77.35，相較 Jev 1.13——該基準正是以其命名——的 73.35；在 ToolACE 上則是 94.52 對 91.29。它在整個測試套件上平均為 79.38，而同系列的 2B 與 4B 版本分別為 84.68 與 90.02。最該讓買家卻步的是 WildJailBreak 欄，它拿下 64.48，而 Jev 為 96.29：如此巨大的拒答穩健性落差是這套微調本身的特性，至於它究竟是源自 Qwen3.5-0.8B 基底、決策調校目標，還是參數量，則完全沒有任何文件說明。它的校準表現更值得細讀——Brier 分數 0.530、期望校準誤差 0.066，對比 Jev 的 0.358 與 0.095——意味著它整體準確度較低，但其宣稱的信心水準與實際準確度貼合得更緊密。對於以閾值為基礎的工作流程而言，這項區別比原始準確度更為重要，而這正是 InternLM 沒有動機公佈的那類資訊。

相對之下，Gemma 4 12B 的評估卡也是廠商自行報告的——那些基準測試同樣是 Google 跑的——但它自六月以來就已問世，已透過各大本地執行環境部署，任何出入早就會浮現。介於「一週未能重現」與「四個月未能重現且無人反駁」之間的證據落差，正是這兩欄的真正差異。

你實際上會如何將它們結合起來

說得通的模式不是二選一。決策頭負責結構化呼叫——路由、分流、分類、依評分規準評分——這類答案集封閉、延遲要緊，而輸出 token 純屬額外開銷。通才模型則負責所有需要散文、程式碼、綜合彙整或長脈絡的事：升級摘要、說明工單為何轉到帳務、由人工修改的草稿。

如果你正在釐清這條界線該劃在哪裡，最省成本的實驗方式，就是把兩半都放在同一個端點後面。OrcaRouter 透過單一相容於 OpenAI 的 API 路由 200 多個模型，具備自動容錯移轉，並以零加成直接反映供應商的定價，這意味著在同一份腳本裡測試一個託管的決策模型和一個託管的通用模型，只需要一把金鑰和一個下午。這裡有一條界線值得說清楚：Intern-Decision-0.8B 並不是我們的模型——它是一份 Apache-2.0 的檢查點，由你自己下載並執行，而選擇一個 1.73 GB 模型的全部理由，就在於它存在於你的資料原本所在的地方。這個模式中生成的那一半，只差一行就能到位。至於 Gemma 4 12B，它同樣不在我們的目錄中；我們實際有路由的 Gemma 4 尺寸是 31B 和 26B A4B，而 12B 則是本地下載。img src="4.png">

那麼，結論並不是贏家。Intern-Decision-0.8B 是來自一個尚未對外說明它的實驗室、便宜、快速且具確定性的評分頭，有一張沒有人重現過的基準測試表，還有一個在它接近不受信任輸入之前就該先測試的拒答穩健性欄位。Gemma 4 12B 則是成熟的開放權重多模態通用模型，有已發布的模型卡、技術報告，以及十四倍的參數數量；而它對於十六欄位分類呼叫來說是錯誤的工具——不是因為它更差，而是因為針對一個你早已寫下答案集的問題生成答案，是取得標籤的昂貴方式。