Recursive Flint 40B-A2.5B：一個以速度為先的程式設計模型

決定Recursive Flint 40B-A2.5B是否值得佔用你磁碟空間的數字，不是 54.9%，而是 2.5。Recursive 首個開放權重程式碼模型擁有 398 億個參數，且每生成一個詞元就喚醒其中約 25 億個參數；這次發布中幾乎所有其他決策——注意力配置、量化配方、自訂 Metal 核心、推論引擎——都源自那個比例。Flint 於 2026 年 10 月 21 日 以 Apache 2.0 推出，這使它在撰寫本文時才問世一天，正處於發布仍算新聞而非歷史的窗口期。因為才問世一天的基準測試表是承諾而非測量，我們將生產紀錄另行保存：AI Incident Archive 記錄了模型與供應商的說法在開始服務真實流量後是否經得起考驗。

給現在就要做決定的人一個簡短版：它是一個稀疏混合專家模型，目標是在筆電上成為同級中最快的；它公布了三項代理式編程分數，而這些分數全都是廠商自行提報且未經重現；它還是一家公司推出的首個模型，而該公司明言其目標是自動化打造模型的研究。這三項事實都很重要，而第三項在一年後仍會值得關注。

實際發佈的內容

四個儲存庫，而不是一個。主要的 RecursiveSI/flint 儲存庫包含 BF16 檢查點、設定、分詞器、聊天範本與 SGLang 服務套件，且建立於 2026 年 10 月 21 日 14:20 UTC。旁邊還有三個量化變體，全部都在同一天下午建立：一個 int4 safetensors 版本、一個 int4 GGUF，以及一個 NVFP4 GGUF。以下每個大小都是從各儲存庫自身的檔案清單測量而來，而非引用自公告。

• BF16 參考版本 — 共 37 個檔案、總計 79.59GB，分成 15 個 safetensors 分片，每片約 5.37GB。這是微調的產物，也是你不會想為了推論而下載的那一份。

• NVFP4 GGUF — 單一檔案 22.86GB，是目前已發布最小的完整推論版本。

• Int4 GGUF — 25.99GB，一種 q4_1 量化，檔案比 NVFP4 檔還大；這與命名順序相反，在依檔名挑選前值得先知道。

• Int4 safetensors — 22.58GB，適用於偏好分片權重而非單一 GGUF 的執行環境。

授權為 Apache 2.0，模型卡另外區分：託管 API 條款與資料實務有別於權重授權——這是常見的拆分方式，且明白寫出，而非埋沒其中。

這個架構是關於記憶體頻寬的論點

在筆記型電腦上，解碼一個詞元主要不是運算問題。問題在於如何夠快地把權重從記憶體搬到算術單元；這就是為什麼一個 400 億參數的稠密模型無論晶片多好都會很慢：每產生一個詞元，都要讀取每一個權重。Flint 的答案是幾乎不讀取其中任何權重。

• 稀疏性 — 每個 MoE 層有 256 個路由專家，每個詞元選用其中 6 個，另加一個始終啟用的共享專家。49 層中有 2 層為稠密層，47 層為 MoE 層，因此除最前兩層外，其餘各層都在執行條件式運算。

• 活躍參數 — 總計 39.8B，計入輸出頭後，每個 token 約有 2.5B 活躍參數，這正是「40B-A2.5B」這個標示的由來。僅活躍主體本身就約有 2.2B。

• 重點 — 35 個滑動視窗層，視窗大小為 513 個 token（當前 token 加上前 512 個），與 14 個完整注意力層交錯排列。僅有 32 個查詢頭與 4 個鍵值頭，頭維度為 128，因此 KV 快取得以維持在夠小的規模，讓長時間的代理工作階段切實可行。

• 位置編碼——滑動視窗層使用旋轉嵌入，全注意力層則完全沒有使用；模型卡陳述了這項選擇，卻未加以解釋。每頭 QK RMSNorm 與可學習的每頭注意力匯點，正承擔位置編碼通常分擔的穩定性工作。

