Ember-1 對上 Gemma 4 12B：一個讓你租用更少的 Token，另一個則把權重交到你手上

Ember-1 和 Gemma 4 12B 並不是在爭奪採購單上的同一行，而要看懂為什麼，最快的方法就是問問自己：每個月結束時，你實際上擁有什麼。Gemma 4 12B 是 Goog​le 的 11.95B 參數稠密多模態模型，於 2026 年 6 月 3 日以 Apache 2.0 發布——你下載它，檢查點就歸你所有。Ember-1 則是 Fireworks Research 以 Moonshot AI 的 Kimi K3 為基礎開發的專門衍生物，於 2026 年 9 月 23 日以研究預覽形式發布在供應商自家的無伺服器平台上——你呼叫它，除了帳單之外什麼都不擁有。一個是關於 token 的租購論證；另一個是資本購置。把兩者並排比較，有用的比較並不是哪個模型更好，因為沒有任何已發布的資料能讓你斷定這一點。重點是這兩種採購形態中，哪一種適合你正在打造的東西。

這兩份合約，直白陳述

Gemma 4 12B 是一個已完成的開放權重版本。Goog​le 會發布權重、架構、基準測試表與授權條款，而由 llama.cpp、vLLM、MLX、SGLang、Transformers 等執行環境組成的社群，則在你掌控的硬體上提供服務。購買之後，每個 token 的成本是電費與攤提，而不是供應商帳單上的一筆項目。你放棄的東西，正是開放權重一向的代價：容量規劃得由你自己負責，而你的品質上限則固定在 11.95B 參數。

Ember-1 則相反。沒有可供下載的權重——它僅以供應商自家平台上的服務選項形式存在——也沒有公開價格。它改而提供的是一個範圍更窄的主張，且是建構在一個大得多的模型之上：達到 Kimi K3 的準確度，而達成該準確度所耗費的 token 數約少 40%。Fireworks Research 專門訓練它縮短推理軌跡而不改變答案，並報告在七項基準測試與兩項客戶生產環境 A/B 測試中，推理長度可縮減 35–50% 而不損失準確度。其中每一項數字都是供應商自行回報、且未經重現驗證。

代幣論點的價值完全取決於由誰來支付這些代幣

Ember-1 的賣點假設了按 token 計費。這個假設對它鎖定的目標客群而言是正確的——那些針對託管式前沿模型執行長時間代理迴圈的團隊；在這種情境下，Fireworks Research 指出 Kimi K3 可能將超過 90% 的生成 token 花在內部推理上，而且每一輪都會重播先前的輪次，因此先前的推理會被重新讀取並再次計費。在這樣的環境中，縮短軌跡長度可直接減少每月帳單金額，而 29.9K 輸出 token 對比 K3 的 49.3K 的 A/B 結果，才是真正重要的數字。

用 Gemma 4 12B 的條件來跑同一個模型，這套論點就站不住腳了。當你自行架設 Apache-2.0 檢查點時，額外的推理 token 消耗的是實際耗時與 GPU 佔用率，而非每百萬美元的費用。在你自己的 16GB 筆電上，冗長的推理軌跡代表的是更慢的答案，而不是更龐大的帳單。這並不代表這種低效率就無害——在代理迴圈中它仍會不斷累積，也仍會以延遲的形式浮現——但匯率不一樣，把 40% 的 token 縮減當成在自行架設硬體上省下 40% 的成本，是範疇上的錯誤。

規格表，每個維度一行

• 這是什麼 — Ember-1：Kimi K3 的研究預覽衍生版本，經過重新訓練以縮短推理過程。Gemma 4 12B：來自 Google Gemma 4 系列、擁有 119.5 億參數的稠密開放權重多模態模型。

• 權重 — Ember-1：未公開任何權重；僅透過供應商平台提供服務。Gemma 4 12B：Apache 2.0，可下載，無須申請審核。

• 規模 — Ember-1：未公開；承襲自 Kimi K3 的架構。Gemma 4 12B：11.95B 稠密，48 層，BF16 權重約 18GB。

• 上下文視窗 — Ember-1：預覽版尚未公布；其基礎模型支援 1,048,576 個 token。Gemma 4 12B：256K 個 token。

• 輸入 — Ember-1：文字。Gemma 4 12B：透過無編碼器的統一設計支援文字、圖像與音訊，部分來源亦列出影片。

• 價格 — Ember-1：未公布；基準測試表中的美元數字是依 Kimi K3 的價目表計算得出。Gemma 4 12B：可免費下載；硬體費用得自行負擔。

• 硬體門檻 — Ember-1：視廠商排程而定。Gemma 4 12B：依 Google 的定位，需 16GB VRAM 或統一記憶體。

• 證據 — Ember-1：廠商基準測試與兩項由廠商進行的 A/B 測試，未經重現。Gemma 4 12B：Goog​le 報告的評估，加上獨立的本機執行生態系。

