FrogNano-4B-2609 對比 Qwen 3.8：當權重屬於你時，編碼代理要付出多少成本

microsoft/FrogNano-4B-2609是一款源自 Qwen3.5-4B 的四十億級儲存庫代理，由你自行下載並架設服務。Qwen3.8-Max則是託管的旗艦版本——一個 2.4 兆參數的稀疏混合專家模型，每個詞元約有 950 億個參數處於作用中，具備一百萬詞元的多模態視窗，費率為每百萬輸入詞元 2.00 美元、每百萬輸出詞元 6.00 美元——自 2026 年 8 月 3 日起可透過 API 金鑰存取。其中一個要耗掉一張 GPU 和一個下午。另一個在使用之前完全免費，之後則按詞元計費，而且是在最常見的長軌跡上收費。這項取捨，而非基準測試表格，才是真正的對決。

這裡的 FrogNano 數據來自 Microsoft 的模型卡與技術報告；Qwen3.8-Max 的數據則來自 Alibaba 公布的定價，以及我們自家目錄中的模型紀錄，而獨立評分無論出現在何處，都會標示為 Artificial Analysis 的數據。請仔細留意命名：開放權重版本 Qwen3.8 已經發布但尚未推出，而 Qwen3.8-Max 則已上線並於今日定價。本文中所有可呼叫的，都是後者。

決定比較結果的算術

先從單一任務的成本談起，因為這並不明顯，而且也不小。

FrogNano 的評估以 150 步的預算執行每一條軌跡，整體落在約 131K 的合計 token 之內，每個助理回合最多生成 8,192 個 token，並有 10,800 秒的上限。把兩個已公布的上限相乘，就會得到單一最壞情況軌跡約 123 萬個生成 token 的上限——而以 Qwen3.8-Max 每百萬輸出 token 6.00 美元計算，對於單一一個跑到預算用盡的任務，大約是 7.38 美元。那是對兩個已公布數字所做的算術，不是一項實測：真實軌跡會提早停止，平均值遠低於上限，而且工具結果與 shell 輸出是以較便宜的輸入費率計費，而非輸出費率。但它確立了這件事的樣貌。一個程式設計代理不會在一道問題上花費幾百個 token；而是會花上一段漫長、推理密集的自我對話，而那段對話的每個 token 都是生成出來的。

現在把帳本的另一邊並列在它旁邊。FrogNano-4B-2609 是 9.32 GB 的 BF16 權重，分成兩個分片，無需申請即可下載。要部署它，需要 SGLang，搭配 Qwen3 推理剖析器與 Qwen3 coder 工具呼叫剖析器，還要為這五個工具準備一個隔離沙箱。在那之後，一條軌跡的邊際成本就是電力，而它佔用的記憶體取決於你的上下文成長到多大，而不是權重有多重。

• 成本模型 — FrogNano-4B-2609 是固定硬體成本，邊際成本近乎為零。Qwen3.8-Max 則是零固定成本、按 token 計費，採用 $2.00 / $6.00 的價差結構，前期不預付任何費用，所有成本都後置到輸出費率上。

• 這筆錢能換來什麼——在自己的晶片上運行一個 4B 級代理，對比一個你永遠不必為其規劃容量的前沿規模模型。

• 損益兩平 —— 當你每月的軌跡量乘以每條軌跡的平均 token 費用，超過你原本得租用的 GPU 成本時，就到了損益兩平點。對於每天執行少量儲存庫任務的團隊來說，距離那條線還遠得很，光是圖方便，託管模型就勝出了。

兩個不從事相同工作的模型

唯有在產出可相互比較時，成本比較才稱得上公平；而在這裡並非如此，而這正是大多數規格表所刻意埋沒的重點。

FrogNano-4B-2609 僅以儲存庫層級的軟體工程進行後訓練。它的整個介面是一個五工具迴圈——Read、Write、Edit、Glob 與 Bash——由 Leaf 執行框架在隔離沙箱中執行，反覆迭代直到模型停止呼叫。Microsoft 的資訊卡指出其支援語言為英文，已驗證的程式設計領域為 Python，並直接說明檢查點中的圖像與影片元件從未進行後訓練，且不受支援。它不會推理你的架構、回答有關你業務的問題，或讀取螢幕截圖。

Qwen3.8-Max 是一個通用模型。阿里巴巴的型錄紀錄顯示，它支援文字、圖像與影片輸入，輸出文字，並具備 1,000,000 個 token 的上下文視窗。它能推理、寫作、閱讀文件並進行對話，而它的函式呼叫是通用模型的一項功能，而非這個檢查點的整個重點。根據 2026 年 9 月 2 日紀錄所載的 Artificial Analysis 數據，其 Intelligence Index 為 45.4，Coding Index 為 76.2。

• 輸入 — FrogNano-4B-2609 僅支援文字。Qwen3.8-Max 接受文字、圖像和影片。

• 上下文 —— FrogNano 受測配置約為 131K 合併 token，而 Qwen3.8-Max 則是 1,000,000。這是 7.5 倍的差距，而它最關鍵的地方，正是在於 coding agent 所拿到的那種等同整個儲存庫規模的輸入。

• 每回合輸出 —— FrogNano 經過驗證的配置，將單一助理回合的上限設為 8,192 個 token。Qwen3.8-Max 則未公布任何等同的每則回應上限。

• 輸出格式 — FrogNano 發出結構化的 Leaf 工具呼叫，並需要一個執行框架來執行它們。Qwen3.8-Max 則傳回散文或對你現有客戶端的函式呼叫。

• 獨立評分——FrogNano-4B-2609 除了自身的模型卡之外，別無其他；上述 Qwen3.8-Max 的數據屬於第三方，來自 Artificial Analysis。