• 背景說明——文件記載的上下文長度為 262,144 個權杖（token），而模型卡明確指出，這個數字涵蓋提示（prompt）與生成輸出兩者。公告宣稱「最高可達 512k」，隨後又建議在撰寫程式碼時維持在 256k 以內。這兩項說法出自同一家廠商，而且只相隔一個段落。

有趣的細節在於這個配置比例是怎麼選出來的。Recursive 表示，其 Eureka Machine——一個自動化研究迴圈，會提出想法、實作、測試，並把有效的做法組合起來——從一個 350 億參數、30 億活躍參數的基線開始，並在各種專家配置與寬度之間搜尋。最終得到的 40B/2.5B 配置，用公告自己的說法，是「在我們 Eureka Machine 測試過的配置中，預計能提供速度與程式設計效能的最佳組合」。是「預計」，不是透過完成品模型之間的評比來證明。在訓練成本高昂時，這是挑選架構的正常做法；而這也是一種日後某個檢查點可能默默推翻的說法。

這三個分數，以及伴隨它們的註腳

Flint 在 Terminal-Bench 2.1 上得分 54.9%，在 SWE-bench Pro v2 上得分 89.7%，在 SWE-bench Verified 上得分 74.2%。這些數字以發布評估的形式出現在模型卡中，且尚無第三方公布對這個模型的測量結果——對於這類發布而言，Artificial Analysis 模型索引通常是獨立的裁判，但截至 10 月 22 日，它完全沒有 Flint 的條目。因此，以下所有內容都是 Recursive 在衡量 Recursive。

廠商就其自身方法論所披露的內容，比大多數發布文章主動提供的還要多，而這會改變這些數字應如何解讀：

• Terminal-Bench 2.1 — 以 Terminus 2 測試框架執行，啟用網際網路存取，而透過網路檢索取得的解答則計為失敗。最後這項調整是刻意設下的障礙；模型卡指出，其他開發者公布的成績可能並未採用這項調整，這使得與第三方數字進行同基準比較變得更加困難，而非更容易。

• SWE-bench Pro v2 與 SWE-bench Verified——以 mini-swe-agent 執行，且完全無法使用網際網路；相較於可在任務進行中搜尋文件的代理程式，這是更嚴苛的設定。

• 嘗試與逾時——在至少五次嘗試中取 pass@1 平均值，且代理逾時時間最長為五小時。取五次嘗試的平均值是合理的做法；五小時的逾時意味著這些分數是針對你願意讓它持續執行的代理，而不是針對自動補全。

• 取樣 — 在每次評估中，temperature 為 1.0、top-p 為 0.95、top-k 為 20，而當請求省略這些參數時，服務套件會套用這些預設值。

廠商的基準測試表也說明了它選擇了哪些同儕。Recursive 自家的圖表將 Flint 與 Qwen 3.5、Qwen 3.6、Qwen 3.8、Laguna XS 21、Muse Glimmer 和 Gemma 4 相比——這些是適合相似硬體的本地模型，對筆電模型而言是合理的同儕比較組，同時也是為了讓稀疏性論點顯得漂亮而挑選的組別。其主張範圍狹窄且站得住腳：Flint 在代理式程式設計上，於總參數低於 500 億的 MoE 模型中領先，並可與 250 億至 400 億的稠密模型匹敵，同時執行速度快得多。這並不是關於前沿程式設計模型的主張，Recursive 也沒有提出這種主張——公告直白表示，Flint「可能需要比你所習慣的更大閉源程式設計模型更多的引導。」

速度：2× 實際上是以什麼為基準衡量的

Recursive 在 M4 Pro MacBook Pro 上於短上下文情境下回報每秒超過 125 個 token，並在 64GB NVIDIA RTX Spark 上回報每秒超過 150 個 token，稱其速度最高可達同類模型的兩倍，且比具有相似程式設計分數、參數量為 250 億至 400 億的稠密模型快逾五倍。速度圖表上的方法論註腳才是值得細讀的部分：在 128,000 個 token 的整個工作階段中平均每秒 token 數，排除 prefill，且其中一家競爭對手僅測到 124k，而非完整長度。

