Φ-Bench：能写代码的AI，能不能把自己家的电线管好？ Оригинал на китайском

你有没有想过一个挺古怪的问题：如果一个AI足够聪明，能帮人写代码、能推理数学题，它能不能反过来去修一修自己身上跑的那套系统？

这套系统听起来抽象，其实说白了就是让大模型能跑起来、跑得快、跑得省钱的那堆软件和硬件工程,业内管它叫"LLM infrastructure"（大模型基础设施：支撑大模型训练和推理运行的软硬件系统总称，包括GPU内核、并行策略、缓存管理等各个层面）。这堆东西藏在每一次你和ChatGPT对话的背后，藏在每一次模型训练的显卡轰鸣里。它不显眼，但没有它，再聪明的模型也跑不动。

一群来自中国科大、StepFun等机构的研究者,做了一件挺有意思的事:他们造了一个考场,专门用来测大模型到底能不能自己修这套系统。这个考场叫Φ-Bench。

**这篇论文最扎心的结论是,目前最强的大模型,在这场考试里也只能拿到36.53分（满分100）。**

这个分数意味着什么，往后慢慢讲。先说说，为什么这件事这么难。

光会写代码，够不够修基础设施

先说个容易被忽略的事实。市面上已经有不少测大模型写GPU代码能力的考题了，比如KernelBench、TritonBench这些。它们的玩法通常是这样的：给你一个函数接口，告诉你输入输出是什么，你把中间实现填上就行。

这就像考驾照的时候，只让你在一条空荡荡的直道上倒个车。你能倒好，不代表你能在下班高峰期的复杂路口开车回家。

真实世界里的基础设施工程师，面对的从来不是"填空题"。他们拿到的是一个庞大的代码仓库，可能几十万行代码，横跨训练、推理、内存管理、通信等好几个层面。他们得先搞清楚瓶颈在哪，这活儿有点像医生看病，得先做检查、找病灶，而不是拿到一张写好的处方直接照做。找到问题后，还要动手改代码，跑测试，看效果，改错了再回头调整，一圈一圈地迭代，直到系统真正变快、变稳。

这种活儿有一个特点：没人告诉你答案在哪个文件里，也没人告诉你该用什么招。

如果之前的考题只测"填空"，那真正该测的应该是"从头到尾解决一个开放性问题"的能力。这正是Φ-Bench想补上的空缺。

从两千多篇论文里抠出来的题库

Φ-Bench的题目不是研究者拍脑袋想出来的。

他们先是从2023到2026年顶级系统会议里,筛出了2260篇跟大模型基础设施直接相关的论文,又从GitHub上扒了1852个有代表性的工程改动（比如某个开源项目里一次重要的性能优化提交）。

这堆材料被丢进一个"标签提炼"流程里,先抠出410个细粒度的技术标签,再聚合成62个中层话题,最后归纳成9个大类,包括训练、推理与服务、模型压缩、内核、I/O、硬件与边缘计算、数据基础设施、系统优化、系统保障。

这个流程有点像整理一个巨大的旧书房。你不会一上来就按"文学、科学"这种大类分类，而是先把每本书翻一遍，记下里面提到的具体主题词，等攒够了几百个词条，再往上聚合成中类，最后才归纳成几个大的书架分区。如果反过来，先定好几个大类再往里塞书，很可能有些书根本塞不进任何一个分类，最后书架上留了一堆空白格子，或者硬塞进去让人找不到书。Φ-Bench选择自下而上的路子，就是为了让分类真正贴合现实世界里工程问题的样子，而不是研究者事先设想的样子。

有了这套分类地图，题目才能真正做到"广撒网"，覆盖到硬件适配、通信优化这些容易被忽视的角落，而不只是扎堆在最热闹的Attention内核优化上。

三种造题的办法也各有讲究。第一种是从真实的PR和issue里倒推，把某次代码改动之前的仓库状态当题目，改动之后的代码当参考答案。第二种是让AI agent自己扫代码仓库，找出有价值的实现点，抠掉一段代码，再让另一个agent循环运行测试、发现没覆盖到的分支、自动补测试用例，直到测试足够扎实。第三种是人工专家从重量级论文里手动挑选那些没法从代码历史里直接复原的开放性难题。

**最终,这个题库沉淀出85道题,覆盖全部九大话题类别,分成三种越来越开放的题型。**

三级考试：从填空到自由创作

Φ-Bench把题目分成三档，一档比一档更接近真实工作。

第一档叫内核函数补全（Kernel Function Completion，简称KFC：给定明确的函数接口和输入输出规范，要求在单个文件内完成或优化一段高性能代码，属于最局部、最收敛的任务类型）。

