Flint v1.0 對上 North Mini Code：兩款開源程式設計 MoE 模型爭奪你的筆電

本站大多數「對比」頁面，配對的都是從未真正互為競爭對手的東西。這一篇不同。Recursive Flint v1.0與Cohere North Mini Code屬於同一類物件：稀疏混合專家程式碼模型，以 Apache 2.0 授權發布，小到能在開發者現有硬體上運行，且兩者都被定位為本地選項，而非前沿選項。Flint 於 2026 年 10 月 21 日推出，總參數 398 億，每個 token 約 25 億活躍參數。North Mini Code 於 2026 年 6 月 9 日推出，總參數 300 億，活躍參數 30 億。兩者如此接近，選擇取決於模型檔案裡有什麼，以及實際測量了什麼——而在這兩方面，答案都不是發布報導所暗示的那個。

這兩個檔案，逐個維度

先從盒子裡有什麼開始，因為對兩款自託管模型而言，這才是經得起現實考驗的比較。

• 總參數 — Flint：39.8B。North Mini Code：30B。

• 每個 token 的活躍參數 — Flint：約 2.5B，其中 2.2B 在主體，其餘在輸出頭。North Mini Code：3B。兩者幾乎相同，而這正是決定推論成本的數字。

• 專家路由 — Flint：256 個路由專家，每個 token 選取 6 個，外加 1 個共享專家，涵蓋 47 個 MoE 層與 2 個稠密層。North Mini Code：128 個專家，每個 token 啟用 8 個。

• 注意力 — Flint：帶有注意力匯點的滑動視窗層與全域層混合架構。North Mini Code：滑動視窗與全域的比例為 3:1。兩者都在押同一個賭注：大多數 token 只需要局部注意力，少數則需要整個視窗。

• 上下文 — Flint：模型卡上記載為 262,144 個 token，公告則提到最高可達 512K，並建議使用 256K。North Mini Code：輸入 256K，最大輸出 64K。

• 模態 — Flint：文字輸入，文字輸出。North Mini Code：文字輸入，文字輸出。兩者皆不支援圖像，若你的工作涉及螢幕截圖，這點就很重要。

• 授權 — 兩者皆為 Apache 2.0，包含權重，無營收門檻。

• 已發佈格式 — Flint：BF16、int4 safetensors、int4 GGUF、NVFP4 GGUF。North Mini Code：BF16、FP8 與 W4A16。

• {{1}}磁碟與記憶體{{/1}} — {{2}}Flint{{/2}}：BF16 格式為 79.59 GB，NVFP4 格式為 22.86 GB，執行時約需 24 GB 記憶體。{{3}}North Mini Code{{/3}}：量化後約 20 至 24 GB，而 {{4}}Cohere{{/4}} 自家的示範在 Mac Studio 上以約 20 GB 執行。

記憶體是第一道關卡，而它比參數量所暗示的還要更近。

對 39.8B 與 30B 的直觀解讀是 Flint 需要多三分之一的記憶體。事實並非如此，因為兩者都是稀疏模型，且都推出了積極的量化版本。你實際上是在一個 22.86 GB 的 NVFP4 檔案與一個約 20 GB 的量化版本之間做選擇——兩者差距小到同一張 24 GB 顯示卡都能執行其中任何一個，也小到單憑佔用空間來看，兩者都不是明顯的首選。

差別在於餘裕空間。據報導，North Mini Code 可在搭載 32 GB DDR4 的 Ryzen 7 上執行 4-bit GGUF——那是一台真正普通的桌上型電腦，而非工作站。Flint 對筆電的說法則更具體：Recursive 的吞吐量數據是在 M4 Pro MacBook Pro 與 64 GB RTX Spark 上測得的，兩者都是高階機器。22.86 GB 的檔案能在 24 GB 的顯示卡上載入。至於它是否能以你能忍受的速度執行，則是另一個問題，而且很大程度上取決於引擎。

如果你的限制是「我已經擁有的機器」，North Mini Code 有更多在普通硬體上運行的回報。如果你的限制是「我擁有的最好機器」，Flint 的架構較新，而且在短上下文下更快。

其中之一有獨立的計分板

這是多數評測文章略過的部分，而這正是應該決定採購結果的部分。

North Mini Code 已由 Artificial Analysis 進行評測。它在 AA Coding Index 上得分 33.4，在 AA Intelligence Index 上得分 27.6；SWE-bench Verified 為 67.6 pass@1 與 80.2 pass@10，mini-SWE-Agent 則為 61.0。這些是在一致協定下產生的第三方測量結果，意味著它們可以與同一指數上的其他模型相比，而無需加上關於評測框架的註腳。

Flint 在 Artificial Analysis 上沒有收錄條目。其公布的分數——SWE-bench Verified 74.2、SWE-bench Pro v2 89.7、Terminal-Bench 2.1 54.9——來自 Recursive 自家的測試框架，且沒有人重新執行過。方法論有公開，這點值得肯定：SWE-bench 各項測試使用 mini-swe-agent 且無網路連線；Terminal-Bench 使用 Terminus 2 並有網路連線，但任何從網路取得的解答都算作失敗；pass@1 取至少五次嘗試的平均值。公開方法論不等於經過驗證的方法論。