排除 prefill 是解碼基準測試的標準做法，這在這裡仍然重要，因為當 coding agent 把整個儲存庫倒進上下文視窗時，prefill 正是它花時間的地方。一個只衡量 128k 工作階段中解碼那一半的數字，會讓任何採用稀疏激活的模型顯得更好看，而 Flint 的整體設計就是稀疏激活。這些都不會讓那個數字變錯。它只是讓它成為一個解碼數字，應該拿來和其他解碼數字比較，而不是拿來和你的 agent 完成一項任務要花多久比較。

量化配方是最容易轉移的部分

大多數量化文章談的是準確度流失了多少。這篇談的則是一個與慣例背道而馳的決定。

Recursive 將輸出層——lm_head——量化到 4 位元。這與常見做法背道而馳，原因則特定於稀疏模型：由於僅有 25 億個活躍參數，輸出層在每個 token 所讀取的權重中佔了很大比例，因此若讓它維持在 16 位元，就會限制模型可能達到的速度上限。要恢復準確率，需要一個離線蒸餾階段：在這個階段中，量化後的模型以自身從自行發現的核心集（coreset）預先取樣出的回應進行訓練，並以 16 位元模型作為教師——Recursive 表示，相較於其量化感知訓練基線，這樣的設定幾乎將訓練步數減半。

公布的結果是：最終 NVFP4 模型在整個基準測試套件中的得分，與 16 位元模型相差在 0.7 分以內。這是廠商的宣稱，而這類宣稱日後很容易查證、造假成本也很高，因此很值得拿來要求他們兌現。實務上的結果就是上述的檔案大小：22.86GB 的下載檔，能在具有 48GB 統一記憶體的機器上執行一個 398 億參數的模型。

在 Apple Silicon 上，這還有第二層。Recursive 的 Eureka Machine 為低位元投影、MoE 運算、注意力與提示處理打造了專用核心，其中包括一個 Metal 巨型核心，在 M4 與 M5 晶片上將整個解碼前向傳遞融合成單次 dispatch。融合解碼階段這類最佳化，只有在同時掌控模型架構、量化格式與核心時才會真正發揮效益——而這正是本次發布的真正主旨，勝過任何單一基準測試數字。

你如何執行它，以及每條路徑會讓你付出什麼代價

有兩種截然不同的部署方案，兩者不可互換。

• 伺服器 GPU — BF16 檢查點隨附一套 SGLang 服務套件，每個副本以單顆 B300 或單顆 H200 為目標，並在連接埠 30000 上提供相容於 OpenAI 的端點，模型名稱為 flint，同時包含用於推理與工具呼叫的範例用戶端。這是完整精度權重唯一受支援的路徑；模型卡明確指出目前尚未包含 Transformers 建模程式碼。

• 本機環境 —— llama.cpp、Ollama、Unsloth、LM Studio、vLLM 與 SGLang 全都被列為支援對象，這對一款首發當天的模型而言異常廣泛，而這也正是「一個檢查點」與「一件可用成品」之間的差別。

• rec 引擎——Recursive 自家的推論引擎，安裝於 ~/.local/bin，需要 M4 Pro、M5 Pro 或 M5 Max，至少 48GB 統一記憶體與約 30GB 可用磁碟空間，並在本機提供 OpenAI 相容 API。其 README 聲稱，在 M4 Pro 上使用 4 位元權重時，於 1,000 至 252,000 個 token 的提示、1,024 個輸出 token、每個上下文長度執行五次且不計預填充的情況下，token 吞吐量是 llama.cpp 的 1.4 倍至 2.6 倍。它明確針對單一工作階段使用進行最佳化——若同時執行多個代理，文件會指引你另尋他處。

決定一次工作階段是否順利的實用重點：上下文視窗由提示與輸出共用，困難問題需要至少 32,768 個 token 的輸出預算（含推理），而回傳的 reasoning_content 必須保留在對話歷史中，否則多輪工具使用會退化。Recursive 自身對複雜任務的指引是把工作拆成更小的子任務並附上明確指示；這是誠實的建議，但讀起來也像是在描述模型的上限。

