Flint v1.0 對比 Qwen3.8 27B：Recursive 模型將自身作為基準進行比較

Recursive 在其Recursive Flint v1.0的發表資料中寫了一句大多數報導都略過的話：在公司自家的六項測試平均上，只有Qwen3.8 27B得分高於 Flint。對廠商而言，在發表當天刊登這種話並不尋常。這也是整份新聞稿中最有用的一句話，因為它告訴你該去查哪一項比較。Qwen3.8 27B 是開放權重稠密模型，於 2026 年 8 月 14 日以 Apache 2.0 授權釋出，也是 Recursive 比較集中唯一在廠商自行建構的彙總指標上勝過 Flint 的模型。所以，有趣的問題不是 Flint 好不好，而是 Qwen3.8 27B 究竟在哪裡更好，以及這個差距在相關評測框架的嚴格檢視下是否依然成立。

先讀班級聲明，再讀分數。

Flint 的核心主張有嚴格的範圍界定：在 SWE-bench Pro v2、Terminal-Bench 2.1 與 SWE-bench Verified 上，它領先總參數低於 500 億的混合專家模型。Qwen3.8 27B 不是混合專家模型。它是稠密模型——270 億參數，每個 token 都會全部啟用，計入視覺編碼器則為 280 億參數，64 層、隱藏大小為 5,120。因此，從設計上來說，它本來就落在 Flint 的比較類別之外，Recursive 完全可以將它排除在該主張之外。

值得精確說明「稠密」的代價與回報。Qwen 的 270 億個參數全都參與每個 token 的運算，因此它在 BF16 下需要約 55.6 GB 記憶體和一張真正的 GPU，其活化記憶體佔用也大約是 Flint 的十一倍。這也是為什麼稠密 27B 模型在準確度上能勝過 2.5B 活化參數的稀疏模型：它每個 token 做更多運算，並向你收取相應代價。

Terminal-Bench 2.1：十八個百分點的差距

這是目前最乾淨的比較，因為兩個實驗室回報的是同一個基準版本，而且差距大到測試框架的雜訊不太可能解釋全部落差。

• Flint — 在 Terminal-Bench 2.1 上取得 54.9%，於啟用網際網路的 Terminus 2 測試框架上執行，但任何透過網路檢索取得的解法都計為失敗。

• Qwen3.8 27B — 根據阿里巴巴的模型卡，在 Terminal-Bench 2.1 上取得 73.0% 的成績。

這是在最接近代理式終端機工作的基準測試上，Qwen 以 18.1 個百分點領先的差距——而這正是這兩款模型所主打的工作。有兩項但書朝相反方向起作用，且兩者都必須說明。

第一項結果對 Flint 有利。Recursive 施加了一項其同業可能不會施加的不利條件：如果代理在網路上找到答案，Recursive 就會將其評為錯誤。若允許模型搜尋並引用來源，它在同一套評測框架下會得到更高的分數。究竟高多少不得而知，而 Recursive 並未公布未加此不利條件的數字。

第二點則打破了任何簡潔的解讀。第三方 PrismML 在 Terminal-Bench 2.1 上給 Qwen3.8 27B 打了 69.7 分，而非阿里巴巴的 73.0 分。同一模型與基準上出現 3.3 分的分歧，是有用的校準：它告訴你，這張表裡幾分的差距是雜訊，而 18 分的差距大概不是。

即使採用較低的 Qwen 數字，69.7 對 54.9 仍留下 14.8 分的差距。方向毋庸置疑。

LiveCodeBench v6：第二個落差，出現在更乾淨的基準測試上

競賽程式設計是兩家實驗室所報告的基準測試中，最不受測試框架影響的一項，因為模型拿到題目後產生程式碼，再由評審系統執行。其中沒有代理迴圈可產生差異。

• Flint — 於 LiveCodeBench v6 上達 80.3%。

• Qwen3.8 27B — 在 LiveCodeBench v6 上達到 90.3%。

這是一個 10 分的差距，而這正是我會賦予最高權重的一項，因為它最難被解釋掉。Flint 的 80.3 對於一個啟用 25 億參數的模型來說是可觀的數字。Qwen 的 90.3 對於一個啟用 270 億參數的模型來說是強勁的數字。兩者都不令人意外。重點是，Flint 所推銷的效率優勢並非沒有代價，而這項基準測試正是代價顯而易見的地方。

看似弗林特勝利、實則不然的基準

這正是大多數比較頁面出錯的地方，值得慢下來好好思考。

Flint 在 SWE-bench Pro v2 上回報 89.7%。Qwen3.8 27B 在 SWE-bench Pro 上回報 61.7%。乍看之下，這像是 Flint 領先 28 個百分點的勝利。但這根本不是同一項比較。「v2」與 Alibaba 所回報的是不同的基準，任務集不同、評估協議也不同，這兩個數字不能相減。任何把它們放在相鄰欄位並宣稱有贏家的頁面，透露的是作者本身的一些事，而不是模型的事。

