36.5% 無所遁形：Φ-Bench 檢驗前沿 LLM 能否親手打造驅動自己的基礎設施

一個運行在整座資料中心 GPU 之上的模型，能否真正改善訓練並服務它這類模型的軟體堆疊？這是 Φ-Bench（Frontier AI Infrastructure Benchmark，前沿 AI 基礎設施基準）背後那個看似天真的問題。這項基準於 9 月 9 日發布，背後是橫跨中國科學技術大學、StepFun（階躍星辰）、北京大學、香港科技大學、耶魯大學與賓夕法尼亞大學的 13 人團隊。答案——至少對這一代前沿模型而言——是：還不行。而 Φ-Bench 是第一個針對「到底差多遠」給出嚴謹、可重現測量的基準。

Φ-Bench 到底測什麼

多數 LLM 編碼評測都安逸地活在玩具世界裡：補完一個函式、修一個 bug、針對預先指定的目標優化某個算子。Φ-Bench 刻意拒絕這種框架。它的 85 項任務源自前沿系統研究中探討過的優化問題，並扎根於真實的公開程式碼庫；三種任務格式的開放程度逐級攀升：

• 核心函式補完（KFC，55 項任務）——局部的核心層級實作：撰寫整個系統賴以運作的運算基元。
• 長程實作（LHI，20 項任務）——倉儲級工程：導覽既有的基礎設施程式碼庫、理解它，並實作能通過所有測試的重大變更。
• 端到端優化（E2EO，10 項任務）——最開放的形式：給定一個可完全編輯的系統、執行時間預算與參數量下限，最小化真實目標，例如 nanoGPT 訓練設置上的驗證 bits-per-byte。

為了建構這套基準，團隊從 2,260 篇論文與 1,852 個倉儲產物中自下而上建立現代 LLM 基礎設施的分類法，再利用基於代理迴圈（agent-loop）的管線自動從倉儲中挖掘高價值工程挑戰、反覆生成測試案例——這是對「人工策展的工程任務根本不足以支撐這種規模」這一事實的務實回應。

計分方式刻意嚴苛。每次嘗試都以正確性為門檻：可建構性、功能正確性、編輯限制與防作弊檢查全部通過之前，任何獎勵都不會發放。效能類任務採用 AB-BA 配對測量協議（至少五個測量對），並相對參考解進行對數正規化；實作類任務則是嚴格的二值計分——唯有解方案能建構、能匯入、通過每一個測試案例並遵守所有禁止編輯限制，才能拿到滿分。

而且因為前沿模型都很「機靈」，基準內建兩套互補的監考機制：基於規則的監視器掃描完整的解題軌跡，搜尋禁止行為（例如在 GitHub 上搜原始實作、拉取上游 patch diff、從已發布的 Python 套件還原程式碼）；另有一個專職監考代理檢查更隱晦的作弊，像是寫死預期輸出、繞過正確性檢查，或插入人為拉高測得效能的分支。被抓到作弊，該次嘗試直接歸零。

結果：三分之一的路程

頭條數字很清醒。Claude Opus 5 以 36.53% 的總分居榜首，其次是 Moonshot 的 Kimi K3（28.12%）與 Qwen3.8 Max（27.73%）。GPT 5.6 Sol 拿到 24.51%，GLM 5.2 得 21.92%，Claude Sonnet 5 則是 17.58%。別忘了這些代理握有什麼：完整程式碼庫、測試案例，每項 LHI/E2EO 任務最多 16 次候選提交，跑在一張 NVIDIA H20 GPU、32 GiB 記憶體與八核 CPU 之上。即使擁有人類工程師所能企求的一切優勢，最強的模型也只勉強越過滿分的三分之一。

分類別的拆解才是故事精彩之處。Claude Opus 5 在九個基礎設施領域中的五個領先（訓練、I/O、資料基礎設施、核心等），但沒有任何模型全面強悍：Kimi K3 在推理與服務（Inference & Serving）和系統優化上最佳；Qwen3.7 Max 意外地在硬體與邊緣（Hardware & Edge）稱雄；GLM 5.2 則以 57.40% 稱霸系統保障（System Assurance）——這是 Claude 訓練類分數之外全場最高的單一類別得分。

硬體與邊緣則是墳場：九個受測模型中最高分只有 5.4%，GPT 5.6 Sol 與 Claude Sonnet 5 等多個模型直接掛零。作者結論直言：現今的前沿模型對 AI 基礎設施的硬體面向理解仍然不足。

堅持比聰明更重要

錯誤模式分析帶來全論文最反直覺的發現：產生較多錯誤的模型得分更高。Claude Opus 5、Kimi K3 與 Qwen3.8 Max 的錯誤數都偏高，因為它們持續挑戰困難任務，歷經一輪輪嘗試、診斷與修正。較弱的模型如 DeepSeek V4Pro 與 Qwen3.7-Max 錯誤較少——因為它們較早放棄，或退回簡單解。拉開差距的不是首發命中率，而是撐過失敗的續航力。

Claude Opus 5 的錯誤構成也獨樹一幟：Python 執行期錯誤占比顯著低於同儕，錯誤集中在 CUDA 執行。它第一次嘗試就能寫出在倉儲內正常運作的 Python，把迭代預算留給真正困難的低階問題。

nanoGPT 端到端任務的案例研究——模型必須透過 token 分派、負載平衡與容量因子調校來優化混合專家（MoE）訓練設置——讀來像一本「好與壞的實驗方法學」野外指南。Claude Opus 5 建立輕量的本地驗證實驗，先便宜地篩選假設再提交正式方案，先廣泛探索再聚焦。DeepSeek V4Pro 則沒先驗證 checkpoint 相容性就對專家模組套用 torch.compile，checkpoint 載不進來，白白燒掉一次提交。Qwen3.7 Max 做了紀律嚴明的單變數實驗，差異卻小於量測雜訊。強的基礎設施工程，說到底長得像強的科學：控制變因、尊重雜訊底線、謹慎歸因。

還有一個清醒的數據點：推理預算並不能穩定換來效能。在 20 道 LHI 題目上以不同推理努力程度評測，三個模型都在最高檔位達到峰值，但分數不隨預算一致上升——GPT 5.6 Sol 尤其出現明顯的非單調性。

為什麼重要

AI 產業的經濟學目前押在一個賭注上：演算法與基礎設施效率的提升會持續複利。基礎設施層級的優化正是 GPU 利用率得失、運算成本消長之處——一次訓練是擠得進預算還是擠不進，差別就在這裡。如果 LLM 代理能可靠地完成這類工作，「AI 改善 AI」的迴圈就從修辭變成現實。

Φ-Bench 讓誠實的測量成為可能：公開排行榜、Hugging Face 上的資料集、GitHub 上的完整評測架構。它也悄悄勾勒出下一個競爭前沿的形狀。所有模型的長程實作（LHI）分數都低於核心補完（KFC）——倉儲級、開放式工程是所有人的痛處。而硬體與邊緣任務的近乎全滅，恰恰對應到當今產業最迫切的技能：加速器供給吃緊，每一瓦功耗、每一 GB 的 HBM 都是兵家必爭之地。

在這個基準上拿三分之一的模型，是一位耐心無限的初級工程師。拿到 80% 的模型將完全是另一回事——而 Φ-Bench 現在就是那把量尺，會在那一刻到來時告訴我們。

Φ-Bench 可於 faibench.org 取得，資料集在 Hugging Face，評測架構在 GitHub。