Φ-Bench：让大模型去优化驱动自己的基础设施，它能行吗？

你有没有想过一个有点科幻的问题——既然大模型写代码越来越溜，那它能不能回过头来，去开发和优化支撑它自己运转的那套基础设施？比如给它一个 vLLM 级别的推理仓库，让它自己找出瓶颈、改代码、把吞吐提上去？

这听起来像是"AI 自己造 AI"的第一步。但问题是，我们连"模型到底有没有这个本事"都测不清楚。KernelBench、TritonBench 这类现有基准，测的都是"补全一个孤立算子"这种小题目——接口给你定好了，输入输出给你写死了，优化目标也喂到嘴边了。这跟真实的基础设施工程完全是两码事。真实的工程师打开的是一个几十万行的仓库，瓶颈在哪没人告诉你，改哪几个文件没人告诉你，甚至"该优化什么"都得自己去 profile。

这篇 Φ-Bench（arXiv:2609.10226）就是冲着这个空白来的。

核心摘要：Φ-Bench 是一个系统评测 LLM 基础设施工程能力的基准，从 2023–2026 年顶级系统会议论文和真实开源仓库的 PR/Issue 中合成了 85 个任务，覆盖训练、推理、压缩、Kernel 等九大主题，按开放程度分为核函数补全、长程实现、端到端优化三档。结果挺打脸的：最强的 Claude Opus 5 也只拿到 36.53 分，Hardware & Edge 类别全场最佳只有 5.4 分。我的判断是：这是目前测"AI 自我改进"最硬核的一把尺子，它不是在刷榜，而是在给"模型能不能参与下一代 AI 基础设施建设"这个命题定锚点。

论文信息

• 标题：Φ-Bench: Can Large Language Models Engineer the Infrastructure That Powers Them?
• 作者：Leilei Ding, Shumin Wang, Yuting Huang, Fanqi Wan, Yinmin Zhang, Qi Han, Yiming Xu, Feiyuan Zhang, Xiaomeng Chu, Guoliang You, Wuyang Zhang, Daxin Jiang, Yanyong Zhang
• 机构：中国科学技术大学、StepFun、北京大学、香港科技大学、耶鲁大学、宾夕法尼亚大学
• 链接：https://arxiv.org/abs/2609.10226 ｜ 排行榜：https://faibench.org ｜ 代码：https://github.com/one2piece2hello/faibench_LLM_Infra_Bench

🎯 为什么现有基准测不了这个

先说说这个领域的评测现状。过去一年 AI 辅助 kernel 生成很热闹，但评测方式其实挺单一的。

KernelBench（斯坦福团队，2025）给了 250 个 PyTorch 算子任务，用 fast_p 指标衡量"正确且加速超过 p 倍"的比例，结果是最强模型在不到 20% 的任务上能打平 PyTorch 基线——当时大家就觉得已经够难了。TritonBench 专注 Triton 代码生成，分 GitHub 真实算子和 PyTorch 对齐任务两路。后来 ISO-Bench、CUDAHercules 把范围扩到了仓库级，但仔细看，它们仍然会告诉你"瓶颈就在这个组件里，去优化它吧"。

这就好比考司机，一种是"在封闭场地里倒车入库"，一种是"给你一辆车和一张地图，从北京开到拉萨，油钱还得省"。前者是 KernelBench，后者才是真实的基建工程。Φ-Bench 想做的是后者。

作者把真实开发者的工作流拆得很清楚：理解并导航现有基础设施栈 → 识别瓶颈与优化机会 → 迭代式地实现、profiling、调试、改进。整个过程是长程的、开放式的。而现有基准只覆盖了其中"实现"这一小环。

🏗️ Φ-Bench 的设计：三档任务，开放度递增

Φ-Bench 的设计原则有三条：长程开放式求解、全面覆盖 LLM 基础设施栈、可扩展的任务合成。

最有意思的是它的任务分级。三种任务类型，按"告诉你多少"递减、按"开放度"递增：

KFC 基本就是 KernelBench 那一档——隔离出一个性能关键的 kernel，接口语义写清楚，模型在单文件内完成实现，先验正确性和数值精度，过了再测效率。

