LFM3-1.7B vs Gemma 4 12B：當小七倍的模型在程式設計基準測試中勝出

LFM3-1.7B 是 Liquid AI 於 2026 年 10 月 26 日發佈至 Hugging Face、並於隔日宣佈的 17.3 億參數文字模型，屬於其 LFM3 系列發布的一部分。Gemma 4 12B 是 Google DeepMind 於 2026 年 6 月 3 日發佈的 119.5 億參數稠密模型，能讀取圖像、音訊以及文字。在兩家廠商都有公佈的唯一程式設計基準 — LiveCodeBench v6 — 中，較小模型得分 73.46，較大模型得分 72.0。請再看一次，因為這正是這個頁面存在的全部原因，也是網路上最容易誤讀的數字。 路由不會在供應商的標價上增加利潤。 0% 加成 請在我們的定價頁面查看轉嫁定價。

這兩個數字都是廠商自行回報的。兩者都未經獨立評估者重現。它們由不同團隊、在不同測試框架上、相隔數月產生，而 Liquid 並未發布任何方法說明，解釋其 LiveCodeBench 執行是如何設定的。因此，上一句話誠實的版本並不是「一個 1.7B 模型在程式碼方面勝過 12B 模型」。而是：兩家廠商在一個名稱相同的基準測試上回報幾乎相同的分數，而 GPQA Diamond 上反方向出現的九分差距則顯示，這兩個模型根本稱不上接近等效。

什麼是真正可比較的，什麼不是

大多數「X 對比 Y」的頁面只是把兩份廠商表格並排放著，就稱之為比較。這只有在兩邊表格確實有重疊項目時才成立。在 Liquid 的 LFM3 發布文章與 Google 的 Gemma 4 模型卡之間，恰好只有兩個基準名稱同時出現在雙方、且定義相容：LiveCodeBench v6 與 GPQA Diamond。其餘項目都只有一方廠商提供數據、另一方沒有，而空白儲存格並不代表零分。

在這兩個共同軸線上，結果呈現明確的分野。LFM3-1.7B 在 LiveCodeBench v6 以 73.46 對上 72.0 勝出。Gemma 4 12B 在 GPQA Diamond 以 78.8 對 63.37 勝出——15.4 分的差距，在只有數百道題目的評測中並非雜訊。

那個模式值得被命名，而不是被平均掉。LiveCodeBench 衡量的是模型完成競賽程式設計問題的能力，這是一種狹窄且高度依賴模式的技能，小型模型若在正確的資料上訓練，就能擅長。GPQA Diamond 衡量的是研究所程度的科學推理，取決於知識的廣度——這正是參數量能換來的。1.7B 模型可以在前者具有競爭力，卻會在後者落敗，而這是個連貫一致的結果，而非矛盾。

該供應商壓低了自身的最佳報價。

以下這段應該會改變你解讀 73.46 的方式。捲動到 LFM3-1.7B 模型卡的最下方，Liquid 用淺白的文字寫道，該模型是為本地代理、工具呼叫與結構化輸出而設計，而且它因其規模較小，不建議用於代理式編碼或複雜的多步驟推理。

那是廠商，不是競爭對手，在告訴你上限。它與一個險勝 11.95B 通用型模型的 LiveCodeBench 分數並列時顯得有些尷尬，而調和之處在於，它們衡量的是不同的東西。解決一道孤立的競賽程式設計題目，與將整個儲存庫保持在上下文中並進行二十次協同編輯，並不是同一種任務。一個模型可以在前者很強，卻明確不適合後者，而 Liquid 正是這麼說，而不是讓基準測試暗示相反的情況。

就照廠商所說。若你的工作負載是代理式程式編寫，這項比較不應以 LFM3-1.7B 作結。若你的工作負載是工具呼叫、結構化擷取、分類，或是在你擁有的裝置上運作的本機助理，那麼這張卡片的警告不適用於你，而 1 GB 的佔用空間就成了全部的論點。

而 12B 只是屬於完全不同類別的東西

Gemma 4 12B 的多模態能力，無法透過微調加到 LFM3-1.7B 上。Google 的模型卡說明，影像與音訊輸入會直接投影到與文字 token 相同的空間，且沒有獨立的編碼器——音訊原生支援於 12B 及其較小的同系列模型。LFM3-1.7B 是文字輸入、文字輸出。Liquid 的視覺能力位於 LFM3-VL-2B，這是另一個具有獨立編碼器的檢查點，而文字模型不會因為經過微調就獲得這種能力。

• 參數 — LFM3-1.7B 為 1.73B 稠密；Gemma 4 12B 為 11.95B 稠密。比例為 6.9 比 1。