Gemma 4 12B 發布什麼，以及它如何閱讀

Goog​le 自己為 Gemma 4 12B 公布的數字，把它放在邊緣裝置規模的 Gemma 4 E4B 與較大的 26B MoE 之間：GPQA Diamond 78.8%、MMLU Pro 77.2%、AIME 2026 在無工具情況下 77.5%、LiveCodeBench v6 72.0、Codeforces ELO 1659、τ-2 平均 69.0%、MMMU Pro 69.1%、DocVQA 94.9，以及 BigBench Extra Hard 53.0%。這些同樣是廠商自行回報的數據——Goog​le 評估自家模型並發布了這份成績表——但它們的優勢在於描述的是一個任何人都能下載並重新執行的檢查點，這也是為什麼開放權重的宣稱往往能迅速獲得第三方驗證，而封閉預覽版的宣稱則不然。

這款模型真正的差異在於結構，而非數值。Gemma 4 12B 沒有獨立的視覺或音訊編碼器：影像區塊與音訊波形會直接投影到 token 空間，這正是讓 12B 模型得以將螢幕截圖或錄音作為輸入的關鍵。它也隨附用於推測解碼的多 token 預測草稿器，這是一項延遲功能，而非品質功能——當你自己執行模型，且每一毫秒的預填時間都得由你買單時，這類功能就很重要。

這兩者真正產生碰撞之處

這兩款模型都主打代理式編碼與工具使用，而這也正是唯一真正存在選擇空間的領域。Ember-1 在 Terminal Bench 2.1 的數字是 82.0%，對手 Kimi K3 Max 為 80.9%，且 token 用量少了 51.9%；其 SWE-bench Verified 結果為 92.2%，K3 Max 則為 93.2%。Gemma 4 12B 在 Goog​le 公布的数据中完全沒有 Terminal Bench 或 SWE-bench 的數字——它的代理式能力證據是 τ-2 的 69.0%。因此你無法把兩者放在同一個基準上比較，任何這麼做的文章都是在憑空捏造比較。

你可以說的是，它們位於成本曲線上的不同位置。如果你的代理工作負載是跑在託管的前沿模型上，而且帳單主要由推理 token 構成，Ember-1 正是針對這一項——代價是兩週的存取視窗，以及沒有公布價格。如果你的工作負載需要在你能掌控的硬體上運行、處理螢幕截圖，或是在供應商決定不再繼續預覽時仍能存活，Gemma 4 12B 是兩者中唯一真正回答這個問題的。

一條中間道路，以及何處尋得它

還有第三種選項，而這並不是任何一款模型自家行銷所圍繞的主打：把較大型號的 Gemma 4 層級當作混合架構中的託管那一半。OrcaRouter 將 Google 的 Gemma 4 26B-A4B 與 Gemma 4 31B連同其他 200 多款模型一併置於單一 API 之後、以供應商定價提供，且零加成；因此，能連上中階 Gemma 的那把金鑰，也能連上你原本得再簽一份合約才能使用的前沿模型。Gemma 4 12B 本身不在我們的平台上，Ember-1 也不在——若你需要在本機執行 12B，就去下載；若你想先測試更大的 Gemma 能否補上落差，那個測試只需付出一個端點的成本。

這樣的安排也是評估研究預覽版的誠實做法。跨供應商的自動容錯移轉意味著，某個從預覽窗口消失的模型不會連帶拖垮你的應用程式；而這正是 Ember-1 的發布狀態所帶來的特定風險，也是其基準測試表中沒有任何內容處理到的特定風險。

哪一個該放在你的路線圖上？

如果「擁有權」是必要條件——隱私、離線運作、固定的成本下限，或是產品在供應商改變心意時仍必須持續運作——那就選擇 Gemma 4 12B。它公布的能力上限低於前沿衍生模型，而它的多模態輸入確實具有差異化優勢，這兩點都不取決於任何其他人的路線圖。

如果你的問題是長時間 agent 執行下的逐 token 帳單，而且你能承受預覽版風險，就選擇 Ember-1。在你擁有的兩週內，以影子模式讓它與現行方案並行運行，在你自己的流量上衡量每完成一項任務所消耗的 token 數，並把那 40% 當成一個假設，而不是一個比率。你不該做的是根據品質在兩者之間做選擇，因為沒有任何一方——包括打造 Ember-1 的實驗室——發表過能讓你這麼做的比較。

更宏觀的重點在於，這兩次發布代表了 2026 年末販售能力的兩種方式。一家實驗室發布檢查點，讓生態系自行找到它的水準；另一家則拿別人訓練好的模型，改善其行為的某一個面向，再把這項改良當作服務來賣。兩者都合情合理，而它們失敗的方式不同：開放權重會緩慢且公開地失敗，預覽版則會突然失敗，而且是透過公告來宣布。