遞迴 Flint v1.0：一個主要由自身研究迴圈打造而成的 40B 程式碼模型

最耐人尋味的一句話，出現在Recursive Flint v1.0的發布公告中，而不是某個基準測試分數。那句話是 Recursive 表示，一個小型團隊在不到四個月內從零打造出一個 400 億參數的程式設計模型，而一個名為 Eureka Machine 的自動化研究系統幾乎參與了每一個階段。Flint 已公開亮相，是一款強力的本地端程式設計模型——總參數量 398 億，每個 token 約有 25 億活躍參數，採用 Apache 2.0 授權，在筆電上也能順跑。但這次發布也是對另一種主張的首次公開驗證：打造模型的過程本身可以大幅自動化。公告裡同時存在這兩種解讀。但只有其中一種是你可重現的。

Flint 於 2026 年 10 月 21 日 以 Apache 2.0 授權發布，權重放在 Hugging Face 上，名稱為 RecursiveSI/flint。它是 Recursive 的第一個模型，這家實驗室由前 Salesforce 首席科學家 Richard Socher 創立；它四天前才問世——近到幾乎沒有任何人能在製作它的實驗室之外對它進行過測試。

Recursive 實際發布了什麼

是四個儲存庫，不是一個。主要的檢查點儲存庫存放 BF16 權重、設定、分詞器、聊天範本與 SGLang 服務套件，並於 2026 年 10 月 21 日 14:20 UTC 建立。旁邊有三個量化版本，全部標示為同一天下午：一個 int4 safetensors 版本、一個 int4 GGUF，以及一個 NVFP4 GGUF。下方的大小來自這些儲存庫本身的檔案清單，而不是公告。

• BF16 參考版本 — 共 37 個檔案、79.59 GB。若你擁有 H200 或 B300，並想使用未經稀釋的完整模型，這就是你要用的檔案。

• NVFP4 GGUF — 22.86 GB。這個版本讓「能在筆電上跑」的說法名副其實，也是大多數人實際上會下載的版本。

• int4 GGUF — 25.99 GB，儘管名義上位元寬度相近，卻比 NVFP4 檔案更大。若你單就磁碟空間在兩者之間做選擇，NVFP4 勝出。

• int4 safetensors — 22.58 GB，適合想要 safetensors 檢查點而非 GGUF 的服務堆疊。

Recursive 宣稱，自家的低位元訓練加上 4 位元輸出頭，再蒸餾回 16 位元模型後，與全精度之間的差距在 0.7 分以內。那個數字是 Recursive 自己的，是在 Recursive 自家的評估上測出來的。檔案大小可不是：任何人都能直接從儲存庫上讀出來。

這四個數字，以及每一個各自衡量的是什麼

Recursive 隨著這次發布公布了一組分數，而關於這些分數，最重要的一點是：它們全都是在 Recursive 自家的評測框架內產生的。沒有任何第三方重新跑過其中任何一項。Artificial Analysis 指數——這類模型通常的獨立裁判——完全沒有 Flint 的條目。

• SWE-bench Verified — 74.2%。這是最多讀者會認得的基準測試，用來衡量模型能否解決真實的 GitHub 問題。Recursive 透過 mini-swe-agent 執行這項測試，且完全沒有網際網路存取；在溫度 1.0、top-p 0.95、top-k 20 的設定下，對至少五次嘗試取 pass@1 平均值。

• SWE-bench Pro v2 — 89.7%。請注意「v2」這個字樣。這與其他實驗室所公布的 SWE-bench Pro 並非同一個基準測試，因此這兩個數字不能相互加減。這個區別的重要性遠超表面上看起來的程度，而且每次將 Flint 與回報一般 SWE-bench Pro 成績的模型相比較時，這個問題都會再次出現。

• Terminal-Bench 2.1 — 54.9%。在這裡，Recursive 做了一件異常誠實也異常尷尬的事：它在啟用網際網路的情況下執行 Terminus 2，然後把任何透過網路檢索取得的解法都計為失敗。這項不利條件是刻意設定的，也意味著這個分數無法與在沒有該規則下產生的 Terminal-Bench 分數直接相比。

• LiveCodeBench v6 — 80.3%。這是競賽程式設計基準，而非代理式基準，因此是四者中對測試框架選擇最不敏感的一個。

• IFBench — 89.2%。指令遵循能力，而這通常是小模型最先失守的地方。

Recursive 實際提出的主張，比報導所暗示的範圍更窄：Flint 在 SWE-bench Pro v2、Terminal-Bench 2.1 與 SWE-bench Verified 上，領先總參數低於 500 億的混合專家模型。這是類別層級的主張，而非絕對主張。規模相當的稠密模型從定義上就被排除在外——這正是為何稠密模型 Qwen3.8 27B 會出現在同一張圖表中，且在 Recursive 自家的六項測試平均分數上得分更高。Recursive 把這一點印了出來。它值得因印出這一點而受到肯定。