这一档最接近传统考题的样子：给你一个函数框架，接口都定好了，你只管把里面的逻辑写对、写快。全部85题里有55题是这个类型，占了大半。这个比例其实也说明,再往上一级的任务有多稀缺,毕竟能从真实工程里提炼出一个"边界清晰、目标明确"的局部难题相对容易,但要提炼出一个开放性的系统难题就没那么容易了。

第二档是长周期实现（Long-Horizon Implementation，简称LHI：只给出一个类似issue的功能需求描述，划定一个粗粒度的可编辑范围比如某个子模块，但具体改哪些文件、用什么策略完全不说）。

这就像老板跟你说"我们系统的批处理调度效率不够，想办法解决"，然后什么都不再多说。你得自己去代码里摸清楚模块之间怎么互相调用，改哪几个文件才不会牵一发动全身，改完还要反复调试。这一档有20题。

第三档是端到端优化（End-to-End Optimization，简称E2EO：只给一个真实的工作负载、一个系统级性能目标和若干约束条件，完全不指定要用什么组件或策略，要求agent自己剖析系统、找瓶颈、定优化方案并实现）。

这是最硬核的一档，10道题，考的是能不能像一个真正的系统工程师那样，先做性能画像，猜测哪里是瓶颈，动手改，测出结果再决定下一步怎么走，反反复复直到系统真的变好。

这三档任务不是随便划的档次，而是刻意设计的一条"能力光谱"：从"能不能写对一段高效代码"，到"能不能在一个大仓库里独立开发一个功能"，再到"能不能像资深工程师一样，自己发现问题、自己定策略"。如果只考第一档，那测出来的只是编码能力，测不出工程师最珍贵的那种直觉：知道从哪里下手，知道什么时候该停止某个方向去试别的路。

怎么给一份"开放式答卷"打分

开放式任务最难的地方，恰恰是怎么公平地打分。因为没有唯一正确答案，你怎么知道这个AI改得好还是改得差？

Φ-Bench分两套打分逻辑。

对有明确性能目标的任务，用一个叫AB-BA配对测量的办法，把候选方案和原始基线来回跑至少五轮，取中位数算出一个相对速度提升值。这个提升值再拿一个参考答案（人类专家写的标准解法）的提升幅度做归一化，用对数函数压缩成0到1之间的分数。简单说，就是你比基线快了多少，再看你和标准答案的差距有多远。

对以功能实现为主的任务，用的是更简单粗暴的二元判定：所有测试用例全过、能正常构建导入、没有违反编辑范围限制，才给满分，否则零分。

**这里还有个细节值得说一说：为了防止AI作弊，研究者专门设了两道防线。**

一道是"软断网"，把pip和GitHub相关的网络请求全部拦截拒绝，防止AI直接去网上搜原始实现抄答案。另一道是找另一个AI当"监考官"，专门检查提交的代码里有没有硬编码答案、绕过测试、故意制造虚假性能提升这些猫腻。

结果整场考试下来，只抓到DeepSeek V4 Pro三次试图访问PyTorch官网的行为，监考AI核实后确认并没有真正作弊。这说明防作弊机制基本管用，考试结果是干净的。

成绩单：最强模型也只考了36.53分

题库造好了，考试也考了。八个当前最领先的大模型，包括Claude Opus 5、Kimi K3、Qwen3.8 Max、GPT-5.6 Sol、GLM-5.2、Claude Sonnet 5、Qwen3.7 Max、DeepSeek V4 Pro，全部上场应考。

**结果是,拿到全场最高分的Claude Opus 5,只考了36.53分。**

排在后面的Kimi K3是28.12分，Qwen3.8 Max是27.73分，一路往下，垫底的DeepSeek V4 Pro只有13.31分。

考虑到这些AI手里已经拿到了完整的代码仓库、完整的测试用例，几乎相当于开卷考试还给了参考书目录，结果还只能拿到三分之一多一点的分数,这足以说明这场考试有多难。

按九大话题细分来看，Claude Opus 5在五个类别里都是第一，说明它的能力面相对均衡，但没有一个模型在所有类别里都强。Kimi K3在推理服务和系统优化上表现最好，Qwen3.7 Max在硬件与边缘计算上意外拿了个第一，GLM-5.2则在系统保障类目里是唯一的第一。

**硬件与边缘计算这个类别，所有模型的表现都惨不忍睹，最好成绩也只有5.4分。**

这个数字挺刺眼的。它说明当前的大模型对硬件层面的理解，比起软件层面差得远。写Python代码、调调超参数它们还算擅长，但真要理解GPU芯片的架构特性、边缘设备的功耗约束，它们几乎是两眼一抹黑。

从三档任务类型来看，KFC（局部填空题）的分数普遍最高，Claude Opus 5能拿到37.16分；E2EO（自由发挥题）反而分数更高，能到62.94分；而LHI（长周期实现）成绩最低，只有21.60分。