• 參數 — 依 FrogNano 自身說明卡的描述約為 4.66B，相較之下 Qwen3.8-Max 總參數量達 2.4 兆、啟用參數約 95B。

4B 真正證明其價值的地方

有一個維度上，4B 代理能徹底勝過前沿模型，而那並不是準確度。

FrogNano 的論文從 Qwen3.5-4B 出發；這個模型以一般通用模型之姿，透過 Leaf harness 在 SWE-bench Verified 上取得 39.4% 的成績。在大約 1,500 項合成任務上進行五輪強化學習迭代後，成績提升到 61.5%，而同一篇論文的附錄則列出逐次迭代的進展為 48.2%、53.4%、58.3%、58.6% 與 61.6%。這套方法——產生校準至當前策略可學習性前沿的任務，且不從更強的模型進行蒸餾——正是其貢獻所在，也是沒有前沿模型預算的研究團隊會關注它的原因。

看看這對比較意味著什麼。微軟的模型卡坦率指出，FrogNano 並非全面優於它所衍生的模型：它的平行工具呼叫率是 1.71%，因為後續迭代失去了觸發並行呼叫的能力，團隊因此加入了一個整併階段試圖挽回。一個能解決更多問題、卻在某項特定行為上退步的模型，是帶有明顯接縫的真實工程產物，而它的模型卡直言不諱，而不是把這件事埋起來。

而 SWE-bench 的數字是一個封閉迴路。基礎模型基準、評測框架與最終分數全都出自同一個實驗室，而且同一篇論文的兩張表對同一個實驗給出了兩套不同的階梯。相較之下，Qwen3.8-Max 的程式編碼數據是由 Artificial Analysis 而非 Alibaba 產出的——證據的種類不同，信心的種類也不同，兩者絕不應互相扣減。

那個你還無法完全規劃因應的 4B

有兩件事橫亙在 FrogNano-4B-2609 與正式上線的席位之間，而這兩件事都存在於它自家的文件裡，而非任何審查者的意見中。

首先是硬體。模型卡給出的 BF16 權重需求約為 9.3 GB，接著補充說，當合併上下文接近約 131K 個 token 時，記憶體會「大幅增加」，然後才表示確切的最低 GPU 型號、VRAM 配置、執行階段版本與效能設定檔「仍須在發布前驗證」——而這句話卻出現在一個已經可下載的模型上。沒有人公布受評估配置的 VRAM 數字，而模型卡也沒有包含這項數字。

第二點是安全態勢。微軟自家的對齊說明指出，針對代理的後訓練並未使用任何安全偏好、拒絕、有害或冒犯性資料集，而是改為以功能正確性和避免回歸為優化目標，且該模型「不應被視為已完全安全對齊，可用於無限制部署」。模型卡最後列出了具體風險：修補程式可能不正確或不安全，即使它們通過了測試；效能對這些測試的品質很敏感；且每個候選修補程式在使用前都需要合格的人員審查，以及回歸與安全測試。一般的託管模型不具備任何這些特定保證，而且它也不會在你的儲存庫中執行 shell 命令。

無論你選哪一方，只需一把鑰匙

在實務上跑這項比較的好處在於，其中只有一半——Qwen3.8-Max，以及你會拿來對自架代理做基準測試的那些通用模型——全部都可以透過 OrcaRouter 上相容於 OpenAI 的端點存取，以 0% 加成——供應商的定價原樣轉嫁，所以供應商一調價，當天就會落到我們這一端；而當你想控制的正是編碼代理的輸出 token 帳單時，這個數字才是真正會變動的那個。這也讓容錯移轉的問題變得簡單：如果你這條流程中代管的那一半效能變差，重試會自動發生，實驗也就繼續下去。

FrogNano-4B-2609 不是我們的路由之一，也沒有排定日期。權重由你自行部署提供服務，而模型卡也誠實說明服務配置尚未經過完整驗證。我們能做的是讓比較的另一邊零成本就能設定好，這樣你最終要回答的才是真正的問題——在你自己的 GPU 上，一個供應商回報 61.5% 的 SWE-bench 代理，是否能在你自己的任務、你自己的用量下，勝過一個按用量計費的前沿模型。

該選哪一個

當工作屬於一般性質、當該由別人的營運團隊來扛容量、當輸入可能包含圖片或長篇文件，或是當你今天就要答案、而不是等到週五才生出一套服務堆疊時，就選用 Qwen3.8-Max。它的第三方評測分數意味著你能大致預測自己買到的是什麼，而它的每 token 帳單則是在你做出承諾之前就能看見的變動成本。對一個每月只執行少量儲存庫任務的團隊來說，這筆帳根本不用比。

當用量高到讓長軌跡的逐權杖計費成為限制時，當資料不能離開你的基礎設施時，或當你真正要測試的研究問題——小型代理能否在沒有教師的情況下被訓練到具備儲存庫層級的能耐——就是這個問題本身時，就選擇 FrogNano-4B-2609。進去之前要知道三件事：61.5% 是實驗室自己在實驗室維護的測試框架上測得的數據；沒有人發表過受評估配置的 VRAM 數字；而且模型卡本身也說服務設定尚未經過驗證。

這組配對之所以值得書寫，在於它們共享兩代之前的同一個祖先。FrogNano 源自 Qwen3.5-4B——那是同一家公司的通用模型，而其 2.4 兆參數的旗艦模型就坐落於本頁的另一側。微軟拿走了小的那個，在合成儲存庫上進行了五輪 RL 迭代，得到了一個專才模型。阿里巴巴走了另一條路，朝規模化發展。兩種答案都已公開，而下載成本與 API 成本之間的落差，正是在兩者之間做選擇時最誠實的方式。