文章摘要
文章围绕大模型Infra全栈重构与Agentic优化方向，介绍了Φ-Bench前沿AI基础设施基准测试。它为评估大模型基础设施工程能力而提出，构建了贴合真实场景的任务体系。评测多款前沿大模型结果显示其能力不均衡，核心差距在持续优化能力。还从多维度分析评测，总结出优秀模型特质，其探索了AI自我改进能力向基础设施层延伸的可能。









文章链接：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

近年来，大语言模型的能力实现了跨越式提升，从代码编写、复杂推理辅助到科研与软件开发支持，LLM已经成为愈发强大的工程助手。但一个深层的行业议题随之浮现：既然模型可以助力人类构建软件，那么它能否反向优化支撑自身运行的基础设施？这一问题正是Φ-Bench（前沿AI基础设施基准测试）试图解答的核心命题。

当前主流的LLM基础设施评测基准大多聚焦于函数补全、代码生成或是单一GPU内核的优化，但真实的LLM基础设施工程远比这些场景复杂。一名基础设施工程师需要面对的问题往往包括：如何定位性能瓶颈、如何理解代码不同模块间的依赖关系、如何设计优化方案并通过实验验证假设、如何在性能、正确性与稳定性之间寻找平衡。这类问题通常没有固定答案，也没有明确的修改位置，需要长期分析、实验与迭代，而现有基准很难覆盖这种开放式的长周期工程过程。

Φ-Bench正是为解决这一痛点提出的，它旨在更真实地评估大模型的基础设施工程能力。该基准的任务来源均取自真实系统论文与开源基础设施仓库，覆盖LLM训练、推理以及系统优化等多个方向。

贴合真实场景的基准测试构建

为打造目前覆盖最全面、最贴近真实工程场景的LLM基础设施基准，Φ-Bench团队系统性梳理了近四年系统领域顶级论文与开源基础设施仓库中的高价值工程问题。团队从海量论文、Issue、PR等资源中挖掘出超过10000个候选任务来源，经过智能代理自动筛选后保留了4000余个高价值候选，再由领域专家逐一复核、筛选与精细化打磨，最终形成85个真实且高难度的评测任务。

同时，团队构建了分层分类体系，包含410个细粒度标签、62个中层次主题与9个高层次主题，实现对现代LLM基础设施问题的全面覆盖。这些任务覆盖从底层内核到端到端系统优化的不同层级，主要分为三类：

  • Kernel Function Completion（KFC）：面向单个算子或内核的实现与优化，任务会明确给定接口与输入输出语义，模型需要在限定文件内完成正确且高效的计算原语实现，并在通过正确性验证后进一步优化性能。
  • Long-Horizon Implementation（LHI）：面向真实代码库中的长周期功能开发与工程实现，任务会提供类似Issue形式的需求，模型需要自主理解代码结构、定位相关模块、修改多个文件，并通过持续测试与调试完成端到端的实现。
  • End-to-End Optimization（E2EO）：面向完整系统级性能优化，任务会提供真实工作负载、优化目标与约束条件，但不指定具体优化路径，模型需要自主分析系统瓶颈，制定优化方案，并进行跨模块、跨层级的代码修改与迭代优化。

三类任务的开放程度逐步提升，从局部代码实现延伸至完整的系统工程流程。

当前大模型的基础设施能力评估结果

Φ-Bench对多款前沿大模型进行了系统评测，整体结果并不乐观。Claude Opus 5以36.53的总分位居第一，Kimi K3以28.12紧随其后，Qwen3.8 Max得分为27.73，不同模型之间存在明显的性能差距。

研究发现，模型的基础设施能力发展并不均衡，不同模型在不同方向各有优势：Claude Opus 5在多个领域保持领先；Kimi K3在推理部署与系统优化方向表现突出；GLM 5.2在系统保障方向更为出色。但没有任何模型能够在所有基础设施领域保持稳定领先，尤其是在硬件与边缘等涉及底层硬件机制的任务中，即便是表现最佳的模型得分也仅为5.4，说明当前模型在硬件相关的系统优化上仍存在明显不足。

进一步分析显示，模型的核心差距体现在持续优化能力上。Φ-Bench通过完整的端到端优化任务，考察模型能否在多轮实验反馈中不断改进方案。模型需要自主分析瓶颈，围绕数据通路、MoE路由、计算调度等方向进行优化，最终降低验证集BPB。实验发现，Claude Opus 5能够从较优的初始方案出发持续提升性能；Qwen3.8-Max和Kimi K3虽然起点较低，但能够通过迭代快速追赶；而部分模型则陷入长期的性能停滞。这说明复杂的基础设施优化并非一次性的代码生成，而是需要持续实验、推理与纠错的长期工程过程。

更多维度的评测发现

Φ-Bench还从多个维度展开了深入分析：首先是推理预算对模型表现的影响，研究显示增加推理预算通常能够帮助模型获得更好的结果，但性能提升并非线性增长，不同模型对额外计算资源的依赖程度存在显著差异。

在错误模式分析方面，团队将模型在完整优化轨迹中的错误分为Python运行时错误、CUDA执行错误、Triton/MLIR/CUDA编译错误以及张量形状不匹配四类。实验发现，高分模型反而会产生更多错误，因为它们会主动探索更复杂的优化方向，并通过实验反馈不断修正；而低分模型虽然错误更少，但也意味着探索不足。进一步来看，Claude Opus 5的错误更多集中在CUDA执行错误，而非基础代码错误，说明它能够更快跨越“让代码跑起来”的阶段，将注意力集中到真正困难的系统优化问题上。

针对任务开放程度的分析显示，任务的开放程度越高，对模型工程能力的挑战越大。从目标明确的KFC，到需要理解代码库并修改多文件的LHI，再到完全开放式的E2EO优化，所有模型在LHI任务上的表现都明显低于KFC，说明相比单个算子实现，理解大型代码库、协调多个模块并完成长期工程开发仍是当前大模型面临的核心挑战。

为保证评测可信度，Φ-Bench采用了软网络隔离与提示约束两种机制防止作弊行为。整个评测过程中，基于规则的检测器仅发现DeepSeek V4 Pro出现3次尝试访问PyTorch网站代码的行为，随后监控代理进一步确认这些行为并未构成实际作弊。实验结果表明，两种机制能够有效防止评测过程中出现作弊行为。

优秀基础设施优化模型的核心特质

除了最终的评测分数，Φ-Bench还分析了模型在端到端优化任务中的完整优化轨迹，试图回答真正擅长基础设施优化的模型应具备哪些核心特质。研究总结出三点关键特征：

谋定而后动

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

实验求新知

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

谨慎解释实验结果

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

论文总结认为，真正强大的基础设施优化模型需要具备持续验证、实验设计与可靠归因的核心能力。

Φ-Bench的行业意义

过去关于递归自我改进（RSI）的讨论，更多聚焦于更好的训练数据、更强的算法与更有效的模型架构。而Φ-Bench提出了另一个重要方向：模型是否能够优化支撑自身运行的基础设施？

未来，如果AI系统能够自主理解复杂的软件栈，发现性能瓶颈，并持续改进训练和推理系统，那么AI不仅是在使用计算基础设施，也可能逐渐参与构建下一代AI基础设施。Φ-Bench探索的正是AI自我改进能力向基础设施层延伸的可能性，从这个角度来看，Φ-Bench也可以被理解为RSI Bench-Infra。

以上内容不代表本平台立场，仅供读者参考