FrogNano-4B-2609 對上 Gemma 4 12B：在 SWE-bench 上拿下 61.5%，卻沒有人查核過

微軟的 FrogNano-4B-2609是一款四十億級別的程式編寫代理，衍生自 Qwen3.5-4B，並在 SWE-bench Verified 上回報 61.5%。Gemma 4 12B是 DeepMind 的 119.5 億參數、無編碼器多模態模型，其模型卡在 LiveCodeBench v6 上回報 72.0%。這兩組數字是買家會拿來並排對照的，而把它們並排對照正是錯誤所在。它們來自不同的基準測試、不同的測試框架、不同的實驗室，而且——更重要的是——只有其中一個擁有已公開發表、且曾有外部人士讀過的評估方法論。這場對決的其他一切，都取決於這兩個模型實際上究竟是什麼，而答案是：它們根本不是同一類的東西。

下方的 FrogNano 數據來自微軟的模型卡及其技術報告，兩者自九月起公開，且實驗室外無人重現過。Gemma 4 12B 的數據來自 Google 的模型卡，這也是一份供應商文件——差別在於，Gemma 的數字背後有二十週及大約 260 萬次下載的審視，而 FrogNano 只有兩週，以及一個尚未突破個位數的下載計數。

每個模型的用途

這是規格表所隱藏的部分。FrogNano-4B-2609 並不是一個剛好擅長程式碼的通用模型。它是一個檢查點，其整個後訓練都是儲存庫層級的軟體工程，而且它的設計是由測試框架驅動，而不是供人與之交談。

它的五個工具是 Read、Write、Edit、Glob和Bash。它會發出對這些工具的呼叫，由沙箱執行並傳回輸出，而迴圈會持續執行，直到模型停止要求為止。受評估的設定是在大約 131K 個合併 token 內進行 150 個互動步驟，並為每個任務產生一個候選修補程式。Microsoft 的模型卡明確指出，該模型適用於以英文為主、大量使用 Python，並具備可重現環境與可執行測試套件的存放庫，且從基礎模型繼承的影像與視訊元件從未經過後訓練，因此不受支援。

Gemma 4 12B 則是相反的形態。它是一個 48 層的統一模型，具備 256K 上下文，且沒有獨立的視覺或音訊編碼器——原始影像區塊與音訊波形會透過輕量線性層，直接投影到單一解碼器的嵌入空間中。它能接收文字、圖像與音訊，並輸出文字。它有一種由系統提示中的詞元觸發的思考模式、原生函式呼叫，而 Google 的模型卡也特別將其代理式工作流程列為預期用途之一。

所以真正的問題不是哪一個比較聰明。而是你想要一個專門的元件，只能在你自己必須操作的一套系統內運作，還是一個通用模型，在許多事情上都表現得不錯，而且能被任何東西呼叫。

逐行，在它們實際有差異的地方

• 參數 — FrogNano-4B-2609 在一張自身描述寫著約 46.6 億的模型卡上，公布了一個範圍「500M-5B」；而下載後則確定為 9.32 GB 的 BF16 權重。Gemma 4 12B 是 11.95B，只陳述一次，從不模糊帶過。這個比例大約是 2.6 比 1，而且會直接反映在你必須租用的資源上。

• 背景 — FrogNano 的評估組態約為 131K 合併 token，推理與工具輸出共用此預算。Gemma 4 12B 具備 256,000 個 token，且在其本身的長脈絡列中，於 128K、八個針的 MRCR v2 上得分 43.4%。視窗幾乎是兩倍，而第二個數字是已發表的量測結果，而非能力宣稱。

• 模態 — FrogNano-4B-2609 是文字進、文字出，儘管其檢查點中還坐著一座視覺塔。Gemma 4 12B 則是文字、圖像與音訊進。

• 輸出上限——經過驗證的 FrogNano 組態允許每個助理回合生成 8,192 個 token，而其模型卡指出 RL 訓練組態也使用了相同的上限。Gemma 4 12B 並未公布等效的單回合上限；那裡的限制是 256K 視窗。

• 代理式介面——FrogNano 發出結構化的 Leaf 呼叫，需要一套執行框架來執行它們。Gemma 4 12B 在其指令調校版本中內建原生函式呼叫功能，且可直接呼叫。

• 授權條款 — Gemma 4 12B 在 Google 的 Gemma 4 條款下採用 Apache 2.0，明確載明。FrogNano 的模型卡在前言部分標示 MIT，但在其正文中卻寫 Apache 2.0，這種模稜兩可正是那種最終會進入法律審查、而非僅止於註腳的狀況。

• 數字 — FrogNano 報告 61.5% SWE-bench Verified、37.6% SWE-bench Pro、31.1% Terminal-Bench 2.0 以及 47.3% PatchEval-Verified。Gemma 4 12B 報告 77.2% MMLU Pro、72.0% LiveCodeBench v6、Codeforces ELO 1659、78.8% GPQA Diamond，以及 Tau2 上的 69.0%。Google 的模型卡並未公布 SWE-bench 一列，而 Microsoft 的模型卡並未公布 LiveCodeBench。這兩個計分板之間完全沒有重疊。

最後那一點，正是應該終結「用數字互相比較」這種直覺的一點。兩張卡片上沒有任何一項基準測試同時出現。讀者若把 61.5 拿來和 72.0 並列對比，就是把儲存庫解決率拿來跟競賽程式設計通過率相比，這大致就像因為馬拉松時間和百米時間都以秒為單位，就把兩者拿來比較一樣。

為什麼 Google 對 SWE-bench 的沉默是個警訊

這份項目符號清單所帶來的一個誘人結論是：FrogNano 有真正的 SWE-bench 分數，而 Gemma 沒有，所以 FrogNano 在程式設計問題上勝出。這個推論並不成立，而其中理由值得我們精確說明。

