AI 評測與基礎設施
Φ-Bench 用 85 項真實基礎設施任務測試程式代理，最佳模型總分仍僅 36.53%
Φ-Bench 將評測範圍從單一 GPU kernel 擴大至跨檔案實作與端到端系統最佳化。八款前沿模型都能偶爾找到有效修改，但推理預算增加並未穩定轉化為更好的工程結果。
新公開的 [Φ-Bench 論文](https://arxiv.org/abs/2609.10226)嘗試回答一個自我指涉的工程問題：大型語言模型能否改進支撐自身訓練與推論的軟體堆疊？它沒有把測試侷限於生成一段 Triton 或 CUDA kernel，而是從系統研究及公開程式庫整理出 85 項任務，涵蓋 GPU kernel、分散式訓練、推論服務、量化、通訊、檢查點、MoE 路由與注意力等九類基礎設施。
任務分為三層：55 項 Kernel Function Completion 已指定函式與介面；20 項 Long-Horizon Implementation 只描述功能，代理須自行尋找修改位置；10 項 End-to-End Optimization 則只給系統目標與限制。公開的[專案頁面](https://faibench.org/)顯示，每題以 Docker 環境執行，長任務允許多輪修改，並按正確性或相對參考實作的效能計分。這使評測更接近「讀取既有系統、定位瓶頸、修改、量測再迭代」，而非一次性程式補全。
論文測試八款前沿模型；Claude Opus 5 的加權總分最高，但也只有 36.53%。它在 KFC、LHI 與 E2EO 分別取得 37.16%、21.60%及 62.94%。軌跡分析指出，較強模型傾向一次只改一個變因、建立較穩定的本機驗證，再把失敗結果用來縮小搜尋範圍；較弱模型則常在雜訊範圍內反覆調參。提高推理 effort 並未帶來單調增益，GPT-5.6 Sol 在中間設定尤其不穩定。
這套基準的價值在於暴露程式代理於效能工程中的探索與實驗設計能力，但分數不能直接解讀為一般 Infra 工程生產力。效能錨點依 NVIDIA H20 或作者的 Sapphire Rapids CPU 校準，換硬體必須重做基線；模型使用的代理框架也不完全相同。工程團隊接下來應關注第三方能否重現排行榜，以及模型是否只適應公開測試與特定硬體。