一張生成的標題卡,寫著「FrogNano-4B-2609 vs LFM2.5 2.6B Base」,副標題為「一個完成訓練的 4B 代理對上一個 2.69B 的預訓練檢查點」,三個標籤分別寫著「RL 後訓練已完成」、「僅經預訓練,30 層的 2.69B 稠密模型」以及「未經指令微調」,頁腳寫著「兩欄皆為廠商自行回報;沒有任何第三方對這兩個模型評過分」,右下角還合成有 OrcaRouter 標誌。
Engineering & Research

FrogNano-4B-2609 對比 LFM2.5 2.6B Base:一個已完成的專才模型,以及一袋預訓練權重

作者

Elias Hawthorne

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

在 LFM2.5 2.6B Base裡輸入一個問題,它會接續你的句子,而不是回答你。這並非瑕疵——Liquid AI 將它發布為 LFM2.5 家族底下的預訓練檢查點,刻意把指令微調留給非 Base 的兄弟模型,而模型卡也明白指出它是要供重度微調使用的。微軟的 FrogNano-4B-2609則展現了那條流程另一端的面貌:同類型的小型語言模型,在合成儲存庫任務上經過五輪強化學習,直到它能透過五工具框架輸出結構化的工具呼叫與候選修補程式。這兩者都沒有公開的獨立基準測試。差別在於,其中一個已經完成後訓練,而知道是哪一個,就是整個決策的關鍵。

下方 FrogNano 的數字來自 Microsoft 的模型卡與技術報告。LFM 的數字則來自 Liquid AI 的模型卡、其架構設定,以及授權條款檔案。歸屬於任一廠商的每個數字都標示為廠商回報,且這兩個模型都未經過第三方評估——就 LFM2.5 2.6B Base 而言,這在很大程度上是刻意如此,因為未經指令微調的檢查點並非對話基準測試的公平對象。

比較只有在你知道自己在比較什麼時才有效。

把兩份規格表並排放,第一個出問題的就是參數量。LFM2.5 2.6B Base 在 30 層中擁有 26.9 億稠密參數——22 個雙閘控短卷積區塊與 8 個分組查詢注意力層,以約 34 兆個 token 訓練而成,涵蓋 16 種語言,詞彙量為 128,000 個 token,上下文長度為 131,072 個 token。其量化版本在 Q4_K_M 下約為 1.67 GB。

FrogNano-4B-2609 的模型卡將其參數欄位標為「500M-5B」這個範圍,而模型摘要則描述它約為 46.6 億。下載內容終結了這場爭論:兩個 safetensors 分片,總計 9.32 GB 的 BF16 權重、738 個張量,建立在一個沿用而來的稠密 32 層混合 Gated DeltaNet 與閘控注意力堆疊上。檢查點中有一個 24 層視覺塔,且從未經過後訓練。

所以大小比例大約是 1.7 比 1,而一旦把量化納入考量,記憶體比例更接近 5.6 比 1。這個差距比參數數字更重要,因為這兩個模型都是可自架設的候選方案,而不是端點——這也是它們唯一該被放進同一篇文章的原因。

• 預期用途 — LFM2.5 2.6B Base 是微調作業的原料。FrogNano-4B-2609 則是在 Leaf 框架內執行儲存庫層級軟體工程的成品策略。

• 指令遵循 — LFM2.5 2.6B Base 開箱即用時完全不具備這項能力;Liquid AI 的模型卡建議將其用於需要大量微調的任務。FrogNano-4B-2609 能遵循任務描述並輸出結構化的工具呼叫,因為這正是其 RL 目標所訓練的內容。

• 上下文 — LFM2.5 2.6B Base 為 131,072 個 token,而 FrogNano 受評估的組態合計約為 131K 個 token。名義上完全相同,但 FrogNano 的視窗必須容納工具結果、shell 輸出與測試記錄,而不只是一段提示詞。

• 輸出上限 — FrogNano 已驗證的配置允許每個助理回合生成 8,192 個 token。LFM2.5 2.6B Base 並未公布同等規格,因為它並非設計用來結束回答。

• 模態——兩者皆僅限文字。FrogNano 的視覺元件為繼承而來,且明確不受支援;LFM2.5 2.6B Base 在設計上即為文字輸入、文字輸出。

