过去几年，大语言模型（LLM）的能力快速提升。从写代码、完成复杂推理，到辅助科研和软件开发，模型正在逐渐成为越来越强大的工程助手。

但一个更深层的问题正在出现：如果模型能够帮助人类构建软件，大模型是否也能够反过来优化支撑自身运行的基础设施？

换句话说：Can Large Language Models Engineer the Infrastructure That Powers Them? 这正是 Φ-Bench（Frontier AI Infrastructure Benchmark）试图回答的问题。

文章链接：https://github.com/one2piece2hello/faibench_Frontier_InfraBench/blob/main/faibench.pdf
项目网站：https://faibench.org/
github：https://github.com/one2piece2hello/faibench_Frontier_InfraBench
hugging face：https://huggingface.co/datasets/faibench-Frontier-Infra-Bench/faibench_Frontier_Infra_Bench

1. 真实的 LLM Infra 工程，远不只是写一个 Kernel

现有的 LLM infra benchmark 主要关注函数补全、代码生成，或者单个 GPU Kernel 的优化。但真实的 LLM Infrastructure 工程远比这复杂。

一个 Infra 工程师面对的问题通常是：

如何定位性能瓶颈？
如何理解代码不同模块之间的依赖关系？
如何设计优化方案，并通过实验验证假设？
如何在性能、正确性、稳定性之间寻找平衡？

这类问题往往没有明确答案，也没有固定修改位置，需要长期分析、实验和迭代。
然而，现有 Benchmark 很难覆盖这种开放式、长周期的工程过程。

Φ-Bench 正是在这一背景下提出，希望更加真实地评估 LLM 进行 Infra 工程的能力。论文指出，Φ-Bench 从真实系统论文和开源 Infra 仓库中构建任务来源，覆盖 LLM 训练、推理以及系统优化等多个方向。

2.一个面向真实工程场景的 Infra Benchmark

为构建目前覆盖最全面、最贴近真实工程场景的 LLM Infra Benchmark，Φ-Bench 团队系统性挖掘并分析了近四年系统方向顶级论文与开源infra仓库中的高价值工程问题。从海量论文、Issue、PR 等资源中挖掘出 10000+ 候选任务来源，经过 Agent 自动筛选，保留 4000+ 高价值候选来源；随后由领域专家逐项复核、筛选与精细化打磨，最终形成 85 个真实、高难度任务。

同时，团队构建了覆盖 410 个 Fine-grained Tags、62 个 Middle-level Topics 和 9 个 High-level Topics 的分层分类体系，实现对现代 LLM infra问题的系统覆盖。

这些任务覆盖从底层 Kernel 到端到端系统优化的不同层级：

1、Kernel Function Completion（KFC）：面向单个算子 / Kernel 的实现与优化。任务明确给定接口和输入输出语义，模型需要在限定文件内完成正确、高效的计算原语实现，并通过正确性验证后进一步优化性能；

2、Long-Horizon Implementation（LHI）：面向真实代码库中的长周期功能开发与工程实现。任务提供类似于 Issue 形式的需求，模型需要自主理解代码结构、定位相关模块、修改多个文件，并通过持续测试和调试完成端到端实现；

3、End-to-End Optimization（E2EO）：面向完整系统级性能优化。任务提供真实工作负载、优化目标和约束条件，但不指定优化路径，模型需要自主分析系统瓶颈，制定优化方案，并进行跨模块、跨层级的代码修改与迭代优化

三类任务逐渐扩大范围和开放程度，从局部代码实现走向完整系统工程。

3.当前模型距离“LLM Infra 工程师”还有多远？

Φ-Bench 对多个前沿模型进行了系统评估，结果并不乐观。Claude Opus 5的总分最高，为36.53，其次是Kimi K3，为28.12，Qwen3.8 Max为27.73，模型间存在明显差距。

论文进一步发现，模型能力并不是均衡发展的。不同模型在不同 Infra 方向存在明显差异：

不同模型展现出了不同优势：

Claude Opus 5 在多个领域保持领先；
Kimi K3 在 Inference & Serving 和 System Optimization 方向表现突出；
GLM 5.2 在 System Assurance 方向表现更好。

但没有任何模型能够在所有 Infra 领域保持稳定领先。尤其是在 Hardware & Edge 等涉及底层硬件机制的任务中，即使最佳模型也只有 5.4 的成绩，说明当前模型对硬件相关系统优化仍存在明显不足。