同樣的陷阱就在下一列。Flint 在 SWE-bench Verified 上報告 74.2%。Qwen3.8 27B 並未公布 SWE-bench Verified 分數——Alibaba 的模型卡報告的是 SWE-bench Pro、QwenSWEBench 79.0、DeepSWE 1.1 42.2、Terminal-Bench 2.1 73.0、LiveCodeBench v6 90.3 與 NL2Repo-Bench 42.3。沒有 Verified 數據可供比較。流傳的 Qwen3.8 27B 在 Verified 上的數字，不是沿用自同系列較早的模型，就是取自二手來源，而該來源同時在數個其他基準上與模型卡相衝突。請將其視為未經證實。

關於阿里巴巴這邊，還有一點需要補充說明：其 SWE-bench Pro 與 QwenSWEBench 的執行使用了外部代理框架（agent harness），而非單純的模型本身，因此即使是拿來與其他實驗室的 SWE-bench Pro 數字相比，也並不可靠。這並非阿里巴巴獨有的問題。這是當前代理式程式設計（agentic coding）基準測試的普遍狀況，也正是為什麼在這裡，Terminal-Bench 與 LiveCodeBench 這兩列的可信度會比 SWE-bench 那幾列更高。

在 Flint 勝出之處，而且贏得毫無懸念

準確度並非唯一的軸線，而在其他軸線上，排序會徹底反轉。

• 記憶體 — Flint 執行時約佔用 24 GB，磁碟上的 NVFP4 建置版本為 22.86 GB。Qwen3.8 27B 以 BF16 執行則需要約 55.6 GB。前者能裝進高階筆電或單張消費級顯卡；後者則需要真正的 GPU 資源配置。

• 每個詞元的有效運算量——Flint 約啟動 25 億個參數，Qwen 則啟動全部 270 億個。這個比例既是速度差距存在的原因，也是 Flint 在大規模部署時服務成本更低的原因。

• 速度 — Recursive 宣稱在 M4 Pro MacBook Pro 上，短上下文下每秒可達 125 個以上 token，而在 64 GB RTX Spark 上則超過 150 個。同樣筆電上的稠密 27B 並不在這個範圍內。Qwen3.8 27B 也被回報在本機執行緩慢，且異常耗費 token——Artificial Analysis 在其索引測試中測得約 1.6 億個輸出 token，這在任何代理迴圈中都是成本倍增因素。

• 背景——兩份文件皆原生支援 262,144 個 token，而 Qwen 透過 YaRN 擴展可達 1,000,000。Flint 的公告則聲稱最高可達 512K。就帳面規格而言，兩者在原生視窗上不相上下；但實際上，Flint 在長上下文下的吞吐量是較弱的一環，獨立測試報告指出，在接近 115,000 個 token 時，速度會降至約每秒 9 個 token。

• 多模態 — Qwen3.8 27B 除了文字之外，還能接受圖像與影片，其混合注意力配置為 48 層 Gated DeltaNet 線性注意力層搭配 16 層全注意力層、比例為 3:1，這正是讓 262K 視窗能以可負擔的成本提供服務的關鍵。Flint 則僅支援文字。

你實際上在選擇的是什麼

• 如果目標是達到最高的程式碼編寫準確度，而且你具備相應的硬體，那麼在兩者能夠乾淨比較的每一項基準測試上，Qwen3.8 27B 都是更強的模型。Recursive 自家的六項測試平均值也顯示這一點。

• 如果模型必須在筆電上執行、保持離線、將原始碼留在本機，或服務量大到活躍參數主導帳單，Flint 就會在決定部署的關鍵面向上勝出。一個每秒 125 個 token 的 2.5B 活躍參數模型，與一個需要 GPU 節點的 27B 稠密模型，是截然不同的產品。

• 如果你兩者都要，它們能很好地搭配：本地模型負責例行與敏感的工作，託管模型負責困難的任務。這種分工是大多數團隊最終採用的方式，而這也正是路由層不再只是細節的地方。

Qwen3.8 27B 是本次比較中由 OrcaRouter 直接提供服務的唯一模型——識別碼是 qwen/qwen3.8-27b，列於我們的即時模型清單中；它接受文字、圖像與影片，並具備完整的 262,144 個位置視窗。由於供應商定價是按原價傳遞，且未加收任何加成，因此阿里巴巴方面的價格變動會在當天反映到我們這裡，而不是等到下一次續約。OrcaRouter 不提供 Flint；那個是下載項目。所以上述混合方案是真正的混合：一條通往託管前沿級模型的路徑，以及一個供所有不得離開本機的內容使用的本機檔案。

沒有人做過的實驗

本文中的每個數字都來自实验室測量自家模型，只有一個例外——PrismML 在 Terminal-Bench 上與阿里巴巴存在 3.3 個百分點的落差，而這是唯一能窺知，當由他人來掐錶計時時，這些數字會有多大變動的線索。

能解決這件事的方法很直接，卻始終沒有發生：兩個模型、同一套測試框架、同一組任務、同一台機器，以及公開的追蹤記錄。在那之前，站得住腳的立場是範圍較窄的那個。在兩個實驗室都誠實回報的基準測試上，Qwen3.8 27B 是更準確的程式設計模型。在決定模型究竟能否運行的部署層面上，Flint 則是效率更高的一方。Recursive 在其自家發布文章中率先這麼說，而那是整個發布中最可信的一點。