InferenceBench：面向AI代理的开放式LLM推理优化基准测试

# 一个面向AI代理的开放式大语言模型推理优化基准测试  
来源：https://arxiv.org/html/2607.20468  

###### 摘要  
AI代理越来越多地被用于自动化研发任务，然而现有基准通常是在预设的工作流或狭窄的动作空间中对它们进行评估。即便是名义上开放式的任务，也常常可以通过检索一个众所周知的方案并调整几个超参数来解决，这使得强结果究竟是反映了真正的优化还是记忆化的解决方案变得不明确。我们引入了 **InferenceBench**，在该基准中，代理必须部署一个兼容 OpenAI 的推理服务器并优化 LLM 推理速度。每个代理会收到一个目标 LLM、一块 H100 GPU、一个优化场景以及两小时的实际时间预算。三个优化场景分别隔离了推理的不同瓶颈（预填充延迟、解码延迟和并发请求吞吐量），第四个场景则同时平衡这三项。在 15 种前沿代理配置中，代理能够可靠地改进一个朴素的 PyTorch 基线（最高提升 **8.08×**），并且常常能匹配或超过使用默认设置的推理引擎（vLLM 为 **4.05×**），但在相同时间预算下仍低于一个简单的超参数搜索（最高提升 **11.53×**）。对代理轨迹的定性分析表明，尽管代理列举了许多相关的优化技术，但它们绝大多数都收敛于一个单一的推理框架。它们只测试了少数几种不同的配置，并将剩余预算用于重新测量、修复或优化超参数，而不是探索截然不同的策略。这表明瓶颈并非领域知识，而是提出多样化配置、系统评估这些配置并提交最佳识别方案的能力。总体而言，**InferenceBench** 反映了代理在开放式 AI 工程环境中运作的能力，在这样的环境中，记忆化的解决方案带来的改进非常有限。  

††footnotetext:1ELLIS Institute Tübingen, Max Planck Institute for Intelligent Systems, Tübingen AI Center.  

Refer to caption  

图 1：基准测试概览。代理接收一个基础模型、硬件环境和特定场景的目标。它在容器化环境中操作，拥有开放式的动作空间，并使用提供的评估脚本作为反馈循环。提交结果必须首先通过质量门和完整性门，然后才会对场景特定的速度指标进行评分。  

## 1 引言  