什麼才是真正未經證實的

三件事，依其對決策應有的影響程度由高到低排列。

第一項是獨立測量。這並不存在。不是排行榜上的低分，也不是有爭議的分數——目前尚未有任何第三方對 Flint 的評估，流通中的唯一數字是廠商提供的，是用廠商選擇的測試框架和廠商針對網路檢索所做的調整所產生的。方法論揭露得足以接受稽核，這是第一天所能要求的最高標準，但揭露不等於已驗證。

第二點是，一個 25 億活躍參數的模型，能否勝任程式編寫代理實際上要處理的長時程工作。基準測試協定允許五次嘗試與五小時逾時，這是相當寬裕的容許範圍；一個需要試好幾次、又需要長時間放手讓它運作的模型，可以拿到漂亮的 pass@1，但在編輯器裡用起來卻讓人覺得不可靠。Recursive 自己提到它需要比大型封閉模型更多引導，這項但書也指向同一件事。

第三個是架構搜尋本身。一個在自動化系統測試過的配置中預測為最佳的配置，只是關於某次訓練執行的假設，而不是關於一個已完成模型的結果。如果 Eureka Machine 的預測是對的，這會是其他小型團隊會複製的範本。如果它大致正確，下一個檢查點就會移動，比例也會改變。

當你的 agent stack 只有一半是本機端時，這適用於哪裡

像 Flint 這樣的模型之所以重要，是因為它只是從帳單上刪掉一行，而不是刪掉所有行。本地推論能處理你可以在自己機器上執行的工作，對於你無法處理的工作則毫無幫助——那些放不下的長上下文工作、超出單台筆電負荷的突發流量，以及更大模型就是更好的任務。這使得大多數團隊仍然要運行兩套系統。

OrcaRouter 是這套安排中負責託管的那一半，而為了把界線說清楚：我們不提供 Flint，本文的任何內容都不是在推銷我們所託管的檢查點。Flint 是從 Recursive 下載的檔案，不是我們的端點。我們所做的，是把單一 API 放在 200 多個託管模型前面，價格就是各供應商自己的定價，不加收任何費用，並透過以設定為基礎的備援鏈在其中進行路由，並在供應商於請求進行到一半出狀況時自動容錯移轉。如果你想比較在本機跑一次 Flint 的價值，與規模相近的託管混合專家模型相比——Qwen3.6-35B-A3B 和 Gemma 4 26B-A4B 都能透過同一把金鑰呼叫——這個比較只需花一次請求，而不是一次部署。

合理的解讀

Flint 是一次真實的發佈，具有特定且不尋常的重心。Recursive 並未推出它所能打造的最強程式碼模型；它推出的是在能塞進筆記型電腦的尺寸下所能打造的最快模型，接著發佈了一套量化與核心堆疊，旨在讓這項優勢在接觸 4 位元權重後仍能存續。Terminal-Bench 2.1 上的 54.9% 與 SWE-bench Pro v2 上的 89.7%，對一個 400 億參數的稀疏模型而言是很強的數字，而且目前這些僅是廠商自行公布的數字。

真正值得一看、而不只是下載的，是它背後的方法。一個聲稱自動化研究迴圈選出了架構、量化配方與核心（kernels）的團隊，是在對一套流程提出主張，而不是對某個模型提出主張；而流程可以被檢驗的方式，正是發布基準測試所無法提供的：下一個版本要嘛來得更快、更好，要嘛不是。Flint 是這場論證中的第一個資料點，並以足夠寬鬆的授權條款釋出，任何人都能自行檢查權重。

如果你有 48GB 統一記憶體和一台 Apple Silicon 機器，搞清楚這件事的代價就是下載 22.86GB，再加上一個下午。如果你沒有，誠實的立場就是等第一份獨立評測，因為一份才一天的基準測試表只是承諾，不是測量結果。