为什么重要
InferenceBench 揭示了一个被忽视的事实：顶尖代码 Agent 在 ML 系统工程上仍然疲软。它把”开放式”做实——不是给出固定动作空间让 Agent 调参，而是让 Agent 在 2 小时内自主选择推理框架（vLLM / SGLang / TGI / TensorRT-LLM）、决定注意力后端、设计量化策略、调度 KV-cache。这是第一个衡量 Agent 真实工程决策能力而非”配方调优能力”的基准。
基准的核心发现是反直觉的：非 Agent 的传统搜索（Random / SMAC3 / TPE）在同等 2 小时预算下击败所有 Agent。原因在于 93.9% 的 Agent 最终都交付 vLLM 启动器，而 58.3% 的运行只启动了一个非默认配置——Agent 的”持续”不等于”自适应”。换言之，Agent 知道的已经够了，难的是真去跑、真去比、真留住有用的。
构建方式
- 固定底模：mistralai/Mistral-7B-Instruct-v0.3（避免模型能力成为混杂变量）
- 固定硬件：单 NVIDIA H100 80GB（标准化硬件预算）
- 固定时间：2 小时 wall-clock（避免无限计算）
- 4 个场景：
- A 输入敏感（prefill 延迟）：TTFT 指标
- B 输出敏感（decode 延迟）：TPOT 指标
- C 高负载吞吐：request/s 指标
- D 通用 all-in-one：上述三者的几何平均
- 15 个 Agent 配置：覆盖 Claude Code（Opus 4.5/4.6/4.7/4.8/Sonnet 4.5/4.6/Haiku 4.5/Fable 5）、Codex（GPT-5.1/5.2/5.3/5.4/5.5）、OpenCode（Gemini 3.1 Pro / Gemini 3.5 Flash / GLM-5 / Kimi K2.6）
- 质量门：MMLU ≥ 0.95× 基线（防止量化/投机解码破坏质量）
- 完整性审计：服务器可达性、reward hacking 检测
- 3 个种子对 × 4 场景 = 12 个评测条件，报告几何平均加速比
任务示例
任务起点：给 Agent 一个 2 小时时间盒的 H100 + Mistral-7B-Instruct-v0.3 目标：部署一个 OpenAI 兼容的推理服务器，最大化特定场景指标 关键决策点：
- 选 vLLM / SGLang / TGI / TensorRT-LLM / 自定义 kernel？
- 量化（FP8 / INT8 / INT4）还是保持 BF16？
- 注意力后端（FlashAttention-2 / FlashInfer / xFormers）？
- KV-cache layout（page size、block size）？
- 调度策略（continuous batching / chunked prefill / prefix caching）？
- 投机解码（draft model selection、acceptance threshold）？
评分：在新容器中重新评测提交的服务，确保不”作弊”。失败质量门/完整性门/可达性/低于 PyTorch 基线的运行记为 1.00×
关键发现
- Sonnet 4.6 8.08x 领先：在 15 个 Agent 配置中 Anthropic 中端模型反而比 Opus 4.6 (3.89x) 高 2.08×，可能因 Sonnet 在工具调用上更节制、更注重”成功提交”
- 非 Agent 搜索击败所有 Agent：SMAC3 / TPE / Random 在 vLLM 空间下 2 小时搜索超越所有 Agent；暴露 Agent 的”配方锁定”问题
- 93.9% 的 Agent 交付 vLLM：即使提示中显式提到 SGLang/TGI/TensorRT-LLM，Agent 仍然选择熟悉的 vLLM，记忆化优于探索
- 中位运行只启动 1 个非默认 vLLM 配置：2 小时预算下，Agent 多数时间花在测量/重启而非搜索
- 58.3% 的运行通过双门但只启动 1 个配置：通过 ≠ 适应
- 65.0% 通过质量门 + 完整性门，18.9% 未通过质量门，6.1% 触发完整性，10.0% 可达性/运行时失败
- GLM-5 (6.20x) 开源第一：智谱 GLM-5 在 OpenCode 框架下达到 6.20x，仅次于 Claude Sonnet 4.6
- Opus 4.7 (2.25x) 反常低：作为前沿模型表现远低于 Opus 4.6 (3.89x)，可能因 4.7 偏向更”防御性”配置选择
- GPT-5.5 低于 GPT-5.3 Codex：4.22x vs 5.48x (High) / 4.86x (Med)，新模型不一定在系统任务上更强
与传统基准的差异
| 维度 | SWE-bench Pro | InferenceBench |
|---|---|---|
| 任务空间 | 预定义 issue 列表 | 开放式决策 |
| 评测方式 | CI 通过率 | 几何加速比 |
| 关键能力 | 代码修复 | 系统工程决策 |
| 失败模式 | 测试不通过 | 启动崩溃 / 性能退化 |
| 是否能调参取胜 | 否（无参数可调） | 是（搜索已知 vLLM 配置即可） |
| 衡量目标 | 模型能力 | Agent 决策质量 |
局限性
- 4 个场景偏少，且都基于 vLLM 生态；SGLang/TensorRT-LLM 的潜力未被充分探索
- 2 小时预算对真实部署仍偏短，企业级部署往往需要数天调优
- 15 个 Agent 配置主要来自头部厂商，开源 Agent（SWE-agent / OpenHands / Aider）覆盖不足
- 加速比 vs PyTorch 朴素基线，可能不能完全反映生产环境价值（vLLM 已经是默认）
- MMLU 质量门对激进量化不敏感，可能放过部分质量退化
关联基准
- SWE-bench Pro：代码修复而非系统部署
- Terminal-Bench 2.0：终端任务但更广泛
- MLPerf Inference v6：传统硬件推理基准（不是 Agent）
- OSWorld 2.0：长程桌面操作 Agent
不足与展望
- 需要扩展到 SGLang / TensorRT-LLM 框架，避免 vLLM 单一生态
- 未来可能加入 4-bit / 2-bit 量化、专家并行（MoE）、speculative decoding 等高级场景
- “持续 2 小时”的设计可能与商业部署节奏脱节，需要 1 天 / 1 周版本
- 当前 15 配置主要来自头部实验室，独立第三方 Agent 平台（OpenHands / Cursor Background Agent）尚未充分参与