• 授權條款 — LFM2.5 2.6B Base 採用 LFM Open License v1.0,年營收低於 1,000 萬美元時可免費使用,達到或超過此門檻則需另行取得授權,且衍生作品亦繼承此營收上限。FrogNano 的模型卡在前言寫 MIT,內文則寫 Apache 2.0。

Microsoft 付費取得的東西,以及你必須自己付費的東西

這是最關鍵的一段,因為正是在這裡,規格比較會造成誤導。

FrogNano-4B-2609 的全部附加價值在於後訓練,而微軟已將該方法公開。從 Qwen3.5-4B 出發,它作為通用模型在 Leaf harness 下於 SWE-bench Verified 拿到 39.4%。從真實快照生成候選儲存庫任務,從當前檢查點執行 rollout 以找出它偶爾能解出的任務,保留這些任務、訓練,然後重複——五輪迭代,總計約 1,500 個經驗證的合成環境,而且全程完全沒有從更大的模型進行蒸餾。微軟自家模型卡上的結果是 SWE-bench Verified 61.5%、SWE-bench Pro 37.6%、Terminal-Bench 2.0 31.1%,以及 PatchEval-Verified 47.3%。論文的效率附錄把同一段攀升記錄為跨迭代的 48.2%、53.4%、58.3%、58.6% 與 61.6%,這是有用的提醒:即便是該實驗室自己針對同一實驗所做的兩份表格,對各級階梯的數字也並不一致。

現在把這對照 LFM2.5 2.6B Base 來讀。它是在那項工作開始之前的檢查點。它模型卡本身的建議——對它進行微調——正是 FrogNano 所記錄的工作:一個任務環境、一個可執行的獎勵、一個長時間服務的測試框架,以及針對變動策略的數次訓練迭代。該論文並未聲稱這很容易。它報告指出,隨著推理軌跡變長,中間檢查點的訓練成本逐漸變得更高;必須加入日誌長度懲罰以阻止漂移;而後續迭代失去了基礎模型原本具備的平行工具呼叫能力,最終並行呼叫率降至 1.71%。任何打算在不同的 2.6B 基礎模型上執行 FrogNano 配方的人,都應特別為這三個問題預留資源。

LFM2.5 2.6B Base 所帶來的是另一種先機:34 兆 token 的預訓練預算、有文件記載的混合架構、現有的量化版本,以及有文件記載的 131,072 token 上下文,而這一切都在一個尺寸下,能在 9.32 GB BF16 檢查點無法容納的硬體上運行。如果你的任務足夠狹窄,使得小型微調能勝過通用模型,那是一個真實的定位——而如果不是,你就省下了一次訓練。

A generated two-column scoreboard titled 'FrogNano-4B-2609 vs LFM2.5 2.6B Base'. The left column reads State RL post-training complete, Params approx 4.66B with the card saying 500M-5B, Weights 9.32 GB BF16, Context about 131K evaluated, Licence MIT in front matter and Apache 2.0 in body, Independent scores none. The right column reads State pretrained checkpoint only, Params 2.69B dense, Weights 1.67 GB in Q4_K_M, Context 131,072 tokens, Licence LFM Open License v1.0, Independent scores none. A footer reads 'Both columns vendor-reported; no third party has scored either model.'

無論如何你都必須打造的東西

這兩者都不是網路呼叫,而這一點對實際比較的形塑作用,遠勝過任何一項規格欄位。

LFM2.5 2.6B Base 需要一個推論執行環境,也需要一次訓練運行。Liquid AI 的模型卡列出了原生格式、GGUF、ONNX 與 MLX 版本,因此 serving 那一半已有完善的涵蓋——對量化檢查點而言,在筆電上跑 llama.cpp 是真實可行的選項。訓練那一半則由你負責:資料、目標、評估,以及一套能判斷結果是變得更好,還是只是變得不同的方法。

