InferenceBench:把 LLM 推理优化交给 AI Agent 自己做,跑出来一份并不漂亮的成绩单

当你让一个「会写代码的 AI Agent」独自面对 1 张 H100、2 小时、一台要部署到线的 OpenAI 兼容推理服务器,它到底能优化到什么程度?ICML 2026 上线的 InferenceBench 给了一份相当冷静的答案。

一句话先讲清这篇在讲什么

InferenceBench 是来自 ELLIS Institute Tübingen / Max Planck Institute for Intelligent Systems / Tübingen AI Center 的 Jehyeok Yeon、Ben Rank、Maksym Andriushchenko 提出的一个开放式基准,收录于 ICML 2026(arXiv:2607.20468,2026-05-20 提交),官方代码与 leaderboard 开源在 。它的核心动作是:把一个目标 LLM、一张 H100、一个 2 小时时钟预算,以及四个互相隔离的优化场景丢给前沿编程 Agent,让它从零搭出一个 OpenAI 兼容的推理服务器,然后只对它「最终提交的那一份」打分。提交的服务器还要过正确性检查和 reward-hacking 完整性审计,任何失败、不可达或回退到 PyTorch 基线以下的最终提交,统一按 PyTorch 基线计分,中间过程的成绩不算。

这四个场景是这么切的

为了让 agent 的优化目标彼此可分,InferenceBench 拆出了四条独立的「瓶颈赛道」:

  1. Prefill Latency:长上下文 prompt,衡量 time-to-first-token(TTFT)。
  2. Decode Latency:长生成,衡量每个 output token 的时间。
  3. Throughput:并发流量,涵盖 burst / Poisson / constant-rate 三种请求剖面。
  4. All-In-One:综合场景,延迟与吞吐指标做几何均值。

每个场景下,Agent 需要在不知道「最优配置」的前提下,自己装引擎、调 flag、跑基准、决定保留还是回滚。基准明确告诉 agent:不能引入第三方预量化检查点,也不能修改评估 harness —— 这两点是为了防止「借力记忆」而非「真优化」。

15 个前沿 Agent 跑下来的成绩单

论文与官方 leaderboard(截至 2026-08 的 v1.0.4 版本,刚把 Cost 列与 Grok 4.5/4.6 加进来)给出的几个核心数字:

  • 相对原生 PyTorch 基线,Agent 普遍能拿到 最高 8.08 倍的加速 —— 比什么都不调的 baseline 强得多。
  • 相对 vLLM、SGLang、TGI 等推理引擎的默认配置,Agent 也能 平均高约 4.05 倍。
  • 但相对同时间预算下的简单超参搜索(直接调 vLLM/SGLang/TGI 的运行参数与 CLI flag),Agent 反而 落后最多 11.53 倍。
  • 跨 15 个前沿 Agent 配置的整体几何均值,在 forced-engine 对比里:TGI-only 8.31×、SGLang-only 7.69×、vLLM-only 6.17×,而非 agent 的 per-scenario best search 跑到 14.30×,依然没人能追上。

换句话说:Agent 是「高手」,但不是「最强工程师」。给它 2 小时,它能干翻裸 PyTorch,也能干翻推理引擎默认设置,但只要让一个会调超参的人类(或脚本)拿同样 2 小时去做穷举,Agent 就输了。

Agent 嘴上全会,手上只押 vLLM

InferenceBench 最值得行业反思的结论,是它对 Agent 行为轨迹(trace)的定性分析:

  • 85.3% 的提交最终落到 vLLM 上,SGLang、TGI 等其它引擎几乎被默认忽略。Agent 在有限预算里强烈收敛到「单一推理框架」,而不是去探索「哪个引擎更合适」。
  • Agent 在 transcript 里反复点名的优化技术:Chunked prefill 99%、Quantization 100%、Speculative decoding 89%—— 这些是它真的懂。
  • 但实际非默认 vLLM launch 配置数很少,Agent 把大量时间花在反复重测、修复、超参微调上,而不是去探索截然不同的策略。

