Flint 本機編碼模型解析：每秒 125 tokens，工作也會更快嗎？（2026）

2026 年 10 月 21 日，Recursive 在官網發布了 〈Introducing Flint〉，把 Flint 本機編碼模型帶到可下載的開放權重市場：主打筆電上的生成速度，也把它當成自動化 AI 研究的成果展示。真正值得追問的是：模型吐字變快後，你手上的程式任務，究竟能提早多久完成？

先看清楚這次發布交出了什麼，再拆開規格與測試條件，最後判斷哪些工作值得交給它。我的初步判斷是：Flint 值得納入本機模型候選，但採用理由應是你的任務成績與資料邊界，不能只是一個 tokens/s 數字。

Flint 本機編碼模型的核心：把運算集中到少數專家

Flint has 40 billion total parameters and activates just 2.5 billion per token.

中文：Flint 總參數約 400 億，每個 token 啟用的參數約 25 億。

Recursive，〈Introducing Flint〉

這是混合專家模型（MoE）的關鍵：模型保有一大組參數，每次生成只動用其中一部分。模型卡給出的較精確總量是 39.8B；約 2.5B 的啟用量包含輸出層，計算口徑也有交代。公開設定檔則可核對每個 MoE 層有 256 個路由專家、每次選 6 個，另有共用專家。

把它想成一間有許多專科的工作室：每道問題只叫來幾位同事，當次運算量因此降低；整間工作室仍要有地方容納。啟用參數少，與整個模型需要多少記憶體，是兩個問題。這也解釋了為什麼「25 億啟用」不能直接讀成「一般小模型的硬體需求」。

能在筆電跑，先問是哪一份權重、哪一套引擎

本次查閱於 2026 年 10 月 24 日。模型權重的 LICENSE標示 Apache 2.0；這讓取得、修改及自行部署有明確授權依據，卻不等於已公開每一項訓練素材與研究過程。正式發布日期可由 官方更新索引和 10 月 21 日初次提交紀錄交叉核對。

項目	公開資料怎麼寫	讀者該怎麼解讀
原始 BF16 權重	模型卡的下載示例約 80 GB	與筆電跑分所用的低位元版本分開看。
rec 的 Mac 要求	M4 Pro、M5 Pro 或 M5 Max；至少 48 GB 統一記憶體、約 30 GB 可用磁碟	這是這套官方快速入口的要求，不能推成所有執行方式的下限。
上下文	模型卡與設定檔列 262,144 tokens；發布文另提最高 512k，建議 256k 內	先按你選定權重與 runtime 的實際設定規劃，輸入與輸出共用空間。
使用形態	rec 針對單一 session 優化，可接 Pi、OpenCode 或自己的 client	多個 Agent 同跑，需要另看服務方式與資源競爭。

上表硬體與使用形態依 rec 官方 README，與原始模型卡分別核對。對已經有符合條件電腦的人，試跑門檻比新增伺服器低；對準備買新電腦的人，先借用相同配置測任務，會比照著短上下文跑分採購可靠。

Flint 本機編碼模型有多快？把三張成績單分開

發布文宣稱，搭配最佳化引擎，在 M4 Pro MacBook Pro 的短上下文可超過每秒 125 tokens。這是 Recursive 的測量與主張。原文也展示跨模型品質與速度圖，但不同圖的速度定義不完全相同：有短上下文，有整段長對話的平均，且圖註排除 prefill。

Prefill 是先讀完你送入的程式與對話；decode 是接著逐 token 生成。檢查長程式庫時，前者可能花掉相當多時間。除此之外，Agent 還會執行工具、等待測試、重試與整理補丁。整項工作的時間，要從送出任務量到測試通過、改動可接受。

外部原始紀錄補上什麼，又沒有證明什麼？

Kapitsa 專案的 2026 年 10 月 22 日測試紀錄提供了一份可讀的外部原始證據：開發者在一台 48 GB M4 Pro 上比較 Kapitsa、rec 0.1.0 與 llama.cpp b11804。其中 Kapitsa 與 rec 使用同一份 Recursive 4-bit MLX 權重（提交 3b93f905）；llama.cpp 使用另一份 Q4_1 GGUF。這是另一個引擎團隊的測量，帶有比較自家產品的動機；本文沒有在 AlphaLab 的設備執行該測試。

同一份公開紀錄	rec 0.1.0	Kapitsa	限制
短上下文 decode，T=1.0	126.56 tokens/s	127.90 tokens/s	彙總兩次流程；各次 decode 取五次 512-token 執行的中位數。
128K 上下文 decode	35.2 tokens/s	45.7 tokens/s	每個長度只做一次請求；不是多機平均。

這份紀錄讓「短上下文約 125 tokens/s」多了一個可追查的外部觀察，也顯示把它延伸到長上下文會高估體驗。作者記錄部分流程受到其他 GPU 工作干擾，長度掃描也未提供同樣的競爭取樣；因此這組差距適合當後續驗證線索，不適合頒發通用速度冠軍。它量的是推論，沒有替你的專案完成率背書。