FrogNano-4B-2609 想要一個與 OpenAI 相容的端點,配備正確的解析器,以及一個有權管理 pod 與網路政策的 Kubernetes 叢集。Microsoft 的 README 異常直白地指出,測試框架是一項相依性,而非便利措施,而模型卡也表明,完全相同的分數需要相符的檢查點、分詞器、服務配置、任務映像與評估協定。配置在這裡絕非細節——若在服務時未搭配 Qwen3 推理剖析器與 Qwen3 程式碼工具呼叫剖析器,模型就會在測試框架預期工具呼叫的地方寫出散文。

這就是這場對決的樣貌:一邊是有個小服務問題的訓練專案;另一邊是有個大評估問題、且已無訓練可做的服務專案。兩者都是幾個晚上的工作量。只有其中一者,是那種可能最終以「模型不夠好」收場、而且錯不在你的幾個晚上工作量。

A screenshot of the Hugging Face model card for microsoft/FrogNano-4B-2609 showing the model summary table with the Parameters row reading 500M-5B, the Context length row reading approximately 131K tokens in the evaluated coding-agent configuration, the Training Dates row reading Jun 2026 to Aug 2026, the Release date row reading 22-SEP-2026, the License row reading Apache License 2.0, the Qwen/Qwen3.5-4B model dependency, and the model overview naming the dense 32-layer hybrid Gated DeltaNet and gated-attention architecture.

在這樣的組裝中,路由器如何贏得一席之地

這兩個模型最終都會進入同一條管線,而該管線也會呼叫某個託管服務。FrogNano 自家的評估設備就是證明:Leaf 測試框架會與一個 OpenAI 相容端點通訊,這意味著受測模型以及任何你拿來與其比較的模型,都是透過同一個介面存取。這是個值得仿效的模式,即使理由只是為了保持整潔也一樣,而這正是單一端點能做出具體貢獻的地方。

OrcaRouter 以單一 OpenAI 相容金鑰提供 200 多款模型,且零加成,因此供應商的定價原封不動地直接傳遞,而廠商調價當天就會在我們這邊生效——當你在評估自架專門模型是否在每項任務成本上勝過託管通用模型時,真正會變動的正是這個數字。自動容錯移轉涵蓋的是這項比較中託管的那一半,而不是你自己在服務的那個檢查點。我們不託管 FrogNano-4B-2609 或 LFM2.5 2.6B Base;兩者都是供下載的。路由層所消除的,是每當你基準測試中託管的那一側變更時所需的第二次整合。

老實說,選一個

如果你的任務範圍狹窄、硬體規模很小,而且你準備好自行扛下整個訓練流程,就選擇 LFM2.5 2.6B Base——授權在營收低於 1,000 萬美元時免費,量化版本為 1.67 GB,而 Liquid AI 自家的模型卡正是為此推薦它。代價是:你得到的是一個起點,而不是一項能力——發佈內容中沒有任何資訊能告訴你,在它之上跑一輪 FrogNano 形態的 RL 訓練會拿到什麼分數,而且也沒有人發表過這樣的結果。

如果任務是儲存庫層級的軟體工程,而且你希望後訓練已經完成,就選擇 FrogNano-4B-2609。61.5%、37.6%、31.1% 和 47.3% 是來自一個詳細描述其方法的實驗室的真實已發表結果——而且它們此刻也是一個閉環:同一個實驗室、同一套測試框架、同一個基礎模型基準。9.32 GB 的下載、測試框架相依性以及複合授權,是跳過一個你原本必須執行的訓練專案所需付出的代價。

A generated pipeline card headed 'The same pipeline, two positions' showing three stages connected by arrows: 'Pretrained checkpoint' captioned LFM2.5 2.6B Base, 'RL on synthetic tasks, 5 iterations' captioned Microsoft's loop, and 'Finished agent' captioned FrogNano-4B-2609, with a footer reading 'Neither model has been independently evaluated; both appear as vendor-reported figures only.'

有用的重新框架是,這兩者並非競爭對手。LFM2.5 2.6B Base 是某個流程的上游,而該流程產出了類似 FrogNano-4B-2609 的東西。如果你發現自己在兩者之間做選擇,真正的問題是:你的問題是否值得你為它投入一次訓練運行——而如果答案是否定的,那麼那個附帶測試框架、已發表方法與廠商回報的 SWE-bench 階梯的 4B 檢查點,才是到手即完成的那一個。