Φ-Bench：大语言模型AI基础设施工程能力评测基准 Φ-Bench: Can Large Language Models Engineer the Infrastructure That Powers Them?
用85个源自真实论文与仓库的任务，测出最强模型仅36.53%的基础设施工程能力
前置知识
LLM 基础设施栈
支撑大模型训练与推理的整套软件系统，包括计算层（CUDA/Triton 内核、FlashAttention）、训练框架（Megatron-LM、DeepSpeed 的并行与通信优化）、推理服务（vLLM、SGLang 的 KV cache 管理与 continuous batching）以及量化、MoE 路由、容错等横切组件。论文将其归纳为九大主题：训练、推理与服务、压缩、内核、I/O 与边缘、数据基础设施、系统优化、系统保障、硬件。
本文的核心问题是“LLM 能否工程化这套基础设施”，Φ-Bench 的 85 个任务正是按这九大主题组织，读懂任务分布和分类法必须先理解这个栈的分层结构。
GPU 内核与 Triton/CUDA 编程
内核（kernel）是跑在 GPU 上的高性能计算函数，如 GEMM、attention。CUDA 是 NVIDIA 的底层编程模型，Triton 是 OpenAI 提出的更上层 DSL 编译器。KernelBench、TritonBench 等先前基准都聚焦于让 LLM 完成单个内核函数的实现与优化。
Φ-Bench 的 KFC 任务格式直接继承这一传统（55/85 个任务），而 LHI/E2EO 则是在此之上向仓库级、系统级的扩展，理解内核优化才能看清三种任务格式的难度梯度。
Agentic Benchmark（智能体评测）
不再只给模型一道题让它一次作答，而是给 agent 一个可执行环境（代码仓库、测试、构建工具），让它多轮导航、编辑、运行、调试后提交方案。评测通常配合脚手架（scaffold，如 Claude Code、Codex）和提交次数预算，考察的是完整的工程工作流而非单轮代码补全。
Φ-Bench 本质上是一个 agentic benchmark：模型以 agent 形态在真实仓库里工作，论文的大量结论（迭代改进、错误模式、案例研究）都来自对 agent 工作轨迹的分析。
加速比与 AB-BA 配对测量
加速比 $s$ 定义为基线耗时与候选耗时之比 $s = \text{median}_i(t_{base,i} / t_{cand,i})$。GPU 计时受频率、缓存等噪声影响，AB-BA 协议指交替先测基线再测候选（再反过来）至少 5 对，取中位数以抵消系统性的时序漂移，是系统论文的标准测速方法。
Φ-Bench 的性能奖励完全建立在这个测量协议上：$R_{\text{perf}}=\min(1, \ln(s/s_{ref})/\ln s_{ref})$，理解它才能看懂评分为何对数封顶、参考解为何要求至少 1.15 倍加速。
长程开放任务（Long-horizon Open-ended Task）
指没有预先指定答案路径、需要几十轮以上工具调用才能完成的任务：agent 要自己读代码库、定位瓶颈、提出假设、实现并验证。与之相对的是函数级补全这类“接口和目标都已写死”的短程任务。
论文反复论证现有基准缺的正是长程开放性，LHI 和 E2EO 两种任务格式以及“推理预算是否带来收益”的消融实验，都是围绕这一概念设计的。
研究动机
现有评测 LLM 基础设施能力的基准存在三类具体缺陷。其一是粒度过细：KernelBench、TritonBench、FlashInfer-Bench 主要考察单个 GPU 算子或融合算子，接口、输入输出规格和优化目标都是预先定义好的，模型只需在单文件内填函数；ISO-Bench 和 CUDAHercules 虽然扩展到了仓库级 GPU 优化，但任务仍然明确指定了目标组件和性能瓶颈，模型不需要自己去发现问题。其二是缺乏开放性：真实的基础设施工程要求开发者先理解并导航一个现有代码库，再定位瓶颈和优化机会，然后迭代地实现、profile、调试、改进——这个端到端流程远超单次提交（single-commit）式的代码修改，而现有基准完全测不到这种能力。其三是覆盖面窄：已有基准只涉及 LLM 基础设施的一小部分主题（主要是内核），无法回答“这个模型能否开发和优化现代 AI 基础设施”这一完整问题。
本文的目标是本文要构建一个长程、开放、覆盖全面的系统化基准 Φ-Bench（Frontier AI Infrastructure Benchmark），评测前沿 LLM 在真实 LLM 基础设施栈上的工程能力。具体目标有三：第一，任务必须源自真实研究和工程实践，从顶级系统会议论文和公开 LLM 基础设施仓库中挖掘，而非人造的合成编程题；第二，建立一套自底向上的覆盖分类法（最终从 4,112 个来源提炼出 410 个细粒度标签、62 个中层主题、9 个大类），保证任务覆盖基础设施栈的每个角落；第三，开发可扩展的任务合成管道，突破人工策展工程工件的供给瓶颈，自动从仓库中挖掘高价值挑战并生成完备测试。最终用这个基准系统评测 8 个前沿模型，刻画其能力边界并给出改进方向。
与已有工作不同的是，本文的独特切入角度有三点。第一，视角从“做题”转向“工程”：不同于以函数完成为中心的基准，Φ-Bench 设计了 KFC→LHI→E2EO 三级任务格式，可编辑范围从单文件逐级放大到整个仓库，目标从指定函数放大到只给一句系统级目标，形成一条连续的能力评估谱系。第二，任务合成带真实溯源：PR/Issue 溯源合成直接把真实仓库变更前的状态作为题目、变更后的代码作为参考解，保留了原始工程意图；再辅以 agent 辅助合成和专家策展两条管道解决规模问题。第三，引入分类法引导的可扩展构建方法学：用 410 个细粒度标签反查覆盖盲区，指导后续任务向未覆盖的主题补齐，这让基准的扩展从“凭感觉加题”变成“按地图填空”。
核心方法
直觉上，Φ-Bench 在问：如果把一个 LLM agent 当作 AI 系统组的实习生，它能不能从修一个内核函数做起，逐步接手在大型仓库里实现新特性，最终独立完成“只给目标不给路径”的全系统优化？技术路线上，论文分四步搭建这个基准：首先从 2023–2026 年顶级系统会议论文和公开仓库的 issue/PR 中收集并过滤出 2,260 篇论文和 1,852 个工程工件（共 4,112 个来源）；然后用 LLM 对每个来源做三级标注，构建覆盖分类法；接着通过三条互补管道合成任务——PR/Issue 溯源、agent 辅助、专家策展；最后配上一套“正确性先行”的评测协议（硬性有效性门 + 连续性能指标或二值实现指标 + 双重反作弊机制）。最终产物是 85 个任务：55 个 KFC、20 个 LHI、10 个 E2EO，覆盖全部九大基础设施主题。
核心创新在于“任务即真实历史”的构建哲学和“分类法引导 + agent 合成”的可扩展方法学。与已有方法的本质区别是：KernelBench 等基准的题目是人写或半自动生成的抽象问题，而 Φ-Bench 的每一道题都对应一次真实世界的工程努力——以某个 PR 或优化工作之前的仓库状态作为初始环境，以该变更的实现作为参考解，相关的单元测试改造为评测 harness，天然保留了问题在真实软硬件语境中的难度和语义。在测试生成上，论文用 agent loop 追踪当前测试套件执行到了目标代码的哪些分支，发现未覆盖路径就迭代生成新测试，使测试完备性不再依赖人工。另一个关键设计是对数归一化的性能奖励 $R_{\text{perf}}$：候选解不超过参考解时得 0 分，超过后按 $\ln(s/s_{ref})/\ln s_{ref}$ 增长，当 $s \ge s_{ref}^2$ 时封顶 1.0，既奖励大幅优化又压制边际刷分。
方法步骤详情
整个构建与评测流程可拆为五步。第一步，源收集与过滤：抓取 2023–2026 年顶级系统会议论文，用 LLM 过滤出与 LLM 基础设施直接相关、研究实现/加速/资源优化且有公开实现的论文；对公开仓库则审查 issue 和 PR，保留引入实质优化、补齐重要能力、解决硬件或负载特定限制的工件，得到 4,112 个来源。第二步，分类法构建：对每个来源用 LLM 打三级标签——410 个细粒度标签、聚类成 62 个中层主题、归入 9 个大类。第三步，任务合成：PR/Issue 溯源合成取变更前仓库为题面、变更后代码为参考解，单文件小改动做成 KFC，跨文件大改动做成 LHI/E2EO；agent 辅助合成让 agent 扫描仓库定位高价值实现点，删除局部代码段或整个实现模块构造任务，并用 agent loop 迭代补充测试用例；专家策展用于无法从仓库历史重建的前沿问题，人工回退仓库到简化状态并设计测试。第四步，质量控制：性能类任务的参考解须在官方环境稳定达到至少 1.15 倍加速且 starter 解不得超过基线；实现类任务参考解须通过全部测试而 starter 至少挂一个；每个实现类任务至少 5 个测试用例，覆盖正常输入、边界条件、错误路径和回归场景，不达标任务直接修订或剔除。第五步，评测执行：每任务配 8 CPU 核、32 GiB 内存和一张 NVIDIA H20；KFC 只许提交一次，LHI/E2EO 最多 16 次、取最优计分；性能用 AB-BA 配对测量至少 5 对取中位数；规则监控器扫描完整轨迹查禁 GitHub 检索原实现、恢复上游补丁等行为，专职 proctor agent 再查硬编码输出、绕过正确性检查等复杂作弊，违者该次尝试计 0 分。
技术新颖性
技术新颖性体现在四个层面。任务格式层面，KFC/LHI/E2EO 三级谱系是新的：先前基准要么停在函数级（KernelBench、TritonBench、FlashInfer-Bench），要么虽到仓库级却仍指定目标和瓶颈（ISO-Bench、CUDAHercules），没有人把“编辑范围逐级放大、目标逐级放空”作为显式设计维度来区分 agent 能力。构建方法层面，分类法引导的合成是首创：410 标签→62 主题→9 大类的三层结构既是覆盖率检查表又是任务生成索引，Figure 3 直观展示了同类基准（KernelBench、SOL-ExecBench、TritonBench、KernelBench-X、FlashInfer-Bench、KernelBench-Hard）各自只覆盖外环的一小段弧。评测协议层面，硬性有效性门（参考解 ≥1.15×、starter 必须失败）和双重反作弊（规则监控 + proctor agent + 软断网 + 提示约束）共同保证了分数的可信性，这在同类基准中少见。分析层面，论文不只报总分，还对解题轨迹做错误模式统计（Python 运行时错误、CUDA 执行错误、编译错误、张量形状不匹配四类）和案例研究，把“为什么强”落到具体工程行为上。
实验结果
主实验（Table 2）显示八模型差距悬殊：Claude Opus 5 以 36.53% 居首，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%、Qwen3.7 Max 16.07%、DeepSeek V4Pro 13.31%。即便模型能看到完整仓库和测试用例，最强模型也只拿到约三分之一分数，说明长程基础设施工程仍有巨大空间。分主题看，Opus 5 在九大类中五类领先，但没有模型全类别强势：Kimi K3 在 Inference & Serving（30.50）和 System Optimization（41.10）最好，Qwen3.7 Max 在 Hardware & Edge 拿到全场最高的 5.40（对，这一类最好的模型也只有 5.4%），GLM 5.2 在 System Assurance 最高（57.40）。按任务格式（Table 3），Opus 5 全面第一：KFC 37.16%、LHI 21.60%、E2EO 62.94%；所有模型 LHI 都低于 KFC，说明仓库级长程实现是普遍短板；DeepSeek V4Pro 的 E2EO 只有 1.97%，几乎完全无法做系统级优化。迭代能力实验（Figure 6）在一个 nanoGPT 端到端任务上以验证集 bits per byte（BPB）为目标：Opus 5 首次提交就达到很低的 BPB 并持续改进；Qwen3.8-Max 和 Kimi K3 早期很差但靠快速迭代收敛到较低水平；DeepSeek V4Pro、Qwen3.7-Max、GLM 5.2、GPT-5.6 Sol 长时间平台期，未能把 BPB 优化下来。推理预算消融（Figure 5，20 个 LHI 任务）显示三个模型都在 max 档最佳，但性能不随预算单调上升：GPT-5.6 Sol 在中间档位明显不稳，Kimi K3 从 max 降到 low 档掉约 45% 分数，说明其强势高度依赖测试时算力。错误模式分析（Figure 7，共约 900 条错误）发现高分模型错误反而更多——Opus 5 n=175、Qwen3.8 Max n=179、Kimi K3 n=139，表明它们靠多轮试错诊断攻坚；低分模型错误少（Sonnet 5 仅 n=26）是过早放弃或退回简单方案。错误类型上多数模型的 Python 运行时错误过半，而 Opus 5 该类占比显著更低、错误更多集中在 CUDA 执行错误，说明它首写的 Python 代码可用性更高。防作弊方面全程只发现 DeepSeek V4Pro 三次请求 PyTorch 网站取码，经 proctor agent 确认无实际作弊。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| Φ-Bench 全量 85 任务（九大基础设施主题综合） | 平均得分（%，正确性门控后取最优提交） | Claude Opus 5：36.53 | 次优 Kimi K3：28.12；其余 Qwen3.8 Max 27.73、GPT-5.6 Sol 24.51、DeepSeek V4Pro 仅 13.31 | 榜首领先次优 8.41 个百分点；最强者也仅得约三分之一分数 |
| KFC 内核函数补全（55 任务） | 平均得分（%） | Claude Opus 5：37.16 | 次优 Qwen3.8 Max：28.79；最低 DeepSeek V4Pro：16.05 | +8.37 个百分点，函数级实现差距相对可控 |
| LHI 长程实现（20 任务） | 平均得分（%） | Claude Opus 5：21.60 | 次优 Kimi K3：19.55；全体模型均不足 22% | +2.05 个百分点；所有模型 LHI 全面低于 KFC，暴露仓库级长程开发是普遍短板 |
| E2EO 端到端优化（10 任务） | 平均得分（%） | Claude Opus 5：62.94 | 次优 Kimi K3：56.41；DeepSeek V4Pro 仅 1.97 | +6.53 个百分点；模型间方差最大的格式，头部与尾部相差 60 分以上 |
| Hardware & Edge 主题（硬件与边缘） | 类别得分（%） | 全场最高仅 Qwen3.7 Max：5.40 | 多数模型为 0–4%（Claude Opus 5 仅 3.90，GPT-5.6 Sol 和 Claude Sonnet 5 为 0.00） | 无提升可言——最难的类别，最好成绩也不到 6%，暴露模型对硬件层理解严重缺失 |
局限与改进
作者承认的局限包括：基准规模有限（85 个任务，其中 E2EO 只有 10 个），难以对单个主题做统计显著的细粒度结论；评测固定在单张 NVIDIA H20 GPU 上，结论可能与该硬件绑定。笔者补充几点观察：第一，脚手架不统一——GPT-5.6 Sol 用 Codex，其余七个模型都用 Claude Code，模型间比较混入了 agent 框架差异这一混淆变量，Opus 5 的领先有多少来自 Claude Code 与同门模型的适配不得而知；第二，软断网（劫持 pip 和相关 URL）加提示禁止检索，虽然防住了作弊，但也排除了真实工程师查文档、读源码包的合法工作流，可能低估模型在真实环境下的能力；第三，性能奖励在 $s \ge s_{ref}^2$ 时封顶 1.0，对数归一化对极端大加速的激励不足，且参考解须 ≥1.15× 的门槛可能筛掉了某些本来有价值的渐进式优化任务；第四，三层分类法由 LLM 标注生成，标签噪声会传导到任务覆盖评估；第五，LHI/E2EO 允许 16 次提交，对善于试错的模型（Opus 5）和容易过早放弃的模型意义完全不同，提交预算本身成为影响排名的实验设计变量。
独立分析的弱点
第一，任务分布头重脚轻：KFC 55 个、LHI 20 个、E2EO 仅 10 个，恰恰是最能区分模型的总分贡献中 E2EO 话语权过小，且 DeepSeek V4Pro 在 E2EO 的 1.97% 与 Kimi K3 的 56.41% 之间 60 分的落差主要由 10 道题撑起，个体题目噪声大。改进方向：按分类法对空缺主题定向扩产 E2EO/LHI 任务，agent 合成管道本就为此设计。第二，硬件单一：所有速度测量都基于 H20，而内核与系统优化的最优策略强依赖硬件（A100 与 H100 的 tensor core 行为不同），模型可能只是学到了 H20 上的经验规律。改进方向：在多种 GPU 上重复标定参考加速比，增加跨硬件泛化维度的评分。第三，反作弊与真实性的张力：断网阻断的不只是作弊，还包括读官方文档等正常工程行为，且规则监控器需要维护禁用行为清单。改进方向：改为受控沙箱联网并审计检索内容，或对“引用上游代码”按任务要求区分合法性。第四，实现类指标是二值的：全过 5 个测试得 1 分否则 0 分，无法区分“差一个边界条件”和“完全没实现”，而论文自己的错误模式分析恰恰表明边界与形状错误是高频失败点。改进方向：引入测试加权的部分得分或失败测试分类统计。第五，轨迹分析以定性案例为主（一个 nanoGPT 任务、三个模型），三大 takeaway（低成本假设筛选、变量与噪声控制、审慎归因）尚未转化为可跨任务量化度的行为指标。改进方向：定义如“每单位性能提升的提交次数”“实验归因正确率”等指标并全量统计。
未来方向
作者层面提出的方向：把 Φ-Bench 作为追踪基础设施 agent 进度的长期测试床；从轨迹分析提炼的三大能力——建立低成本本地验证以筛选假设、控制变量与估计噪声以提高实验信息量、归因前排查编译缓存等混杂因素——可直接转写为模型训练目标或 agent 脚手架的反思提示。基于本文成果可自然延伸的方向：其一，把这套带硬性有效性门的奖励协议用作强化学习环境，$R_{\text{perf}}$ 和 $R_{\text{impl}}$ 都是自动可算的 reward，适合训练系统优化专用模型；其二，跨硬件与跨栈迁移评测，检验在 H20 上学到的优化策略能否迁移到其他加速器；其三，多 agent 协作的基础设施工程（一个负责 profile、一个负责实现、一个负责验证），因为真实系统组就是分工的；其四，把分类法反向用于训练数据合成，按 410 个细粒度标签针对性地生成 SFT/RL 数据补齐模型的硬件层短板（Hardware & Edge 全场最高仅 5.4% 是最明显的能力空洞）；其五，课程化任务难度，用 KFC→LHI→E2EO 的谱系构造从易到难的训练课程。此外 Figure 5 显示推理预算与性能非单调，如何自适应分配测试时算力（何时该多想、何时该动手试）本身就是值得研究的元问题。
复现评估
复现条件总体友好但有门槛。开源情况：论文首页给出了 Leaderboard、GitHub 仓库和 Hugging Face 页面链接，85 个任务的规格、仓库环境、测试用例和评测 harness 对 agent 完全可见（仅 harness 对模型隐藏），任务合成管道在论文中有足够细节（三层分类法标注、agent loop 测试生成、有效性门阈值 1.15×、对数奖励公式）可复用。算力需求：官方环境为每任务 8 CPU 核、32 GiB 内存加一张 NVIDIA H20，这是主要门槛——H20 并不普及，迁移到 A100/H100 时所有参考加速比 $s_{ref}$ 和有效性门都需要重新标定，相当于重跑一遍基线测量。评测成本：每个 LHI/E2EO 任务最多 16 次提交、任务本身是长程 agent 工作流，单模型全量评测的 token 和机时开销不小，八模型对比的实验规模一般实验室难以复制，但复跑两三个模型做对比分析是可行的。难度评估：跑通现成任务为中等（需多卡环境与 agent 脚手架工程），从零复现任务合成管道为高等（需要 2023–2026 顶会论文语料、仓库挖掘和 LLM 标注质量控制）。对想入门系统评测的团队，建议先从 KFC 子集和公开 leaderboard 复核开始。
论文图表