Gemma 4 12B 在 Tau2 上回報 69.0%——這是一項代理式工具使用基準，取三次執行的結果——同時具備函式呼叫支援，並明確定位於代理式工作流程。在 Tau2 上拿到 69.0 分的模型，並非無法勝任代理式工作的模型；而是其供應商選擇回報工具使用效能、而非儲存庫解析的模型。Google 同樣未回報 26B 或 31B 的 SWE-bench 數據，這是全系列的編輯取捨，而非 12B 的弱點。

與此同時，微軟自家論文中那個違反直覺的結果，值得 Gemma 買家仔細閱讀。FrogNano 從 Qwen3.5-4B 這個通用模型出發，透過 Leaf 測試框架在 SWE-bench Verified 上取得 39.4% 的成績。經過約 1,500 項合成任務的五輪強化學習後，成績提升到 61.5%。這帶來的教訓並不是「小模型不會寫程式」——而是當有人在一個稱職的 agent 迴圈中執行它時，一個 39.4% 的通用 4B 檢查點，早已能解決超過三分之一由人類驗證的困難 issue 集。Gemma 4 12B 的規模是它的三倍，且成熟度多出二十週。沒有人把它跑過 Leaf，而在有人這麼做之前，「Gemma 不是 repo agent」只是個假設，而非研究發現。

測試框架稅，排行榜完全隱藏了它

這就是實務上的不對稱，而它正是決定購買與否的關鍵。

Gemma 4 12B 是一個模型。下載 11.95B 的權重，讓 Transformers、vLLM 或 SGLang 指向它們，送出文字，取得文字。Google 公布了服務路徑，授權條款清楚明確，而且已有相當於 260 萬次下載的使用者碰過那些粗糙邊緣並記錄下來。如果任務是「摘要這段堆疊追蹤」、「讀取這張螢幕截圖並告訴我哪裡壞了」，或「用這些引數呼叫這個函式」，它現在就能運作。

FrogNano-4B-2609 是一個模型加上一套測試框架，而 Microsoft 自家的 README 讓這套框架成為必要項目。github.com/microsoft/FrogNano 上的儲存庫是 Leaf 評估工具組，不是訓練程式碼——它需要 Kubernetes 叢集、既有的命名空間、管理 Pod 與網路政策的權限、對基準測試容器映像的拉取權限，以及一個已配置正確推理與工具呼叫剖析器的 OpenAI 相容端點。Microsoft 的模型卡直言相符條件：分數若要相同，就必須有相符的檢查點、分詞器、服務配置、任務映像檔與評估協定。這個發布版本中負責產生分數的那一半，正是模型卡指向一個 GitHub 連結的那一半。

這其中確實有真正的價值，值得點名而非輕忽帶過。FrogNano 的貢獻在於一個任務合成迴圈，能依據當前策略的能力重新生成訓練問題——該論文的主張是，小型代理可在完全不做蒸餾的情況下，透過合成任務訓練到具競爭力的水準，而這也為負擔不起前沿教師模型的人開了一條路。它的 API 是公開的。它的方法原則上可重現。這比又一個漸進式的檢查點是更紮實的貢獻，而且也比大多數團隊當初決定投入時所預期的還要費工。

如果你要選一個，就依工作來選。

如果工作會混合多種模態，如果需要看見影像或聽見音訊，如果上下文必須同時容納龐大的檔案樹和長篇逐字稿，或者你想要一個任何框架都能載入、背後不必再多一套系統的模型，就選 Gemma 4 12B。它的 69.0 Tau2 分數和原生函式呼叫功能，讓它成為代理式流程中站得住腳的選擇，而且不必單憑某間實驗室的說法——這款模型已由數千人評估過，結果並不是什麼祕密。

如果你已經在執行沙箱化的儲存庫代理，而且想要一個 4B 級別的檢查點放進去，那就選 FrogNano-4B-2609；如果 9.32 GB 的下載量、能裝在普通硬體上，是驅動這項決定的限制條件，也一樣。要清楚看待先後順序：你不是在買一個分數，而是在對一種方法下注，而你首先會發現的，是你的輪詢迴圈和工具呼叫解析器看起來是否夠像 Leaf。有些團隊會在第三天下午就得到接近 61.5% 的行為，有些則會花兩週才發現自己的評估集比 SWE-bench Verified 還簡單，而實驗室外還沒有人能告訴你，你屬於哪一種。

如果這個決定確實難分高下，最省成本的實驗方式，是把兩者放進同一套測試框架、用你自己的問題來跑，而不是爭論那些根本沒有共用基準的公開數字。OrcaRouter 在一組與 OpenAI 相容的金鑰 零加價之下提供 200 多種模型，因此供應商的定價會原封不動地穿過——這讓你可以把一個代管的一般模型與你候選名單中的其餘模型，放在同一個端點、同一張帳單之下，邊用邊決定。FrogNano 不是我們的路由之一，也沒有任何上線日期；其權重是你自行下載、自行代管的。我們能替你消除的，是比較另一端的摩擦：在你自己的測試框架中替換候選模型，而不需要第二份合約、第二套 SDK，或第二組憑證。

誠實的總結是，61.5 這個數字是做出它的實驗室扎實的真實成果，而且它目前是在程式編寫方面偏好 FrogNano 的唯一理由。當 Microsoft 以外的人在同一批 500 項任務上重現 61.5——或無法重現——這場對決才會得到真正的答案。在那之前，對多數團隊而言更安全的預設選擇，是那個擁有乾淨授權、已公布長上下文量測，且其他人在二十週內的錯誤早已被吸收進其文件的 11.95B 模型。