編碼分數看的是整套 Agent，不只一份權重

模型卡的發布評測列出 Terminal-Bench 2.1 為 54.9%、SWE-bench Pro v2 為 89.7%、SWE-bench Verified 為 74.2%。三者都是 Recursive 報告的成績；不同考卷的百分比不能互換，89.7% 也不能讀成「你的程式問題有近九成能解」。

原文交代 Terminal-Bench 使用 Terminus 2，SWE-bench 使用 mini-swe-agent；Agent 評測每題至少五次嘗試後回報平均 pass@1，允許最長五小時的任務時間。這種報告方式與「五次挑最好一次」有別。SWE-bench 原專案本來就把問題定義為：給定程式庫與 issue，產生能解決問題的 patch。換了工具、提示與時間預算，你也換了受測系統。

另一個重要差異是網路條件：原文的 SWE-bench 執行不開網路，Terminal-Bench 開網路但把靠檢索取得解答的題目計為失敗。這是具體可核對的評測規則，不是所有比較分數都必然採用的共同設定。截至本次查閱，本文取得的上述編碼成績來自廠商發布資料，未取得足以獨立確認這三項分數的完整外部重跑證據。

Eureka Machine 的敘事：工程成果與自我改進要各自舉證

Flint is our starting point.

中文：Flint 是我們的起點。

Recursive，〈Introducing Flint〉

原文更大的訴求，是讓 Flint 成為 Eureka Machine 的可用成果。Recursive 描述這套系統會提案、寫實作、做實驗，再依結果挑下一條路；在 Flint 上，它協助探索專家配置、低位元量化與蒸餾，以及 Apple／NVIDIA 的推論核心。這些都是廠商對開發過程的描述，不能因為模型已可下載，就把各階段的貢獻比例也當成獨立驗證。

這條路有合理的工程邏輯：架構減少每步要算的量，量化減少搬運的權重，再讓核心程式配合硬體執行。改善可以相互配合，而非只靠把模型縮小。原文還把下一代更強模型回饋到研究系統，當作未來加速的方向。

但要檢驗「研究系統會愈來愈好」，還需要每代相近的算力與人力預算、被淘汰實驗的成本、人工介入量，以及未參與挑選的新任務結果。單次交付一個有效模型，與證明持續的遞迴改進，中間仍有一段需要用資料接起來的距離。這正是 AI 開始打造 AI 的另一個案例值得對照的地方。

AlphaLab 的判讀：把速度換成可接受的改動

一、少搬參數有價值，硬體成本仍要完整算

Flint 的吸引力在於把 MoE、量化與硬體核心一起設計。若你已有合適的 Mac，資料留在本機的選項值得測；若要為此買設備，還要算常用程式同時開啟後的記憶體、長上下文等待與維護時間。官方 rec 的 48 GB 要求，是一個有用的起點，不是替所有版本判定能不能跑。

二、短回覆很快，可能只是把瓶頸移到重試

假設某個模型生成一輪只需較短時間，卻常常理解錯測試、改錯檔案，你可能花更多輪才能收工。這是選型時的假設情境，並非本次測得的 Flint 表現。應一起記錄首次可接受補丁的時間、重試次數、測試結果與人工修正量，讓速度和品質落在同一張工作單上。可沿用 AI Evals 的驗收觀念來定義成功。

三、本機推論是資料邊界的一層

權重放在本機，代表你可以把模型推論安排在自己的設備；資料之後會不會送出，還取決於接上的 harness、網頁搜尋、外部工具與備援服務。要驗證「這個工作流留在本機」，應記錄實際網路請求、關閉雲端 fallback，下載完成後再做斷網任務。Agent Harness 的角色和 Agent 憑證管理，恰好補足模型之外的兩層。

我同意的，是本機編碼模型值得以整套系統效率重新評估；我存疑的，是把有限配置的跑分直接推成全面替代，或把一次模型發布推成自我改進已獲證明。開放權重最有用的地方，是讓更多人可以把這些疑問變成可檢查的結果。

接下來怎麼選？先拿三種熟悉任務對帳

先從你熟悉且可還原的小程式庫挑題：補一個單元測試、修一個已知錯誤、完成一項跨檔案的小功能。每題先寫驗收條件，用相同的工具權限、時間上限與上下文，再分別記錄輸入讀取時間、生成時間、工具等待、測試通過與人工改動。這是一份建議測試設計，並非本文已完成的實測。

如果它在這些題目上較早交出可接受的 patch，且資料路徑符合你的需要，Flint 就有明確的位置。若長上下文或重試拖慢工作，先縮小任務、比較引擎與量化，再考慮保留另一個模型處理困難題。不要先追一個抽象的全能冠軍；先找到能替你穩定完成一類工作的配置。

接著追三件可對帳的事：不同人能否在相近硬體重現速度；相同 harness 與預算下的編碼完成率；下一代模型是否在相近研發資源下交出更好結果。這三張成績單，會比發布當天的掌聲更能決定 Flint 的份量。