LFM3-1.7B vs Gemma 4 26B A4B：低成本 token 的兩種配方，只有一種能裝進手機

表面上，這兩個模型對同一個問題採取相同的方法。LFM3-1.7B，由 Liquid AI 於 2026 年 10 月 27 日發布，以及 Gemma 4 26B A4B，由 Google DeepMind 於 2026 年 4 月 2 日發布，兩者存在的目的都是回答一個問題：如何把一個有能力的模型塞進很小的記憶體預算裡？它們給出相反的答案。Liquid 把模型縮小。Google 則讓模型維持龐大，並且每個 token 只支付其中一部分的成本。 權重是免費的，所以帳單就是最便宜且夠格的託管商收取的費用。我們轉嫁供應商的定價，並以 0% 加價。

這種區別聽起來像架構冷知識，直到你為部署估算成本，這時它就成了唯一要緊的事。Gemma 4 26B A4B 每個 token 啟用 38 億個參數，但你仍然得把其中 252 億個參數存放在某處。LFM3-1.7B 會啟用其全部 17.3 億個參數，並且正好儲存同樣多的參數。一個的運算成本低。另一個的持有。

打造便宜代幣的兩個配方

Gemma 4 26B A4B 是一個混合專家模型：128 個路由專家加上一個共享專家，30 層，每個 token 大約有八個專家會啟動。這讓它具備 25.2B 稠密模型的知識容量，而算術成本卻更接近 4B 模型。Google 自己的說法是，它在 MMLU-Pro 上的得分約可達到稠密版 Gemma 4 31B 的 97%，而 FLOPs 僅約為其 12%。

LFM3-1.7B 走的是另一條路。它完全稠密——每個參數都會在每個 token 上運算——而節省來自重新設計的架構，而非稀疏性。Liquid 的三混合堆疊共有 24 層：13 層閘控短卷積、5 層滑動視窗注意力、6 層全注意力。大部分的序列建模由成本低廉的卷積完成，全注意力僅出現六次。這就是一個 1.73B 模型能承載 262,144 個 token 的上下文與 128,000 個 token 的詞彙表，而不讓 KV 快取吃掉機器資源的原因。

• 總參數量 — LFM3-1.7B 為 1.73B；Gemma 4 26B A4B 為 25.2B。

• 每個 token 的啟用量——1.73B 對上約 3.8B。這是唯一一列兩者處於同一量級的項目。

• 4 位元下的記憶體 — 約 1 GB 對比約 18 GB。這就是決定部署的那一列。

• 上下文 — 兩者皆為 262,144 個 token，再次形成真正的平手。

• 模態 — 僅限文字，相對於文字與圖片輸入，具備原生函式呼叫與可設定的思考模式。

• 授權 — LFM Open License v1.0，年營收低於 1,000 萬美元可免費使用；Gemma 4 26B A4B 採用 Apache 2.0，無門檻。

為什麼 3.8B 活躍參數不等於 3.8B 的記憶體

這是閱讀混合專家（mixture-of-experts）規格表時最常見的錯誤，所以值得直說。活躍參數決定的是運算量，粗略來說也決定速度。它們並不決定你下載的檔案大小，也不決定你預留的 VRAM 容量。Gemma 4 26B A4B 需要讓全部 252 億個參數常駐，才能在專家之間進行路由；以 4-bit 計算，大約落在 18 GB。你可以在單張 24 GB 的顯示卡上執行它，而 Google 也推出 FP8 與 NVFP4 版本讓這件事變得可行，但你無法把它放進手機裡。

LFM3-1.7B 在 4-bit 下約為 1 GB——Liquid 的說明卡指出它能裝進手機或筆電，而在這樣的尺寸下，這個說法可信，並非行銷話術。它在 128K tokens 時也保有 1.6 GB 的 KV 快取，而這個數字才真正決定你能同時容納多少個長上下文請求。

實務上的後果是：26B-A4B 部署是推論伺服器層級的決策，而 1.7B 部署是應用程式交付層級的決策。這些是不同團隊、不同成本結構的不同專案，沒有任何基準測試能彌合兩者之間的差距。

各家廠商發布了什麼，以及這告訴了你什麼

Google 為 Gemma 4 26B A4B 公布了一份大型表格：MMLU-Pro 82.6、GPQA Diamond 82.3、AIME 2026 在無工具下 88.3、LiveCodeBench v6 77.1、Codeforces Elo 1718、MMMU-Pro 73.8，以及在 128K 長度、八個針（needle）條件下 MRCR v2 44.1。全部皆為廠商自行報告，無一經獨立重現。第三方追蹤顯示其 LMArena Elo 接近 1438。

