一位開發者發布了一項關於本地運行的大語言模型（LLM）與 Anthropic Claude API 模型在實際程式碼除錯任務上表現的對比測試。該測試旨在回應社群中關於「不應為了追求生成速度（tok/s）而犧牲模型能力」的討論，透過評估模型在真實工作負載中的實際產出來進行比較。
**測試環境與設定：** * **硬體配置：** 本地模型運行於作者自研引擎 (capy-flash)，硬體為 2x RTX 5070 Ti 16 GB、Ryzen 9900X、96 GB DDR5。未使用 Flash Next 的專家跳過（expert skipping）技術。 * **任務來源：** 選取了該引擎私有歷史中的 9 個真實回歸 Bug（涉及 C++/CUDA），包括效能斷崖、數值漂移以及僅在 WSL2 雙 GPU 環境下出現的 Bug。這些 Bug 從未公開過。 * **任務描述：** 每個 Bug 報告均模擬作者向自己提交的方式，包含症狀、數據和日誌，但不提供查找方向的提示。 * **執行限制：** Agent 在無網路、無 CUDA 工具鏈的沙盒 Mac 環境中運行，無法編譯或執行程式碼，必須僅透過閱讀程式碼進行推理並撰寫補丁。每個任務最多 80 步，每個模型對每個任務執行 3 次。 * **Harness 選擇：** Claude 模型使用 Claude Code，本地模型使用 OpenCode。作者嘗試過讓本地模型通過橋接器在 Claude Code 中運行，但表現較差，因此雙方均使用各自最適化的工具環境。
**評分機制：** 每個補丁接受兩次評分： 1. **自動評分：** 基於真實修復構建的隱藏關鍵指標（正確的文件和函數、補丁精度、代碼檢查）。 2. **盲評法官：** 由 Claude Opus 5 作為盲評法官，看到 Bug 報告、代碼、標記為「一個有效解決方案而非唯一解」的真實修復以及編譯器輸出，給出 1 / 0.75 / 0.5 / 0.25 / 0 的分數。無法編譯的補丁在兩種評分中均被限制為最高 0.25 分。
兩種評分的相关係數為 r = 0.79，且對模型的排序一致。法官評分比自動評分稍嚴，但並未偏袒 Claude（Claude 模型的法官減自動分數為負值，Qwen 模型則接近零）。
**測試結果：** 由於樣本量僅為 9 個任務，置信區間較寬（約 ±0.2），但整體層級依然成立。分數差距小於 ~0.1 的模型視為無顯著差異。 * **Claude Opus 5.5 (API):** 得分 0.74，每任務 Token 數 16k，耗時 3 分鐘。 * **Claude Sonnet 5.5 (API):** 得分 0.58，每任務 Token 數 8k，耗時 1 分鐘。 * **Qwen3.8-Flash-Next NVFP4 (本地):** 得分 0.50，每任務 Token 數 53k，耗時 10 分鐘。 * **Qwen3.8-Flash-Next 3-bit (本地):** 得分 0.48，每任務 Token 數 53k，耗時 9 分鐘。 * **Claude Haiku 5.5 (API):** 得分 0.47，每任務 Token 數 45k，耗時 4 分鐘。 * **Qwen3.8-27B 3-bit (本地):** 得分 0.39，每任務 Token 數 111k，耗時 18 分鐘。 * **Qwen3.8-27B NVFP4 (本地):** 得分 0.34，每任務 Token 數 81k，耗時 13 分鐘。 * **Claude Sonnet 5 (API):** 得分 0.28，每任務 Token 數 43k，耗時 8 分鐘。 * **Claude Sonnet 4.5 (API):** 得分 0.19，每任務 Token 數 15k，耗時 6 分鐘。 * **Claude Haiku 4.5 (API):** 得分 0.13，每任務 Token 數 23k，耗時 4 分鐘。 * **Gemma 4 26B-A4B (Thinking) (本地):** 得分 0.07，每任務 Token 數 33k，耗時 5 分鐘。
**量化影響分析：** 測試重點在於比較 NVFP4 與 3-bit 量化的影響： * **Flash-Next (僅專家部分 3-bit):** 分數變化 -0.02，Token 數量 x1.03。在 9 個任務的樣本下，幾乎無差異。 * **27B 模型:** 分數變化 +0.05（在噪音範圍內），但每任務生成的 Token 數量增加了 40% (x1.40, CI 1.25-1.59)。儘管 3-bit 27B 在作者的引擎上解碼速度更快（153 vs 132 tok/s），但因生成更多 Token，每個任務仍需 18 分鐘而非 13 分鐘。部分差距來自較慢的 3-bit 預填充路徑（已修復），但在新版本重測中仍顯示 x1.30 的 Token 增長。 * **結論：** 量化的損害並未表現為分數降低，而是表現為模型需要更長的思考時間來達到相同結果。僅看 tok/s，3-bit 27B 看似更好；但按每個 Bug 修復計算，則不然。
**其他觀察：** * **無法編譯的補丁：** Flash-Next 在 3-bit 下有 5/27 個補丁無法編譯（NVFP4 為 1/27）；27B 模型在 3-bit 下為 2/27，NVFP4 下為 4/27。數據未顯示明確趨勢。 * **本地模型定位：** Flash-Next 表現與 Haiku 5.5 相當，優於舊版 Sonnet。Sonnet 5.5 明顯更強，Opus 5.5 領先所有模型。 * **效率對比：** Sonnet 5.5 僅用 8k Token 就比 Flash-Next 用 53k Token 解決了更多問題（每 Bug 耗時 1.5 分鐘 vs 10 分鐘）。 * **架構差異：** Dense 27B 落後於 MoE (Flash-Next)（配對比較 +0.16, P = 0.92），且消耗更多 Token。 * **Gemma 4 表現：** 作為 Agent 效果不佳。關閉思考模式時，在 9 個任務中從未編輯任何文件；開啟思考模式時雖有編輯，但大多錯誤。
**測試限制：** * 僅限於一個代碼庫（GPU 推理領域）的 9 個任務，Bug 報告以義大利語撰寫。 * 結果反映的是模型在作者特定工作上的表現，非通用排名。 * Claude 與本地模型使用了不同的 Harness。 * 法官是 Claude 模型，雖有自動評分校驗且兩者一致，但仍屬限制。 * 無編譯或測試環節，僅測量透過閱讀代碼進行診斷和撰寫補丁的能力，非完整的編輯-構建-測試循環。 * 任務未公開以保持其測試價值。
尚待確認：樣本量僅為 9 個任務，置信區間寬達 ±0.2，統計顯著性有限。
尚待確認：測試僅針對特定領域（GPU 推理）和特定代碼庫，結果不可推廣至通用場景。
尚待確認：Bug 報告以義大利語撰寫，可能影響非母語模型的表現或引入語言偏差。
尚待確認：法官由 Claude Opus 5 擔任，可能存在模型自我偏見，儘管有自動評分校驗。
尚待確認：本地模型與 Claude API 使用了不同的執行環境（OpenCode vs Claude Code），比較基準不完全一致。
尚待確認：測試未包含編譯和執行驗證，僅評估靜態代碼閱讀與補丁生成能力。