4.模型真正的差距，体现在持续优化能力。

Φ-Bench 通过一个完整的E2EO任务，考察模型能否在多轮实验反馈中不断改进方案。模型需要自主分析瓶颈，并围绕数据通路、MoE 路由、计算调度等方向进行优化，最终降低验证集 BPB。

实验发现，Claude Opus 5 能够从较优初始方案出发持续提升；Qwen3.8-Max 和 Kimi K3 虽起点较低，但能够通过迭代快速追赶；而部分模型则陷入长期停滞。

这说明复杂 Infra 优化并不是一次性代码生成，而是一个需要持续实验、推理和纠错的长期工程过程。

5.推理预算是否决定模型能力？

Φ-Bench 进一步分析了 reasoning budget 对模型表现的影响。结果表明，虽然增加推理预算通常能够帮助模型达到更好的结果，但性能提升并非线性增长，不同模型对额外计算资源的依赖程度存在显著差异。

6.错误模式分析

Φ-Bench 对模型完整优化轨迹中的错误进行了分析，并将其划分为 Python Runtime Error、CUDA Execution Error、Triton/MLIR/CUDA 编译错误以及 Tensor Shape Mismatch 四类。

实验发现，高分模型反而产生更多错误，因为它们会主动探索更复杂的优化方向，并通过实验反馈不断修正。而低分模型虽然错误更少，但这也意味着探索不足。

进一步来看，Claude Opus 5 的错误更多集中在 CUDA Execution Error，而非基础代码错误，说明它能够更快跨越“让代码跑起来”的阶段，将注意力集中到真正困难的系统优化问题上。

7.任务开放程度越高，对模型工程能力的挑战越大。

Φ-Bench 进一步分析了三类任务在不同开放程度下的模型表现：从目标明确的 KFC，到需要理解代码库并进行多文件修改的 LHI，再到完全开放式的 E2EO 优化。

实验发现，Claude Opus 5 在三类任务中均排名第一；Kimi K3 和 Qwen3.8 Max 也展现出较强的综合能力。

值得注意的是，所有模型在 LHI 任务上的表现都明显低于 KFC，说明相比单个算子实现，理解大型代码库、协调多个模块并完成长期工程开发仍是当前 LLM 面临的核心挑战。

8.防作弊机制分析

为保证评测可信度，Φ-Bench采用软网络隔离和提示约束两种机制防止 hacking 行为。

整个评测过程中，基于规则的检测器仅发现 DeepSeek V4 Pro 出现 3 次尝试请求访问 PyTorch 网站代码的行为，随后 Proctor Agent 进一步确认这些行为并未构成实际 hacking。

实验结果表明，两种机制能够有效防止评测过程中出现 hacking 行为。

9. 什么样的模型，才能真正做好 Infra 优化？

除了最终分数，Φ-Bench 进一步分析了模型在端到端优化任务中的完整优化轨迹，试图回答一个更关键的问题：真正擅长Infra的模型，究竟应该具备什么特质？分析出三点特征：

① 谋定而后动

优秀模型不会盲目修改代码，而是通过低成本的假设筛选和验证机制，降低每次优化迭代的成本。

② 实验求新知

优秀模型能够设计有效实验，控制变量和噪声影响，从每一次尝试中最大化获取有效信息。

③ 谨慎解释实验结果

优秀模型不会简单根据性能变化归因，而是主动排除其他混杂因素，避免测量误差导致错误优化方向。

论文总结认为，真正强大的 Infra 模型需要具备持续验证、实验设计和可靠归因能力。

10. 为什么 Φ-Bench 值得关注？

过去关于 Recursive Self-Improvement(RSI) 的讨论，更多关注：

更好的训练数据；
更强的算法；
更有效的模型架构。

而 Φ-Bench 提出了另一个方向：模型是否能够优化支撑自身运行的基础设施？

未来，如果 AI 系统能够自主理解复杂的软件栈，发现性能瓶颈，并持续改进训练和推理系统，那么 AI 不仅是在使用计算基础设施，也可能逐渐参与构建下一代 AI 基础设施。

Φ-Bench 探索的，正是 AI 自我改进能力向 Infra 层延伸的可能性。从这个角度看，Φ-Bench 也可以被理解为RSIBench-Infra