Liquid 為 LFM3-1.7B 發布了一份範圍較窄的表格，且內容偏向代理式（agentic）工作：BFCL V4 為 71.39、ToolSandbox 為 80.36、τ³-bench 為 68.01、LiveClaw 為 45.60、WebArena-Verified 為 38.42。它同時回報 IFEval 96.66、IFBench 73.03、GPQA Diamond 63.37、LiveCodeBench v6 73.46，以及 128K 下的 RULER 65.56。Liquid 並未公布 LFM3-1.7B 的 MMLU-Pro 數值，而這項缺席並非零——只是單純沒有測量。

只有 LiveCodeBench v6 與 GPQA Diamond 能乾淨地重疊。Gemma 4 26B A4B 在兩者上都勝出，分別領先 3.6 分與 18.9 分。在 Liquid 的測試套件轉向代理型（agentic）之處，並沒有 Gemma 的數字可供比較——Google 回報 τ²-bench 為 68.2，而 τ² 並非 τ³，因此把 68.01 放在它旁邊，會是包裝成嚴謹比較的捏造對比。

1.7B 在對話中保留於何處

3.6 分的 LiveCodeBench 差距，比 14 比 1 的參數比例所預測的還要小，而原因在於架構。競技程式設計看重的是能否記住一個模式並輸出正確的函式——這項能力更受益於乾淨的訓練訊號，而非單純的原始容量。如果寫程式的題目就是工作的全部，那麼 26B 會勝出，而這一節也會很短。

真正讓 LFM3-1.7B 保有相關性的，是 262,144 個 token 的上下文與 1 GB 佔用空間的組合。一個能容納大型文件、並在閱讀該文件的裝置上執行的模型，與一個能在伺服器上容納同一份文件的模型，是截然不同的產品。Liquid 在 128K 的 RULER 上回報 65.56，這不是亮眼的長上下文分數——Gemma 4 26B A4B 在同一基準系列上回報 81.4——但它至少是在裝置端、以 1 GB 的規模實際測量出來的。

而在指令遵循方面，這個小模型也毫不遜色：IFEval 上的 96.66 和 IFBench 上的 73.03，對這個尺寸級別來說都是很強的數字，且兩者皆為廠商報告。對於工具呼叫或結構化輸出的工作負載而言，這比 GPQA Diamond 更接近真正重要的指標。

路由層實際改變了什麼

Gemma 4 26B A4B 已登上 OrcaRouter 目錄——一組 API 金鑰即可存取它，以及超過 200 個其他模型，供應商牌價以 0% 加價原樣傳遞，因此廠商價格變動當天就會反映，不必等待重新定價週期。這一點在此比平常更重要，因為這個模型的經濟效益完全取決於供應商定價：權重免費，所以帳單就是最便宜且稱職的託管商收取的費用，而那個數字會變動。

自動容錯移轉是另一半。具備 256K 上下文的 26B 混合專家模型，正是會在尖峰時段撞上容量上限的那種工作負載，而跨供應商路由意味著單一主機的糟糕午後不會成為你的停機事故。LFM3-1.7B 完全不需要這些，因為它在你掌控的硬體上運行，也沒有可供容錯移轉的供應商。這既不是它的優點，也不是它的缺點——而是選擇另一套方案的結果。

對我們角色的誠實界定：我們負責路由大型稀疏模型，並不提供小型稠密模型，而兩者之間的選擇並不是路由器能替你做出的決定。

一次完成決策

如果部署目標的記憶體少於 20 GB——手機、筆電、Jetson、AI PC——那麼 Gemma 4 26B A4B 就不是候選方案，比較也無需再談。選擇 LFM3-1.7B，圍繞 Liquid 自身指出的知識缺口來規劃檢索，並在其數據確實具競爭力的工具呼叫與結構化擷取場景中使用它。

如果你是在 GPU 上提供服務，且工作負載偏重知識、多模態，或需要 82.3 GPQA Diamond 與 82.6 MMLU-Pro 等級的推理能力，那麼 Gemma 4 26B A4B 是更好的模型，而 18 GB 就是入場成本。Apache 2.0 完全免除了授權方面的討論，對大型組織而言，這比幾個基準測試分數更有價值。

如果你正在打造一個同時涵蓋這兩端的產品——一個會把困難查詢升級到伺服器的裝置端助理——這兩者根本就不是競爭對手。它們是同一套架構的兩個層級，而真正有趣的工程問題是你要把升級界線畫在哪裡，而不是哪個模型能在表格上勝出。

尚未解決的問題不在於能力——這點已對 Google 有利地定案——而在於一個具備 256K 上下文的 1 GB 模型，是否足以勝任大多數裝置端產品實際需要的狹窄代理型任務。Liquid 自家的模型卡異常坦率地表明它並非推理模型。這份坦率比 LiveCodeBench 的差距更有價值，因為它告訴你該把工作量中的哪一半送到哪裡。