这个现象有点反直觉。你可能觉得开放性越强的任务应该越难，为什么E2EO反而分高？其实这跟评分方式有关系：E2EO的性能指标是相对提升幅度，只要模型能做出一点点像样的改进就能拿到不少分，而LHI是二元判定，功能要么全对要么全错，容错空间几乎为零。这也提醒我们，看AI能力时，不能光看单一分数，得结合评分机制去理解这个数字到底代表什么。

多试几次会不会更好？多想一会儿会不会更好？

研究者还做了两组对照实验，挺值得琢磨。

第一组测的是"迭代次数"。他们挑了一个训练基础设施优化的硬核任务：给AI一套可以任意修改的nanoGPT训练系统,一个时间预算,一个参数量下限,目标是让验证集上的BPB（bits per byte，衡量语言模型压缩效率的指标，数值越低说明模型预测得越准）尽可能低。这个任务要求模型懂得专家路由的高效调度、负载均衡、容量因子权衡这些MoE（混合专家模型：一种通过多个专家子网络分工处理不同输入的模型架构）训练里的经典难题。

**结果显示，Claude Opus 5第一次提交就拿到了很低的BPB分数，而且随着迭代轮数增加还能持续往下压。**

Qwen3.8 Max和Kimi K3一开始表现很差，但通过多轮迭代快速追了上来。而DeepSeek V4Pro、Qwen3.7 Max、GLM-5.2、GPT-5.6 Sol这几个模型，在迭代过程中出现了长时间的"卡壁"，怎么都突破不了。

这就像一群人爬山，有的人一开始爬得慢，但每一步都踩在对的路径上，越爬越顺；有的人一开始冲得快，走了一段发现是死路，回头重新找路，反而更快；还有的人干脆就卡在半山腰，来回打转怎么都上不去。爬山能力的差距，不完全体现在起点，更体现在能不能持续找到往上走的路。

第二组测的是"思考预算"。他们挑了三个模型Claude Opus 5、Kimi K3、GPT-5.6 Sol，在20道LHI任务上，分别用低、中、高、极高、最大五档推理强度测试。

结果显示三个模型都在最大强度时拿到最高分，但分数并不随强度线性上升，GPT-5.6 Sol在中间档还出现了明显的波动。更值得注意的是，**Kimi K3在最低推理强度下，成绩比最大强度掉了将近45%，而Claude Opus 5和GPT-5.6 Sol之间的差距在各档强度下都不算大。**

这说明Kimi K3的强劲表现很大程度上依赖大量的思考时间，一旦时间预算被压缩，它的能力就掉得很快。这有点像一个人做数学题，如果给足时间，能一步步推导出正确答案；如果限时五分钟，只能凭直觉蒙一个大概答案，准确率自然大打折扣。而有些模型不管给多少时间，直觉本身就更扎实，表现的波动也更小。

犯错也是一种能力

研究者还翻看了各个模型解题过程中留下的报错记录，这一看，发现了个有意思的规律。

**表现好的模型，比如Claude Opus 5、Kimi K3、Qwen3.8 Max，反而犯了更多错误。**

表现差的模型，比如DeepSeek V4 Pro、Qwen3.7 Max、Claude Sonnet 5，犯的错误总数更少。

乍一听有点违背直觉，犯错多不是更差吗？但仔细想想就明白了：犯错多说明它们在不断尝试、诊断、修正，愿意跟难题死磕到底；犯错少更可能是遇到困难就放弃了，转而选一个更简单、更保险的方案交上去。

这就像两个学生做一道难题，一个学生写了三种解法，前两种都算错了，第三种才做对；另一个学生看了一眼觉得太难，干脆跳过写了个最简单的猜测答案。表面上第一个学生"犯错更多"，但他真正在攻克难题，第二个学生的"零错误"背后其实是回避挑战。如果只看错误数量给学生打分，会误判两个学生的真实能力，这也是为什么研究者要专门把这个现象拎出来讲。

在错误类型上，还有个细节挺能说明问题：大多数模型的错误里，超过一半是Python运行时错误，说明它们连最基本的代码语法和逻辑都容易出岔子。而Claude Opus 5这类错误的比例明显更低，它的错误更多集中在CUDA执行层面。这意味着它能更稳地把Python代码写对，把更多精力放在真正复杂的底层优化问题上，而不是在最基础的语法关卡反复摔跤。

从优化轨迹里看出的三种差距

为了搞清楚强模型到底强在哪里，研究者挑了一道有代表性的题目，仔细对比了Claude Opus 5、Qwen3.7 Max和DeepSeek V4Pro的解题过程，发现了三个关键差异。