更扎心的是「Found vs Submitted」对比:Agent 经常在中间过程中「找到」一个看起来更优的配置,但因为没有正确验证 / 持久化 / 提交,这个更好的版本在最终提交里消失了。换句话说,Agent 的真正瓶颈不是不知道怎么做,而是不会系统地比较、记录、保留自己已经验证过的最优解。

论文的失败模式分析里,把这种行为称作「premature stop」:Agent 看到一个已经 PASS 的 baseline,出于「再改有风险」的判断,直接把这个版本当作终态提交 —— 而不是把它当成「下一步继续优化的起点」。

Trajectory Viewer:每个 Agent 都被「拆给你看」

为了让这件事不只是论文里的文字,官方站点提供了 Trajectory Viewer:每个 run 的工具调用被自动归类为 inspecting / installing / launching / evaluating / debugging / 实际优化 六类 episode,你可以逐回合回放任一 Agent 的 trace,或者把它放到一张「行为地图」里和所有其他 run 对比。从可视化里能直接看到:大多数 run 都只在「inspect → 编辑 → 评估 → 调试」四步里打转,很少推进到更难、更结构化的优化(比如算子融合、调度策略、KV cache 重组)。

同时,官方还配套了一个 Cost vs Performance 图:横轴是该 Agent 跑完 12 轮评估的 API 成本(对数刻度),纵轴是相对加速,点越靠左上说明「便宜又能打」。这等于把「InferenceBench 不是一个对工程成本无感的玩具」写进了产品形态里。

截至 2026-08 的 leaderboard 现状

v1.0.4(Aug 2026)的 leaderboard 已经在跑 Claude Opus 5†、Claude Sonnet 5†、GPT-5.6 Sol Ultra†、Kimi K2.7 Code†、Kimi K3†、Grok 4.5/4.6(Grok Build)、Claude Opus 4.7/4.8、Claude Fable 5、Gemini 3.5 Flash、GLM-5.2 Max、GPT-5.5 High/xHigh、Kimi K2.6 等 15 个以上 Agent 配置。带 † 的运行使用的是 strict prompt,显式说明「不允许第三方预量化 checkpoint、不允许改评估 harness」,正是为了让分数反映真正的「开放域工程能力」,而不是「靠记忆拿分」。

截至目前,Claude Opus 5† 排第一——它不是单一场景跑得最猛的,而是「每个场景都能稳定交出有效最终服务器」。换句话说,这次的赢家是**「重复性能」**,而不是「单次峰值」。

这事对行业意味着什么

把 LLM 推理优化丢给 AI Agent 自己做,这件事本身就在拷问一个更基础的问题:「端到端 AI 工程」到底什么时候能闭环? InferenceBench 给出的答案是:会的部分在变多,但仍远没到能让 AI 自己替代 ML Systems Engineer 的程度。

具体几个信号:

  • Agent 在「知识枚举」这一层已经满分:chunked prefill、量化、投机解码,Agent 都能列、能写、能配。但**「枚举→验证→保留→提交」这条链上,任何一环掉链子,优化就消失了**。这是「工程纪律」问题,不是「模型能力」问题。
  • 单一框架的强先验:85.3% 押 vLLM,说明 Agent 训练数据里 vLLM 的曝光率压倒性地高,这反过来会让其它引擎在 Agent 时代的可见度持续下降——一个值得关注的「AI 工具同质化」信号。
  • 「最终提交要 score」的设计非常狠:它直接把 reward hacking 写进了评分规则,失败的提交回到 PyTorch 基线。这倒逼所有想刷榜的人,必须真正把优化跑稳,而不是堆跑分脚本。
  • Cost vs Performance 图把工程成本摆到了台面上:未来我们要谈「Agent 优化 LLM 推理」,就不能只谈「几倍加速」,还要谈「花了多少钱的 API 才换来这几倍」。

一句话总结:InferenceBench 不是告诉你 AI Agent 有多强,而是告诉你 AI Agent 现在的「工程化弱点」具体卡在哪一步。这比一份漂亮的速度榜单有用得多。

关键链接

原始研究 / 引用提示:Yeon, Rank, Andriushchenko (2026). InferenceBench: A Benchmark for Open-Ended LLM Inference Optimization by AI Agents. arXiv:2607.20468 / ICML 2026.