模型輸出快，開發就快，這個直覺在大多數時候是對的，但 NaiveAI 公布的 2,100 tokens/s 恰好是個好例子，說明「快」這個字需要先問：快的是哪一段？
先把可確認的事實放穩。NaiveAI 在 2026 年 11 月 10 日發布的技術說明指出，Naive-N0.5-Flash 模型在其命名為 NaiveRT 的推論環境上，於 8 張 Blackwell GPU 執行 41 個 HTML／SVG 請求，關閉思考模式時的最佳一秒窗口，單一串流達到 2,122 tokens。數字排除輸入預填充（prefill），也不含長提示與工具呼叫往返的延遲。
解碼峯值像什麼：像是高速公路的極速紀錄
打個比方，這個數字像是車輛在測試跑道上的極速紀錄。它證明引擎與路面的工程水準，但你的通勤時間取決於上交流道排多久、中途要下幾次交流道。模型的輸出時間同樣由幾段組成：首字等待（你送出提示到第一個字出現）、解碼速度（字冒出來的快慢）、以及端到端完成時間（包含模型呼叫工具、讀檔案、來回修改的全程）。
NaiveRT 的做法結合了推測解碼與 GPU 最佳化：草稿模型先猜多個 token，再由目標模型驗證，接受率高的時候就能跳過逐 token 的等待。這對長輸出的 HTML、SVG 這類任務特別有效，因為內容結構重複性高，草稿容易被驗證通過。但平均解碼變快，並不保證首字更早出現，也不保證代理流程裡多次工具往返的總時間縮短。
基準分數的語境：三個分數，三把不同的尺
NaiveAI 技術頁列出三個分數：DeepSWE v1.1 得 67.8、Terminal-Bench 2.1 得 86.7、NL2Repo-Bench 得 71.9，另外 SWE-bench Pro 為 73.6。官方同時說明評測條件：Claude Code 2.1.207、百萬 token 上下文、temperature 1.0、top-p 0.95，搭配基本檔案與 Bash 工具。
這裡有兩個容易誤讀的地方。第一，三個分數測的任務類型不同：DeepSWE 評軟體工程代理的任務處理，Terminal-Bench 以終端操作為主，NL2Repo-Bench 測自然語言需求對程式庫的處理。它們不能換算成同一個「正確率」，也不能從中推得「在你公司程式碼庫上的修復成功率」。第二，這些是模型方自行公布的結果，並非獨立第三方驗證，而且 SWE-bench Pro、SWE-bench Verified 等不同版本的規則與題目各異，分數之間不能直接比較。
這也是為什麼評測環境本身的配置會影響結果。先前我們整理過 Microsoft 開源評測平臺 Scope 把代理驗收拆成可逐條檢查的條件，正是同一個道理：換一套代理工具、換一組驗收標準，同一個模型可以得出很不一樣的分數。有興趣可以參考Microsoft Scope 如何把代理驗收拆成可逐條打勾的條件的分析。
速度要轉成效率，中間隔著「修改成本」
真正能回答「值不值得用」的，是端到端的研究，而非單項速度。來源引用了一個可查證的案例：GitHub Next 與 Microsoft 首席經濟學家辦公室的研究，隨機分派 95 名專業開發者以 JavaScript 撰寫 HTTP 伺服器，一組用 GitHub Copilot、一組不用。使用組平均用時 1 小時 11 分，未使用組 2 小時 41 分，完成率分別為 78% 與 70%。
這個研究測的是 Copilot 而非 NaiveAI，但它示範了正確的量法：計時、隨機分派、以測試評分。輸出速度只是其中一個變數。如果模型生成得快，但生成的程式碼需要來回修改、測試失敗重跑，總工時可能反而上升。這與我們先前分析過的現象相通：AI 專案跑一小時才結束，問題常常出在測試被串行執行，模型本身不慢，流程在排隊。可參考AI 代理執行過長的常見原因分析。
一般開發者可以帶走的判斷
如果你打算試用這類強調速度的模型，務實的做法是把官方數字當成能力輪廓的參考，然後用自己的任務量三件事：提示送出到第一個字出現的等待、生成過程的解碼速度、以及從下指令到測試通過的完整時間。第三個數字才是會反映在工時單上的那一個。
同時留意基準的量測條件。關閉思考模式、單串流、HTML／SVG 任務，這些設定下的峯值，與日常使用長上下文、多工具呼叫、需要推理的場景，是不同的世界。數字沒有說謊，但它只回答了被問到的那個問題。
依現有來源，NaiveAI 的速度聲稱有其量測依據，但缺乏獨立驗證與真實工作場景的端到端數據。這不是否定，而是留白：留給實際把模型放進自己流程、量過完整時間的開發者來填。