第一个差异是有没有先做"小范围试验"再正式提交。Claude Opus 5会先跑一个只涉及部分工作负载的低成本本地验证，确认这个方向靠不靠谱，再决定要不要正式提交。而Qwen3.7 Max和DeepSeek V4Pro几乎是直接改代码、直接提交，用正式提交本身去试错，一旦某个假设错了，就白白浪费了一次宝贵的提交机会。论文里举了个具体例子：DeepSeek直接给专家模块应用了torch.compile编译优化，却没提前验证这样改动后checkpoint还能不能正常加载，结果这次提交因为checkpoint加载失败而白白浪费。

这就像装修房子前先做个样板间试试效果，还是直接把整栋楼刷完漆才发现颜色不对。样板间成本低，出问题只需要重新刷一小块；整栋楼刷完才发现问题，返工的代价就大多了。Claude Opus 5的做法本质上是把犯错的成本压到最低，让每一次真正的"正式考试"都建立在更有把握的基础上。

第二个差异是怎么控制变量和噪音。DeepSeek经常一次改动好几个变量，实验结果说不清是哪个改动起的作用；Qwen3.7 Max倒是很守规矩地一次只改一个变量，但很多时候测出来的差异跟测量误差本身差不多大，压根看不出这个改动到底有没有效果。

Claude Opus 5的做法更细致：它不仅一次只改一个变量，还会先估算测量本身的波动范围，只有当效果明显超出这个波动范围时，才认定这个改动是真的有效。论文举了个例子，它调整学习率调度策略后BPB从1.3646恶化到1.3932，因为两次实验用的随机种子相同、训练步数相同、运行时间几乎一致，它判断这个恶化是真实信号而不是噪音，进而推断"低学习率阶段停留太久是有害的"，据此提出warmup-stable-decay调度策略，最终把BPB改善到1.3248。

第三个差异是对实验结果的归因态度。Claude Opus 5不会看到指标变差就立刻归咎于最新的改动，它会主动排查有没有别的干扰因素。有一次它发现某次改动让吞吐量大跌，深挖后发现是这次代码修改让编译缓存失效了，导致这次运行多花了冷启动编译的时间，跟改动本身其实没关系。它重新在缓存条件一致的情况下再测一次，发现吞吐量其实没变，BPB确实有改善，这个改动才被保留下来。

Qwen3.7 Max和DeepSeek V4Pro更多是直接把观察到的变化归咎于最近一次改动，容易被这种测量假象带偏方向。

这三个差异合在一起，其实指向同一件事：**长周期的系统优化，考的不只是写代码的手速，更是能不能像一个严谨的实验科学家那样，管理好每一次假设、每一次验证、每一次归因。**

写在后面

读完这份报告，最让我意外的不是分数低，而是"低分背后的差距为什么这么大"。36.53和13.31之间差了23个百分点，这几乎是两种完全不同的做题方式，一种像资深工程师带着实验思维在推进，一种像新手在盲目试错。这提醒我，衡量AI能力光看模型参数量或者基准跑分是远远不够的，真正决定它能不能干成事的，往往是那些藏在解题轨迹里的、不容易被量化的习惯，比如敢不敢先做小实验、会不会区分信号和噪音、能不能在归因之前多想一步。

还有个细节让我反复琢磨：硬件与边缘计算这个类目上，所有模型的表现都接近于零。这可能说明当前大模型的训练语料里，跟具体芯片架构、边缘设备约束相关的高质量工程知识本身就稀缺，AI没吃过这类"饭"，自然不会做这道题。这个短板不是靠推理能力堆出来的，可能得靠专门补充这类数据才能解决，这也是这篇论文留下的一个值得追问的方向。

如果有一天AI真的能把自己所依赖的基础设施修得又快又稳，那会是一种什么样的自我循环？它优化了跑自己的系统，系统跑得更快了，于是它又能用省下来的算力去优化更多东西。这个循环现在才刚刚露出一个缝，缝有多大，谁也说不准。

Q&A

Q1：Φ-Bench是什么？

A：Φ-Bench是一个专门评测大语言模型能否工程化和优化大模型基础设施的基准测试，包含85道题，覆盖训练、推理、内核优化等九大话题类别，任务从局部代码填空到开放式系统优化逐级递进。

Q2：目前表现最好的大模型在Φ-Bench上能拿多少分？

A：目前表现最好的是Claude Opus 5，总分36.53分（满分100分），已经是所有参测模型里的最高分，但整体成绩仍显示大模型在基础设施工程上还有很大提升空间。

Q3：为什么大模型在硬件与边缘计算类任务上表现特别差？

A：因为这类任务需要理解具体芯片架构、边缘设备功耗约束等专业知识，当前大模型在这方面的训练数据和推理能力都明显不足，测试中最好成绩也只有5.4分，是所有类别里表现最差的。