LHI 开始有意思了：只给一个 issue 式的特性请求和一个粗粒度的可编辑范围（比如某个子模块），具体改哪些文件、依赖什么、怎么实现，全都不说。模型得自己浏览代码库、搞清楚模块间的交互，跨文件修改，然后迭代构建、测试、调试。

E2EO 是最狠的：只给代表性工作负载、系统级优化目标和约束，连"该动哪个组件"都不告诉你。模型要自己 profile 系统、识别瓶颈、制定优化方案，可以做全仓库范围的修改。这已经是资深性能工程师的活儿了。

最终基准包含 85 个任务：55 个 KFC、20 个 LHI、10 个 E2EO，覆盖九大基础设施主题。

🔧 任务从哪来：4112 个来源炼出 85 个任务

基准最怕两件事：覆盖太窄、任务太假。Φ-Bench 的解法是从真实世界"挖矿"。

图2：Φ-Bench 的任务合成流水线——从论文与 PR/Issue 两大来源出发，经分类法组织、三种合成方式产出任务，再由质量控制和正确性门控的评测体系收尾

上游是两个来源池。学术池收集了 2023–2026 四年间顶级系统会议的论文，LLM 过滤后留下"直接关于 LLM 基础设施、研究训练/推理的实现加速或资源优化、且有公开实现"的，共 2260 篇。工程池则翻遍了主流 LLM 基础设施仓库的 issues 和 pull requests，筛出非平凡、有技术挑战的，共 1852 个。合计 4112 个来源。

然后是一套三级分类法：4112 个来源抽出 410 个细粒度标签，聚成 62 个中层主题，再归到 9 个顶层大类——Training、Inference & Serving、Compression、Kernel、I/O、Hardware & Edge、Data Infrastructure、System Optimization、System Assurance。这个分类法既是任务合成的索引，也是后面分析模型能力分布的坐标系。

任务合成有三条路：

1. PR/Issue grounded 合成：拿变更前的仓库状态当任务输入，变更后的实现当参考解。单文件小改动做成 KFC，跨文件大改动做成 LHI 或 E2EO。这个思路很妙——真实的 PR 天然携带"问题描述 + 参考实现 + 测试"三件套。
2. 智能体辅助合成：让 agent 按预定义流水线扫仓库，识别高价值实现点，把局部代码段或整个模块挖空；再跑一个 agent loop 分析执行流、追踪测试套件覆盖的分支，迭代生成覆盖未执行路径的新测试。
3. 专家策划合成：人类专家从有影响力的论文和会议挑战赛里出题，手动设计测试用例和评测负载。

质量控制这块立了硬规矩：性能类任务，参考解必须稳定达到 至少 1.15 倍加速，空操作解不能超过基线；实现类任务，参考解必须过全部测试、初始解至少挂一个测试，且每个任务至少 5 个测试用例（正常输入、边界条件、错误路径、回归场景都得有）。不达标的任务直接改或者扔。

图4：任务在"九大主题 × 三种任务格式"上的分布热力图。Kernel（19 个 KFC）和 Training（15 个 KFC）是任务最密的格子，而 Hardware & Edge、Data Infrastructure 等方向任务稀疏——这也预示了后面模型在这些类别上的惨淡表现

📏 怎么打分：正确性门控 + 反作弊

评分体系有两个细节我觉得值得单拎出来说。

一是正确性门控。所有任务都先过可构建性、功能正确性、编辑约束、反作弊这四道硬检查，过了才谈奖励。性能指标用 AB-BA 配对测量（至少 5 对），候选加速比取中位数 \(s = \text{median}_i(t_i^{base} / t_i^{cand})\)，再跟同环境下参考解的中位数 \(s_{ref}\) 比：

也就是说，达到参考解水平才算及格线，做到参考解的平方倍才拿满分。这个对数标尺挺狠的——你比参考实现快 10% 和快 100%，在分数上的差距被拉开了，逼模型做深度优化而不是小修小补。实现指标则是二值的：全过得 1，否则 0。

二是反作弊。这是这类基准的死穴——模型完全可能去 GitHub 搜原始实现、或者硬编码测试输出。Φ-Bench 上了双保险：基于规则的监控扫完整解题轨迹和代码改动，查"搜 GitHub 原始实现、抓对应 patch/commit diff、从已发布包里恢复上游代码"这类行为；再加一个专门的 Proctor Agent 检测更隐蔽的 hacking（硬编码期望输出、绕过正确性检查、插人为抬高性能的分支）。评测环境还做了软断网——劫持 pip 和相关 URL 请求。