所以你能把 67.6 和 74.2 相比嗎？不能負責任地比。它們是由不同組織、在不同測試框架上、依不同規則產生的，而 6.6 分的差距，穩穩落在光是測試框架選擇就能造成分數變動的範圍內。你能說的更狹窄但仍有用：North Mini Code 的數字已由未參與打造該模型的人核查過，而 Flint 的則沒有。如果你是根据證據而非規格來做選擇，那才是真正重要的不對稱。

North Mini Code 這一欄還有一個不光彩但值得掌握的資料點：Artificial Analysis 指出它異常冗長，測試時消耗約 7,500 萬個輸出 token，而同類模型中位數接近 2,500 萬。在代理迴圈中，冗長程度是成本乘數。一個「思考出聲」量達三倍的模型，可能每個 token 更便宜，但每項任務更昂貴。

在長上下文中，速度表現會完全改變。

兩個模型在短提示下都很快，而當上下文填滿時，兩者都會變慢。差別在於變慢的程度。

• Flint — Recursive 宣稱在 M4 Pro MacBook Pro 上可達到每秒 125 個以上的 token，而在 64 GB 的 RTX Spark 上可超過 150，這些數據是在短上下文中測得，且不計入預填充（prefill）時間。獨立測試則回報，短提示下約為每秒 110 個 token，但當上下文接近 115,000 個 token 時，會降至大約每秒 9 個 token。這正是你設計代理（agent）時該據以規劃的數字，因為代理式編碼（agentic coding）絕大多數時間都處於長上下文的狀態。

• North Mini Code — 在 Cohere 的 API 上，每秒約輸出 199 至 210 個 token，首個 token 約需 0.25 秒，且在相同測試中，吞吐量約為同級小型模型的 2.8 倍。在本機硬體上，數字完全取決於你的引擎與量化方式，但模式相同：短上下文時速度快，隨著視窗填滿而變慢。

誠實的比較不是「哪個比較快」，而是「哪個比較快，取決於 agent 實際運作的方式」。一個模型在 4K 上下文下用 8 毫秒寫出一個 token、在 115K 下用 110 毫秒，這與另一個衰退得更平緩的模型，是截然不同的產品。兩家廠商都沒有公布曲線。如果長上下文 agentic 工作是你的使用情境，在做決定前，先在你自己的儲存庫上實測——這只需一個下午，而它告訴你的會比兩篇發布文章都多。

動能與新鮮感

North Mini Code 在 2026 年 8 月中突破 15 萬次下載，距離發布僅兩個月。這是個明確訊號：一款採用度這麼高的模型，曾被運行在其作者從未測試過的硬體上，已在社群中累積修正，其未完善之處也已被那些沒有理由手下留情的人記錄下來。Cohere 報告了這個數字，因此請將該數字視為廠商提供，但其趨勢可由流通中的衍生量化版本數量獲得佐證。

Flint 問世才四天。它有更亮眼的主打規格、更快的短上下文解碼、更長且有文件記載的上下文視窗，以及更有趣的開發故事。但它在 llama.cpp 的 GGUF 路徑中也有已知的聊天範本錯誤、在長上下文下出現無人解釋的吞吐量斷崖，而且幾乎沒有社群歷史。早期採用一款才四天大的模型，是在押注它的發展軌跡，而不是在評估這個成品。

週一該下載什麼

• 如果你想要附有獨立評分的模型、硬體規格普通、你的任務是在能輕鬆放入上下文的儲存庫中進行一般軟體工程，而且比起較新的架構，你更重視兩個月的社群錯誤回報，那就選 North Mini Code。要預期它會比較冗長。

• 如果你有高階筆記型電腦或 24 GB 顯示卡，想要更長的上下文視窗，短上下文速度才是你的工作流程實際會用到的，而且你願意當早期採用者，以換取一個一個月後很可能更好的模型，就選 Flint。

• 不要把兩者中的任何一個當成你的唯一選項。兩者都是 2.5 到 3B 活躍參數的模型。它們擅長範圍明確的任務，但它們不是前沿的程式設計助理，而 Recursive 對自家模型也是這麼說的。兩者都做不好的工作，正是需要託管式前沿模型的工作——而合理的架構是以本地模型為預設，並具備升級路徑，而不是要求單一模型什麼都包辦。

這條升級路徑正是路由發揮價值的地方。OrcaRouter 並未提供這兩個模型，所以這裡不是在替通往它們的路線打廣告。路由層對本地優先架構的作用是另一個方向：它讓你可以把需要更大代管模型的任務，組成同一條呼叫路徑，並針對本地模型停滯或上下文溢出的請求，提供備援鏈。配置得當的話，本地模型會處理例行工作，只有在確實需要時才會觸及昂貴的模型——這是這套架構唯一能省錢的做法。

無聊的答案才是正確的。這兩個檔案都是免費的，而且都能在你大概已經有的硬體上執行；要知道哪一個更適合你的儲存庫，唯一的方法就是在你的儲存庫上把兩者都試一遍。它們之間的基準測試差距，比它們任一個和你實際工作負載之間的差距還小。