• 模態 — 僅文字，對比文字、圖像與音訊輸入。

• 上下文 — 兩者皆為 262,144 個 token。這是小型模型唯一毫不退讓的一列，而且這是三混合架構的真正成就，而非巧合。

• 佔用空間——4 位元下約 1 GB，相較之下約 7 GB。在手機上，這個差距就是能否出貨的關鍵。

• 語言 — 16 種具名語言，相較於 140 多種已預先訓練且開箱即用支援完善的語言。對拉丁字母產品而言，這差距鮮少造成影響；對區域性部署而言，卻是決定性的。

• 授權 — LFM Open License v1.0 在年營收低於 1,000 萬美元時可免費商用，超過此門檻則需付費取得授權。Gemma 4 12B 採用 Apache 2.0，沒有營收門檻。

這兩張票據並非以相同貨幣計價。

Gemma 4 12B 之所以有市場價格，是因為有第三方提供服務。Artificial Analysis 報告指出，在託管這些開放權重的平台上，混合中位數為每百萬輸入 token 0.10 美元、每百萬輸出 token 0.30 美元——這是跨供應商的中位數，而非定價表上的價格，且會隨供給變化而變動。在這樣的費率下，大多數團隊根本不會考慮自行運行 12B 模型。

LFM3-1.7B 並沒有這樣的價格。Hugging Face 的模型卡明確指出，該模型未由任何推論供應商部署，這與我們自身所見一致：OrcaRouter 目前並未路由 LFM3-1.7B。如果你想呼叫它，你得下載 3.46 GB 的 BF16 權重，或約 1 GB 的 4 位元版本，然後自行執行 vLLM、SGLang、llama.cpp、MLX 或 ONNX。Liquid 自家的 API 會提供它，幾個第三方平台也會。

因此，成本比較並不是 token 對 token，而是微調與服務帳單對上每次呼叫的帳單。在低用量時，API 毫無疑問勝出；在持續用量、且使用你已擁有的硬體時，一個只佔 1 GB、還讓 GPU 其餘部分保持空閒的模型，其經濟型態完全不同。這種不對稱——而不是 LiveCodeBench 上四分的差距——才是考慮小型模型的真正理由。

每個實際上是用來做什麼的

選擇 LFM3-1.7B——當部署目標本身就是限制條件時：手機、筆電，或還得同時處理其他工作的單張小型 GPU。在這個規模下，256K 上下文確實罕見，16 種語言的詞彙涵蓋大多數區域性產品，而六向推論支援意味著你不會把賭注押在單一執行環境上。請接受你買的是工具呼叫與擷取模型，而非推理模型，並針對廠商自己指出的知識缺口規劃檢索。

選擇 Gemma 4 12B時機是任務需要廣度、輸入是螢幕截圖或錄影，或 Apache 2.0 對採購流程而言很重要。它在研究所程度的科學推理上高出 15 分，能原生讀取圖像，而且第一天就以公開的中位價格供應。代價是記憶體：4 位元下需 7 GB，這屬於筆電或規格不高的 GPU，而非手機。

兩者並用：當你同時有高流量的窄範圍路徑與低流量的寬範圍路徑時，就兩者並用。把寬範圍路徑交給託管的通用型模型，並把小模型留在裝置端，負責窄範圍、對延遲敏感的呼叫。OrcaRouter 正是為這樣分工的前半段而打造——一組金鑰通行 200 多個模型，供應商定價以 0% 加成原樣傳遞，價格一有變動當天就反映，供應商服務劣化時還會自動容錯移轉。它無法幫你自行託管 LFM3-1.7B，因為我們並未提供該模型，若暗示不然則有失誠實。

什麼能讓它塵埃落定

對 LFM3-1.7B 在其未自行選擇的評測框架上進行一次獨立評估，會比這整頁更有價值。Liquid 的發布表格詳盡且內部一致，而本部落格將其視為廠商自行回報而非經查證的資料，事實也正是如此。值得特別留意的具體事項包括：第三方 LiveCodeBench 或 SWE-bench 執行結果能重現 73.46、能將兩個模型放在同一尺度上的 Artificial Analysis 評測概況，以及任何關於該模型處理真實儲存庫任務的報告——而這正是模型卡警告不要做的用途。

在那之前，站得住腳的解讀比標題所暗示的更狹窄。一個具備 256K 上下文、1 GB 佔用空間和強大工具呼叫表現的 1.73B 模型，在某個孤立的程式設計基準上追上了 12B 的通用模型，卻在知識方面大幅落後。這不是爆冷。這是兩個為不同工作打造的模型，而有用的问题是：你面對的是哪一種工作。