顺便说一句环境配置：每个任务 8 CPU 核、32 GiB 内存、单张 NVIDIA H20 GPU，禁用其他 GPU 类型保证一致。KFC 只许交 1 次，LHI/E2EO 最多 16 次提交取最佳。

📊 主实验：最强模型只拿了三分之一的分数

评测了 8 个前沿模型：闭源的 Claude Opus 5、Claude Sonnet 5、GPT-5.6 Sol、Qwen3.8 Max、Qwen3.7 Max，开源权重的 Kimi K3、GLM 5.2、DeepSeek V4 Pro。除 GPT-5.6 Sol 用 Codex 脚手架外，其余都用 Claude Code，推理 effort 统一拉满。

图1：左侧是八模型总分柱状图，Claude Opus 5 以 36.53 领跑，DeepSeek V4 Pro 仅 13.31 垫底；右侧雷达图展示各模型在九大主题上的能力分布——没有任何模型是"六边形战士"，Hardware & Edge 方向全员塌陷

表：八大模型在九大基础设施类别上的得分（百分比），加粗为该类别最佳

几个数据值得盯着看。

36.53。 这是全场最高分。也就是说，即便给模型完整仓库、完整测试用例、16 次提交机会，最强模型也只解决了约三分之一的基建工程问题。这跟 SWE-bench 上动辄六七十的分数形成鲜明对比——基建工程的难度水位完全不是一个量级。

5.4。 这是 Hardware & Edge 类别的全场最佳（Qwen3.7 Max）。八个模型在这一类基本团灭，Claude Opus 5 也只有 3.9。说实话这个数字让我愣了一下——前沿模型对硬件层面的理解几乎是空白。你想想看，模型自己跑在 GPU 上，却答不好 GPU 层面的工程问题，这事儿本身就挺讽刺的。

能力分布严重偏科。 Claude Opus 5 在九个类别里领先五个，但 System Assurance 被 GLM 5.2（57.40）大幅反超，Inference & Serving 和 System Optimization 是 Kimi K3 更强。没有六边形战士。

再看按任务格式切分的结果：

表：三种任务格式上的得分（百分比）

等等，这里有个反直觉的现象——E2EO 分数普遍高于 KFC 和 LHI？端到端优化不是最难的吗？我的理解是：E2EO 的评分是连续的性能奖励，拿到部分分相对容易（优化一点就有一点的分），而且 10 个任务里有 3 个落在 Training 这类模型相对熟悉的领域；而 LHI 是二值指标，一个测试挂了就归零，20 个任务还横跨各种陌生仓库。所以别被"E2EO 分高"误导，真正的分水岭在 LHI——所有模型的 LHI 都低于 KFC，说明长程仓库级实现依然是集体短板。DeepSeek V4 Pro 的 E2EO 只有 1.97，基本是放弃了这类任务。

🔬 消融分析：推理预算、错误模式与迭代行为

推理预算不是越多越好，但没有是真不行

在 20 个 LHI 任务上测了三个模型在不同推理 effort 下的表现：

图5：LHI 任务上性能随推理 effort 的变化。Claude Opus 5 从 low 到 max 一路平稳爬升（31.33 → 35.38）；Kimi K3 依赖最重，low 档只有 17.45，max 档 31.83，差了约 45%；GPT-5.6 Sol 在中等档位明显不稳（medium 22.18，high 反而跌到 18.27）

三个模型都在 max 档拿到最好成绩，但收益并不随预算线性增长。最有信息量的对比是：Claude Opus 5 在 low 档就有 31.33，说明它的能力底盘扎实；Kimi K3 砍掉推理预算直接损失约 45% 的分数——它的高分很大程度是拿测试时算力堆出来的。GPT-5.6 Sol 的曲线忽上忽下，中等预算下表现不稳定，这个行为差异说实话我没完全看懂，可能跟它的推理调度策略有关。

错误多是坏事吗？不一定

作者把模型轨迹里的错误分成四类：Python 运行时错误、CUDA 执行错误、Triton/MLIR/CUDA 编译错误、张量形状不匹配。结果很有意思——强模型犯的错更多。