Eureka Machine 的主張，是比模型更持久的那一部分。

撇除基準測試，留下來的是一個更不尋常的故事。Recursive 表示，其自動化研究系統會產生想法、執行實驗，並利用實驗結果來決定接下來要執行哪些實驗。該公司將其貢獻歸功於預訓練、後訓練、推論、量化與硬體核心等領域。其中三項貢獻夠具體，可以對照相關產物來查核：

• 模型形態。設計從 35B-A3B 基線出發，最終落在總參數 40B、活躍參數 2.5B。這是刻意朝更高總容量、同時維持相同啟用成本的方向推進——更稀疏，而不是在對推論真正重要的意義上變得更大。

• 量化。將輸出頭改為 4 位元，並從 16 位元模型自我蒸餾回來，正是 0.7 點這項說法背後的配方，也是為什麼一個 39.8B 模型能有 22.86 GB 可散布建置版本的原因。

• 核心。Recursive 寫了一個針對 M4 和 M5 晶片的 Metal 巨型核心；考量到其吞吐量宣稱，這是清單上最不令人意外的項目，也是最具體的一項。

Recursive 沒有披露的是 Eureka Machine 節省了多少研究員時間。這項省略正是整個論點的核心。若要主張某個系統已將模型開發的大部分流程自動化，唯有在你了解替代方案的成本時才有意義——而該公司自身的表述在此相當謹慎：整個流程仍由人類監督，而非完全自主。請把這份發布內容視為一次早期的公開示範，而不是遞迴式自我改進的證明。

四天的親手實測能告訴你什麼、不能告訴你什麼

到目前為止，外界對 Flint 最深入的一次檢視，是《Wired》的 Will Knight，他在一台配備 48 GB 記憶體的 Mac 上運行 Flint，並打造了一個待辦事項應用程式、一個網路研究工具，以及一個小型解說網站。這三項全都成功了。這是實打實的成果，但它並不是基準測試。它只是三項任務、一台機器、一個人。

對於任何真的打算使用它的人來說，更有用的訊號來自那些長時間測量吞吐量、而非只在工作階段開始時測量的評測者。一項獨立測試回報，短提示下約為每秒 110 個 token，但在上下文約 115,000 個 token 時，會降到約每秒 9 個 token。這是超過五倍的效能衰減，也是你的代理在寫入任何內容前先讀取大型儲存庫時，規劃時必須納入考量的數字。Recursive 的宣傳速度數據——在 M4 Pro 上每秒超過 125 個 token，在 64 GB RTX Spark 上超過 150 個——明確是在短上下文中測得，且排除 prefill。

在 llama.cpp 的 GGUF 路徑中，還有一個已知的聊天範本錯誤。如果你載入量化版本後，模型表現得像失去理智，先檢查範本，再怪罪權重。

在不把生產路徑押在它身上的情況下執行它

Flint 是下載項目，不是端點。OrcaRouter 不提供它，這裡的任何內容都不應被解讀為我們有提供。

這件事改變的是你該怎麼試用它。評估一個才問世四天的開放權重模型，誠實的做法是把它跟你已經信任的模型並排執行，並在你自己的儲存庫上比較，而不是把它換進來然後指望它行。如果你已經透過同一個 API 呼叫託管模型，低風險的做法是保留那條路徑作為備援，同時讓 Flint 處理你願意交給它的任務，並讓故障轉移鏈接住本機模型卡住的請求，而不是在正式環境中才發現它卡住。這是路由決策，不是忠誠度決策。

下載前另一件值得知道的事：Flint 可免費執行，但並非免費擁有。22.86 GB 的下載量是入場券，而能從容容納它的機器才是真正的成本。如果你要把這與按 token 計價的託管模型比價，也別忘了把硬體成本算進去。

接下來一個月要關注什麼

三件事將決定 Flint 究竟是會被記住為一個優秀的小型程式碼模型，還是會成為一場更長論證中的第一個資料點。

第一點是獨立的基準測試執行。在 Artificial Analysis 或同等的中立第三方對它評分之前，任何涉及 Flint 的比較，都只是某個實驗室自我測量與另一個實驗室自我測量之間的比較。第二點是長上下文吞吐量問題究竟會是 llama.cpp 的人為產物、引擎問題，還是模型本身的特性——這些問題的修正方式截然不同。第三點是 Eureka Machine 的貢獻到底能否被評估。Recursive 表示該流程有人類監督；更有意思的問題是人類與代理的比例是多少，而這正是發布文章並非設計來回答的問題。

目前，站得住腳的總結很短。Flint 是一個真正小巧、真正快速、真正開放的程式設計模型，它能在你大概已經擁有的硬體上運行，但它的一組分數沒有人核實過，它的開發歷程也沒有任何公司外部的人驗證過。這兩個事實本身就是整件事的重點。