越来越多的基准测试在自主研究任务上评估前沿代理，范围涵盖端到端的科学发现流程（Luet al., 2024 (https://arxiv.org/html/2607.20468#bib.bib23)）、Kaggle 式的机器学习实验（Chanet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib12); Huanget al., 2024 (https://arxiv.org/html/2607.20468#bib.bib13)）以及自主后训练（Ranket al., 2026 (https://arxiv.org/html/2607.20468#bib.bib14)）。任务结构各不相同，有些基准提供了需要改进的启动脚本，有些则要求从头开始编写，但实践中相关的动作空间往往很狭窄，例如超参数调优、数据混合选择以及对样板代码的局部编辑。即使在技术上提供了更广泛的动作空间，行使这些空间也很少是为了获得高分而必需的。因此，这些基准的一个常见发现是探索过程很浅，代理很快收敛于记忆化的解决方案，而不是设计并执行真正不同的实验（Toledoet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib7); Zouet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib8); Nangiaet al., 2026 (https://arxiv.org/html/2607.20468#bib.bib4)）。当有效搜索空间缩减到少数几个众所周知的配置时，这就引出了一个问题：自主代理相比对同一空间进行更廉价的随机搜索或贝叶斯优化，究竟提供了什么？  

推理系统工程带来了性质上不同的挑战，这些挑战是先前自动化研究基准在很大程度上未曾涉及的。一个可运行的服务器需要组装组件，这些组件之间的依赖关系经常冲突——例如推理框架、注意力后端、量化格式以及运行时参数（如批大小、KV 缓存分配和 CUDA 图捕获），所有这些都需要针对 GPU 的内存层次进行调优。错误的组合不会带来稍差的损失曲线；它会导致服务器启动时崩溃、触发 CUDA 驱动不兼容，或因 JIT 重新编译而卡住数十分钟。一个依赖回忆配置而不探测当前环境的代理会立即且明显地失败。  

我们引入了 **InferenceBench**，这是一个基准测试，其任务是让代理进行推理系统优化，并衡量其实现的优化以及所展现的工程行为。每个评估实例提供一个基础语言模型（例如 Mistral-7B-Instruct-v0.3）、一块 NVIDIA H100 GPU、一个实际时间预算和一个优化目标。其中三个目标针对推理速度的不同瓶颈（长上下文提示的预填充延迟、长生成序列的每令牌解码延迟、并发流量下的请求吞吐量），第四个多目标场景要求同时平衡这三者。主要得分是相对于固定 PyTorch 基线的加速比，因此自然是无上限的，而不是限制在一个阈值内。代理必须交付一个可运行、兼容 OpenAI 的推理服务器，该服务器需通过一个完整性门（用于筛查奖励黑客攻击，例如返回预生成的文本或替换成更小的模型）以及一个单独的质量门（用于检查在留出数据集上的准确性）。代理没有获得明确的解决路径，也没有得到任何起始代码：它可以自由选择任何框架、量化策略、注意力后端和调度配置，甚至可以从头构建一个服务解决方案。  

我们的贡献如下：  

- **InferenceBench**，第一个以端到端推理系统工程作为代理任务的开放式基准。我们的任务需要系统级、内核级和运行时级的决策，这些决策共同提供了比狭窄的超参数表面更全面的自主研发能力评估。  
- **四个评估场景**：三个分别隔离推理服务的不同瓶颈（预填充延迟、解码速度、并发吞吐量），第四个多目标场景要求同时平衡这三者。每个场景都配有一个定义明确的速度指标和一个从自然出现的长上下文文档中抽取的工作负载。  
- **对 15 种前沿代理配置的大规模评估**，跨越三种代理框架（Claude Code、Codex CLI、OpenCode）。代理能够可靠地改进一个朴素基线，最佳代理达到了 **8.08×** 的总体加速比，超过了最佳默认推理引擎的总体加速比（vLLM 为 **4.05×**），但一个简单的匹配预算超参数搜索仍然表现更好，达到了 **11.53×** 的总体加速比，并在每个场景中都匹配或超过了最佳代理。定性上，在几乎每份记录中，代理都列举了相关的优化措施，然而在 180 次运行中有 169 次（93.9%）交付了 vLLM，在 2 小时预算内只启动了中位数作为一个不同的非默认 vLLM 参数集，并且偶有在测量到良好的中期配置后却交付了一个损坏的服务器的情况。  

## 2 相关工作  

#### 代理能力基准测试  
最近的基准测试在软件工程（Jimenezet al., 2024 (https://arxiv.org/html/2607.20468#bib.bib1)）、机器学习实验（Huanget al., 2024 (https://arxiv.org/html/2607.20468#bib.bib13); Chanet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib12)）、后训练（Wijket al., 2025 (https://arxiv.org/html/2607.20468#bib.bib20)）、论文复现（Staraceet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib9)）、算法发现（Presset al., 2025 (https://arxiv.org/html/2607.20468#bib.bib17)）以及本地推理优化（Reinet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib21); Toledoet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib7); Zouet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib8)）方面评估代理。特别是，PostTrainBench 针对自主 LLM 后训练（Ranket al., 2026 (https://arxiv.org/html/2607.20468#bib.bib14)），而 ISO-Bench 评估 vLLM 和 SGLang 中的局部补丁级优化任务（Nangiaet al., 2026 (https://arxiv.org/html/2607.20468#bib.bib4)）。**InferenceBench** 则衡量端到端的部署和优化一个完整兼容 OpenAI 的推理服务器，暴露框架、量化和运行时选择，并与匹配预算的非代理搜索基线进行比较，而不是与地面真相补丁或专家调优模型比较。AutoResearch 提供了一个突出的开源例子，展示了固定预算迭代代理驱动训练实验的潜力（Karpathy, 2026 (https://arxiv.org/html/2607.20468#bib.bib51)）。AlphaEvolve 同样证明，编码代理可以驱动对科学和算法发现领域程序的进化搜索，包括计算基础设施的优化（Novikovet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib3)）。  

#### 推理系统与内核优化  
**InferenceBench** 也建立在先前关于连续批处理（Yuet al., 2022 (https://arxiv.org/html/2607.20468#bib.bib26)）、预填充/解码调度（Agrawalet al., 2024 (https://arxiv.org/html/2607.20468#bib.bib27)）、前缀共享与运行时（Zhenget al., 2024 (https://arxiv.org/html/2607.20468#bib.bib28)）以及注意力内核与后端（Kwonet al., 2023 (https://arxiv.org/html/2607.20468#bib.bib29); Daoet al., 2022 (https://arxiv.org/html/2607.20468#bib.bib31); Yeet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib34)）的工作之上。最接近的代理系统工作处于低一层，针对内核生成（Ouyanget al., 2025 (https://arxiv.org/html/2607.20468#bib.bib44); Langeet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib45)）或单内核优化（Xinget al., 2026 (https://arxiv.org/html/2607.20468#bib.bib6)），而非完整的服务器集成。相比之下，**InferenceBench** 询问代理是否能够将这些组件组合成一个可工作的服务器、在竞争框架中进行选择、应对真实流量并满足准确度门；KernelBench 的发现——前沿模型在不到 20% 的内核上击败 PyTorch（Ouyanget al., 2025 (https://arxiv.org/html/2607.20468#bib.bib44)）——建立了每个组件难度的下界，与我们观察到的更高层次行为限制是一致的。  

## 3 InferenceBench  

### 3.1 任务与环境  

每个 **InferenceBench** 实验运行指定一个基础模型（例如 Mistral-7B-Instruct-v0.3）、一个固定的硬件环境（一块配备 80 GB 显存的 NVIDIA H100）、一个优化目标以及一个实际时间预算。代理必须交付一个兼容 OpenAI 的推理服务器，暴露 `GET /v1/models` 和 `POST /v1/chat/completions` 接口，并最大化场景的主要指标。代理在一个容器化的 Linux 环境中工作，该环境包含 CUDA 驱动、构建工具、root 权限、互联网连接以及预缓存的模型权重。动作空间不受限制：代理可以安装包、编译依赖项、采用现有的推理框架（例如 vLLM, SGLang, TensorRT-LLM）、应用量化、调整运行时参数、编写自定义注意力内核，或从头构建服务解决方案。禁止的行为也包含在提示中，例如将推理卸载到外部 API、篡改评估工具或替换基础模型。完整的环境细节可以在附录 A (https://arxiv.org/html/2607.20468#A1) 中找到。  

### 3.2 场景  

三个场景分别隔离了推理服务的一个不同瓶颈，第四个场景要求同时平衡三者。表 1 (https://arxiv.org/html/2607.20468#S3.T1) 给出了每个场景的请求参数和主要指标。  

- **场景 A（预填充）**：隔离在第一个输出令牌之前处理长提示的成本，以首令牌时间（TTFT）衡量。对于 8k 令牌的输入，无论解码速度如何，TTFT 主导了感知延迟，因此聚焦于注意力后端选择、分块预填充配置和前缀缓存等因素。  
- **场景 B（解码）**：隔离长输出上每令牌生成的成本，以每输出令牌时间（TPOT）衡量，计算公式为 \((t_{\text{end}} - t_{\text{first}}) / (n - 1)\)，其中 \(n\) 是生成的令牌数量。对于 8k 令牌的生成，一旦预填充完成，TPOT 主导总响应时间，相关的杠杆是内存带宽利用率和 KV 缓存效率。  
- **场景 C（吞吐量）**：在 64 个并发请求下对调度器施加压力。指标是三种流量模式（突发、泊松、恒定速率）下每秒请求数的几何平均值，反映了在不同到达模式下的调度器行为。  
- **场景 D（多目标）**：衡量从运行测量中得出的三个越高越好量的几何均值：逆 TTFT、逆 TPOT 和请求吞吐量，测试代理是否能同时平衡所有三个目标，而不是优化一个而牺牲其他。  

除了主要指标外，每次运行还会报告令牌间延迟（ITL）、生成吞吐量以及 p90 和 p99 的尾延迟。确切的指标定义可以在附录 A.5 (https://arxiv.org/html/2607.20468#A1.SS5) 中找到。  

#### 请求采样  
用于推理速度评估的请求来源于 LongBench v2 (Baiet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib18))，这是一个自然出现的长上下文文档语料库。对于每个场景，提示的标记化长度在 \([0.8 L_{\text{in}}, L_{\text{in}}]\) 范围内采样，以更好地模拟自然出现的文档，同时不扭曲分词器的合并结构和注意力模式，任何溢出部分会被截断至 \(L_{\text{in}}\)。输出长度也根据每个请求从 \([0.8 L_{\text{out}}, L_{\text{out}}]\) 均匀抽取。每个请求集与其内容哈希一起序列化，以便每个代理和基线都对字节相同的输入进行评分。关于请求采样的更多细节可以在附录 A.4 (https://arxiv.org/html/2607.20468#A1.SS4) 中找到。  

表 1：场景规范。\(L_{\text{in}}\) 和 \(L_{\text{out}}\) 是目标输入和输出长度（以令牌计），从 \([0.8L, L]\) 均匀抽取。请求来源于 LongBench v2 (Baiet al., 2025 (https://arxiv.org/html/2607.20468#bib.bib18))。  

### 3.3 门控  

评分应用两个门；任一门失败都会对该次运行进行惩罚。  

#### 质量门  
纯速度优化可能允许琐碎的漏洞，从而破坏模型的效用（例如激进的量化、剪枝层）。因此，我们要求优化后的服务器在种子固定的 500 题 MMLU-Pro (Wanget al., 2024 (https://arxiv.org/html/2607.20468#bib.bib19)) 子集上，使用 10 选项多项选择（标签 A–J）和贪婪解码，得分至少达到基线准确率的 \(\tau=95\%\)。关于阈值敏感性 \(\tau\) 的消融实验（附录 C.1 (https://arxiv.org/html/2607.20468#A3.SS1)）表明，最佳代理的身份和主要结论在不同阈值下是稳定的；在 \(\tau=0.95\) 时排名不变，在 \(\tau=0.97\) 时最多变化一个位置。  

#### 完整性门  
一个审查代理主动检查每次运行及其环境，以发现不允许的行为，例如……