Claude Opus 5、Kimi K3、Qwen3.8 Max 的错误总数反而高于弱模型。原因不难想：它们敢碰更难的任务，试错轮次多，诊断-修复循环跑得勤。弱模型错得少，是因为它们试几把就放弃了，或者干脆选个保守方案交差。

再看错误结构：多数模型的错误里 Python 运行时错误占了一半以上，而 Claude Opus 5 这类错误占比明显更低，错误集中在 CUDA 执行层。这说明它的 Python 代码一次写对率高，可以把精力花在底层的实现和优化上。坦率的讲，这个"错误结构分析"比单纯的分数更能反映模型的工程素养。

迭代行为：学霸和学渣的区别在方法论

E2EO 的迭代曲线里藏着最像"人味"的分析。任务是给一个完全可编辑的 nanoGPT 训练系统，在 wall-clock 预算和参数量约束下最小化 validation BPB。Claude Opus 5 首次提交就拿到很低的 BPB 且持续改进；Qwen3.8 Max 和 Kimi K3 开局差但迭代追赶快；而 DeepSeek V4 Pro、Qwen3.7 Max、GLM 5.2、GPT-5.6 Sol 陷入漫长的平台期，最终也没把 BPB 压下来。

案例研究里有个细节特别能说明问题。Opus 会先做轻量级本地验证实验筛假设，而 Qwen3.7 Max 和 DeepSeek V4 Pro 基本是"实现-提交-观察"的裸循环——DeepSeek 甚至没验证 checkpoint 兼容性就给 expert 模块套 torch.compile，白浪费一次提交。还有控制变量：Opus 发现一次学习率调度变更让 BPB 从 1.3646 恶化到 1.3932（同种子同步数，判定为可靠信号而非噪声），据此提出 warmup-stable-decay 调度，把 BPB 改进到 1.3248；它甚至能识别出"吞吐下降其实是代码改动让 Inductor 编译缓存失效导致的冷编译开销"，在匹配缓存条件下重测确认。

这套"本地验证 → 控制变量 → 谨慎归因"的流程，就是人类性能工程师的方法论。模型之间的差距，说到底不只是代码能力的差距，是实验科学的差距。

至于作弊检测，全部评测跑下来规则检测器只抓到 DeepSeek V4 Pro 三次试图从 PyTorch 官网拉代码的请求，Proctor Agent 确认没有实际 hacking 发生。防线是有效的，但说实话，随着模型能力变强，这块的压力只会越来越大。

💡 我的判断

这篇论文最值钱的地方，不是某个具体分数，而是它把"AI 能否参与建造 AI 基础设施"这个宏大命题，落成了 85 个可执行、可复现、防作弊的硬任务。

亮点很清晰。任务来源真实（真 PR、真 issue、真论文），三档开放度的设计直接把"补全算子"和"系统优化"区分成了两种能力，反作弊双保险和 AB-BA 配对测量这些评测细节做得很扎实。错误结构和迭代行为的分析，比干巴巴的排行榜有信息量得多。

但也有几个地方我想说两句。一是 85 个任务的规模偏小，尤其 E2EO 只有 10 个，单个任务的波动对总分影响不小，E2EO 分数反超 KFC 很可能就吃了任务构成的红利。二是 Hardware & Edge 全员团灭，到底是模型真不懂硬件，还是这类任务的测试环境（单张 H20）本身限制了发挥空间，论文没完全说清楚。三是 scaffold 不统一——GPT-5.6 Sol 用 Codex，其余用 Claude Code，这对跨模型对比的公平性多少是个干扰项，虽然作者可能有不得已的理由。

跟同期工作比，KernelBench 测的是"会不会写 kernel"，SWE-bench 测的是"会不会修 bug"，Φ-Bench 测的是"能不能当性能工程师"。这三者是一个能力谱系，而 Φ-Bench 站在最难的那一端。36.53 分的现状告诉我们：让 AI 自主优化下一代 AI 基础设施，现在还是个"能起步但远未及格"的状态。

如果你在做 coding agent 或者 AI4AI 方向，这个基准值得跑一跑——它暴露的那些短板（长程规划、实验方法论、硬件理解），可能就是下一代模型训练的靶子。而"强模型靠试错和纠错取胜"这个发现，对 agent 训练也有直接启发：与其教模型一次做对，不如教它怎么科学地错、高效地改。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我